He trabajado principalmente en proyectos que siguieron el modelo Waterfall y tuvimos muchas listas de verificación y auditorías durante el SDLC que aseguraron que pudiéramos cumplir con los objetivos de calidad.
Ahora trabajo en una organización donde la mayoría de los proyectos usan Scrum o Kanban. Muchas veces los requisitos/historias son proporcionados directamente por los usuarios/clientes. Hay muy poca priorización que hacemos con el cliente. El tamaño del proyecto varía de 2 desarrolladores a 20 desarrolladores. Las estimaciones dadas por los desarrolladores para sus historias a veces pasan por alto las pruebas unitarias, la revisión del código y el esfuerzo de reelaboración. Los he educado y ahora han comenzado a estimarlo correctamente.
¿Qué procesos puedo introducir para que los parámetros de calidad como la tasa de inyección de defectos, la efectividad de la revisión del código y la efectividad del diseño del software puedan estar bajo control? Creo que muchos desarrolladores confunden el modelo Agile/iterativo con el desarrollo de atajos. Así que educarlos es lo primero que estoy haciendo.
Me gustaría preguntar a los expertos aquí si hay alguna regla general que pueda usar o si hay mejores prácticas que pueda implementar para que todos los proyectos sigan un proceso similar, los proyectos sigan un camino más predecible, la cantidad de historias entregadas sea mayor. y los parámetros de calidad se pueden lograr.
Creo que en los métodos ágiles, probablemente querrá un conjunto diferente de métricas de calidad para realizar un seguimiento.
En un proyecto ágil, especialmente en lo que respecta al diseño, el código y las actividades de prueba, es altamente iterativo y es posible que no haya una separación clara de estas actividades, por lo que las métricas basadas en fases (que miden la efectividad del diseño y las revisiones de código, por ejemplo) se vuelven duro. Además, dado que las pruebas generalmente se realizan de forma concurrente y continua, no creo que obtenga curvas típicas de llegada de defectos.
Creo que querrá tener en cuenta el Manifiesto Ágil al desarrollar nuevas métricas para realizar un seguimiento de la calidad. Específicamente, el Manifiesto Ágil favorece "individuos e interacciones" y "colaboración con el cliente". También querrá tener en cuenta los Principios detrás del Manifiesto Ágil , especialmente el primero: "nuestra mayor prioridad es satisfacer al cliente a través de la entrega temprana y continua de software valioso".
Su primera métrica debe ser una de satisfacción del cliente. Una buena medida inicial serían los defectos informados por los clientes y usuarios finales. Si está rastreando la gravedad o la prioridad informada, esto podría ser parte de esa medición. También puede realizar un seguimiento del número de iteraciones para resolver los defectos (probablemente en función de la prioridad o la gravedad). Este tipo de métrica se relaciona con el tiempo de respuesta del defecto (tiempo entre el informe y la verificación) o el tiempo de respuesta del defecto (el equipo de desarrollo resuelve los defectos verificados). Incluso podría crear objetivos en torno a estos puntos de datos para mejorar sus actividades de calidad hasta el punto de 0 problemas "significativos" (según su definición de "significativo") informados por los clientes en los lanzamientos.
Una buena métrica ágil para la satisfacción del cliente posiblemente sea la cantidad o el porcentaje de historias de usuario que se aceptaron al final del sprint. Idealmente, debe terminar todas las historias planificadas y todas las historias terminadas serían aceptadas. Sin embargo, ese no es siempre el caso.
Dado que también está utilizando Kanban, el seguimiento de una distribución de gravedad (algo que va desde defectos estéticos hasta problemas de bloqueo) y distribución de prioridad (algo que va de menor a mayor) junto con el carril en el que se encuentra el elemento de trabajo puede generar datos interesantes. Por ejemplo, una vez que un desarrollador dice que una historia o tarea se completó con el desarrollo, no debe haber problemas de bloqueo o de alta prioridad en ella. El seguimiento de que una gran cantidad de artículos están llegando a la prueba de aceptación con defectos por encima de una cierta gravedad o prioridad podría desencadenar acciones.
Un poco más cerca del equipo de desarrollo, una buena métrica puede ser la cobertura de prueba automatizada. Los métodos ágiles tienden a favorecer la integración continua, y las pruebas automatizadas de unidad, integración, sistema y regresión están bien soportadas en este tipo de entorno. La cobertura de seguimiento, especialmente en código nuevo, puede ser útil. Por supuesto, la cobertura de la prueba no es una métrica de calidad (consulte también: Cómo hacer un uso indebido de la cobertura del código) ya que no dice qué tan buenas son sus pruebas, pero puede usarlo con otros informes de defectos encontrados durante las actividades de prueba o posteriores al lanzamiento para saber qué tan bueno es. Sin embargo, puede usarlo como una verificación rápida para asegurarse de que se están escribiendo algunas pruebas para el código nuevo y que, a medida que se encuentran problemas, se escriben pruebas para incluirlas en conjuntos de pruebas para probar el problema y luego que el problema se ha resuelto. .
Desde la perspectiva de los requisitos, las historias traídas al sprint deben entenderse relativamente bien y en qué trabajará. Aunque Agile reconoce el hecho de que los requisitos pueden cambiar y deben aceptar el cambio, por lo general no desea cambios importantes en las historias que forman parte de la iteración actual. Probablemente debería querer medir la volatilidad de las historias que incorporó al sprint: una vez que pasan por el proceso de preparación y son aceptadas por el equipo, realice un seguimiento de la cantidad de cambios en algún aspecto de la historia (incluidas las historias que se agregan o remoto). La adición o eliminación de una historia es visible en un gráfico de avance o avance, pero es posible que los cambios en una historia no se reflejen allí.
Aparte de los requisitos, me preocupa cuando dice que los usuarios y el cliente proporcionan directamente los requisitos y las historias y se establece muy poca priorización con el cliente. Si no tiene un usuario o cliente en el sitio para actuar como propietario del producto , debe haber una persona en su equipo que pueda actuar en esta capacidad y tenga una comprensión sólida de las necesidades y deseos de los usuarios y el cliente. El propietario del producto debe ser responsable de priorizar las historias y proporcionar criterios de aceptación claros. Tener historias priorizadas y criterios de aceptación claros será visible en medidas como la volatilidad de los requisitos y los defectos descubiertos después de un lanzamiento.
Aunque agrega gastos generales, si está trabajando en un contrato que ya requiere un seguimiento del tiempo, considere realizar un seguimiento del tiempo en relación con ciertas tareas. Depende de cómo divida su trabajo en tareas, pero si tiene que realizar un seguimiento de las horas trabajadas, puede realizar un seguimiento del costo de la calidad. Lo que debe buscar es cuánto tiempo dedica a escribir y ejecutar pruebas (manuales y automatizadas), revisiones por pares de diseños o códigos, y tiempo de reelaboración de diseños o códigos debido a pruebas fallidas. Por supuesto, tenga cuidado de que esto no agregue muchos gastos generales; puede que no sea adecuado para proyectos que no requieren seguimiento de tiempo.
Desde la perspectiva de la calidad del proceso, examine qué tan buenas son sus estimaciones. Es un poco más difícil con los puntos de la historia por historia, pero puede realizar un seguimiento de su velocidad general a lo largo de los sprints. Después de algunas iteraciones, debería poder decir constantemente cuántos puntos de la historia puede completar en un solo sprint y luego alcanzar ese número (tal vez con algunas variaciones menores). Sus gráficos de trabajo pendiente y el seguimiento de la velocidad pueden revisarse a lo largo del tiempo para asegurarse de que está analizando y ejecutando correctamente sus elementos de trabajo.
Tengo una última palabra de precaución. Recomendaría adoptar los principios de Lean Software Development . Asegúrese de que las medidas y métricas que recopile realmente agreguen valor al cliente, al equipo o a la organización. Cuando sus métricas o indicadores muestren un problema, empodere al equipo para que tome decisiones sobre cómo avanzar y realizar acciones correctivas.
jmort253