project-management - tutorial - popular tool used in agile software development
Versiones de Sprint vs Versiones de lanzamiento en Jira y Greenhopper (6)
Cuando se utiliza Greenhopper con Jira, está claro que Greenhopper está utilizando el campo "corregido en la versión" en los problemas de Jira para representar en qué scrum sprint se está trabajando en el problema. Esto en sí mismo es un poco intrincado, porque posiblemente se puede trabajar en un problema en varios sprints, y porque la relación entre un problema y un sprint es precisamente que se ha trabajado durante el sprint, con el reconocimiento de que es posible que no se complete La tarea dentro del tiempo previsto.
Pero bueno, podría ser un truco con el que se pueda vivir, al menos si no hay nada más que intente usar el campo "arreglado en la versión" para otra cosa.
Pero estoy descubriendo que hay otras preocupaciones que también se basan en el campo "corregido en la versión". Específicamente, uno debería poder ver qué problemas se planean abordar en qué versiones de lanzamiento ( versiones de la vida real), y utilizar esta información como un medio de verificación / control de calidad.
¿Cómo combinan otros usuarios de Greenhopper estos dos usos del campo "arreglado en versiones"? ¿Está configurando las versiones de sprint como subversiones de las versiones de lanzamiento? ¿Está utilizando algún campo personalizado para las versiones de lanzamiento? Encuentro que esto es difícil porque el equipo de scrum está trabajando en múltiples componentes, con versiones independientes. Además, puede haber lanzamientos de corrección de errores y desarrollo de características en el mismo componente, que suceda en el mismo sprint.
Para resumir, me parece inevitable que el equipo esté trabajando en "Some Product 3.4.0" (una versión de la característica), "Some Product 3.3.1" (una versión de corrección de errores), y "Other Product 1.2" dentro del mismo sprint . No sería posible marcar este sprint como una subversión de cada una de estas tres versiones (a través de dos componentes diferentes). Y hacer tres sprints diferentes en Greenhopper, realmente diluiría el valor de Greenhopper.
¿Están otros usuarios de Greenhopper en esta misma situación? ¿Cómo ha lidiado con ello?
¿No debería un sprint tener en teoría un producto "enviable" al final? Lo que significa que un sprint tiene los problemas resueltos o "falla". Es por eso que recomiendo dividir el tema en partes más pequeñas.
Hay dos problemas en juego aquí.
Primero, sus versiones de sprint son en realidad "subversiones" de su versión de lanzamiento. Esto significa que sus historias realmente obtienen dos valores en el campo fixVersion.
Puede configurar esto en Greenhopper configurando una versión maestra.
Entonces, si tiene un lanzamiento de 3 sprint para la versión 1.0, entonces establezca su fecha de lanzamiento en 1.0 y ponga sus historias en sprint 1, sprint 2 y sprint 3, de modo que
- 1.0
- Sprint 1
- Sprint 2
- Sprint 3
- 1.1
- ...
Cuando juegue STORY-1 en Sprint 1, encontrará que STORY-1 tendrá una versión fija de "1.0, Sprint 1"
Para los elementos que está rastreando para el lanzamiento, pero no en un sprint, simplemente configure la fixVersion a 1.0.
En segundo lugar (y esto es solo una sugerencia), puede utilizar proyectos separados para su trabajo de sprint y para su trabajo de soporte de producción. Esto es útil en grandes organizaciones.
Intento usar KISS siempre que sea posible, así que he estado usando el campo de etiqueta para marcar lanzamientos. Rara vez necesito ver el lanzamiento en el contexto de scrum / taskboard. Entonces, cuando llega el momento de ver todos los elementos de una versión, simplemente hago una búsqueda de mi nombre de versión.
Nos hemos enfrentado con el mismo problema en varias organizaciones, donde un equipo no solo está trabajando en varias versiones (como se detalla en su ejemplo) sino también en el que el equipo participa para ayudar a la organización de soporte cuando surgen los problemas del cliente o cuando la Prueba de aceptación del usuario de versiones anteriores, muestre los problemas que "deben tratarse" de inmediato.
Por lo tanto, introdujimos un concepto donde los problemas se separan de las tareas, pero se vinculan entre sí mediante la función de "vinculación de problemas" de JIRA. Los problemas (o especificaciones como los llamamos) se administran en un proyecto de lanzamiento, mientras que las tareas se administran en un proyecto de equipo.
El versionado en un proyecto de lanzamiento denota lanzamientos (es decir, 2.2-patch1, 1.1 ...) El versionado en un proyecto de equipo denota sprints (sprint 10-15, sprint 10-20)
El proyecto de lanzamiento solo contiene errores, solicitudes de características, consultas ... El proyecto de equipo solo contiene tareas, historias, ...
La automatización nos permite mantener sincronizadas las especificaciones y las tareas relacionadas: el escenario típico se ejecuta de la siguiente manera
- Se crea una especificación en un proyecto de lanzamiento.
- Una persona de soporte crea una o más tareas en los proyectos de equipo y vincula la especificación con las tareas que usan un enlace ''se implementa mediante''.
- Desde el momento en que se inicia el trabajo en la tarea, la especificación avanza a un estado "en desarrollo".
- La especificación se considera resuelta una vez que todas las tareas relacionadas se han abordado
Las transiciones para las especificaciones se activan automáticamente. Este concepto de separación entre especificación y tarea le permite admitir muchas organizaciones de proyectos diferentes, como
- Una epopeya que necesita ser desarrollada sobre una serie de sprints.
- Un problema que debe ser abordado por varios equipos en varios lugares
- Un equipo que trabaja en un nuevo producto y mantiene un viejo.
Puedo proporcionarle más información sobre este tema si está interesado.
Francis Martens
Solo use tablas rápidas en GreenHopper, fueron introducidas no hace mucho tiempo, pero dan casi todo lo que necesita.
Puede poner ETIQUETAS en sus asuntos, por ejemplo, ''sprint-1'', ''sprint-2'' y así sucesivamente. Entonces crea el problema FILTRO . A continuación, cree RAPID BOARD en función del filtro. Al final obtendrás una buena tabla con los problemas actuales de sprint-X independientemente de la versión e incluso del proyecto .
Por favor, compruebe que Sprint no es esencialmente una versión de software. En el mundo real, cuando tiene más de un cliente, necesita arreglar y admitir muchas versiones, pero todavía necesita mantener todo en el buen camino. En este caso, los sprints siguen siendo excelentes, pero solo representan la cantidad de trabajo que se debe realizar durante el período de tiempo. De todos modos, la versión es lo que presentará a cualquier persona fuera de su tiempo de desarrollo. Por lo tanto, ¡no mezcle las versiones del software y los sprints ("mapeo" entre el tiempo y las tareas)! ¡No utilice jerarquías en las que la versión Sprint es hija de una versión de software real! Mantener las cosas no relacionadas separadas !!!
Yo también he estado plagado por el mismo problema y he encontrado la solicitud de características en jira / greenhopper para agregar un nuevo campo para sprints que permita el seguimiento de la información de la versión de sprint y la versión de forma independiente.
Si desea que esto se haga realidad tanto como yo, vaya a http://jira.atlassian.com/browse/GHS-945 y vote por el problema. Esta cita lo resume: "Si GreenHopper tuviera iteraciones como ciudadanos de primera clase ..."
Sin embargo, en este momento, es probable que tengamos que crear un nuevo campo llamado versiones en jira y usarlo para rastrear las "versiones reales del producto" con las que se relaciona un problema. También tenemos un enlace de confirmación en nuestros repositorios de código fuente, por lo que cuando un desarrollador realiza una confirmación, actualizará el ticket de jira con la "versión real del producto" que se relaciona con el código fuente que están confirmando. Mantenemos esta información en un archivo de configuración para que el gancho de confirmación sepa qué versión usar para qué ruta / repositorio de código fuente. Esto no es ideal, pero es nuestra única opción en la actualidad.