¿Cómo pueden las historias de usuario no contener requisitos (cuando están escritas en una tarjeta) y aún ser implementables?

18

Me han dicho "Las historias de usuario no son requisitos, es solo un recordatorio de lo que el cliente quiere, no se pueden poner requisitos dentro de una historia". Pero tomemos como ejemplo que un cliente desea un procesamiento diferente para diferentes tarjetas de crédito. Hay requisitos estrictos que deben implementarse y conocerse para poder escribir casos de prueba. ¿Dónde deben ir los requisitos si no están en la historia del usuario?

¿Cómo pueden desarrollar los desarrolladores a partir de una historia si no hay requisitos más bajos? ¿Cómo pueden los probadores escribir casos de prueba (detallados) basados ​​en una historia de usuario? ¿Dónde viven los requisitos como las restricciones de la base de datos, la validación de campos, etc., fuera de la historia del usuario?

usuario144171
fuente
66
Las historias de usuarios son solo eso: requisitos de nivel de usuario. Los "requisitos de software" de nivel inferior (a menudo, las limitaciones que se consideran aceptables) siempre deben cosecharse por separado y documentarse por separado con una referencia adecuada.
Gusdor
77
El punto de obtener las historias de los usuarios es que la mayoría de los usuarios de su programa nunca sabrán ni les importará cómo funciona . No les importa la estructura de la base de datos, la separación de preocupaciones, las estructuras de clase, etc. Se preocupan por la estabilidad, la velocidad y la facilidad de uso. Es por eso que captura sus historias, para averiguar para qué van a usar el programa. La forma de implementarlo es un nivel completamente separado de requisitos, los usuarios generalmente no podrán o no estarán dispuestos a informar ese proceso.
jonrsharpe
2
mosquito: En realidad no. Pregunté porque estoy realmente interesado en cómo se puede hacer esto correctamente, ya que estoy seguro, dado el uso generalizado de SCRUM, esto debe ser un problema para muchos equipos.
user144171
44
@maple_shaft El problema con los elementos "desvergonzados" es que estos tienden a atraer respuestas desvergonzadas. Estoy de acuerdo en que hay un núcleo sensible en allí, se preguntan si puede ser de edición ed sólo para mantener ese núcleo y acabar con invitación a respuestas Ranty
mosquito
2
Aquí hay una buena pregunta, pero está escrita como una diatriba. Hice un intento de edición.
DA01

Respuestas:

28

Esta respuesta se centrará en cómo trabajar con Historias de usuarios y requisitos de nivel inferior. No discutiré las virtudes, o la falta de ellas, de Scrum o Agile. Tampoco voy a hablar de gurús.

Esta respuesta asume que estás a bordo con Scrum pero aún no has encontrado una manera de hacerlo funcionar para ti.

Como otros han mencionado, las Historias de usuarios están destinadas a cubrir cómo les gustaría a los usuarios que sea el software. Debido a que a los usuarios no les importan las cosas de implementación de bajo nivel como tablas de bases de datos, restricciones, patrones arquitectónicos, etc., no encontrará tales detalles en una historia de usuario.

Sin embargo, eso no significa que estos detalles no deben registrarse en ningún lado.

Cuando los desarrolladores implementan Historias de usuarios, deben conocer los detalles de nivel inferior que los Usuarios típicos no sabrán. Esta información puede provenir de PYME, BA, el Propietario del producto, su arquitecto o cualquier otra persona experta o con una mentalidad técnica.

¿Esto significa que los detalles de bajo nivel deben registrarse en las Historias de usuarios? No y sí).

En algún momento entre el momento en que se crea y se implementa la historia, alguien tendrá que averiguar cómo implementarla. Esto generalmente toma la forma de conversaciones con las personas involucradas en la historia (usuario, arquitecto, desarrollador, etc.). Estas conversaciones deberían dar lugar a criterios de aceptación inequívocos que delineen claramente el alcance de la implementación de la historia del usuario. Estos detalles deberán registrarse en algún lugar y donde eso realmente depende de usted. La clave aquí es que estos detalles se obtienen después de que se haya creado la historia de usuario. Creo que esto es lo que tu guru está tratando de enfatizar.

Como desarrollador, está claro que necesitará una forma de asociar requisitos más específicos con su Historia de usuario. La forma en que lo haga depende completamente de su equipo.

Si las personas de su equipo desean mantener estos detalles fuera de las Historias de usuarios, entonces es posible que deba respetarlos. Hay beneficios al mantener sus historias de usuario de alto nivel libres de detalles de implementación. Los mantiene esbeltos y su cartera de pedidos se puede leer como un historial de lo que querían sus usuarios y propietarios de productos. Solo haga conocer sus necesidades como desarrollador también. Debería poder llegar a un compromiso en el que simplemente vincularse a la Historia del usuario mantenga a todos felices.

MetaFight
fuente
3
Los criterios de aceptación de +1 agregan más detalles
fraccional
3

Sí, es BS. Y Scrum no es ágil.

Odio la rigidez de los llamados practicantes ágiles que te dicen que hay una forma de hacerlo ágil y que debes seguir todas las reglas establecidas en las sagradas escrituras de cualquier metodología 'ágil' que utilicen. Es todo BS.

Ágil se trata de ser ágil.

Agile se trata de hacer cosas con un mínimo de sobrecarga. Esto no significa "sin documentación", ya que generalmente terminas documentando más en un rol ágil, simplemente continúas con la documentación sin tener que planificar un proceso para hacer la documentación. De manera similar con la codificación, prueba y captura de requisitos. Las únicas cosas que importan en un proceso ágil son aquellas que lo ayudan a realizar su trabajo, de manera rápida y eficiente, sin ningún BS.

Entonces, en este caso, si poner los requisitos del usuario en las tarjetas lo ayuda a escribir, probar, documentar y demostrar el código que se necesita ... ponga los requisitos en la tarjeta y dígales a los gurús que el equipo siempre tiene la razón.

¿Qué piensa el resto de su equipo de desarrollo? En una metodología verdaderamente ágil, si todos piensan que los requisitos deben escribirse por adelantado sin ninguna 'conversación de usuario', entonces eso debería ser, usted hace lo que el equipo cree que funciona mejor para que ellos hagan su trabajo. Si el equipo piensa que las conversaciones de los usuarios son algo bueno, escúchelas y comprenda por qué piensan esto y sumérjase en su forma de trabajar.

gbjbaanb
fuente
44
¿Le importaría expresar esto de una manera menos (es decir, no) despectiva? Estoy de acuerdo con usted en el tema, pero las personas tienen opiniones diferentes y eso no es justificación para perder sus modales de esa manera.
Frank
En realidad, no puedo imaginar requisitos no escritos por adelantado, incluso para las cosas más simples, como los campos numéricos, necesita conocer la longitud, el tipo de datos y las validaciones. Según esos gurús, estas cosas no son necesarias para estar en la historia. Pero cuando escribe el código, los Estados Unidos de alto nivel son inútiles, debe conocer las restricciones, los flujos, etc., etc. Nunca he visto un proyecto con Estados Unidos de dos oraciones que fuera eficiente para la implementación y las pruebas.
usuario144171
3
El cliente aceptó un número entero de 8 bits, por lo que no es mi culpa.
JeffO
2
@gbjbaanb: Ágil es solo una nueva palabra elegante para "usar el sentido común", es decir, encontrar el equilibrio adecuado entre el análisis / diseño inicial y ofrecer rápidamente una solución parcial para recopilar comentarios. Encuentro el término ágil bastante irritante porque hay muy poco nuevo en estas ideas, aparte del nombre. Lo peor sucede cuando un marco bastante inflexible como SCRUM se impone como ágil . IMO realmente ser ágil significaría dejar las palabras ágil y SCRUM y adaptar su proceso a sus necesidades, como siempre habíamos estado haciendo antes de que comenzara la ola ágil.
Giorgio
1
@Alex está preguntando mucho en el contexto de SCRUM y procesos ágiles.
gbjbaanb
3

Simplemente no llame a esto una historia de usuario y todos estarán felices.

Creo que la respuesta es, puedes escribir esto donde quieras.

En general, las implementaciones específicas no se incluyen en una historia de usuario por algunas razones:

  1. Sabe lo que quiere el cliente, pero no sabe cómo se implementará.
  2. El cliente es consciente de que hay requisitos más específicos involucrados, pero realmente no le importa y / o los comprende de todos modos.
  3. Todos piensan que son plenamente conscientes de las implementaciones específicas en este momento, pero nadie quiere escribirlas porque, según su experiencia, todo va a cambiar de todos modos y nadie querrá volver a escribirlas.

No hay reglas que omitan documentos adicionales cuando sea necesario. Tal vez el cliente necesita acceso a él y tal vez no. Si sus esperanzas son generar algún tipo de contrato entre usted y el cliente sobre la implementación específica como si pudiera seguirla y cuando no funciona, culpe al cliente por aceptarla, está equivocado. Si el cliente comprende los detalles técnicos del procesamiento de la tarjeta de crédito, debe compartir estos documentos con ellos y posiblemente hacer que formen parte de la conversación.

JeffO
fuente
1
Pero aquí está el problema, algo de clain US es todo lo que necesita, pero digo que no es posible cuando la historia trata sobre "qué" y no sobre "cómo". Si quieren una pantalla de inicio de sesión, ¿qué longitud tendrá el campo? ¿Qué personajes se permitirán? etc ... a los usuarios no les importa, pero los desarrolladores y evaluadores sí lo harán y, por lo tanto, esto debe escribirse en alguna parte.
user144171
44
¡Así que escríbelo! No hay nada de malo en la documentación complementaria si eso es lo que se necesita para hacer el trabajo. Solo comprenda que en muchos casos, no puede tratar esto como una especie de contrato de cliente. El cliente realmente usará su pantalla de inicio de sesión y luego le dirá que necesita más caracteres, independientemente de lo que diga su documentación. Ahora puede decidir si desea cambiar su código, la documentación o ambos.
JeffO
Y si es una tarea masiva ajustar la longitud de una entrada, su código no es muy ágil de todos modos, por lo que poca o ninguna documentación no hará mucha diferencia.
JeffO
2
@ user144171 Intentar escribir TODOS los requisitos para un proyecto, o una característica, por adelantado, y de la manera más detallada posible, hasta el último bit, es tan malo como no tener ningún requisito. Lo mismo ocurre con el diseño.
AK_
@AK_ No creo que esté afirmando que todo esto debe hacerse por adelantado, pero ciertamente debe hacerse por adelantado antes de correr cuando exista un retraso considerable.
maple_shaft
2

Creo que si lo que le dicen sus consultores de Scrum es que Scrum no requiere requisitos, entonces tiene algunos consultores muy pobres. Incluso se equivocan al decirle que una historia de usuario no es un requisito en absoluto, sino que es un tipo de requisito.

¿Cuáles son los diferentes tipos de requisitos de software?

Requerimientos comerciales

Estas son generalmente una necesidad comercial de alto nivel, algo que generalmente equivaldría a algún tipo de declaración de estilo ejecutivo sobre un sistema. Es intencionalmente de alto nivel y amplio y, por sí solo, no se puede implementar sin muchos más detalles.

Requisitos de usuario

Estos son los requisitos de User Story con los que está familiarizado. Generalmente pueden caber en una nota adhesiva.

  • Actor: normalmente, un usuario o parte interesada.
  • Necesidad: algún elemento o funcionalidad general que necesita el usuario
  • Motivo: la razón o el contexto detrás de por qué existe esta necesidad
  • Criterios de aceptación: este es el marco para las pruebas de aceptación del usuario y durante la demostración de Sprint cómo el propietario del producto podrá decidir si se acepta o no una historia de usuario.

Requisitos funcionales o del sistema

Esta parece ser la pieza que falta en tu rompecabezas. A partir de los requisitos de nivel de usuario, un requisito funcional define los actores y las propiedades de un sistema a nivel de sistema, así como los comportamientos y funciones de un sistema. Esto también podría hacerse en formato de historia e incluirse en su cartera de pedidos. Estos elementos deben ser independientes y pueden implementarse independientemente de los requisitos de cualquier usuario.

  • Actor: un sistema o componente de algún tipo.
  • Necesidad: una necesidad, propiedad o declaración de comportamiento de un sistema que debería existir.
  • Motivo: un contexto detrás de por qué esto es necesario en el sistema
  • Criterios de aceptación: escenarios, comportamientos, funciones y flujos que son necesarios para comunicar cómo se deben realizar las pruebas de Sistema e Integración. Cuando se pasan estos tipos de pruebas para el requisito, entonces sabemos que este requisito funcional se ha completado. Estos pueden existir en la documentación externa de sus historias de usuario, pero deben completarse antes de que estas historias se asignen en un sprint.

Los requisitos funcionales definen su solución, que suena como lo que está describiendo como la brecha en su proceso.

Tipos de requisitos notables que deben mencionarse pero que no tienen importancia para su pregunta: requisitos no funcionales, requisitos técnicos, etc.

árbol de arce
fuente
No estoy seguro acerca de su distinción entre los requisitos del usuario y los requisitos funcionales. Los requisitos del usuario, como en los EE. UU., Deben ser requisitos funcionales, y los requisitos funcionales son bastante distintos de los requisitos del sistema.
Alex
@Alex: Historia / requisito del usuario => desea retirar dinero del cajero automático, requisito funcional => el tiempo total para dispensar facturas no puede exceder los 30 segundos. El requisito del usuario no abarca el requisito funcional.
jmoreno
@jmoreno Esa "historia de usuario" en su ejemplo no es una historia de usuario, es el punto de partida de una historia de usuario. Y el "requisito funcional" sobre el tiempo de ejecución se encuentra en una zona gris, el principal requisito funcional para dispensar facturas, la restricción de tiempo podría tener muchos orígenes.
Alex
2
@jmoreno En realidad, una métrica de rendimiento como esa se considera un requisito no funcional a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors . Los comportamientos en sí mismos son funciones de un sistema . La historia del usuario contrasta ambos al definir la necesidad de un usuario. La función de un usuario es, en cambio, lo que conocemos como un caso de uso y no un requisito funcional.
maple_shaft
@Alex Vea mi comentario arriba. Creo que ambos están confundidos sobre qué es un requisito funcional.
maple_shaft
1

Una historia de usuario es un tipo específico de artefacto con el objetivo de describir la interfaz que el usuario espera del sistema y es por eso que los detalles de bajo nivel simplemente no pertenecen allí. Si los coloca allí, está cambiando la intención del artefacto y ya no se ajusta a la definición de Estados Unidos.

Utilice otras formas de especificación para capturar requisitos de nivel inferior y decisiones de diseño. Exactamente cuáles deberían ser estos otros formularios es algo que debe resolverse en su organización y personalizarse para su entorno específico.

Tu pregunta suena muy similar a algo como

Tengo este CarFactory y necesito que también fabrique Bicicletas, pero nuestro "Gurú" de OOD dice que no se me permite hacerlo. ¿Qué es este BS?

Respeta la separación de preocupaciones y la cohesión de tus artefactos, tanto los que están en tu código como los que están en tus procesos.

Alex
fuente
1

Creo que el propósito de este enfoque no es restringir las historias de los usuarios, sino evitar malos requisitos.

En mi experiencia, los usuarios son generalmente incapaces de escribir requisitos. Los desarrolladores son generalmente incapaces de escribir requisitos. Diablos, admitámoslo directamente: ¡los requisitos son difíciles de escribir!

Creo que sería válido para un usuario escribir algo en la jerga de requisitos como parte de una historia de uso. Sin embargo, hacerlo no debería convertirlo automáticamente en un requisito. Tener dos historias de uso conflictivas es un problema menor; Tener dos requisitos en conflicto es un problema importante de ruptura de contrato. No tiene sentido promocionar uno a otro antes de tiempo.

Creo que el punto de vista draconiano proviene del reconocimiento de la naturaleza humana. Si las personas comienzan a pensar en las historias de los usuarios como un lugar para poner requisitos, comenzarán a hacerlo. La ventaja real de usar historias sobre otros medios de recopilación de requisitos, como la información, es que están redactadas en la redacción y notación natural del usuario. Esto hace que sea más probable que los desarrolladores piensen desde la perspectiva del cliente. En un mundo perfecto, la jerga de requisitos fríos también podría ir allí. En realidad, tales palabras tienden a hacer que los desarrolladores se aferren a los requisitos fáciles de entender y se pierdan las sutiles palabras y matices que el desarrollo ágil quiere descubrir usando historias de uso.

Cort Ammon - Restablece a Monica
fuente
1
El problema con esta línea de pensamiento es que funciona bien en un proyecto creativo donde las necesidades del usuario son claras pero las especificaciones estrictas son limitadas. Cuando comenzamos a hablar sobre interacciones complejas del sistema y, especialmente, las restricciones regulatorias y la necesidad comercial de parámetros del sistema definidos, las historias de los usuarios a menudo no logran capturar los detalles importantes. Entonces inician la conversación, pero cuando tengo 20 páginas de especificaciones y reglas duras y flexibles, eso es demasiado para absorber en una "conversación". Los requisitos funcionales son necesarios aquí también.
maple_shaft
1
Estoy de acuerdo en que se necesitan requisitos, solo creo que deberían ir a otro lado. No puedo hablar por el resto del mundo, pero he descubierto que es extraordinariamente fácil usurpar el propósito de las historias de los usuarios y convertirlas en folletos llenos de requisitos. Si eso sucede, no tengo a dónde ir las historias de los usuarios. En un mundo perfecto, podrías incluir ambas en historias de usuarios, pero los desarrolladores son humanos y la cultura es voluble. Si un equipo tiene la costumbre de usar historias de usuarios para requisitos, puede ser culturalmente imposible volver a lo que creo que es su objetivo principal.
Cort Ammon - Restablece a Monica
1

Toma tus propias decisiones

La respuesta a 'Entonces, ¿cómo pueden los desarrolladores desarrollar una historia si no hay requisitos más bajos?' es muy simple: los requisitos detallados que son ortogonales a las necesidades del usuario final (por ejemplo, restricciones de la base de datos, validación de campos, etc.) en realidad no le importan al usuario. Si las necesidades del usuario pueden satisfacerse con una validación de campos muy diferente, estructuras de bases de datos muy diferentes o tal vez incluso ninguna base de datos tradicional, sería contraproducente que los usuarios compongan dicha información con una implementación particular en mente, lo que puede ser muy diferente de cómo se implementa el sistema al final.

Ustedes son desarrolladores profesionales, así que tomen decisiones profesionales lo mejor que puedan sobre los detalles de implementación. Un usuario que quiere una mesa puede decirle al carpintero qué tipo de madera le gustaría, pero se espera que el carpintero decida qué tan gruesas deben ser las patas de la mesa para manejar cargas razonables. Si carece de información para tomar una decisión significativa, entonces eso debe discutirse con el usuario, pero alrededor del 90% del contenido para un documento de requisitos detallado en realidad no necesita ninguna información, aparte de las vagas historias de usuario, sentido común y las mejores prácticas de la industria. .

Todos esos detalles no son arbitrarios: hay malas elecciones y mejores opciones, y deben documentarse ya que afectan otras partes de la implementación, pero al final siguen siendo detalles de implementación que el equipo de implementación puede y debe decidir. a las necesidades del usuario y las mejores prácticas.

Una analogía estándar del automóvil: si un cliente desea que el automóvil se pinte de rojo, una aclaración adecuada para la historia del usuario sería preguntar qué tono de rojo sería mejor, pero no la composición química de la pintura; no obstante, se esperaría que no elijan pintar el automóvil con acuarelas que se laven bajo la lluvia, ya que es una buena práctica no hacerlo.

Pedro es
fuente
1

TL; DR

Las historias de usuarios son para documentar qué valor se debe agregar al producto y por qué. Los detalles de implementación (por ejemplo, cómo se debe agregar, probar, medir o validar el valor) están limitados por la historia, pero no están contenidos en ellos. Se dejan deliberadamente como artefactos separados para mantener la flexibilidad y la agilidad dentro del marco.

Las especificaciones y los detalles de implementación se capturan con mayor frecuencia en otros artefactos, como los guiones y escenarios de Desarrollo impulsado por pruebas de aceptación (ATDD), Desarrollo guiado por pruebas (TDD) y Desarrollo guiado por comportamiento (BDD). Estos artefactos particulares no están obligados por el marco de Scrum, pero sin duda le darán un buen punto de partida si aún no tiene otros controles de proceso efectivos.

Las historias de los usuarios no son especificaciones

El póster original (OP) hizo la siguiente pregunta :

[Un] cliente quiere un procesamiento diferente para diferentes tarjetas de crédito, hay requisitos estrictos que deben implementarse y conocerse para que se puedan escribir casos de prueba ... ¿DÓNDE DEBO PONERLO SI NO ESTÁ EN LA HISTORIA?

Una historia de usuario es una característica que ofrece valor , proporciona un contexto para guiar las conversaciones sobre la implementación y un punto de vista vinculado a un consumidor de valor que se beneficiará del valor entregado por la característica.

El objetivo de una historia de usuario es que los detalles de implementación no son prescriptivos. El equipo es libre de implementar la función de cualquier manera que entregue el valor identificado al consumidor de valor dentro del contexto apropiado.

Un ejemplo trabajado

Una muestra de historia de usuario

Esto es más fácil de explicar si comienza con un conjunto menos ambiguo de historias de usuarios. Dado que el OP no proporcionó una historia de usuario accionable que sigue la mnemotecnia INVEST , inventaré una por el bien de un ejemplo. Considere la siguiente historia:

Como usuario que prefiere pagar con la tarjeta Discover,
me gustaría tener la opción de realizar mis compras con la tarjeta Discover
para no limitarme a Visa, Mastercard o American Express.

Esto proporciona una característica concreta, proporciona un contexto que puede guiar las decisiones de implementación que debe tomar el equipo e identifica al consumidor de valor como un cliente propietario de la tarjeta Discover. Ese no es un conjunto de especificaciones, pero es lo que necesita para tener las conversaciones correctas con el cliente y con el equipo sobre la mejor manera de implementar la historia durante una iteración de desarrollo.

Análisis e Implementación

La implementación real depende del equipo. El equipo tendrá que hacer un análisis para determinar:

  • La forma más fácil de implementar una nueva característica.
  • ¿Cuál de las diversas opciones de implementación será más fácil de soportar en el futuro, sin acumular deuda técnica?
  • Cómo aplicar los principios abierto-cerrado y YAGNI para garantizar que su nueva característica sea robusta sin ser diseñada en exceso.

Uno de los principios centrales del Manifiesto Ágil es la colaboración con el cliente. Se espera que un equipo interdisciplinario y autoorganizado pueda colaborar con el cliente para resolver los detalles de implementación dentro de las pautas proporcionadas por la historia del usuario.

Si sus historias de usuario no están bien escritas, o si el equipo no tiene las habilidades o la madurez de proceso para hacer el análisis lo suficientemente requerido por su marco ágil, entonces esto obviamente será mucho más difícil de lo necesario. Se han escrito libros completos sobre el tema de cómo crear buenas historias de usuario con el nivel de granularidad adecuado; desafortunadamente no hay una bala de plata, pero es una habilidad que se puede aprender para equipos ágiles.

Diseño basado en pruebas y basado en el comportamiento

La mejor manera de garantizar que el análisis sea sólido y que la implementación sea sensata y compatible es mediante el uso de prácticas TDD y BDD. Por ejemplo, dada la historia anterior, el equipo debe capturar la implementación planificada a través de artefactos como:

  • Funciones de pepino con escenarios comprobables.

    Esto es más útil para impulsar el desarrollo de pruebas de aceptación y para documentar las expectativas del usuario sobre el comportamiento de la aplicación. Por ejemplo, la historia del usuario debe tener una o más funciones de pepino relacionadas que describan cómo el usuario puede pagar con una tarjeta Discover y cómo se ve ese proceso para el usuario.

  • Pruebas de RSpec que validan el comportamiento (no los detalles de implementación internos) de las nuevas características del código.

    Esto es más útil para documentar y validar el comportamiento previsto de la función dentro de la aplicación. Por ejemplo, la historia del usuario impulsará la creación de pruebas unitarias y de integración que aseguran que el uso de una tarjeta Discover invoca cualquier comportamiento específico de la tarjeta que la aplicación requiera para autorizar una venta a través de la pasarela de pago.

Las herramientas específicas no importan. Si no le gusta Cucumber o RSpec, use las herramientas o metodologías que funcionen mejor para su equipo. Sin embargo, el punto es que los detalles de implementación se basan en la historia del usuario , pero no están prescritos por ella . En cambio, la implementación (o especificaciones, si lo prefiere) son detalles que se elaborarán durante el desarrollo de la función de manera colaborativa.

CodeGnome
fuente
0

Muchas buenas respuestas aquí. Espero poder agregar algo de valor con otro ...

Creo que uno de los problemas que podría tener su equipo es migrar desde una metodología no ágil.

Eso suele ser una metodología de cascada de formas y, en la práctica, eso generalmente implica tratar de documentar todos los requisitos técnicos antes de escribir una línea de código.

Pero eso no siempre funciona. A menudo no funciona. ¿La razón? Porque los requisitos rara vez se alinean con la realidad. Las cosas cambian. De ahí el movimiento hacia Agile.

Con Agile, la historia del usuario es lo único que le importa al usuario. Quieren pasar del punto A al punto B. Cómo llegar en términos de implementación está en sus manos. Si está esperando que alguien le diga los requisitos técnicos, entonces eso no es realmente ágil. Si tiene alguna pregunta, pregunte. Si necesita documentación, documento, pero no desea que el cliente tome todas estas decisiones por usted. Pueden tener opiniones, pero en un entorno ágil esas opiniones deberían (como sugiere su gurú) debatir en una conversación.

Puede parecer que esto es una carga para su equipo, pero considérelo un lujo. Su equipo ahora tiene mucho que decir en la solución, lo cual no fue necesariamente el caso en el modelo de cascada.

DA01
fuente