Un anillo para gobernarlos a todos
Jrtolkien
“Solo puedes controlar lo que se puede medir”
P. DruckerCuando se trata de métricas, me vienen a la mente docenas, si no cientos, de diferentes opciones.
¡Qué medidas no se han inventado!
Pero el problema es que, cuando miras estas bellas imágenes, a menudo es completamente incomprensible lo que significan.
Y, en general, ¿no está completamente claro si estas métricas se eligieron correctamente o si valdría la pena mirar otras completamente diferentes?
Quiero algún tipo de métrica, de tal manera que lo miré, y todo se volvió claro de inmediato.
¿Pero existe? ¿O no hay magia?
Echemos un vistazo y veamos un ejemplo específico ...
A menudo, todo lo que tenemos es solo un cierto conjunto de datos de entrada con los que no está muy claro qué hacer.
Jira y sus tareas
Imagine que su empresa utiliza el rastreador de tareas de Jira y que todos los desarrolladores están obligados a marcar eventos de llevar tareas al trabajo y sus soluciones.
Puede descargar las tareas de Jira, pero ¿qué hacer a continuación?
Una buena idea en esta situación es pensar exactamente qué es lo que quiere administrar y qué resultado quiere lograr.
Lea, por ejemplo, el artículo "
Información sobre las métricas: según tengo entendido, cuáles son las métricas y cuál es su principal encanto "
Y si agregamos aquí también los libros "Lean Analytics", "Running Lean" y Tao Toyota, entonces queda claro que en el caso de Jira es más correcto administrar y medir el tiempo de entrega de la funcionalidad desarrollada para el baile de graduación.
Por lo tanto, se elige el objetivo: queremos medir el tiempo de entrega del software, pero puede hacerlo de cien maneras diferentes. Por ejemplo, puede medir la duración de cada uno de los pasos de desarrollo y también agregar a esta medición la pérdida de tiempo para esperar, corregir defectos, redescubrir, etc. Incluso se puede llamar a vskidku entre 50 y 70 métricas diferentes relacionadas con el desarrollo de software.
Como ser ¿Existe esa única métrica por la cual una mirada puede entender todo?
Si vio con sus propios ojos las docenas de métricas que se analizan anteriormente, entonces sé su respuesta de antemano: dirá: ¡No! Y entonces quiero ...
Me gustaría una métrica de este tipo, una mirada en la que uno pudiera entender cuán exitosamente se está moviendo el desarrollo y si es necesario hacer algo adicional con él.
Sorprendentemente, parece que hay una métrica digna que puede reclamar con seguridad el título de
Único .
Echemos un vistazo más de cerca.
Existe un informe en Jira como el "Diagrama de flujo total" ...
"Stop-stop-stop ... Todo el mundo lo conoce, tú dices, no encontraré nada nuevo aquí"
En general, sí, el informe es bien conocido por todos, pero aún así, echemos un vistazo con un poco más de detalle. Le aseguro que encontrará varias sorpresas "agradables".
Así es como se ve generalmente:
Algunas rayas ¿Por qué son ellos? Por qué ¿Qué quieren decir? Y esto es lo que ...
Barra roja oscura: el número de tareas completadas sobre una
base acumulativa . El azul es el número de tareas en el trabajo y el amarillo son las nuevas tareas registradas en el trabajo atrasado.
El total acumulativo es cuando las tareas realizadas siempre se agregan a la cantidad de tareas realizadas anteriormente.
Por ejemplo, imagine que realizó 2 tareas anteayer. En el gráfico de anteayer se observará: 2.
Ayer hiciste 3 tareas más. El siguiente punto en el gráfico será 2 (ayer) +3 (ayer) = 5.
Y hoy has hecho una tarea más. El punto de hoy en el gráfico será igual a 2 (ayer) +3 (ayer) +1 (hoy) = 6
Es decir el horario aumentará todo el tiempo.
Entonces, si coloca en el gráfico la cantidad de tareas realizadas, la cantidad de tareas en el trabajo y las nuevas tareas, entonces puede extraer la métrica One One and Only.
Consideremos un ejemplo real (descarga de Kibana y Elasticsearch):
¿Ves?
De hecho, podemos calcular la velocidad (o productividad) del desarrollo. 200 nuevas tareas completadas en 17 días. A partir de aquí, obtenemos que la velocidad de desarrollo actual es de 11.76 tareas / día, es decir
0.085 días por
tarea .
Son juzgados por el horario, el número de tareas en el trabajo, el área azul, no cambia (el ancho de la tira es casi el mismo en todas partes), es decir Podemos suponer que la velocidad de desarrollo es constante, en contraste con el número de nuevas tareas.
A la velocidad de desarrollo actual, 800 nuevas tareas creadas el 17/06/2018 se completarán solo después de 68.03 días.
Ok? En mi opinión, no realmente.
Hablando? Definitivamente!
Aquí hay otro ejemplo del mundo real (informe Jira). Este es el cronograma de ejecución del ticket por parte del soporte técnico:
Del mismo modo, calculamos la productividad del servicio de soporte: 2.7 tareas / día.
Hay algo por lo que luchar
No es suficiente saber la velocidad actual. También debe comprender el valor objetivo, es decir ver por qué luchar.
Al comprender la velocidad de una persona, puede calcular cuántas personas necesitará el servicio de soporte para realizar el número objetivo de tareas o aumentar la productividad actual.
El servicio de soporte emplea a 15 personas. Resulta que hay 0,18 tareas / día por persona.
Suponga que desea aumentar la velocidad de ejecución y hacer que el servicio pueda resolver no 2.7 tareas por día, sino 10 (valor objetivo).
Una persona realiza 0,18 tareas por día, lo que significa que 56 personas realizarán 10 tareas.
Bueno, o como una opción, puede aumentar la velocidad de una persona.
A una velocidad de 1 tarea por día, para 10 tareas ya no necesitará 56 personas, sino solo 10.
Gestionamos el tiempo de entrega
Resulta que la métrica le permite, de hecho, afectar el tiempo de entrega.
Al comparar el rendimiento actual con el valor objetivo, puede comprender cuántas veces necesita acelerar el proceso.
Al variar los parámetros que conforman la productividad (el número de personas y la velocidad de su trabajo), puede controlar el tiempo total de entrega.
¿Dónde más es esto aplicable?
De hecho, los análogos de la métrica se pueden ver en muchas áreas.
Tome DevOps por ejemplo. DevOps se usa para acortar el intervalo de tiempo entre la creación de un kit de distribución y su implementación en una fiesta de graduación, es decir. aquí, como en los ejemplos anteriores, debe controlar el tiempo de entrega.
Obviamente, la métrica también es ideal para DevOps. Solo cuente cuántas distribuciones (ensamblajes) han alcanzado el baile de graduación en un momento determinado y obtenga el rendimiento actual de su canalización.
En principio, la misma métrica se puede utilizar en áreas relacionadas con el dinero.
Por ejemplo, para una tienda en línea, uno podría calcular de manera similar la cantidad de pedidos por un tiempo determinado. Toda la pregunta es, ¿las tiendas realmente lo necesitan?
Conclusión
Como puede ver, One Only Universal Metric todavía tiene derecho a la vida, al menos en el campo del desarrollo de software y en las divisiones de servicio (servicio de soporte técnico).
Es fácil de calcular, contiene significado y se puede usar para comparar con el valor objetivo.
Por supuesto, no se puede usar sin pensar. Antes de comenzar la implementación, piénselo, pero realmente lo necesita.
¿Qué opinas sobre la métrica universal?
¿Qué métrica usas como universal?