Documentación de requisitos en un proyecto Agile

Uno de los valores del Manifiesto Ágil es "software de trabajo sobre documentación completa" . Y, sin embargo, existe la necesidad de documentar los requisitos. Si se modifica una función desarrollada hace 6 meses, yo (como desarrollador) necesito un lugar al que acudir para hacer referencia a los requisitos existentes. Obviamente, los requisitos documentados también son importantes para los recursos de control de calidad. Además, si surge una pregunta sobre un requisito en particular, debe haber una sola ubicación a la que se pueda hacer referencia para aclarar en lugar de pedirme que analice mi código o una cadena de correos electrónicos para ver cómo se construyeron las cosas.

Todos los equipos Agile en los que he estado han utilizado una gestión en línea (por ejemplo, Rally, Jira) donde los requisitos se pueden definir en cada historia de usuario como criterios de aceptación. Si bien considero que esta es una solución/ubicación extremadamente funcional para la documentación de requisitos, ya que constantemente usa la herramienta para avanzar en la historia, parece un poco informal. En el proyecto más reciente en el que trabajé, el equipo de gestión del proyecto mantuvo un BRD (Documento de requisitos comerciales) que contenía todos los requisitos del sistema en un solo documento. En este proyecto en particular, el BRD se utilizó para la aprobación del cliente sobre lo que se iba a desarrollar y también fue revisado por el equipo de administración de mi empresa (de consultoría) para garantizar que todo se completara. El problema con los BRD en mi experiencia es que son detallados hasta el punto de que no se pueden leer.

El marco Agile no se preocupa por definir un medio específico de documentación, pero ¿existe una mejor práctica única para documentar los requisitos en un proyecto de desarrollo Agile?

¿Por qué cree que es necesario documentar los requisitos fuera del conjunto de historias de usuario completadas (y los criterios de aceptación asociados)?
En otros términos, ¿qué valor se agrega al mantener sus requisitos en dos herramientas o formatos diferentes? Primero, considere el valor para las partes externas (clientes, usuarios). Segundo, considere el valor interno. Luego, considere el esfuerzo necesario para crear y mantener sus requisitos en dos lugares. Tenga en cuenta que desea tener una única fuente de información .
@ThomasOwens Estoy totalmente de acuerdo en que debería haber una única fuente de información, de ahí este tema :). Como se indicó, los altos mandos de mi empresa utilizaron el BRD, que era el "documento de requisitos" de facto para el proyecto, básicamente como un contrato que el cliente y nosotros acordamos. No creo que las historias de usuarios individuales sean lo suficientemente formales para su satisfacción ni creo que estén dispuestos a usar una herramienta como Rally (no es que eso sea aceptable).
Entonces, si las historias de usuario + los criterios de aceptación son insuficientes, ¿por qué los estás usando? No hay nada que diga que no puede usar una especificación de requisitos formales en cualquiera de los métodos ágiles.
@ThomasOwens No es el contenido de las historias de usuario + AC. Es su ubicación; en una herramienta en línea con la que un gerente puede no estar familiarizado, separados por historia individual. Estoy comparando esto con un BRD que es un único documento de Word omnipresente.
Entonces, tienes opciones. Necesitas una única fuente de información. ¿Qué vas a hacer? ¿Ajustar su proceso para capturar los requisitos en un BRD, un documento de Word cargado en un lugar particular que las personas adecuadas pueden editar (quizás con el historial de revisión)? ¿O capacitar a sus gerentes para que entiendan el proceso y usen las mismas herramientas que el equipo?
¿O crear el documento único para los gerentes a partir de las historias de Jira? No estoy seguro de si Jira lo admite de forma nativa, aunque hay algo para compilar notas de la versión de los campos de problemas, pero estaría dispuesto a apostar que hay alguna extensión (complemento) que hace esto, ya que probablemente no seas el único con este desafío. .

Respuestas (2)

Hay tres principios ágiles que están en juego:

  1. "Software de trabajo sobre documentación completa" del Manifiesto Ágil .
  2. "La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial". Este es uno de los Principios detrás del Manifiesto Ágil .
  3. La fuente única de información de Agile Modeling , que reúne varias técnicas y principios para diseñar y documentar software en un entorno ágil.

Mantener los requisitos en una herramienta como Rally o JIRA en forma de historias de usuario + criterios de aceptación y simultáneamente en un documento de requisitos no es inherentemente ágil. Está creando un exceso de documentación, no logra maximizar el trabajo no realizado y tiene múltiples fuentes de información que deben mantenerse (y pueden perder la sincronización entre sí).

La única solución es mantener sus requisitos en un solo lugar. Si su equipo está usando una herramienta ahora y algunas partes interesadas no se sienten cómodas con esa herramienta, tiene dos opciones. La primera opción es que su equipo pueda ajustar su proceso para que todas las partes interesadas se sientan cómodas. La segunda opción es que su ScrumMaster o Agile Coach pueda educar a las partes interesadas sobre el valor

No hay nada que diga que un proyecto ágil no puede crear y mantener un documento de requisitos en forma de hoja de cálculo o documento de Word y trabajar a partir de eso. Después de todo, los buenos requisitos (entre otras cosas) especifican la importancia para permitir la priorización, son verificables y se pueden vincular a la información necesaria para probarlos (incluso si no está todo disponible en una herramienta o documento) y se pueden rastrear a otro trabajo ( probablemente sea una identificación). Si tiene una especificación de requisitos, su equipo aún puede rastrear tareas de trabajo, casos de prueba o criterios de aceptación a elementos en el BRD a través de los identificadores de requisitos únicos, por ejemplo.

Eso es un poco de una simplificación excesiva. Es cuestión de ver el bosque desde los árboles. Por lo general, el proyecto se beneficiaría de algún tipo de documentación de alto nivel que sea más una estrategia que una táctica. Los comentarios de Jira son solo de naturaleza táctica. Una de las debilidades que noté por tener un ciclo de Sprint demasiado corto es que los proyectos en realidad serpentearán con el tiempo. Los problemas fundamentales se dejarán sin resolver en la búsqueda de objetivos a corto plazo.

El pensamiento ágil sugiere que la mejor práctica es documentar lo suficiente. Si necesitas documentar algo por una buena razón, ¡documentalo!

En el desarrollo de software cada proyecto tiene sus propias necesidades, no hay una única fuente de verdad definida. Para algunos equipos o proyectos, los casos de prueba automatizados son suficiente documentación. Algunos necesitan una forma más formal, como historias de usuarios en un sistema de flujo de trabajo, en lugar de solo fichas.

Los BRD suenan como una sobredocumentación y una forma de tener el comando y el control sobre el equipo de desarrollo por parte del cliente, pero si funciona para el proyecto y el equipo, no es anti-ágil en sí.

El marco Agile no se preocupa por definir un medio específico de documentación.

La mayoría de los marcos Agile no especifican nada, excepto ser impulsados ​​por el valor y trabajar en iteraciones y, por supuesto, los otros principios . En general es una mentalidad. Los marcos que especifican todo se centran en procesos y herramientas sobre individuos e interacciones . Pregunta qué tan ágil es realmente ese marco.

Encuentra una forma de trabajar que se ajuste a tu industria, empresa, proyecto o producto. Inspeccione y adáptese continuamente, de esta manera eventualmente encontrará la forma óptima de trabajar.

Documentación de requisitos en un proyecto Agile
RespuestasAquíPolítica de privacidad1y, 0v