Asignación de historias de usuario a la especificación [cerrado]

Estoy buscando una herramienta que me ayude a mantener la coherencia de la cartera de productos y las especificaciones.

Considere que tengo especificaciones del cliente. Según la especificación, creo las historias de usuario (el caso también puede ser al revés). Ahora mismo parece que todo funciona muy bien. Pero es importante tener alguna herramienta que muestre que todos los casos están cubiertos por historias de usuarios.

Lo siguiente es que la especificación no es fija y cambia con el tiempo. En ese caso, necesitamos sincronizar todos los cambios en la documentación con el backlog del producto.

¿Conoces algunas herramientas en el mercado para dicha sincronización (mapeo)? Para hacerlo más simple, podemos decir que la especificación y la cartera de productos se crean en MS Word y MS Excel.

Las solicitudes de herramientas están fuera del alcance; si comienza una pregunta con "Estoy buscando una herramienta...", es muy probable que su pregunta se cierre. Por favor consulte Cómo Preguntar . Es posible que desee enviar la pregunta sobre el intercambio de la pila de requisitos de software o revisar la pregunta para preguntar sobre métodos en lugar de herramientas. (Soy consciente de que esta pregunta tiene 5 años; estoy respondiendo en base a la teoría de la ventana rota).

Respuestas (5)

Recuerdo haber investigado un producto llamado Telelogic DOORS para este tipo de seguimiento. Parecía perfecto, pero no estaba en condiciones de recomendarlo en ese momento.

El producto ahora es parte del conjunto de herramientas Rational de IBM, y supongo que tiene un precio elevado.

Puertas Racionales de IBM

+1 Doors es sin duda un camino a seguir. Lo usé en un proyecto de tamaño mediano para recopilar especificaciones y vincularlas a historias de usuarios (que se entregaron en la herramienta Rally). Doors, sin embargo, es una forma muy "de la vieja escuela" de hacer las cosas... aunque no he visto nada más que lo aborde (aunque voy a echar un vistazo a las sugerencias de Al Biglan ).
Gracias por la sugerencia. Esto parece ser lo que estoy buscando.

Desafortunadamente, este es un problema bien entendido y un dolor de cabeza colosal de cualquier manera que lo aborde. Si necesita un "mapeo completo, rastreable y auditable", debe considerar extraer la especificación y las Historias de usuario en la misma herramienta.

Estas herramientas le permiten hacer un mapeo inicial desde la especificación hasta los requisitos/historias de usuario y luego le muestran cambios, discrepancias, brechas, etc. Por lo general, requieren una inversión significativa por adelantado para generar una especificación inicial y luego construir las Historias de usuario. También tienden a no ayudar en absoluto cuando construye una parte de la especificación una vez, la llama completa y luego el cliente cambia esa parte de la especificación.

Lo mejor que puede hacer es trabajar con el cliente para entregar partes de la especificación y hacer que "se terminen y no se puedan cambiar" lo más rápido posible. Trabaje en versiones versionadas (por ejemplo, la compilación en enero será 0.6, la de febrero será 0.6, etc.) y construya hasta 1.0 con su cliente. No tenga miedo de empujar las cosas fuera del alcance/proyecto actual y ponerlas en "1.1"

Algunas herramientas que he usado que ayudaron

  • Calibre RM de Borland - Usado este 2003-2005. Teníamos 1200 requisitos y una "especificación flexible". Me gustaban las herramientas de mapeo y las funciones de importación/exportación. Hizo un buen trabajo al rastrear los requisitos y lo suficientemente decente en la especificación.
  • Desarrolle su propio formato de documento SGML: lo usó a finales de los 90 Básicamente, "compilamos" nuestros documentos y el compilador se quejaba si no había una etiqueta de requisitos de mapeo. Requirió una -enorme- dedicación definir la estructura y mantener los vínculos. (Era un producto relacionado con la seguridad, por lo que tenía sentido)

Realmente, esto es un gran dolor de cabeza. Si tuviera que enfrentarme a esto nuevamente, adoptaría el siguiente enfoque:

  • Para menos de 750 requisitos o menos de 80 páginas de especificación, mantendría un mapeo de hoja de cálculo y lo mantendría yo mismo
  • Para más de 750 requisitos o más de 80 especificaciones de página, trabajaría con el cliente para dividirlos hasta que fueran lo suficientemente pequeños para trabajar con ellos en un Spreadshhet
  • Salvo eso, mapearía mis necesidades para esto, pasaría de 3 a 4 semanas seleccionando la herramienta adecuada y estructuraría todo el proceso de desarrollo de mi proyecto en torno a esa herramienta.

hth
y lo siento, la respuesta es tan larga :-(

El divide y vencerás siempre es una buena práctica, pero en grandes proyectos no es fácil sugerir esta estrategia. El problema es especialmente con los vendedores que siempre luchan por tener un gran proyecto (un gran resultado = mucho dinero).
Fui gerente de ingeniería de un proyecto de $ 81 millones que utilizó este enfoque de "divide y vencerás" con buenos resultados y gerente de proyecto para un proyecto de $ 32 millones que hizo lo mismo. También formaba parte de un proyecto (no como gerente) que probablemente estaba en el rango de $ 200 millones (reactor nuclear) que tenía al menos 22 compilaciones intermedias para desarrollar y agregar funcionalidad. Los argumentos no siempre son fáciles, pero ciertamente pueden aplicarse a proyectos grandes y pequeños por igual.
+1: Es un dolor independientemente del soporte de herramientas o no. Excel a alguien? Mantener todo alineado es un trabajo especializado. Llamaría a ese trabajo " ingeniería de sistemas ", pero ese nombre puede tener connotaciones diferentes (incorrectas, en mi opinión) en el software.
Gracias por ejemplo del gran proyecto de la vida real. Estoy completamente de acuerdo contigo. Sus ejemplos requerían el enfoque de "divide y vencerás". En este momento puedo equilibrar mi comentario de que tenía la sensación de que el proyecto intermedio parece que se puede completar en un solo paso, pero lo mejor será aplicar las reglas en desuso.

DOORS (Sistema de requisitos dinámicos orientados a objetos) es una herramienta de base de datos de requisitos diseñada específicamente para gestionar las especificaciones de requisitos. Es vendido por IBM (por Telelogic antes de que IBM los comprara) y se usa mucho en la industria de defensa de EE. UU. (y, a menudo, incluso por mandato contractual).

Un poco de información sobre cómo funciona DOORS es instructivo para comprender cómo podría usarse para vincular historias de usuarios:

  • Los requisitos de una especificación dada residen en un solo módulo, con cada requisito y sus metadatos asociados almacenados en un objeto separado.
  • Por lo tanto, un grupo de módulos forma el conjunto de especificaciones para un sistema complicado como un satélite, comenzando en la Especificación de desarrollo de elementos primarios (PIDS) de nivel superior y fluyendo hacia abajo a través de las especificaciones de nivel inferior hasta llegar a las Especificaciones de requisitos de software ( SRS) y los equivalentes de hardware.
  • La interrelación entre los requisitos en estos distintos niveles se documenta y gestiona con enlaces. Los enlaces son conexiones entre requisitos (es decir, objetos) que (normalmente) residen en diferentes especificaciones (es decir, módulos).

Los enlaces son la forma en que va a asignar su especificación mercurial a su trabajo pendiente.

Los enlaces muestran las relaciones de requisitos padre-hijo. En su caso, parece como si hubiera recibido una especificación de su cliente y desea poder rastrear las historias de los usuarios según sus requisitos. Suponiendo que sus historias de usuario realmente tengan una asignación bastante sencilla a los requisitos de los padres, esto debería ser fácil de hacer. Cada historia de usuario puede ser un objeto en un módulo de historia que se vincula a un requisito.

Estos enlaces luego se utilizan durante el proceso de diseño y desarrollo para comprender cómo los cambios de requisitos en un nivel de la jerarquía fluyen a través de todo el sistema.

Por ejemplo, si se cambia un requisito de rendimiento de alto nivel, un informe simple ejecutado en un conjunto de especificaciones correctamente vinculado permitirá a los ingenieros de sistemas determinar el conjunto completo de requisitos secundarios que ahora deben evaluarse para determinar el impacto. O, en su caso, un cambio de requisitos se puede rastrear instantáneamente hasta la(s) historia(s) de usuario en las que afectará el cambio .

A continuación, DOORS le permitirá ejecutar auditorías para ver si hay algún requisito no asignado a una historia de usuario, cualquier historia de usuario no vinculada a un requisito y cualquier otra combinación que se le ocurra (p. ej., requisitos satisfechos por varias historias de usuario, aunque esto probablemente indica que el requerimiento no está lo suficientemente descompuesto).

Una vez que el código está completo y publicado, los metadatos de la historia de usuario y las especificaciones se pueden actualizar para mostrar que se ha cumplido el requisito y se pueden generar informes para mostrar el progreso general y las características sobresalientes.

Estoy seguro de que hay otras herramientas (probablemente menos costosas) que tienen una funcionalidad similar, pero DOORS es, con mucho, la más omnipresente, al menos en la industria aeroespacial y de defensa.

No estoy seguro de "asignar a una especificación", pero ser capaz de mapear historias de usuarios individuales de nuevo al "panorama general" es definitivamente algo con lo que también lucho. No he encontrado ningún software que haya sido bueno en esto, aunque tampoco he buscado mucho. No me sorprendería si algunas de las suites ALM más grandes tuvieran esto. Personalmente, en este momento estoy administrando un "Story Map" que nos permite ver cómo las historias de usuarios individuales encajan en el panorama general. Sin embargo, administrar eso es un proceso manual, por lo que no hay nada automatizado. Si está interesado en los story maps, puede consultar parte del material de Jeff Patton sobre ellos (http://www.agileproductdesign.com/blog/the_new_backlog.html).

Gracias por compartir tu experiencia. Me gustaría añadir algo sobre las especificaciones. Para mí, el mapeo de la especificación es muy importante porque este es uno de los lugares estables para hablar sobre las expectativas y los cambios desde el punto de vista del cliente. En mi organización no es fácil hablar con los clientes a través de historias de usuario. La razón principal es que los clientes no están preparados para hablar de esta manera. Las documentaciones estándar pueden ser aburridas y demasiado largas, pero los clientes las usan como documentos oficiales para un contrato. En ese caso, no podemos usar solo el panorama general para administrar un proyecto.

Hay un complemento de mapeo de historias de usuario de Jira realmente bueno que puede usar

https://marketplace.atlassian.com/plugins/com.bit.agile.bit-storymap/cloud/overview

Asignación de historias de usuario a la especificación [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v