¿Se pueden convertir SRS tradicionales en User Stories?
Muchos proyectos gestionados de manera tradicional comienzan con una Software Requirements Specification (SRS). En algún momento durante el proyecto se decide cambiar a un enfoque ágil. En este caso, surge naturalmente la pregunta de si una SRS puede servir como el nuevo Product Backlog ágil. Algunos equipos incluso consideran reescribir la SRS en un Product Backlog con User Stories. Pero, ¿es realmente necesario?
Antes de abordar esta pregunta, quiero aclarar brevemente qué entiendo exactamente por Requirements Specification o SRS. He notado que estos documentos pueden variar mucho entre diferentes empresas. Básicamente, me refiero a un documento típico que contiene declaraciones como "El sistema debería...".
Mi consejo aplica en general a casi todos los documentos de especificación tradicionales. Esto es válido para cualquier documento con requisitos integrados y numerados, independientemente de si todas las declaraciones están formuladas como "El sistema debería...".
Algunas desventajas de usar una SRS como Product Backlog
En un producto ágil, el Product Backlog tiene dos funciones importantes:
- Sirve como archivo de todo el trabajo que debe realizarse
- Facilita la priorización del trabajo
El Product Backlog le dice a un equipo qué trabajo debe realizarse y además puede utilizarse como herramienta de planificación para secuenciar el trabajo. En cambio, una SRS tradicional solo indica qué trabajo debe completarse en un proyecto.
Una SRS no está diseñada para escribir requisitos que puedan incorporarse a un Sprint, ni para priorizarlos. Escribir requisitos independientes es, en el mejor de los casos, un objetivo secundario, lo cual se puede ver claramente en la organización jerárquica de la mayoría de los documentos SRS con sus requisitos numerados (1.0, 1.1, 1.1.1, etc.).
Mientras una SRS se vea como un documento de requisitos puro, esto no genera ningún problema. Sin embargo, si los ítems de una SRS deben servir como Product Backlog Items y ser priorizados, surgirán problemas.
Con una SRS, a menudo no es posible para un equipo desarrollar el requisito 1.1.1 sin desarrollar también simultáneamente los requisitos 1.1.2 y 1.1.5. Estas dependencias hacen las cosas mucho más difíciles que si simplemente se seleccionara y trabajara una Story tras otra de un Product Backlog bien elaborado.
La priorización de ítems subordinados es tan difícil en una SRS como la identificación de features subordinados para la creación de un Minimum Viable Product.
Una Software Requirements Specification es buena como especificación de requisitos. Es buena para representar lo que un sistema o producto debe hacer. (Por supuesto, no aborda todos los aspectos ágiles de requisitos emergentes, colaboración, aprendizaje, etc. Sin embargo, asumo que estas cosas ocurren).
Mi recomendación sobre SRS en el Sprint
Básicamente, no recomendaría sacrificar tiempo para reescribir una SRS impecable. Por supuesto, podría ser útil reescribir la SRS en User Stories y un bonito Product Backlog considerando los problemas mencionados, pero generalmente el esfuerzo simplemente no vale la pena.
Alguien tendría que tomarse el tiempo para hacerlo, pero esa persona normalmente puede usar ese tiempo de manera mucho más productiva. Desaconsejo especialmente reescribir una SRS si otros miembros del equipo tendrían que esperar al nuevo Product Backlog para poder comenzar su trabajo.
El Scrum Master u otro miembro del equipo debe encontrar una manera de medir el progreso incluso con una SRS y asegurarse de que ningún requisito se pierda. Normalmente es una buena idea involucrar al equipo de calidad para garantizar que todo en la SRS se haya completado o se haya listado en el Backlog.
Además, es importante comunicar a quienes participan en la creación de los documentos SRS que en futuros proyectos lo hagan de una manera que sea más compatible con Agile. Si lo logras, podrás evitar en tu próximo proyecto los problemas que surgen por la discrepancia entre Agile y un documento SRS tradicional.
Este texto proviene del blog de Mike Cohn y fue traducido por nosotros al español.
Requisitos no funcionales
=> Descubre aquí cómo convertir requisitos no funcionales en User Stories.
Sprint Planning orientado al compromiso
=> Aquí descubrirás por qué prefiero el Sprint Planning orientado al compromiso frente al Sprint Planning orientado a la velocidad.
