Estamos usando métodos ágiles en mi proyecto actual en este momento, y tenemos un montón de historias como estas:
Como asistente, quiero pagar un reembolso a un cliente para que pueda obtener algo de dinero cuando lo solicite.
Como cliente, quiero pagar una compra para poder recibir mi artículo.
Lo que hemos hecho hasta ahora es elegir las historias más importantes de cada sprint y elaborarlas en una serie de especificaciones de requisitos formales (agrupamos algunas de las historias que son similares en la misma especificación). Dependiendo de la historia, podría ser solo un botón en una pantalla o un flujo de trabajo completo.
El problema ahora es que debido a que hay tantas historias, no está claro de inmediato para ninguna parte del sistema qué historias se relacionan con él.
Funciona en el momento de los desarrolladores, cada sprint los desarrolladores solo obtienen una especificación que describe lo que necesitan hacer y los cambios que deben hacer. Pero en términos de mantener esta lista de historias y para las pruebas, está comenzando a tener errores de seguimiento realmente duros y, en general, solo mantiene las especificaciones, porque una pieza de funcionalidad en la pantalla podría haberse documentado en varios lugares diferentes debido a que es dividido por historia.
¿Es una buena idea escribir especificaciones basadas en historias? ¿Hemos escrito las historias de manera incorrecta?
fuente
Respuestas:
Esto puede ser controvertido, pero aquí va!
¡Hemos trabajado en sistemas en tiempo real en los que uno de los jefes anteriores me sugirió que hagamos AGILE! Fue fácil ganar la gestión en eso realmente; Sin embargo, fue más fácil decirlo que hacerlo.
El concepto de historias es bueno, pero para ser muy directo, es bastante vago. ¿Qué es una historia realmente? El problema real es que el uso de historias
alone(y lo mismo ocurre con los casos de uso) tiene varios problemas, como sigue:Los requisitos no pueden estar fuera de contexto (a menos que esté haciendo repeticiones groseras tantas veces). Hay suposiciones, conocimientos previos y otros requisitos que también están vinculados a un requisito dado; tienen sentido solo bajo un contexto y solo bajo un orden específico. Implementar el más importante primero tiene sentido comercial, pero cuando los archives al menos, mantén una referencia completa desde el principio cuando los recopiles. La palabra de requisito en sí misma es compleja y no se limita realmente a casos de uso / historias. De hecho, las historias son procesables, pero luego hay requisitos que pueden no ser procesables, como el rendimiento, las restricciones que deben cumplirse, las reglas comerciales, etc.
¡Los requisitos deben ser apropiados en tamaño y de manera cuantificable, de lo contrario, nunca podrá necesitar más de 1 historia grande! ¿Qué forma exactamente 1 historia?
¡El conocimiento del dominio es realmente un requisito! Un ejemplo simple de un arquitecto que conoce varias propiedades del vidrio, el acero y la madera. ¡Este conocimiento no es parte del documento de requisitos para el edificio por decir! Del mismo modo, si está escribiendo un software bancario, existen muchos conceptos sobre la banca. Expresándolos, como el Requisito mismo lo hace no manejable porque no le dice qué debe hacer el software en lugar de cómo funciona el mundo . ¿La historia incluye tales complejidades de dominio? o excluye esto?
Modelar el mundo es un requisito previo que no es del todo compatible.
Ha habido mucha literatura sobre modelado que se enfoca en entender cómo funciona el mundo es un conocimiento básico. El modelado forma una base firme sobre la cual los requisitos adquieren un significado claro; Sin embargo, tal cosa debe ser por adelantado. Desafortunadamente, la mayoría de las prácticas ágiles rechazan el valor en el modelado inicial en aras de entregas más rápidas y ágiles; pero eso todavía creo que es un gran obstáculo cuando las cosas tienen que escalar. Muchos proyectos no tienen éxito porque el modelado es irrelevante, sino que los ingenieros experimentados los conocen en su cabeza y no necesitan mucha orientación explícita.
Entonces, viniendo a tu pregunta:
Creo que las historias de los usuarios tienen valor como veredicto explícito dado por el cliente. Pero si están mal organizados e insuficientemente detallados (o vagos), hay un problema. A menos que tenga una estructura más grande para acumular la comprensión más amplia (conocimiento del dominio) y el alcance (especificación total). Historias de usuarios solo para segmentos o elementos dentro de un sistema más grande.
PD: Tengo una opinión exacta sobre los casos de uso (como se representan en diagramas ovales) de que, a menos que los coloque en el contexto apropiado y con la granularidad adecuada, no harán un buen trabajo. (Los llamo casos inútiles ). La única fuente creíble que encuentro para que la redacción de casos de uso sea realmente escalable y significativa es Escribir casos de uso efectivos por Cockburn
fuente
Sí, si puede gestionar las interdependencias y prioridades de sus historias.
Aquí hay un artículo sobre mapas de historias que puede ayudarlo a ordenar y gestionar muchas historias de usuarios.
fuente
Al momento de escribir esta respuesta, me di cuenta de que no se trata de pruebas, sino de documentación. Primero debes leer el manifiesto ágil :
Por lo tanto, debe hacer que sus especificaciones sean ejecutables, es decir, escribirlas como un conjunto de pruebas totalmente automatizado.
Sí, en mi opinión. Se llama "desarrollo impulsado por el comportamiento" o "especificación por ejemplo". En ruby hay una gran herramienta de pepino que ayuda mucho.
¿Por qué quieres que quede claro? Quiero decir, ¿realmente necesitas una matriz de trazabilidad de "prueba / código"? La ventaja de escribir pruebas como especificación es que no necesita una trazabilidad separada de "requisitos / pruebas", porque las pruebas se convierten en requisitos. A los fines de las pruebas de integración, debe tratar su software como un todo, no como partes separadas.
Es posible que necesite una herramienta de cobertura para ver si hay módulos "muertos", partes de su sistema no cubiertas por sus pruebas de especificación. Pero realmente no debería importarle a qué especificación corresponde este código en particular. Debería ser al revés: a partir de una especificación particular, debe saber qué parte del sistema le corresponde. No debe preocuparse por alguna duplicación en sus especificaciones. Y si aplica un principio DRY a su código, habría docenas de especificaciones ejecutando el mismo código.
No es raro que cientos de pruebas de integración se rompan con un pequeño cambio en un módulo crítico. Ahí es donde entran las pruebas unitarias.
Debe estructurar sus pruebas como tales para que pueda saber si una prueba en particular cubre un requisito de alto nivel, o solo un detalle sutil del mismo. Si es lo último, debe separar esta prueba de su conjunto de pruebas de integración. El propósito de las pruebas unitarias es localizar errores. De modo que si introduce un error, habrá una y solo una falla de prueba.
Creo que solo necesita organizar sus historias en épicas, ya sea por usuario, por ejemplo, "Cliente", "Asistente" o por funciones / pantallas / flujos de trabajo ("Compra", "Reembolso").
Y nuevamente, las pruebas de especificación no son un reemplazo de las pruebas unitarias. Lee mas
fuente
Mencionó un problema y la forma en que lo resuelve, pero olvida mencionar algún ejemplo de sus especificaciones y agrupación, y cómo se relaciona con la forma en que desarrolla su producto.
Ágil no lo prohíbe. En Agile puede hacer lo que sea necesario para ofrecer el máximo valor comercial a un ritmo sostenible. Entonces, si escribir especificaciones es algo que necesita para entregar más valor comercial, está absolutamente bien hacerlo.
Su ejemplo muestra dos historias de usuario. Quizás estén relacionados de alguna manera en la lógica de su negocio, pero ese es un escenario muy común.
Si necesita unir la funcionalidad a las historias de los usuarios, puede volver a utilizar lo que mejor le convenga, incluida la documentación, algunos diagramas o su "especificación", pero debe estar preparado para mantener estos artefactos le costará más a medida que aumenta la complejidad de la aplicación desarrollada. Entonces, la única pregunta que debe responder en este caso es: si no uso mis especificaciones, ¿nos costará más? Si la respuesta es sí, elegiste una mejor opción.
El ágil funciona mejor para proyectos pequeños a medianos con un equipo pequeño donde toda la arquitectura se mantiene como conocimiento tácito compartido en el equipo. Durante la planificación de la iteración, revisará sus historias seleccionadas, discutirá un impacto en la implementación actual y escribirá algunas tareas necesarias para completar la historia. La documentación real en tal caso será el conjunto de pruebas con aceptación automática e integración / pruebas unitarias. Una vez que su SW o equipo crezca, el conocimiento tácito tendrá que pasar parcialmente a cierta documentación.
fuente
Ahora aquí es donde la abstracción juega un papel importante. Debe mirar las historias con respecto a la perspectiva relevante. Reúna los sustantivos y verbos en las declaraciones y confírmelos. No puede basar sus modelos en suposiciones personales. También preste atención a los detalles.
Escribir especificaciones basadas en historias de usuarios no puede ser exacto. Necesita cavar detalles adicionales y, a veces, ignorar los detalles que no son relevantes. Las especificaciones deben escribirse cuando su modelo esté completo y sea exacto luego de la confirmación de su analista.
fuente