El analista comercial de mi equipo y yo escribimos algunos archivos de Gherkin que describen historias de usuarios de nuestro nuevo proyecto.
Como de costumbre, un archivo Gherkin se compone de una característica, que se detalla a través de uno o varios escenarios.
El paso actual es establecer los diferentes sprints (evolución ágil) y su respectivo contenido.
Personalmente, quiero que esos sprints prioricen valores útiles y tangibles para el usuario final.
Por eso pienso en considerar un escenario como la unidad de esos sprints.
Por ejemplo, tendríamos:
Se entiende la idea: la implementación de una característica no podría implementarse atómicamente, pero un escenario sí lo haría.
Esto permitiría programar de forma incremental varias funciones durante un mismo sprint, al tiempo que ofrece la posibilidad de completar completamente una función después de N sprints.
Me pregunto cómo manejar la alimentación de Jira.
¿Podría un "boleto" de Kanban representar un escenario exacto de alguna función o debería representar la función completa en su lugar?
Primero me gustaría decir que este es un experimento maravilloso. Por favor, haga una crónica de su experiencia y compártala con el mundo.
Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo.
El manifiesto para el desarrollo ágil de software
Jira no tiene un concepto de características, pero sí tiene Epics. Puede ingresar sus funciones como epopeyas y cada escenario como una historia de usuario (vinculada a su epopeya principal). Los conceptos se mapean razonablemente bien y esto debería brindarle la trazabilidad que necesita.
Bueno, hay JIRA Epics que encajarían con tus características y Stories podrían ser tus escenarios. Debe jugar con el uso de épicas, historias y subtareas para satisfacer mejor sus necesidades. Creo que el método que estás describiendo sería un muy buen experimento. ¡Mira qué sucede!
Barnaby dorado
Mik378
Barnaby dorado