Breaking

Post Top Ad

Your Ad Spot

viernes, 6 de septiembre de 2019

Estrategias para mejorar sus retrospectivas de Sprint con datos


La mayoría de los equipos ágiles realizan retrospectivas de sprint al menos una vez al mes, para iterar y mejorar su proceso de desarrollo de software y flujo de trabajo. Sin embargo, muchos de esos mismos equipos confían solo en sus sentimientos para "saber" si realmente han mejorado. Pero necesita un sistema de referencia imparcial si desea comparar cómo fueron dos sprints. 
Dependiendo de en qué se esté enfocando, hay métricas que podrían interesarle. Por ejemplo, si su equipo usa la estimación, hacer un seguimiento de cómo esas estimaciones pueden ser realmente valiosas y comparar la varianza entre sprints podría proporcionar una métrica de este tipo. . 
En este artículo, no me enfocaré en las métricas que son el resultado de su equipo de ingeniería, sino más bien en los indicadores que muestran la salud de la colaboración de su equipo, lo que impactará directamente el resultado. Puede valer la pena considerarlos durante tus retrospectivas de sprint. 
Este artículo es en realidad un extracto de  la guía avanzada de métricas de ingeniería de software . Independientemente de las métricas que elija utilizar, debe seguir algunas reglas si alguna vez desea utilizar métricas de ingeniería de una manera no tóxica y eficiente. Para más información sobre ese tema, recomendaría leer  este artículo .
Comencemos con una revisión de qué son las métricas de ingeniería de software y cuáles no.

¿Qué son las métricas de ingeniería de software?

En software, hay 2 categorías de métricas y usamos diferentes nombres para ellas:
Parece que las métricas de ingeniería de software , también conocidas como métricas de desarrollo de software o rendimiento de entrega de software, cada equipo tiene un nombre diferente para ellos. Lo importante aquí es que esos indicadores miden cómo se está construyendo el software y la productividad del equipo de ingeniería. Las métricas de rendimiento del software o la aplicación  son las métricas del software entregado, el tiempo de respuesta de la aplicación, etc. NewRelic suele ser uno de los principales proveedores de dichas métricas. También podría pensar en esto en términos de métricas de satisfacción del cliente (puntaje neto del promotor típicamente). 
En esta guía, nos estamos centrando en el primer conjunto de métricas. Esos son los que ayudan a una organización a escalar y eso realmente afectará el segundo conjunto, que es uno de los resultados finales del trabajo realizado por el equipo.
Para comprender las métricas de ingeniería de software, necesitamos comprender los objetivos principales detrás del seguimiento y análisis:
Determine la calidad y la productividad del proceso actual de entrega de software e identifique las áreas de mejora; prediga la calidad y el progreso de los proyectos de desarrollo de software; administre mejor las cargas de trabajo y las prioridades entre los equipos y los miembros del equipo.
En general, las métricas de ingeniería ayudarán a los equipos a aumentar el retorno de la inversión en ingeniería, al ofrecer una evaluación del impacto de cada decisión en proyectos, procesos y objetivos de rendimiento.

Métricas de proceso o flujo de trabajo

1. Lead Time  and Cycle Time
El tiempo de  entrega es el período de tiempo entre el comienzo del desarrollo de un proyecto y su entrega al cliente. El historial del tiempo de entrega de su equipo de desarrollo de software puede ayudarlo a predecir con un mayor grado de precisión cuándo un elemento podría estar listo. Estos datos son útiles incluso si su equipo no proporciona estimaciones, ya que las predicciones pueden basarse en los plazos de entrega de proyectos similares.
Si desea ser más receptivo con sus clientes, trabaje para reducir su tiempo de entrega, generalmente simplificando la toma de decisiones y reduciendo el tiempo de espera. El tiempo de entrega incluye el tiempo del ciclo.
El tiempo de ciclo  describe cuánto tiempo lleva cambiar el sistema de software e implementar ese cambio en la producción. Los equipos que utilizan la entrega continua pueden tener tiempos de ciclo medidos en minutos o incluso segundos en lugar de meses. 
¿Cuándo usarlos?
Si su prioridad es implementar la entrega continua, o hacer que su proceso sea más ágil e implementar en la producción lotes más pequeños más frecuentes, estas dos métricas serán muy útiles. Dentro del plazo de entrega, también podría profundizar un poco más para comprender dónde se pasa la mayor parte del tiempo. 
2. Deployment Frequency 
El seguimiento de la frecuencia con la que se implementan es una buena métrica de DevOps. En última instancia, el objetivo es hacer implementaciones más pequeñas con la mayor frecuencia posible. La reducción del tamaño de las implementaciones facilita la prueba y el lanzamiento.
La frecuencia con la que se implementa en QA o entornos de preproducción también es importante. Debe implementar temprano y con frecuencia en el control de calidad para garantizar el tiempo para las pruebas. Encontrar errores en el control de calidad es importante para mantener   baja la tasa de escape de defectos . Pero es posible que desee contar las implementaciones de producción y no producción por separado.  
¿Cuándo usarlo?
Esta métrica es un buen complemento para los tiempos de avance y ciclo, en el sentido de que muestra sus resultados. 
3. Commit Frequency or Active Days
La frecuencia de compromiso y los días activos sirven para los mismos propósitos. Un día activo es un día en el que un ingeniero contribuyó con código al proyecto, que incluye tareas específicas como escribir y revisar el código. 
Esas dos métricas alternativas son interesantes si desea introducir una mejor práctica para comprometerse todos los días. También es una excelente manera de ver los costos ocultos de las interrupciones. Las tareas sin codificación, como la planificación, las reuniones y la búsqueda de especificaciones son inevitables. Los equipos a menudo pierden al menos un día cada semana por estas actividades. El monitoreo de la frecuencia de confirmación le permite ver qué reuniones tienen un impacto en la capacidad de su equipo para impulsar el código. Es importante tener en cuenta que  empujar el código es en realidad la forma principal en que su equipo proporciona valor a su empresa. 
Los gerentes deben esforzarse por proteger la atención de su equipo y garantizar que la sobrecarga del proceso no se convierta en una carga.
¿Cuándo usarlos?
¿Has oído "Cometer a menudo, perfeccionar más tarde, publicar una vez"? Si no se compromete y luego hace algo mal pensado, puede tener problemas. Commits es el denominador común para la colaboración dentro de su equipo. Por lo tanto, si empuja su flujo de trabajo para comprometerse con más frecuencia de lo que lo hace actualmente el equipo, podría ser útil realizar un seguimiento de esta métrica. Además, como se mencionó anteriormente, si desea comprender el impacto de las interrupciones, esta métrica podría ser un buen punto de partida.
4. Pull Requests-Related Velocity
Hay varias métricas que pueden ser interesantes para usted.
El número de solicitudes de extracción abiertas por semana El número de solicitudes de extracción fusionadas por semana El tiempo promedio  de fusión. Alguna alternativa podría ser el porcentaje de solicitudes de extracción fusionadas en un tiempo determinado. Esto es algo equivalente al tiempo de ciclo (tiempo que tarda el código en pasar desde la confirmación hasta la implementación: en el medio, podría pasar por pruebas, control de calidad y puesta en escena, dependiendo de su organización). Es una métrica muy interesante que le muestra qué obstáculos encuentra en su flujo de trabajo.
¿Cuándo usarlo?
Estas métricas podrían darle una idea del rendimiento constante de su equipo de ingeniería. Por ejemplo, si ese número no aumenta cuando contrata a más personas, puede haber un problema relacionado con un nuevo proceso o una deuda técnica que debe abordarse. Sin embargo, si aumenta demasiado rápido, es posible que tenga un problema de calidad. 
5. Work In Progress (WIP)
Work in Progress es el número total de tickets que su equipo ha abierto y en los que está trabajando actualmente. Es una medida objetiva de la velocidad de un equipo que es similar al rendimiento, como un indicador en tiempo real (en lugar de uno rezagado).
Esta métrica es útil para entender la carga de trabajo actual de un equipo como una tendencia. Idealmente, el número se mantendrá estable con el tiempo, ya que un aumento en WIP significa que su equipo enfrenta bloqueadores / cuellos de botella que no se están abordando (a menos que haya agregado miembros del equipo, por supuesto). WIP también es un método para identificar procesos ineficientes.
También puede considerar crear una métrica que divida WIP por la cantidad de contribuyentes para obtener una cantidad promedio de WIP por desarrollador. Idealmente, este número estará cerca de una relación uno a uno. 
¿Cuándo usarlo?
Esta métrica ayuda a evitar el agotamiento y aumentar la eficiencia, ya que se ha demostrado que trabajar en una cosa a la vez mejora el enfoque. 
6. Commit or Pull Request Risks
Puede determinar los riesgos en una solicitud de confirmación o extracción mediante:
La cantidad de código en el cambio Qué porcentaje del trabajo se edita en el código antiguo El área de superficie del cambio (piense en 'número de ubicaciones de edición') El número de archivos afectados La gravedad de los cambios cuando se modifica el código antiguo Cómo este cambio se compara con otros del historia del proyecto
Muestra la cantidad de reflexión y trabajo que se ha realizado en los commits y, por lo tanto, el impacto potencial en el producto, si se implementa sin revisión de código. 
¿Cuándo usarlo?
El monitoreo de un riesgo promedio de solicitud de confirmación o extracción lo ayuda a comprender cómo funciona su equipo y si debe esforzarse por cambios de código más frecuentes y simples.
Tenga en cuenta que algunas métricas pueden no haber aparecido en la lista porque no eran lo suficientemente populares o solo se aplicarían en ciertos casos (como las estimaciones). Traté de centrarme principalmente en las métricas que podrían ser comunes a todos los equipos. 
Algunas métricas que pueda tener en cuenta también podrían ser parte de  métricas relacionadas a la velocidad  y  las métricas relacionadas con la calidad  que me dirijo en otros artículos. 
Déjame saber lo que piensas, si me he perdido alguno. El objetivo final es crear una lista completa de las mejores prácticas relacionadas con las métricas de ingeniería de software para ayudar a los equipos a mejorar sus propios procesos.
Finalmente, si está interesado en capacitar a su equipo con datos de ingeniería de software para impulsar una mejor colaboración y toma de decisiones, eche un vistazo a la plataforma de administración de ingeniería de software que estamos construyendo en  Anaxi  que reúne sus sistemas, datos y personas para este propósito. .

No hay comentarios.:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

Post Top Ad

Your Ad Spot

Páginas