Consideremos una historia simple para una pantalla de autenticación de usuario:
Como usuario,
quiero poder iniciar sesión con mi nombre de usuario y contraseña
para poder hacer xyz.
Esto se ve bien, pero faltan todos los detalles relacionados con lo que debería suceder cuando la contraseña es incorrecta, cuántos reintentos se deben permitir, validaciones y un montón de otras cosas que deberían incluirse en esa historia.
¿Dónde debería ir toda esa información en una configuración ágil de Scrum? ¿Es un FRS (o cualquier otro documento monolítico equivalente que contenga detalles de todas las especificaciones funcionales)? En caso afirmativo, dado que habrá cientos o miles de estas pequeñas historias, ¿cómo deberían sincronizarse entre sí las referencias a sus secciones FRS correspondientes? ¿Cuál es la mejor manera de gestionar este nivel de detalle en un mundo Scrum ágil?
Básicamente has acertado con el propósito de las historias de usuario. Verá, las historias de usuarios surgieron cuando teníamos grandes documentos de requisitos que tenían todos los detalles que el equipo de desarrollo podría necesitar para desarrollar el software. El problema con esto es que esos detalles toman mucho tiempo para documentarse y resulta que a menudo no son lo que el usuario quiere (o al menos no dan en el blanco). Ahora todo ese tiempo se ha perdido. En cambio, escribimos una historia de usuario que nos brinda la información suficiente para tener una conversación con la persona que la escribió. El equipo de desarrollo puede hacer preguntas y obtener una mejor comprensión de sus necesidades, luego crear algo que las satisfaga. Escribirán sus notas en algún lugar y, según su aplicación, incluso podría tener sentido que se almacenen en un lugar muy específico. Entonces, el propósito de las historias de usuario era alejarse de los documentos monolíticos y pasar a las conversaciones personales. Si vincula una historia de usuario a los detalles en un documento de requisitos extenso, ha eliminado el valor de las historias de usuario.
La respuesta corta es que no. La gran planificación inicial es ortogonal al desarrollo ágil. En su lugar, debe centrarse en el desarrollo iterativo e incremental con ciclos de retroalimentación estrictos para asegurarse de que está creando las cosas correctas y aceptando el cambio a lo largo del ciclo de vida del proyecto.
Hacer requisitos detallados o a gran escala al inicio de un proyecto es un antipatrón ágil. En particular, el Manifiesto para el desarrollo ágil de software valora:
Software de trabajo sobre documentación completa[.]
Del mismo modo, Scrum Theory evita explícitamente el uso de una planificación fija y por adelantado:
Scrum emplea un enfoque iterativo e incremental para optimizar la previsibilidad y controlar el riesgo.
Si bien no hay nada que le impida vincular historias de usuarios u otros tipos de elementos de la cartera de productos con requisitos funcionales, hacerlo suele ser un "olor de proyecto" que está arreglando el alcance, que idealmente es la parte móvil del Triángulo de Hierro en Scrum. Además, a menudo es una indicación de que está tomando decisiones de implementación demasiado pronto en el proceso. Las prácticas Lean requieren que tome decisiones arquitectónicas y de diseño en el último momento responsable , que casi nunca es al comienzo de un proyecto cuando generalmente se recopilan las especificaciones de requisitos funcionales.
Dentro del marco Scrum, debe aprovechar el marco para realizar una planificación justo a tiempo con el nivel adecuado de granularidad. En particular:
Si bien Scrum no lo requiere, las prácticas ágiles generalmente requieren la integración de un diseño basado en pruebas o un desarrollo basado en el comportamiento (a menudo en colaboración con las partes interesadas o los clientes) para garantizar que los requisitos funcionales en el alcance de la iteración actual estén bien definidos y sean comprobables. Este tipo de "documentación viva" suele ser más útil, más precisa, más fácil de mantener y más eficaz que los documentos de requisitos funcionales típicos.
Creo que parte del problema es que esto:
iniciar sesión con mi nombre de usuario y contraseña
no es un requisito. Es una elección de diseño disfrazada de requisito. El requisito real es algo así como: "Como usuario, necesito autenticarme (de manera única y segura) con el sistema para poder...". Elegir el nombre de usuario y la contraseña descarta inmediatamente otros medios de autenticación de menor fricción. ¿Ya inició sesión en Active Directory/G Suite/Office 365/otro proveedor de Oauth? ¿Podemos usar eso? ¿Qué pasa con el reconocimiento facial y la huella digital? ¿Es eso suficiente?
Tenga esto en cuenta a medida que avanza en sus historias de usuario. ¿ Le están diciendo cómo debe hacerse algo en lugar de lo que debe hacerse? Muy a menudo esto está bien; están ampliando/clarificando opciones de diseño anteriores. Pero a veces vale la pena dar un paso atrás y preguntarse qué problema realmente están resolviendo, y ¿hay una mejor manera?
Como dijeron otros, los detalles deben aclararse en el último momento responsable, a veces en el momento de la implementación en estrecha colaboración entre desarrolladores y, por ejemplo, empresarios o expertos en UX. Sin embargo, la información específica podría anotarse como criterio de aceptación. Los criterios más generales y repetitivos pueden estar mejor ubicados dentro de la Definición de 'Terminado' del equipo (o de las organizaciones).
Para los criterios de aceptación, es posible que también desee echar un vistazo a una sintaxis como Gherkin , y es posible que desee automatizar las pruebas con cosas como Cucumber como una documentación viva y de mayor valor agregado y como base para las pruebas de regresión.
"¿Cuántos reintentos deben permitirse, faltan validaciones y un montón de otras cosas que deberían incluirse en esa historia? ¿Dónde debería ir toda esa información en una configuración ágil de Scrum?"
Por eso tienes criterios de aceptación .
Pero me parece que tienes otro problema: ¿quién escribió tu FRS? ¿Por qué hiciste esa inversión, si sabías que sería un proyecto ágil? En Agile el equipo decide los detalles técnicos. Si lee el manifiesto ágil detenidamente, verá que los desarrolladores llaman a la revolución.
Todd A. Jacobs