Mejores prácticas para el concepto "hecho" de Scrum en JIRA

Question

Trabajo en una pequeña empresa basada en servicios donde estamos comenzando a implementar prácticas de Scrum, y también estamos comenzando a usar JIRA con greenhopper para el seguimiento de problemas. Nuestro equipo ha definido "hecho" como:

• codificado
• unidad probada
• integración ensayados
• revisada por pares
• qa ensayados
• documentación actualizada

estoy tratando de averiguar si esto se debe hacer usando un tema separado para cada elemento en el anterior l ist para cada "tarea", o si algunos de estos elementos deben implementarse en el flujo de trabajo del ticket, o si simplemente agruparlos en un solo problema es el mejor enfoque.

No estoy dispuesto a hacer estas subtareas de una tarea, ya que solo hay un nivel de anidamiento de problemas y me temo que hay un mejor uso para esa capacidad.

Tampoco estoy demasiado 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 forman parte del mismo ticket, me parece extraño porque es probable que el trabajo se extienda entre varios miembros del equipo, y será difícil realizar tareas menores de 16 horas que incluyan todos esas cosas.

Siento que entiendo todos los problemas, pero hasta el momento no sé cuál es la mejor solución.

¿Existe una mejor práctica? ¿O algunas opiniones fuertes?

Answer 1

• codificado unidad
• probado

mi humilde opinión estos pertenecen juntos, ya que tanto debe ser manejado por la misma persona (preferiblemente TDD, lo que realmente hace que sea imposible separar estos).

• integración probada

En nuestro equipo, esto se suele hacer por el mismo promotor, por lo que normalmente lo hacen como parte de la tarea anterior. Otros equipos pueden hacerlo de manera diferente.

• comentó

¿Se refiere a los comentarios de código? Entonces, para mí, esto no merece una tarea separada. De lo contrario, aclara.

• con comité de

una tarea separada para un desarrollador independiente (o más).

• qa probado

Una tarea separada para el personal de probadores/QA.

Añadiría documentación - no siempre es necesario, pero a menudo lo es. Nuevamente, debería ser una tarea separada, típicamente para el mismo tipo que realizó la implementación (pero no siempre).

Una preocupación principal para prácticamente todos los equipos Scrum con los que he estado trabajando hasta ahora es asegurarme de que no se olvide nada importante de lo anterior. Particionar en tareas distintas puede ayudar a esto. Entonces puede ver claramente en su trabajo atrasado lo que queda por hacer. Unir todos estos elementos en una sola tarea hace que sea fácil olvidarse de este o aquel pequeño detalle. Para nosotros, era más típico olvidarse de la revisión y documentación del código, esa fue la razón principal por la que convertimos esto en tareas independientes.

Answer 2

Ciertamente no los anidaría, ya que son pasos comunes para cada tarea. Convertirlas en subtareas simplemente aumentaría la complejidad y el estándar del sistema. Me parecen etapas perfectas de flujo de trabajo.

Algo así como Enviado-> Asignado-> Codificación-> Revisión-> Pruebas-> Terminado.

Donde la codificación requiere "codificación", "unidad probada" y "prueba de integración" antes de pasar a revisión, revisión requiere revisión por pares antes de pasar a la prueba, la prueba requiere prueba de calidad antes de pasar a finalizado.

La única razón por la que esto sería complicado es si permite que la Revisión por pares y las Pruebas se realicen en paralelo. Veo problemas para permitir eso, ya que si el código no se revisa por pares y se modifica posteriormente, invalida el trabajo de prueba realizado por QA.

Answer 3

Hecho está hecho - tiene que ser todo lo que ha definido, sin embargo, tratándolos como pasos explícitamente con un rastreador de errores puede tener el efecto secundario no deseado de alentar divisiones dentro del equipo y tirar cosas al otro lado de la pared. Así codificadores afirmarían que se realizan una vez billete está marcado "codificado" y "unidad de prueba", los probadores de una vez marcado probado etc.

Esto es exactamente lo contrario de lo que pretende hacer Scrum - la toda 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 que se deben lograr son en realidad los pasos, uno debe tener mucho cuidado al consolidar estos pasos en cualquier tipo de flujo de trabajo definido.

(Esto muestra por cierto muy bien por qué utilizar un gestor de fallos como una herramienta scrum es una mala idea Esos son diferentes herramientas que deben ser optimizados para diferentes cosas -. Incluso si unidos entre sí a través de algunas API.)

Answer 4

y será difícil hacer tareas que sean menos de 16 horas que incluyan todas esas cosas.

Este es su verdadero problema; capacidad de dividir historias en pequeñas porciones verticales útiles de funcionalidad. Trabajar en esto hará que su equipo sea más ágil y le dará más flexibilidad al PO.

Por el contrario, dividir el trabajo por proceso/paso mecánico solo lo hará menos ágil y realmente no sirve para nada. O has terminado o no lo estás haciendo; a nadie le importa si eres dev completo y no probado, así que no te molestes en rastrearlo por hora ... es un desperdicio.

Reenfoque en sus historias, no en las tareas.

Answer 5

Utilizamos subtareas.

Dado que la historia es un elemento compartido (todo el equipo de scrum trabaja en ello), utilizamos las subtareas como 'las notas de post-it' que permiten rastrear las tareas que las personas deben abordar.

No es necesario que cada pequeña parte de la tarea se represente como una subtarea.

No somos contadores, sino desarrolladores.

El acuerdo del equipo es que si no puede realizar una tarea inmediatamente, simplemente anótela como una subtarea de la historia. (Usando el plugin ágil, es realmente fácil). es decir. nunca tendremos sistemáticamente una subtarea 'crear prueba unitaria', pero en algunas ocasiones, cuando alguien está luchando por poner en funcionamiento esa dínamoqueta, verá esta subtarea emergente en la historia. Tenerlo allí permite que el equipo lo discuta durante el scrum.

Si desea generar la lista de verificación automáticamente, mire 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 se ha confirmado la historia.

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

Answer 6

Done define lo que significa que el equipo cuando se compromete a “hacer” un elemento de la Pila de Producto en un Sprint. Algunos productos no contienen documentación, por lo que la definición de "hecho" no incluye 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 todas las posiciones de Producto pendientes en el incremento. Las pruebas incluyen pruebas de unidad, sistema, usuario y regresión, así como también pruebas no funcionales como rendimiento, estabilidad, seguridad e integración.

Referencia: Guía de Scrum - Escrito por Ken Schwaber y Jeff Sutherland (Inventores de Scrum)

estado en el que que está siguiendo "Prácticas de Scrum". A mí me parece que solo estás usando algunas partes del Marco de Scrum y no otras, ¿es cierto? Antes que nada, 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 tanto, aparte de las reglas básicas del marco de Scrum, nada es inamovible, por lo que no obtendrá una respuesta exacta a su pregunta. La mejor manera de saber la respuesta es contratar Scrum Professionals experimentados y Desarrolladores experimentados y probadores y probar el plan hecho anteriormente en su Scrum Team.

Recuerde siempre inspeccionar y adaptar. Hay tres puntos para inspección y adaptación en Scrum.La reunión Daily Scrum se usa para inspeccionar el progreso hacia el objetivo de Sprint y para realizar adaptaciones que optimicen el valor del próximo día de trabajo. Además, las reuniones de Revisión y planificación de Sprint se utilizan para inspeccionar el progreso hacia la Meta de lanzamiento y para realizar adaptaciones que optimicen el valor del próximo Sprint. Finalmente, la Retrospectiva de Sprint se usa para revisar el Sprint pasado y determinar qué adaptaciones harán que el próximo Sprint sea más productivo, satisfactorio y agradable.

No pase mucho tiempo documentando o buscando 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, simplemente es mejor inspeccionar y adaptar siempre que tenga al menos los conocimiento de scrum y estás usando el framework Scrum y no solo unas pocas prácticas similares a Scrum.

Answer 7

Lo importante es que usa la subtarea como tarea real; no como actividad de la tarea principal. El rastreador de problemas está destinado principalmente para lo que estás haciendo; no cómo estás y en qué orden.

Answer 8

Utilizamos un sistema bastante similar en JIRA y tengo una pregunta abierta aquí y en las juntas 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 subtareas que son de tipo 'técnico' o 'proceso'. Las tareas técnicas son el trabajo real de implementación de la historia "Investigue las causas posibles en el sitio del proveedor", "Implemente la corrección en la clase de infografía". Los elementos del proceso incluyen 'Revisión por pares', 'Hacer compilación', 'Verificación de QA', 'Fusionar'. Como se señaló en un comentario, es posible que tenga control de calidad antes/durante la revisión por pares. Como parte del proceso de Scrum, tenemos control de calidad casi todo el tiempo (forman parte del equipo), a veces se sientan con el desarrollador, a veces obtienen 'compilaciones piratas' para ejecutar en un entorno de prueba. Esta es una prueba exploratoria y se considera parte del proceso de codificación para nosotros. La subtarea para 'QA Testing' es para pruebas de integración y regresión, y es una validación final de toda la historia después de que se completa la revisión por pares. En ese momento, el equipo de control de calidad ya cuenta con un plan de prueba completo que desarrollaron durante las pruebas exploratorias y, por lo general, solo se trata 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 pensar en grupo en una dirección con pocas esperanzas de respaldar todo el camino y considerar un camino diferente.

Answer 9

Utilizamos dos tablas para este propósito. Tenemos una placa para el desarrollo Sprint donde "Hecho" está listo para la prueba. No puede ingresar a un sprint a menos que esté realmente listo para comenzar el desarrollo (todos los análisis realizados, las estimaciones realizadas, las personas saben lo que se supone que deben hacer, todas las conversaciones se han tenido, digamos, aunque nuestras conversaciones tienden a tener lugar en JIRA Comentarios dados al equipo distribuido) ... y sales cuando terminas el desarrollo. Esa es la mejor manera de rastrear si nuestro equipo de desarrollo está logrando sus propios objetivos sin verse afectado por el control de calidad. Mientras tanto, QA utiliza una placa de estilo Kanban y van desde "Ready for Testing" (esta es su "tarea pendiente"), pasando por In Testing to Ready for Release.

Cambiamos a esto porque anteriormente teníamos todos estos pasos en una sola placa, y no estábamos "cumpliendo nuestros compromisos" en ningún sprint porque no había forma de que ambos desarrollaran la prueba & 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 continúan durante todo el proceso. Todavía estamos tratando de descubrir cómo hacer las cosas correctamente, por lo que esta puede no ser la respuesta correcta, y sin embargo, parece que no es algo en lo que hayas pensado, así que tal vez te funcione.