Versiones de Sprint frente a Versiones de versiones en Jira y Greenhopper

Question

Al usar Greenhopper con Jira, está claro que Greenhopper está utilizando el campo "versión fija" en los problemas de Jira para representar en qué scrum sprint se está trabajando. Esto en sí mismo es un poco hackish, porque un problema puede ser trabajado en múltiples sprints, y debido a que la relación entre un problema y un sprint es precisamente que ha sido trabajado en durante el sprint, con el reconocimiento de que podrías no completar la tarea dentro del tiempo planificado.

Pero está bien, podría ser un truco con el que uno pueda vivir, al menos si no hay nada más que intente usar el campo "versión fija" para otra cosa.

Pero me parece que hay otras preocupaciones que también se basan en el campo "versión fija". Específicamente, uno debe poder ver cuáles son los problemas planificados que se tratarán en los que lanzan versiones (versiones de la vida real), y utilizar esta información como medio de verificación/QA.

¿Cómo son otros usuarios de Greenhopper que combinan estos dos usos del campo "versiones fijas"? ¿Estás configurando las versiones de sprint como subversiones de las versiones de lanzamiento? ¿Estás usando algún campo personalizado para las versiones de lanzamiento? Estoy descubriendo que esto es difícil porque el equipo scrum está trabajando en múltiples componentes, independientemente versionados. Además, puede haber versiones de corrección de errores y desarrollo de características en el mismo componente, que ocurren en el mismo sprint.

En resumen, me parece inevitable que el equipo trabaje en "Some Product 3.4.0" (una versión de la función), "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 (en dos componentes diferentes). Y hacer tres sprints diferentes en Greenhopper, realmente diluiría el valor de Greenhopper.

¿Hay otros usuarios de Greenhopper en esta misma situación? ¿Cómo ha lidiado con ello?

Answer 1

¿No debería un sprint tener en teoría un producto "expedible" al final? Lo que significa que un sprint tiene los problemas resueltos o "falla". Es por eso que recomendaría dividir el problema en pedazos más pequeños.

Answer 2

Nos hemos enfrentado con el mismo problema en varias organizaciones, donde un equipo no solo está trabajando en múltiples lanzamientos (como detalla en su ejemplo) sino también en el equipo que ayuda a la organización de soporte cuando el cliente se plantean problemas o cuando las Pruebas de aceptación del usuario de versiones anteriores muestran problemas que "deben resolverse" de inmediato.

Por lo tanto, presentamos un concepto en el que los problemas se separan de las tareas, pero se vinculan mediante la función 'vincular problemas' de JIRA. Los problemas (o especificaciones como los llamamos) se gestionan en un proyecto de lanzamiento, mientras que las tareas se gestionan en un proyecto de equipo.

El control de versiones en un proyecto de liberación denota liberaciones (es decir 2,2-patch1, 1,1 ...) El control de versiones en un proyecto de equipo denota carreras cortas (10-15 de sprint, sprint 10-20)

El proyecto de liberación solo contiene errores, solicitudes de características, consultas ... El proyecto del equipo solo contiene tareas, historias, ...

automatización nos permite mantener las especificaciones y las tareas relacionadas en sincronía: El escenario típico es como sigue

• Una especificación se crea en un proyecto de liberación.
• Una persona de soporte crea una o más tareas en los proyectos del equipo, y vincula la especificación con las tareas utilizando un enlace 'es implementado por'.
• Desde el momento en que se inicia el trabajo en la tarea, la especificación avanza a un estado 'en desarrollo'. Se considera
• La especificación resueltos una vez que todas las tareas relacionadas se han abordado

Las transiciones para las especificaciones se activan automáticamente. Este concepto de la separación entre la especificación y la tarea le permiten apoyar muchas organizaciones diferentes de proyectos - tales como

• Una epopeya que necesita ser desarrollado a través de una serie de carreras.
• Un problema que necesita ser tratado por varios equipos en varias ubicaciones
• Un equipo que trabaja en un nuevo producto y mantiene un antiguo.

Puedo proporcionarle más información sobre este tema si está interesado.

Francis Martens

Answer 3

yo también he sido azotado por el mismo problema y han encontrado la solicitud de función en jira/GreenHopper añadir un nuevo campo para carreras cortas para permitir el seguimiento de la carrera corta y la liberación de información de la versión independiente.

Si quiere que esto se convierta en realidad tanto como yo, vaya al http://jira.atlassian.com/browse/GHS-945 y vote por el problema. Esta cita resume: "Si GreenHopper tenía iteraciones como ciudadanos de primera clase ..."

Por el momento, sin embargo, es probable que vamos a tener que crear un nuevo campo llamado versiones en jira y el uso que se 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 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 enlace de confirmación sepa qué versión usar para qué repositorio/ruta de código fuente. Esto no es ideal, pero es nuestra única opción en este momento.

Answer 4

Hay dos cuestiones en juego aquí.

Primero, sus versiones de sprint son en realidad "subversiones" de su versión de lanzamiento. Esto significa que sus historias en realidad obtienen dos valores en el campo fixVersion.

Puede configurar esto en Greenhopper configurando una versión maestra.

Así que si usted tiene una versión 3 de sprint para la versión 1.0, a continuación, fijar su fecha de lanzamiento de 1,0 y poner sus historias en el sprint 1, sprint 2, y Sprint 3, de tal manera que

• 1.0
  • Sprint 1
  • Sprint 2
  • Sprint 3
• 1,1
  • ...

Al reproducir HISTORIA-1 en Sprint 1, encontrará que STORY-1 tendrá una versión de FixVersion de "1.0, Sprint 1"

Para los artículos que está rastreando para el lanzamiento, pero no en un sprint, simplemente configure el fixVersion en 1.0.

En segundo lugar (y esto es solo un consejo), puede utilizar proyectos independientes para su trabajo de esprint y para su trabajo de soporte de producción. Esto es útil en organizaciones grandes

Answer 5

Intento utilizar K.I.S.S. siempre que sea posible, así que he estado usando el campo de etiqueta para marcar lanzamientos. Raramente necesito ver el lanzamiento en el contexto de scrum/taskboard. Entonces, cuando llega el momento de ver todos los artículos en un lanzamiento, simplemente ejecuto una búsqueda de mi nombre de lanzamiento.

Answer 6

Solo use tableros rápidos en GreenHopper, fueron introducidos no hace mucho tiempo, pero dan casi todo lo que necesita.

Puede poner ETIQUETAS en sus problemas, por ejemplo, 'sprint-1', 'sprint-2', etc. A continuación, cree el problema FILTRO. A continuación, cree RAPID BOARD en función del filtro. Al final obtendrá un buen tablero con las ediciones actuales de sprint-X independientemente de la versión e incluso del proyecto.

Por favor, compruebe que Sprint esencialmente no es una versión de software. En el mundo real, cuando tiene más de un cliente, necesita arreglar y admitir muchas versiones, pero aún necesita mantener todo en orden. En este caso, los sprints aún son 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ás a cualquiera fuera de tu tiempo de desarrollo. Por lo tanto, no mezcle versiones del software y sprints ('mapeo' entre el tiempo y las tareas)! ¡No use jerarquías donde la versión de Sprint es hija de la versión de software real! Mantenga las cosas sin relación separadas !!!