JIra + Greenhopper - cómo hacer Ágil correctamente

Soy nuevo en el Agile flow 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 historias GRANDES). Quería saber cuál es el flujo de creación de las tareas:

  1. Primero, abrimos una historia/Épica 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 el story - For development, se crean nuevos tickets (bug/new feature/task, etc.) y se vinculan utilizando el ISSUE QUE ENLAZA con el story.

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 tickets de desarrollo por separado y los enlazo juntos - entonces, ¿cuál es el propósito de las subtareas en story?
  2. ¿Hay una manera mejor / más fácil de crear los tickets de desarrollo directamente de GH? ¿o debo abrirlos por separado y vincularlos al problema de los padres de la historia?

Muchas Gracias por la rápida respuesta.

Author: jessehouwing, 2011-06-05
Source

2 answers

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, priorizaremos las historias que queremos lograr. Para cada historia, el equipo creará tareas (sub-tareas) sobre cómo construir la historia. Estas tareas son cosas específicas que se deben hacer: Crear una tabla de base de datos, cambiar el código del controlador, QA la característica, actualizar la Documentación Pública, etc; junto con la persona que será la realización de la tarea y su estimación a tiempo.

A medida que avanza la iteración, cada miembro del equipo registra su trabajo realizado en cada tarea, así como refina su estimación en 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 su implementación.

Además, cuando está creando sub-tareas, si elige agregar sub-tareas de 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 subtarea hasta que termine. En nuestra opinión, una forma muy rápida y fácil de ingresar tareas.

Esperemos que esto ayude. Hágame saber si tiene alguna pregunta o desea más detalles sobre cualquier otra cosa.

 27
Author: Steven Mastandrea,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-06-08 20:14:47

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 la Épica y luego la 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 Sub-Tareas.

Algunos equipos dan una estimación puntual de la historia (generalmente fibonacci) a las Historias, otros asignan una hora estimación de las Sub-Tareas. Al asignar una estimación de horas, los equipos a menudo actualizan la Estimación restante a medida que avanzan. Esto da una buena indicación en el gráfico de burndown de horas cuál es el progreso del sprint.

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

Las Epopeyas generalmente se programan en cualquier cosa que no sea un backlog de lanzamiento, ya que a menudo abarcan varios backlogs de sprint. Tanto los sprints como las versiones se manejan como versiones Fijas en JIRA, el anidamiento de los backlogs padre/hijo ayuda a proporcionar visualización de lo que se planea.

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

Saludos, Nicholas Muldoon

 16
Author: Nicholas Muldoon,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-07-01 03:05:36