métrica

¿Sabes cómo y dónde encontrar cuellos de botella en vuestro flujo de trabajo? ¿Son permanentes? ¿Sabes cómo y dónde mejorar el flujo? ¿Cuál de los estados tiene más problemas? Si te asaltan preguntas sobre la mejora de procesos vente a jugar e interactuar conmigo en esta sesión práctica e introductoria en la que te llevarás nuevas herramientas con la que responder preguntas difíciles a partir de la observación de métricas y gráficos. Entre otras muchas cosas veremos: 1. Aging WIP 2. Liquidity 3. Net Process Flow 4. Jump Plot 6. Flow Time 7. Cumulative Flow Diagram 8. Histograms 9. Run Charts y más Por último nos adentraremos en el lado oscuro de las métricas veremos algunos ideas para gestionar su uso y minimizar el daño que nos podemos hacer con ellas. Toda métrica que adquiera suficiente relevancia, pasará a gestionarse en si misma, y se desconectará de la realidad subyacente que pretendía representar. Ley de Goodhart Pablo Grueso ------------- ¡Conoce Autentia! -Twitter: https://goo.gl/MU5pUQ -Instagram: https://lk.autentia.com/instagram -LinkedIn: https://goo.gl/2On7Fj/ -Facebook: https://goo.gl/o8HrWX

¿Sabes cómo y dónde encontrar cuellos de botella en vuestro flujo de trabajo? ¿Son permanentes? ¿Sabes cómo y dónde mejorar el flujo? ¿Cuál de los estados tiene más problemas? Si te asaltan preguntas sobre la mejora de procesos vente a jugar e interactuar conmigo en esta sesión práctica e introductoria en la que te llevarás nuevas herramientas con la que responder preguntas difíciles a partir de la observación de métricas y gráficos. Entre otras muchas cosas veremos: 1. Aging WIP 2. Liquidity 3. Net Process Flow 4. Jump Plot 6. Flow Time 7. Cumulative Flow Diagram 8. Histograms 9. Run Charts y más Por último nos adentraremos en el lado oscuro de las métricas veremos algunos ideas para gestionar su uso y minimizar el daño que nos podemos hacer con ellas. Toda métrica que adquiera suficiente relevancia, pasará a gestionarse en si misma, y se desconectará de la realidad subyacente que pretendía representar. Ley de Goodhart

Todos hemos oído la famosa frase: "What gets measured gets managed" y es muy cierta. Seguro que somos capaces de recordar al menos un caso en el que hemos visto tomar decisiones importantes sin disponer de datos suficientes... Para evitar este tipo de errores, muchas empresas y equipos fijan métricas o indicadores de performance (KPIs), otros siguiendo las últimas tendencias, las implementan a través de juegos o gamificación. En todos los casos el objetivo final es medir buscando siempre obtener la combinación perfecta que haga que el equipo esté motivado, sea más productivo y mejore de forma continua. Pero no es suficiente sólo con medir; medir por medir, medir a las personas... a veces es peor el remedio que la enfermedad, tan importante es implementar una métrica como saber quitarla a tiempo. Qué es lo bueno de una métrica? Sin lugar a dudas, la tendencia. Qué es lo malo de una métrica? Que nos puede dar información errónea, que puede dirigir a un equipo al objetivo incorrecto. Qué es lo feo de las métricas? Los trucos que se hacen para que el número salga y cumplir el objetivo. Desde nuestra propia experiencia del día a día queremos contar el resultado obtenido en distintos equipos usando las métricas más comunes del desarrollo de software ágil: velocidad, cycle time, flow efficiency, defect density, número de bugs....

Un día sin escribir una línea de código puede ser más productivo que una semana picando código sin parar. Nunca el número de líneas, métodos o clases debe considerarse como métrica de avance del proyecto, al menos, mirándolo desde una perspectiva general. El mejor código es aquel que nos ahorramos de escribir porque la funcionalidad …Leer Más - por Jummp

Si la visión que tienes del desarrollo de software está demasiado condicionada por los enfoques clásicos y por gestiones orientadas a procesos demasiado rígidas es posible que no estés de acuerdo con la siguiente reflexión de Ken Schwaber: “El software que funciona es la principal medida de progreso”. Lo demás son papeles y palabras (teniendo …Leer Más - por Jummp

Uno de los grandes problemas del desarrollo de software en la Administración Pública lo tiene la utilización generalizada del ciclo de vida clásico o en cascada, no hago referencia directa a MÉTRICA v.3 ya que la misma no deja de ser un ordenación particular de dicho ciclo de vida que además es lo suficientemente abierta …Leer Más - por Jummp

El puglin de Sonar Quality Index proporciona otra métrica agregada (resultado de otras métricas) para obtener un valor que indique la calidad del software. En este caso lo que se pretende es obtener un valor entre 0 y 10. Particularmente me gusta más SIG MM ya que se centra en la mantenibilidad que es lo …Leer Más - por Jummp

En muchas ocasiones el concepto de mantenimiento adaptativo se utiliza de forma incorrecta confundiéndose muy a menudo con el mantenimiento evolutivo, siendo dos tipos de mantenimiento que persiguen objetivos distintos. Lo mejor es recordar las definiciones que Métrica V.3, hace de cada uno de estos mantenimientos: – Mantenimiento evolutivo: “Incorporaciones, modificaciones y eliminaciones necesarias en …Leer Más - por Jummp

ACD es otra métrica que mide el acoplamiento utilizando en este caso un elemento más genérico como es el componente que se puede definir como una unidad de división de una determinada aplicación. En base a esta definición tan generalista se podría considerar componente un paquete, las unidades de compilación (.java) o directamente considerar exclusivamente …Leer Más - por Jummp

Otras métricas de calidad que resultan interesantes de estudiar están relacionadas con el cálculo de acoplamiento aferente (hacia dentro) y eferente (hacia afuera) de un paquete y la relación entre los mismos, dando lugar a una métrica resultado de ellas denominada inestabilidad de un paquete. Estas tres métricas fueron propuestas por Robert Cecil Martin aka …Leer Más - por Jummp