software - JIra+Greenhopper-cómo hacer Agile correctamente

jira tutorial español

Question

Soy nuevo en el flujo Agile en JIRA + Greenhopper. Estoy tratando de entender cuál es la forma correcta / mejor de trabajar Agile en JIRA + GH. He leído en la red para obtener información. Hasta ahora, entiendo que tenemos Historias y epopeyas (que son GRANDES historias). Quería saber cuál es el flujo de creación de las tareas:

1. Primero, abrimos una historia / epopeya y la definimos en un texto no técnico.
2. Podemos crear subtareas a la historia (solo tengo subtareas técnicas ahora).
3. después de abrir la historia: para el desarrollo, se crean nuevos tickets (error / nueva función / tarea, etc.) y se vinculan mediante el ENLACE DE EMISIÓN a la historia.

¿Es este el flujo correcto? Mis preguntas son:

1. No entiendo por qué en (2) deberíamos abrir subtareas para problemas técnicos si abro los tickets de desarrollo por separado y los vinculo, ¿cuál es el propósito de las subtareas en la historia?
2. ¿Hay una forma mejor / fácil de crear las entradas de desarrollo directamente desde GH? ¿O debo abrirlos por separado y vincularlos con el tema principal de la historia?

Muchas gracias por la rápida respuesta.

Answer 1

Cómo lo hemos estado usando es como sigue:

1. Creamos una historia para definir una solicitud de característica (una tarea no técnica en su verbage)

Cuando planeamos una iteración, daremos prioridad a las historias que queremos lograr. Para cada historia, el equipo creará tareas (sub-tareas) sobre cómo construir la historia. Estas tareas son tareas específicas que se deben realizar: crear una tabla de base de datos, cambiar el código del controlador, QA la función, actualizar la documentación pública, etc. junto con la persona que realizará la tarea y su estimación a tiempo.

A medida que avanza la iteración, cada miembro del equipo registra el trabajo realizado en cada tarea y refina su estimación de la tarea a medida que tienen más información. Cuando la tarea está completa, se cierra. Cuando todas las tareas están completas, la historia está lista para el despliegue.

Además, cuando está creando subtareas, si elige agregar subtareas desde la vista de tarjeta debajo de la rueda dentada, aparecerá una tarjeta para ingresar los elementos de la tarea (similar a la creación de la tarjeta), donde Puede continuar creando tarjetas de subtareas hasta que esté hecho. En nuestra opinión, una forma muy rápida y fácil de ingresar tareas.

Esperemos que esto ayude. Déjame saber si tienes alguna pregunta o quieres más detalles sobre cualquier otra cosa.

Answer 2

Creo que es importante tener en cuenta que el flujo difiere de un equipo a otro.

Por ejemplo, algunos equipos tienen un propietario de producto que comienza con Epic y luego lo divide en Historias, agregando criterios de aceptación / condiciones de éxito a medida que avanzan. A menudo, en este escenario, el equipo se reunirá en una sesión de planificación y descompondrá esas historias en subtareas.

Algunos equipos dan una estimación puntual de la historia (generalmente fibonacci) a las Historias, otros asignan una estimación de la hora a las Subtareas. Al asignar una hora estimada, los equipos a menudo actualizan la estimación restante a medida que avanzan. Esto da una buena indicación en el gráfico de quema de horas sobre el progreso del sprint.

También he visto equipos en los que el propietario del producto crea muchas Historias y las agrega manualmente en Epics en un momento posterior. Si tuviera un método preferido, sería el primer enfoque por facilidad, pero invariablemente habrá Historias que se pierden / olvidan y se agregan durante una sesión de planificación.

Las Epopeyas generalmente se programan en otra cosa que no sea un retraso de lanzamiento, ya que a menudo abarcan múltiples atrasos de sprint. Tanto los sprints como los lanzamientos se manejan como Corregir versiones en JIRA, el anidado de los trabajos pendientes de padres / hijos ayuda a proporcionar una visualización de lo que se planea.

Esto es para scrum. Si estás interesado en Kanban, puedo compartir lo que he visto hacer a los equipos en ese escenario, solo di la palabra.

Saludos, Nicholas Muldoon