¿Cómo realiza un seguimiento de un documento de requisitos en un equipo ágil?

Entiendo que las Historias de usuarios dominan el mundo ágil, pero ¿cómo se almacenan estos artefactos, para que los nuevos desarrolladores que se unan al equipo puedan ponerse al día con los requisitos?

¿Qué sucede si la historia del usuario cambia más tarde, cómo se actualiza y se mantiene como un artefacto? He visto a muchos equipos abrir un nuevo boleto / solicitud de función / informe de error en lugar de realizar un seguimiento de la historia original.

En primer lugar, casi nada en la respuesta de @ DXM coincide con mi experiencia con Agile, y especialmente con Scrum.

El Manifiesto Ágil afirma que si bien la documentación completa es valiosa, el software de trabajo es MÁS valioso. Entonces, la documentación ciertamente no es algo malo, pero realmente debería estar al servicio de la creación de software de trabajo.

Individuos e interacciones sobre procesos y herramientas.

Software de trabajo sobre documentación completa

Colaboración del cliente sobre negociación de contrato

Responder al cambio sobre seguir un plan

Es decir, si bien hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.

Determinar cada detalle antes de comenzar a codificar ha demostrado ser un desperdicio una y otra vez, por lo que la documentación generalmente se trata de manera JIT (justo a tiempo). Es decir, documenta lo que realmente va a codificar.

Una de las formas populares de hacer Scrum es usar Historias de usuarios, que son mantenidas por el Propietario del producto y se guardan en el Registro del producto. El Product Backlog es una lista de bastante alto nivel de todas las cosas que una solución necesita hacer, y una historia de usuario es generalmente una forma muy agradable de describir cada cosa en la lista. Las Historias de usuarios no son obligatorias, pero parecen ser una buena manera de no exagerar los detalles e inspirar la colaboración.

Entonces, de todos modos, cuando se hace una historia: el equipo ha creado, probado y desplegado algo que cumple con los criterios de aceptación, la historia no está CHUCKED, simplemente está marcada como hecha en el backlog, por lo que el backlog tiene alguna indicación de lo que se hizo en cada sprint: historias y los puntos asociados con ellas. Esto es lo que le permite calcular la velocidad, y es una documentación valiosa en sí misma.

Dicho todo esto, una historia de usuario puede ser toda la documentación necesaria para comprender un requisito, pero lo más probable es que sea algo para generar una conversación entre el cliente y el equipo de desarrollo. Como tal, hay muchas cosas que puede hacer en torno a esa conversación. Si se trata de una cuestión ad hoc cara a cara, como suele ser, el analista / desarrollador puede (y posiblemente, según su organización, debería) escribir cualquier decisión que se haya tomado y guardarla en algún lugar, como un Wiki o un repositorio de documentación. Si se trata de una conversación por correo electrónico, puede guardar los correos electrónicos. Si es una sesión de pizarra, tome una foto de la pizarra con su dispositivo móvil y guárdela. El punto es que estas cosas son las que lo ayudan a completar el código y podrían ayudarlo más adelante si necesita averiguar cómo o por qué lo hizo de la manera en que lo hizo.

Otro método para capturar los requisitos es incrustarlos de inmediato en casos de prueba (que creo que es a lo que DXM se refería). Esto puede ser realmente eficiente, ya que de todos modos debe probar cada requisito. En este caso, puede almacenar efectivamente sus requisitos en su herramienta de prueba.

Si se completa una historia (y se acepta) y luego el usuario cambia su necesidad, bueno, entonces probablemente deba crear una nueva historia. Si utiliza un wiki para su documentación, puede vincular la nueva historia con la original, y también vincular esa historia original con las nuevas cosas para que alguien que la vea sepa que las cosas cambiaron. Eso es lo bueno de los wikis: es fácil y bastante sencillo vincular cosas. Si está haciendo el enfoque basado en pruebas, actualizaría el caso de prueba para hacer frente al cambio o crearía nuevos casos de prueba para la nueva historia si lo nuevo y lo antiguo no son mutuamente excluyentes.

Al final, depende de cuál sea su necesidad. Si lo principal es hacer que la gente se ponga al día rápidamente, probablemente sea una buena idea que alguien escriba un documento de incorporación para ayudarlos. Entonces, que alguien haga eso. Como mencioné, los Wiki son una gran herramienta para mantener este tipo de cosas, por lo que puede considerar las soluciones de Atlassian que pueden integrar Confluence Wiki con Jira y Greenhopper para rastrear sus historias / tareas / defectos y administrar su proyecto en general. También hay muchas otras herramientas para elegir.

[actualización n. ° 1] Como señaló @MatthewFlynn, su experiencia con ágil y con muchos otros (incluido el mío) es muy diferente de la respuesta que proporciono aquí. La respuesta aquí se basa en mis observaciones de lo que funcionó y no funcionó en mi propio equipo en el pasado, combinado con muchos libros y blogs que leí sobre el tema ...

La mayor parte del impulso hacia el desarrollo ágil está específicamente dirigido a eliminar los documentos de requisitos.

Agile trata de eliminar la mayoría de la documentación y estoy de acuerdo con sus ideas, pero de todos los documentos, los requisitos tienen con mucho el mayor blanco pintado en ellos. La razón de eso (IMO) es que los documentos de requisitos están más alejados del código de trabajo real y de todos los documentos, lo que los hace

• menos precisa
• más difícil de mantener
• menos útil

Para guiar al equipo sobre lo que se debe desarrollar a continuación, Agile reemplaza los documentos de requisitos con una acumulación de historias que identifican en qué debe trabajar en los elementos siguientes y de mayor prioridad con el mayor rendimiento (tanto el dólar actual como el futuro) generalmente se colocan primero en esa lista

Sin embargo, una acumulación no debe confundirse con un documento de requisitos:

• En una cartera de pedidos, solo se debe completar un número N de historias. Cuanto más avanzada sea una historia, menos detalles debe incluir (es decir, no pierda su tiempo tratando de definir algo que no sucederá durante medio año) )
• Más allá de cierto punto, los artículos de "requisitos" ni siquiera deberían colocarse en una cartera de pedidos si están fuera de más de 2 ciclos de lanzamiento (también conocidos como incrementos potenciales de envío (PSI)). Incluso si sabe que el requisito es importante y debe hacerse en algún momento, resista la tentación de agregarlo al trabajo atrasado. Si es realmente importante, alguien lo recordará en la próxima versión. Si nadie lo recuerda, lo más probable es que no sea tan importante después de todo.

Una vez que se completa una historia, esa historia se elimina de la cartera de pedidos y se CHUCKED ⁽¹⁾ . Nuevamente, las historias no son requisitos. SOLO le dicen al equipo en qué trabajar después; No son para el registro histórico.

Sin embargo, en un proceso ágil adecuado, cada vez que entregue trabajo, parte de esa entrega debe ser pruebas de unidad / integración / aceptación. Estas pruebas son muy valiosas porque tienen muchos propósitos. No entraré en la lista completa, pero uno de esos propósitos es la documentación de su software de producción actual.

Una prueba documenta cómo debe comportarse el software dado un cierto conjunto de entradas y condiciones previas. También documenta cómo usar las API públicas (e internas) de su código. También sirve como una red de seguridad, de modo que cuando un nuevo desarrollador ingresa a un equipo e inadvertidamente rompe algo, ese error se detectará tan pronto como se registre.

El proceso ágil obviamente promueve aprovechar las pruebas unitarias automatizadas tanto como sea posible, pero todos sabemos que no todas las cosas pueden automatizarse. Su paquete de software siempre tendrá un conjunto de pruebas que deben ejecutarse manualmente. Sin embargo, a) sus desarrolladores deberían estar trabajando activamente en la automatización tanto como sea posible yb) su equipo de control de calidad debería ejecutar regularmente un conjunto manual de pruebas para que cualquier interrupción en la funcionalidad se descubra lo antes posible.

⁽¹⁾ - Desde que recibí varias respuestas para la parte "arrojada". En 5 años desde que se mudó a ágil, mi equipo nunca tiró una sola historia, incluso el 30% de las programadas, luego diferidas y luego olvidadas. Mi jefe quería mantenerlos "como referencia" y, sin embargo, nadie ha visto ninguna de esas historias.

Las personas generalmente están apegadas a sus datos y sé que es difícil imaginar tirar algo una vez que ya lo tiene, pero mantener el inventario (ya sea físico o eléctrico) no es gratuito y cuanto más lo pienso, más estoy de acuerdo con el "chucking". Esto es de "Requisitos de software ágiles: prácticas de requisitos ajustados para equipos, programas y la empresa" (p.190) : "Las historias de usuario se pueden desechar de forma segura después de la implementación. Eso las mantiene livianas, las mantiene amigables para el equipo y fomenta la negociación, pero las pruebas de aceptación persisten durante la vida de la aplicación ... "

¿Qué sucede si la historia del usuario cambia más tarde, cómo se actualiza y se mantiene como un artefacto? He visto a muchos equipos abrir un nuevo boleto / solicitud de función / informe de error en lugar de realizar un seguimiento de la historia original.

Administrar cualquier documentación puede ser difícil, independientemente de si está utilizando historias ágiles o un gran documento inicial, y para reducir la carga, la documentación debe ser mínima y actualizarse gradualmente para que coincida con los esfuerzos realizados en las pruebas y la implementación. Sin embargo, como aludió el OP, simplemente actualizar la documentación corre el riesgo de perder el historial de cómo el software ha evolucionado con el tiempo.

¿Es esto realmente importante? A veces puede ser. En su mayor parte, simplemente desea ver las historias / UML / lo que sea junto con las pruebas y el código en sí en este momento, sin embargo, cuando surgen preguntas sobre por qué una característica se ha implementado de una manera particular, a menudo puede ser útil para mirar a la historia con el fin de ver cómo la característica ha cambiado con el tiempo, para pintar una imagen más clara de por qué opción de implementación X fue elegida en lugar de la opción de Y .

Hay un par de formas en que puede realizar un seguimiento de dichos artefactos. Una de las mejores opciones puede ser mantener sus historias en una herramienta que le permita tener el texto de su historia versionado de manera similar a la versión de su código fuente. Los Wiki tienden a ser muy buenos en esto, y también lo son algunas de las herramientas de gestión de proyectos / problemas, como Trac o Redmineque mantienen historiales de cambios en los problemas mismos, así como las páginas wiki dentro de estos sistemas. Sin embargo, esto puede llevarse un poco más allá, para mejorar la capacidad de rastrear los cambios de un tema a otro, asegurando que las nuevas historias o problemas estén vinculados de alguna manera a temas e historias relacionadas más antiguas. Esto podría ser tan simple como agregar una identificación de problema / historia anterior al texto de una publicación / historia más nueva, pero puede mejorarse enormemente al incluir cualquier identificación de problema o historia al comentario de verificación cada vez que realiza un cambio en su sistema de control de versiones . Sin embargo, este método es de gran valor si sus confirmaciones son frecuentes y se limitan a una sola historia o problema.

La mayor dificultad, por supuesto, es que este tipo de enfoque requiere una atención cuidadosa y un compromiso por parte de cada miembro del equipo para ser consistente y mantener sus compromisos pequeños y frecuentes, y para aquellos que manejan las historias y / o los sistemas de seguimiento de problemas / proyectos para mantener además de los artefactos que proporcionan enlaces entre el estado actual de su implementación y todos los cambios que ocurrieron anteriormente.

Se ha dicho antes, pero creo que lo esencial es esto:

• Los requisitos pueden cubrir muchas facetas y, por lo general, dan como resultado más de una historia.

• una historia organiza el trabajo de un equipo en trozos lo suficientemente pequeños como para caber dentro de los límites de tiempo de un sprint.

• a menudo hay muchos detalles que deben definirse para que alguna función particular funcione correctamente. Aquí es cuando comienza a ser útil mantener estas definiciones en un documento de requisitos por separado, para mayor claridad, comprensión común y referencias posteriores.

Considere el legendario ejemplo de una tienda de mascotas en línea:

• La historia puede decir "Como usuario, quiero ver el IVA impreso en mi recibo, ...". Ahora, el cálculo del IVA (impuesto al valor agregado) puede ser un asunto complicado y probablemente necesite más trabajo del que sugiere esta historia.
• Puede haber una historia adicional que solicite que se haga el cálculo del IVA (por ejemplo, multiplique el monto total de ventas por la tasa del IVA ), pero es probable que no incluya todas las variaciones de ese cálculo.
• Al principio, el equipo se centraría en proporcionar el módulo básico, por ejemplo, tomar una lista de productos y su precio de venta, y devolver el importe del IVA. Eso es algo que un equipo puede lograr dentro del tiempo de un sprint.
• Es probable que haya muchas más historias para cubrir todos los casos posibles para el cálculo del IVA.
• Para mantener visibles las diferentes reglas de cálculo del IVA a través de sprints individuales y más allá, tiene sentido mantener un documento de requisitos por separado que enumere todas las diversas formas de calcular el IVA. Este documento puede evolucionar con el tiempo. De hecho, agregar una nueva sección podría ser parte de la tarea de una historia para completar.

Puede usar freemind para recopilar la lista de características. Cómo se hace, eche un vistazo a este tutorial (en algún lugar en el medio).

Cuando tiene una lista de características, puede escribir historias de usuarios. Esto se puede hacer mediante el uso de un archivo de texto simple, un documento de Word o algo tan complejo como una herramienta de administración ágil .

Cuando termina con las historias de los usuarios, se les da prioridad. Más tarde, a partir de las historias de los usuarios, las personas producen tareas, toman tareas y las implementan en código.

Todo esto se puede ver cómo se gestiona el proyecto ac # desde el comienzo en el otoño de la serie ágil de videocast .