En el manifiesto para el desarrollo ágil de software se puede leer:

Software de trabajo sobre documentación completa

Esto no significa que la documentación sea algo malo. En cambio, el código de trabajo es mejor para que pueda documentar lo que va a codificar.

Dicho esto, las historias de usuarios y los criterios de aceptación pueden ser todo lo que necesita para comprender los requisitos, teniendo en cuenta que no es responsable del Documento de visión y alcance.

Animo a las personas a no pensar en las historias de usuarios (o en los elementos pendientes de ningún tipo) como otra forma de requisitos. Existe una diferencia crítica de pensamiento entre el uso de documentos de requisitos y los trabajos atrasados ​​que los equipos y las organizaciones deben comprender para utilizar estos últimos de manera efectiva. Los retrasos son emergentes. Esto significa que no solo cambian con el tiempo (no hay nada que impida que cambie un BRS), sino que los elementos posteriores del backlog se basan y modifican elementos anteriores, de modo que es posible que los elementos anteriores ya no describan el comportamiento de la aplicación.

Esto significa que la documentación que necesita estará en gran medida separada de sus requisitos (piense en ello como lo que entró en el desarrollo sabiendo frente a lo que hizo en el desarrollo). Tenga en cuenta que cosas como ISO 9001 se trata principalmente de validar que sigue sus procesos (cualesquiera que sean) y que registra la información que necesitará para auditar o mantener el software más adelante. Los días en los que los estándares de documentación y auditoría consistían en asegurarse de que el resultado coincidiera perfectamente con la idea original se han ido. El único lugar que veo que ya es donde lo tienen escrito en sus procesos y no quieren cambiar los procesos documentados, en cuyo caso es una elección consciente, no una restricción.

Agregando esta sección para responder al comentario:

Agile y Scrum pueden ser confusos de adoptar porque hay muchas buenas prácticas que la gente ha ideado y que se han agrupado en Agile y Scrum, mientras que, al mismo tiempo, muchas de las prácticas y principios básicos se dejan de lado.

Agile: Agile es solo declaraciones de valores y principios. Puede encontrarlos en https://agilemanifesto.org/ . Realmente no puedes practicar Agile; más bien, tus prácticas pueden ser más o menos ágiles (como adjetivo) dependiendo de qué tan bien alineadas estén con estos valores y principios.

Scrum: Puedes seguir las prácticas de Scrum. Scrum es un marco ligero, lo que significa que brinda una cantidad de eventos, artefactos, roles y prácticas, pero hay mucho espacio para completar cómo hace el trabajo y cómo se ve ese trabajo. Puede encontrar la última versión de las Guías de Scrum en https://www.scrumguides.org/scrum-guide.html . Probablemente valga la pena señalar que si muchos equipos eligen qué seguir fuera de Scrum. Si bien eso no es intrínsecamente incorrecto, está diseñado para funcionar como un todo y se pierden muchos beneficios cuando comienza a abandonar las prácticas.

XP: No mencionó esto, pero muchas prácticas comunes en Scrum que no se enumeran específicamente en la Guía de Scrum (como Historias de usuarios) son en realidad de XP. XP es mucho más prescriptivo sobre cómo hacer el trabajo. Hay una curva de cambio bastante grande con la adopción de XP y no veo que muchos equipos lo hagan, pero cuando comenzó Scrum, a menudo asumían que XP iba ​​a llenar parte del espacio de procedimientos en su marco, por lo que siempre vale la pena. mirando a. http://www.extremeprogramming.org/ es un buen lugar para comenzar, aunque un poco torpe.

BA del lado del cliente aquí, actualmente en medio de una iniciativa de modernización de infraestructura y almacenamiento de datos empresariales a gran escala. Los equipos de proyecto usan Jira en lugar de TFS y, aunque los conceptos son los mismos, nuestro uso de la plataforma es principalmente como una herramienta de seguimiento y generación de informes para interactuar con el equipo central (empresarial) de desarrollo Agile. El enfoque de nuestras historias de usuarios es principalmente discutir y rastrear pruebas, requisitos de mejora, informes de defectos: todo el tipo de comentarios que llegan "después del hecho" del producto de trabajo de cada sprint, por así decirlo, y mucho después de los requisitos iniciales. ha sido publicado.

Comentarios clave sobre las especificaciones de BRS/SRS : deben solicitarse a los usuarios finales en la fase de planificación/creación de prototipos para priorizar el desarrollo de la arquitectura y desarrollar el plan general del proyecto; esto se puede lograr con una encuesta u otra herramienta de evaluación de solicitudes, redactada por líderes técnicos y el E/PMO y enviada a los clientes potenciales en las etapas iniciales de planificación. Esto permite que el E/PMO calcule el alcance de referencia y la viabilidad de los requisitos preliminares, haga las asignaciones de recursos necesarias y priorice el trabajo en olas, sprints, a lo largo de un tablero kanban, etc. para las metodologías en juego.

Las historias de usuarios , por otro lado, tienden a estar más enfocadas en responder a los comentarios sobre canales, servicios, dominios o plantillas particulares que surgen después de que los consumidores hayan realizado un análisis de factibilidad y brechas contra el lanzamiento prototipo.

En resumen, si bien el propósito exacto de cada documento variará entre diferentes organizaciones y proyectos, la documentación de requisitos y las tiendas de usuarios son, en última instancia, manzanas con naranjas, sin embargo, los tres podrían combinarse en la misma canasta de frutas. El énfasis en el papel de cada uno debe adaptarse a los intereses del grupo o grupos que impulsan la iniciativa.

Los usuarios finales establecerán sus requisitos con anticipación e independientemente del trabajo que se realice en cada sprint; del mismo modo, ajustarán continuamente su plan de acuerdo con los comentarios de BA/DevOps a lo largo del camino: esta comunicación se transmite a través de las historias de los usuarios durante el desarrollo como una especie de boletín de seguimiento. Los tres son complementarios, pero a menudo servirán para documentar los intereses y necesidades de grupos de accionistas claramente diferentes.

Documentación como código

es la frase clave aquí.
Los marcos de prueba modernos combinan contenido legible en inglés con las instrucciones para realizar las pruebas reales, las llamadas al sistema, las interacciones de la interfaz de usuario, etc.

En BDD (Behavior Driven Development), al igual que con TDD, especifica el comportamiento por adelantado como una prueba, por ejemplo

Los usuarios ingresan AB234, presionan regresar y ven su código de acceso

La prueba falla, por supuesto, ya que aún no se ha escrito ningún código real para implementarla.

Luego escribe el código y la prueba pasa y luego, críticamente, tiene una prueba más en su suite para el futuro (a menudo denominada regresión, pero evito ese término, es solo la suite de prueba, igual que todas las pruebas). Ahora puede ejecutar esta prueba para asegurarse de que la funcionalidad funciona y, a menudo, incluye un indicador o una configuración para mostrar la parte legible por humanos de las pruebas que pasaron o fallaron.

Enfoque ágil ≠ falta de documentación

Si necesita documentar cosas realmente importantes, como recursos, horas de trabajo, equipo requerido, por supuesto que puede hacerlo. Prefiero decir que deberías hacerlo.

Usando el enfoque ágil, puede crear solo documentos de resumen que representen la situación en curso.

Un hecho interesante es que en el enfoque tradicional hay mucha documentación completa que en realidad no es esencial ni valiosa.