Algunas personas en mi trabajo se han unido para formar un grupo cuyo objetivo es analizar los beneficios de implementar algunos principios de desarrollo de software/gestión de proyectos Agile.¿Cómo debo implementar User Stories en Bugzilla?
Como desarrollador, veo un gran beneficio en User Stories. Estamos buscando armar un radiador de información que pueda usarse para monitorear las etapas de la versión actual y planear lanzamientos futuros. Me gustaría usar User Stories para este proceso.
En este momento, estamos utilizando Bugzilla para el seguimiento de problemas. La mayoría de los planes de lanzamiento se realizan utilizando errores de este sistema. El uso de Bugzilla probablemente no cambie. Proporciona la mayor parte de lo que necesitamos al costo correcto ($ 0).
Una preocupación es el mapeo de User Stories a los errores. La gestión de lanzamientos se realiza actualmente utilizando números de error. El problema es que una historia de usuario puede incluir tres errores o viceversa.
En el caso de tener múltiples errores reportados para una sola historia de usuario, una idea es tener un error de historia de usuario que deletrea la historia y establecer dependencias en los errores infantiles que conforman esa historia. Me preocupa que esto pueda terminar siendo demasiado complejo y crear confusión entre las partes interesadas, el desarrollo y la garantía de calidad. Además, atiborrará bastante a Bugzilla.
¿Alguien ha pasado ya por esta carretera? Si es así, ¿qué has hecho? ¿Debería presionar para abandonar la idea de Historias de usuarios en Bugzilla? ¿Hay una solución más simple?
Cualquier pensamiento sería apreciado.
Estoy de acuerdo hasta cierto punto con su punto, pero creo que el problema de dividir las historias de usuario en historias de usuarios más pequeños aún agrega la capa adicional de indirección que un "error de historia de usuario" en bugzilla; simplemente está moviendo el direccionamiento indirecto a la herramienta de historias de usuario en lugar de a bugzilla. no es que eso sea lo incorrecto; Depende de la empresa lo que mejor funciona. Pero si intenta minimizar la complejidad y la profundidad, reconozca que esto solo mueve la complejidad a otra parte. Como digo, nada de malo en eso, si eso es lo que su organización considera que funciona. –
Sí, como dije, el otro enfoque simplemente no nos funcionó muy bien, pero sigue siendo una buena solución para muchos. –
Gracias por su consejo. Un problema que veo con esto es en un escenario inverso donde un único error necesita varias historias. Nuestros clientes son internos Una de las razones por las que utilizamos Bugzilla es porque permite a todos los usuarios enviar un error sin costo adicional de licencia. Obtendremos casos en los que un error enviado por el usuario se correlaciona con varias historias de usuarios. Podríamos crear múltiples errores de la historia y cerrar el problema original, pero esto aún agrega una capa de complejidad que estoy tratando de evitar. –