sprints - Las mejores prácticas para el concepto "hecho" de Scrum en JIRA
scrum tutorial español (9)
Trabajo en una pequeña empresa basada en servicios donde estamos empezando a implementar las prácticas de Scrum, y también estamos empezando a utilizar JIRA con greenhopper para el seguimiento de problemas. Nuestro equipo ha definido "hecho" como:
- codificado
- unidad probada
- integración probada
- revisado por pares
- qa probado
- documentación actualizada
Estoy tratando de averiguar si esto debería hacerse usando un problema separado para cada elemento en la lista anterior para cada "tarea", o si algunos de estos elementos deberían implementarse en el flujo de trabajo del ticket, o simplemente agrupándolos en Un tema es el mejor enfoque.
No estoy dispuesto a hacer estas subtareas de una tarea, ya que solo hay problemas de anidación de un nivel y me temo que hay un mejor uso para esa capacidad.
Tampoco estoy muy entusiasmado con la modificación del flujo de trabajo, ya que este enfoque ha demostrado ser una carga para nosotros en otros sistemas.
Si todos estos elementos son parte del mismo boleto, entonces me parece extraño porque es probable que el trabajo se distribuya entre varios miembros del equipo, y será difícil realizar tareas que sean menores de 16 horas e incluyan todas esas cosas.
Siento que entiendo todos los problemas, pero aún no sé cuál es la mejor solución.
¿Hay una mejor práctica? ¿O algunas opiniones fuertes?
y será difícil realizar tareas de menos de 16 horas que incluyan todas esas cosas.
Este es tu verdadero problema; Capacidad para dividir historias en pequeños segmentos verticales útiles de funcionalidad. Trabajar en esto hará que su equipo sea más ágil y le dará más flexibilidad a la OP.
Por el contrario, desglosar el trabajo por proceso / paso mecánico solo lo hará menos ágil y realmente no tiene ningún propósito útil. O has terminado o no has terminado; a nadie le importa si está completo y no ha sido probado, así que no se moleste en rastrearlo por hora ... es un desperdicio.
Reenfocarse en sus historias, no en tareas.
- codificado
- unidad probada
En mi humilde opinión, estos pertenecen juntos, ya que ambos deben ser manejados por la misma persona (preferiblemente TDD, lo que realmente hace que sea imposible separarlos).
- integración probada
En nuestro equipo, generalmente lo hace el mismo desarrollador, por lo que normalmente lo hacemos como parte de la tarea anterior. Otros equipos pueden hacerlo de manera diferente.
- comentado
¿Te refieres a los comentarios de código? Entonces, para mí, esto no merece una tarea separada. De lo contrario, por favor aclarar.
- revisado por pares
Una tarea separada para un desarrollador separado (o más).
- qa probado
Una tarea separada para los evaluadores / personal de control de calidad.
Yo agregaría documentación : puede que no siempre sea necesaria, pero a menudo sí lo es. De nuevo, debe ser una tarea separada, generalmente para el mismo tipo que hizo la implementación (pero no siempre).
Una de las principales preocupaciones de prácticamente todos los equipos de Scrum con los que he estado trabajando es asegurarse de que no se olvide nada importante de lo anterior. La partición en tareas distintas puede ayudar a esto. Entonces puedes ver claramente en tu cartera lo que queda por hacer. Agrupar todo esto en una sola tarea hace que sea fácil olvidarse de este o ese pequeño detalle. Para nosotros, lo más típico era olvidarse de la revisión de código y la documentación, esa fue la razón principal por la que convertimos estas tareas en tareas independientes.
Ciertamente no los anidaría, ya que son pasos comunes a cada tarea. Hacerles las subtareas solo aumentaría la complejidad y el motor del sistema. Estas me parecen etapas perfectas de flujo de trabajo.
Algo como Enviado-> Asignado-> Codificación-> Revisión-> Pruebas-> Finalizado.
Donde la codificación requiere "codificado", "unidad probada" e "integración probada" antes de pasar a Revisión, Revisión requiere Peer Review antes de pasar a Pruebas, Pruebas requiere control de calidad antes de pasar a Finalizar.
La única razón por la que esto sería complicado es si está permitiendo que Peer Review y las Pruebas se realicen en paralelo. Veo problemas para permitir eso, ya que si el código falla en la revisión por pares y luego se modifica, invalida el trabajo de prueba realizado por QA.
Listo define lo que significa el Equipo cuando se compromete a "hacer" un elemento de Product Backlog en un Sprint. Algunos productos no contienen documentación, por lo que la definición de "hecho" no incluye la documentación. Un incremento completamente “hecho” incluye todo el análisis, diseño, refactorización, programación, documentación y pruebas para el incremento y todos los elementos de Product Backlog en el incremento. Las pruebas incluyen pruebas de unidad, sistema, usuario y regresión, así como pruebas no funcionales como el rendimiento, la estabilidad, la seguridad y la integración.
Referencia: Scrum Guide - Escrito por Ken Schwaber y Jeff Sutherland (Inventors of Scrum)
Usted declara que está siguiendo "Scrum Practices". Me parece que solo estás usando algunas partes de Scrum Framework y no otras, ¿es cierto? En primer lugar, Scrum no es necesariamente una práctica, es un Framework, o usas el framework o no. Funciona sobre la base de inspeccionar y adaptar, por lo que, aparte de las reglas básicas del marco de Scrum, no hay nada en piedra, por lo que no obtendrá una respuesta exacta a su pregunta. La mejor manera de saber la respuesta es contratar a profesionales de Scrum con experiencia, y desarrolladores y evaluadores experimentados, y probar el plan anterior en su equipo de Scrum.
Recuerda siempre inspeccionar y adaptar. Hay tres puntos para la inspección y adaptación en Scrum. La reunión de Daily Scrum se utiliza para inspeccionar el progreso hacia la meta de Sprint y para hacer adaptaciones que optimicen el valor del siguiente día laboral. Además, las reuniones de Revisión y Planificación del Sprint se utilizan para inspeccionar el progreso hacia el Objetivo de Lanzamiento y para hacer adaptaciones que optimicen el valor del próximo Sprint. Finalmente, Sprint Retrospective se usa para revisar el Sprint pasado y determinar qué adaptaciones harán que el próximo Sprint sea más productivo, satisfactorio y placentero.
No dedique mucho tiempo a documentar o buscar una solución a un problema de Proceso dado porque la mayoría de las veces los problemas cambian más rápido de lo que cree, es mejor inspeccionar y adaptarse siempre que tenga al menos el conocimiento básico de scrum y está utilizando el marco de Scrum y no solo algunas prácticas similares a Scrum.
Lo hecho está hecho, tiene que ser todo lo que definió, sin embargo, tratarlos como pasos explícitos con un rastreador de errores puede tener el efecto secundario no deseado de alentar las divisiones dentro del equipo y lanzar cosas por el muro. Por lo tanto, los codificadores dirían que se hacen una vez que el ticket se marca como "codificado" y "se prueba en una unidad", los probadores cuando se marcan como probados, etc.
Esto es exactamente lo opuesto a lo que Scrum intenta hacer: todo el equipo se compromete a hacer las historias para que cumplan con la definición de "hecho" al final. Por lo tanto, aunque algunos de los elementos para lograrlo son los pasos, uno debe tener mucho cuidado al consolidar estos pasos en cualquier tipo de flujo de trabajo definido.
(Esto, por cierto, muestra muy bien por qué usar un rastreador de errores como herramienta de scrum es una mala idea. Esas son herramientas diferentes que deberían optimizarse para diferentes cosas, incluso si se enlazan a través de algunas API).
Lo importante es que usas la sub-tarea como tarea real; No como actividad de tarea principal. El rastreador de problemas está pensado principalmente para lo que está haciendo; No cómo estás y en qué orden.
Usamos dos tablas para este propósito. Tenemos una placa para el Desarrollo Sprint donde "Listo" está listo para la prueba. No puede ingresar a un sprint a menos que esté bien y verdaderamente listo para comenzar el desarrollo (todo el análisis realizado, las estimaciones realizadas, la gente sabe lo que se supone que deben hacer), hemos dicho todas las conversaciones, aunque digamos nuestras conversaciones tienden a ocurrir en los comentarios de JIRA dado al equipo distribuido) ... y usted sale cuando termina el desarrollo. Esa es la mejor manera de hacer un seguimiento de si nuestro equipo de desarrollo está logrando sus propios objetivos sin ser afectado por el control de calidad. Mientras tanto, el control de calidad utiliza un tablero de estilo Kanban y van desde "Listo para pruebas" (esta es su "tarea pendiente"), pasando por Pruebas hasta Listo para su lanzamiento.
Cambiamos a esto porque anteriormente teníamos todos estos pasos en una sola placa, y no estábamos "cumpliendo con nuestros compromisos" dentro de ningún sprint porque no había manera de desarrollar y probar todo en un solo sprint, donde tenemos que hacer una migración de código al entorno de control de calidad para que se realicen las pruebas finales, aunque las pruebas se realizan a lo largo del camino. Todavía estamos tratando de averiguar cómo hacer las cosas correctamente, por lo que puede que esta no sea la respuesta correcta y, sin embargo, parece que no es algo que hayas pensado, por lo que quizás funcione para ti.
Utilizamos subtareas.
Dado que la historia es un elemento compartido (todo el equipo de scrum trabaja en él), usamos las subtareas como "notas post-it" que permiten realizar un seguimiento de las tareas que los individuos necesitan abordar.
No requerimos que cada pequeña tarea sea representada como una subtarea.
No somos contadores, sino desarrolladores.
El acuerdo del equipo es que si no puede realizar una tarea de inmediato, simplemente anótelo como una subtarea de la historia. (Usando el plugin ágil, es realmente fácil). es decir. nunca tendremos sistemáticamente una subtarea ''crear prueba de unidad'', pero en algunas ocasiones, cuando alguien está luchando para que esa cerradura dinámica esté funcionando, verá esta subtarea emergente en la historia. Tenerlo allí permite al equipo discutirlo durante el scrum.
Si desea generar la lista de verificación automáticamente, consulte la subtarea de creación en el complemento de transición. https://studio.plugins.atlassian.com/wiki/display/CSOT/Jira+Create+Subtask+for+transition Le permite agregar automáticamente las subtareas cuando la historia se ha confirmado.
BTW - JIRA es más que un rastreador de errores. Lo estamos utilizando en una amplia variedad de aplicaciones, incluida la gestión de nuestra actividad de sprint. (como socio de Atlassian, soy parcial :-).
Francis
Utilizamos un sistema bastante similar en JIRA y tengo una pregunta abierta aquí y en los tableros de Atlassian haciendo una pregunta muy similar. Tenemos una definición similar de hecho. Creamos la historia principal en forma descriptiva, es decir, "El texto de la leyenda en el gráfico de pérdidas y ganancias se superpone". Luego definimos sub-tareas que son de tipo ''técnico'' o ''proceso''. Las tareas técnicas son el trabajo real de implementar la historia "Búsqueda de posibles causas en el sitio del proveedor", "Implementar corrección en la clase de infografía". Los elementos del proceso incluyen ''Revisión por pares'', ''Hacer compilación'', ''Pruebas de control de calidad'', ''Combinar''. Como se señaló en un comentario, es posible que el control de calidad se realice antes o durante la Revisión por pares. Como parte del proceso de Scrum, tenemos control de calidad casi todo el tiempo (son parte del equipo), a veces se sientan con el desarrollador, a veces hacen que las ''compilaciones de contrabando'' se ejecuten en un entorno de prueba. Esta es una prueba exploratoria y se nos considera parte del proceso de codificación. La subtarea para ''Pruebas de control de calidad'' es para pruebas de integración y regresión y es una validación final de toda la historia una vez que se completa la revisión por pares. En ese momento, el equipo de control de calidad ya tiene un plan de prueba completo que elaboraron durante las pruebas exploratorias y, por lo general, es solo una cuestión de ejecutar el plan y "verificarlo".
Hemos llegado a este punto después de ejecutar sprints durante un año y hacer cambios durante la retrospectiva. Estoy abierto a sugerencias, ya que creo que una de las desventajas de la retrospectiva es que puedes agruparte, pensar en ti mismo en una dirección con pocas esperanzas de retroceder y considerar un camino diferente.