Historia de usuario vs requisito

33

User Story captura lo que el usuario quiere hacer con el sistema a un alto nivel. Entiendo que la historia del usuario impulsaría aún más un número de requisitos de bajo nivel. ¿Es la historia del usuario igual que el requisito de alto nivel para el sistema?

Punter Vicky
fuente
"User Story captura lo que el usuario quiere hacer con el sistema a un alto nivel". Considero esto polémico. Me encontraría de acuerdo si reemplazaras el nivel alto con el nivel de función .
8bitjunkie

Respuestas:

52

Para ser honesto, después de pasar cerca de dos años inmerso en el desarrollo ágil, sigo pensando que "historia de usuario" es solo un término elegante para "requisito funcional".

Es diferente en un nivel superficial , por ejemplo, siempre toma una cierta forma ( "como una X, quiero Y para que Z ..." ), pero los elementos clave, identificar al actor y la razón, también son inherentes a requisitos funcionales escritos Es tan fácil escribir una mala historia de usuario como escribir un mal requisito ( "como [nombre de nuestra empresa], quiero [característica vaga] para que pueda [hacer algo que evidentemente es parte de mi trabajo, como 'vender más a los clientes'] " ).

Lo que las historias de usuarios casi nunca capturan, en mi experiencia, son requisitos no funcionales como el rendimiento y la seguridad. Este tipo de requisitos es muy difícil de escribir correctamente y el formato de la historia del usuario simplemente no es muy bueno para capturarlos, porque se trata más de la calidad general del producto y mitigar (pero no eliminar) los riesgos en lugar de cumplir con un usuario específico necesitar.

Entonces, realmente pienso en las historias de los usuarios como un subconjunto de requisitos, con una fórmula específica, y todavía uso los términos de manera bastante intercambiable.

La principal ventaja que tienen las historias de usuario sobre los requisitos es que la palabra "requisito" sugiere que se requiere una función donde a menudo solo se desea . En teoría, las historias de los usuarios pueden priorizarse y ubicarse en cualquier versión, mientras que los requisitos parecen ser un requisito previo para cada versión.

Por supuesto, para que la distinción mencionada sea importante, sus clientes y / o la alta gerencia deben adoptarla; no sirve de nada si tiene 30 historias de usuarios agrupadas en un "proyecto" que deben completarse al mismo tiempo. También podría llamarlos "requisitos" en ese caso porque de hecho son obligatorios.

Aaronaught
fuente
todas las respuestas ayudaron a mi comprensión, quería marcar todo como correcto :)
Punter Vicky
55
No estoy de acuerdo: los requisitos se centran en CÓMO el usuario interactúa con el sistema, las historias sobre QUÉ propósito tienen las funciones. Son cosas completamente diferentes.
Sklivvz
1
@Sklivvz: No creo haber leído alguna vez una historia de usuario que no diga algo sobre cómo el usuario interactúa con el sistema, y ​​como dije, los buenos requisitos vienen con una declaración de propósito para que puedan ser entendidos en contexto. Por alguna razón, mucha gente parece asumir automáticamente que "requisitos tradicionales = requisitos malos" e "historias de usuarios = requisitos buenos". Ninguno de los dos es necesariamente cierto. Tomemos, por ejemplo, "EVO" , que vincula todos los requisitos no solo a un objetivo comercial sino a una métrica real.
Aaronaught
1
@hanzolo: Eso sí que es tonto. Las tareas son manera demasiado granular a ser de alguna utilidad como requisitos funcionales. Con frecuencia, las tareas se establecen a niveles altamente técnicos como "implementar un analizador sintáctico usando la biblioteca jibbler". Tal vez podría hacer un caso para que las tareas sean un poco más o menos como las especificaciones , pero esas vienen después de los requisitos. Las historias de usuario se supone que vienen con criterios de aceptación - los que son mucho más como los requisitos funcionales detallados utilizados en Cascada / modelos tipo RUP.
Aaronaught
2
@Sklivvz: El "qué" generalmente es una interacción entre el usuario y el sistema. "Quiero poder ver el total de votos en las respuestas" es un ejemplo típico de la parte media de una historia de usuario, y está redactado casi de manera idéntica a un requisito funcional ("El usuario debería poder ver el total de votos en las respuestas") . El "quién" y el "por qué" son las únicas partes que son aparentemente diferentes, y muchos sistemas / metodologías de seguimiento de requisitos que no sean historias de usuarios esperan que también se proporcionen.
Aaronaught
16

Ron Jeffries escribió hace mucho tiempo sobre las 3C de historias de usuarios ( http://xprogramming.com/articles/expcardconversationconfirmation/ ) con énfasis en una tarjeta (descripción breve), conversación entre los clientes y el equipo de entrega una vez que la historia del usuario se vuelve procesable, y la confirmación acordada de una historia después de esa conversación.

esencialmente, antes de la conversación, las historias de los usuarios son solo un alcance planificado: ideas aproximadas sobre lo que podríamos hacer. Después de la conversación, debe tener una manera de confirmar que la historia está completa. Entonces, dependiendo del momento en que mire la historia en esta línea de tiempo, una historia podría ser solo una idea amplia sobre el alcance o un requisito detallado.

En estos días, el significado de "historia de usuario" parece limitarse solo a la parte de "tarjeta" de las 3Cs de Jeffries. en ese caso, una historia de usuario no es un requisito, sino una promesa de mantener una conversación sobre los requisitos.

Puede encontrar toneladas de pepitas de oro de sabiduría sobre historias de usuarios en el wiki de c2 ( http://xp.c2.com/UserStory.html )

Gojko Adzic
fuente
7

Las historias y los requisitos de los usuarios son bestias muy diferentes.

Requisitos

Los requisitos presuponen que el diseño de la aplicación se realiza de antemano y que el desarrollo es la implementación de ese diseño. Por lo tanto, los requisitos se centran en cómo implementar una funcionalidad.

Ejemplo de requerimiento:

  • Cree un formulario de contacto de usuario con los siguientes campos: nombre, apellido, correo electrónico, texto libre y un botón de envío. Cuando se presiona el botón Enviar, se envía un correo electrónico a nuestro equipo de soporte.

Historias de usuarios

Las historias de los usuarios se centran en qué lograr e insisten en que el diseño del producto se realiza en el último minuto y que es una colaboración entre una persona productora y una persona desarrolladora. Los detalles se deciden durante la implementación en función de la oportunidad.

Ejemplo de una historia:

  • Como Jimmy, el usuario, quiero ponerme en contacto con su equipo de soporte cuando no pueda usar el sitio correctamente para que puedan ayudarme.

¿Cuál es la diferencia?

Como puede ver, ciertamente hay una diferencia en la cantidad de detalles proporcionados, pero también hay mucha información que solo está disponible en la historia, a saber, el propósito que estamos tratando de lograr con esta función.

Si bien puede parecer que el propósito es relativamente poco importante, esta es una suposición errónea en el desarrollo ágil. Normalmente hay dos casos en los que conocer el propósito es muy importante: reducir el costo de oportunidad y permitir la agilidad.

Costo de oportunidad

Si hay supuestos ocultos en el requisito, podría ser muy difícil de lograr. Por ejemplo: ¿hay un servidor de correo disponible? De lo contrario, el requisito puede llevar mucho más tiempo en desarrollarse. En algunos otros casos, se puede perder una forma más simple de lograr el mismo objetivo debido al diseño.

Por el contrario, la historia del usuario trata sobre un usuario que se contacta con nuestro departamento de soporte. Si enviar un correo no es factible o es demasiado costoso, podemos idear una solución diferente en el acto: escribir en una base de datos, por ejemplo, o usar un formulario a través de documentos de Google, o simplemente poner una dirección de correo electrónico en lugar del formulario. Esto no se puede hacer fácilmente con un requisito, pero se hace fácilmente con una historia y una persona de producto presente.

Agilidad

Por esta razón, con los requisitos generalmente tendemos a pensar en estas suposiciones ocultas de antemano y nos aseguramos de que no haya problemas. Entonces, en este caso, podría haber un requisito diferente, programado de antemano, que aseguró que un servidor de correo estuviera presente.

Esto nos lleva a otra gran diferencia entre historias y requisitos que es la jerarquía . Como he ejemplificado anteriormente, los requisitos deben, por su propia naturaleza, ordenarse en alguna jerarquía natural para que se cumplan las dependencias. Las historias, por otro lado, se centran en el propósito y no tienen tales restricciones.

Esto es así por diseño, ya que en ágil es de suma importancia agregar, eliminar, reprogramar y modificar historias según sea necesario durante la ejecución del proyecto. Los requisitos generalmente se pueden agregar, a veces modificar o eliminar, pero generalmente es muy doloroso moverlos debido a todas las dependencias. Simplemente no se hace con mucha frecuencia. Si está trabajando con los requisitos, su implementación ágil sufrirá, o probablemente no será muy ágil en absoluto, en el sentido de poder aceptar el cambio.

Sklivvz
fuente
66
Yo diría que los tiene al revés: los requisitos son "dejar que el usuario se ponga en contacto con el soporte", la historia es cómo definir eso en algo que tenga sentido agregando detalles. Tal vez todo se deba a la terminología y, por lo tanto, nos estamos volviendo locos por nada.
gbjbaanb
2
Estoy bastante seguro de que no me equivoqué.
Sklivvz
15
"Por lo tanto, los requisitos se centran en cómo implementar una funcionalidad". - Esto está muy mal. Si un requisito dice cómo hacer algo, no es un buen requisito. A menos que haya una restricción conocida, los requisitos no incluyen ningún diseño o detalles de implementación. Si vi su "requisito" de muestra, lo rechazaría de inmediato: especifica los detalles de implementación.
Thomas Owens
44
Múltiples fuentes (altamente consideradas y a menudo citadas) más mi capacitación y experiencia en ingeniería de requisitos me dicen lo contrario. Si dices algo sobre cómo lograr algo, has hecho un trabajo de diseño. Una maqueta es diseño y no requisitos. Independientemente del formato, un requisito es "cualquier cosa que impulse las elecciones de diseño", no las elecciones de diseño en sí mismas. Estoy totalmente de acuerdo con la respuesta de Aaronaught de que una historia de usuario es solo un formato con el que capturar los requisitos funcionales, haciendo que la mayoría de esta respuesta sea incorrecta con respecto a los términos comúnmente aceptados.
Thomas Owens
6

Para mí, un elemento crítico de una historia de usuario es que captura por qué y cómo un usuario usa el sistema. Es especialmente útil porque no especifica mucho en la forma en que el sistema ofrece la funcionalidad requerida. Cuando se necesitan pruebas de UI y usabilidad, la historia del usuario puede ser el documento más importante.

Claro, puede hacer que el selenio verifique que ciertos nodos estén presentes en el HTML o tome capturas de pantalla, o verifique que ciertos píxeles estén donde espera que estén. Pero si hay texto engañoso, o no es evidente cómo el usuario debe usar el sistema o es difícil para un usuario descubrir cómo lograr su objetivo, de repente ya no tiene un sistema completo. Ahora se requiere capacitación para usar el sistema. Revisar el sistema completo en función de los escenarios de los usuarios es un componente crítico de las pruebas manuales.

Hay una mentalidad capturada en historias / escenarios de usuarios que debería influir en muchas decisiones de diseño detalladas sobre la implementación. A menos que los desarrolladores hablen directamente con los usuarios o los vean usar el sistema, el escenario del usuario puede ser el único enlace que les permita comprender las necesidades del usuario.

Finalmente, permiten que los empresarios especifiquen lo que necesitan sin sugerir cómo se debe lograr. Es mucho más fácil describir una solución que una necesidad, y los escenarios de usuario proporcionan un marco para describir las necesidades sin proponer una solución específica. El requisito comercial más común que he escuchado es: "Quiero que sea como Excel, pero en la web", que nunca ha sido lo que realmente necesitaban.

Entonces, diría que una buena historia no debe incluir ningún detalle específico sobre cómo se debe implementar el sistema. Debería decir: "Una vez al mes, el sistema A debe actualizarse con cualquier dato nuevo del sistema B. Esos datos pueden requerir correcciones. El cliente tiene un historial de ingresar datos no válidos y no darse cuenta del problema durante semanas". No debería decir: "El sistema debe aceptar un archivo CSV latin1 al menos una vez al mes y lanzar una excepción NumberFormatException si la columna 3 no es un número". ¿Ves la diferencia? El escenario describe la necesidad, no una solución específica. Luego, en las pruebas, vuelve al escenario para asegurarte de que la solución se ajuste a la necesidad. Los requisitos pueden mezclar algunas necesidades con algunas soluciones, o incluso centrarse por completo en las soluciones.

GlenPeterson
fuente
Gracias Glen! Pero, ¿el requisito o la historia del usuario no deberían ser independientes del sistema / solución? Esta es otra pregunta sobre la que sigo reflexionando al crear una historia / requisito de usuario, pero no he podido hacerlo con éxito en varios casos
Punter Vicky
Puede comenzar preguntando al usuario sobre el problema comercial que abordará el sistema. ¿Cómo manejas este problema ahora? ¿Trabajará de la misma manera una vez que tenga el sistema? ¿Quién hace estas tareas ahora? Donde lo hacen ¿Cuáles son los desafíos más comunes? Tiene sentido que los requisitos sean bastante independientes del sistema en teoría. Pero la práctica es más desordenada. Quiero un sistema que haga todo mi trabajo por mí de tal manera que todavía me puedan pagar por no hacer nada. Eso es agnóstico del sistema, pero inútil. Lo que nos importa son los requisitos que el equipo de desarrollo es capaz de construir.
GlenPeterson
3

Tropecé con esto durante una búsqueda en Google y pensé en tirar mi opinión.

Realmente no hay diferencia entre un requisito y una historia de usuario. Ambos están indicando el resultado u objetivo deseado desde la perspectiva del usuario.

La única diferencia es la forma en que un analista de negocios captura este objetivo o resultado. En este caso está en la redacción.

Ejemplo:

Como líder del equipo, quiero ver cuáles de mi equipo están trabajando en casos de hipotecas para poder monitorear su desempeño.

La solución mostrará a los miembros del equipo que trabajan en casos hipotecarios.

Ambos de los anteriores podrían interpretarse de la misma manera, pero ambos también tienen mucha ambigüedad. El punto principal aquí es una diferencia de estilo. Creo que el problema que vemos principalmente es qué tan lejos llegamos a definir la solución antes de salir del mundo de los requisitos y entrar en el mundo del diseño funcional. ¿Es responsabilidad del analista de negocios indicar "lista de usuarios registrados por nombre y segundo nombre en el menú principal de la aplicación" o es demasiada información? Cuando estamos sentados hablando con nuestros grupos de interés y todos conocemos la solución y podemos interpretar cómo se verá, incluso el lenguaje de código probable sobre el que se construirá y la forma en que se implementará, realmente necesitamos jugar el juego puro de " definamos objetivos y no soluciones ". Aquí es donde siento que realmente está la confusión.

Los requisitos a menudo suponen que no sabemos nada acerca de la solución, solo los resultados deseados. Sí, esto hace que la solución sea agnóstica, pero ¿eso realmente nos ayuda en el ciclo de desarrollo? Si podemos definir algo con precisión temprano, ¿por qué no hacerlo?

En general, no me preocuparía por las historias de los usuarios y las diferencias de requisitos. En última instancia, desea definir suficiente información para que alguien desarrolle una solución. Una historia de usuario que tiene un nivel demasiado alto simplemente será rechazada y se le pedirá que se divida en historias de usuario más pequeñas. Lo mismo que un estilo de "el sistema debe". El requisito probablemente será rechazado por ser demasiado ambiguo si no tiene suficientes detalles.

Al final, vaya con lo que a sus desarrolladores y partes interesadas les gusta ver y trabajar a partir de eso.

munkee
fuente
3

Creo que hay mucha inconsistencia en lo que significa la palabra requisitos, incluso dentro de los libros de texto clásicos. La misma inconsistencia se aplica a las historias de los usuarios. Las diferentes organizaciones y libros de texto tratan estos términos de manera diferente. Por ejemplo, cómo el clásico libro de texto de Ingeniería de Software de Roger Pressman habla sobre los requisitos es bastante diferente del libro de Requisitos de Software Ágil de Dean Leffingwell. Los respeto a ambos y ambos pueden ser válidos.

Los requisitos pueden ser cosas que codificamos y que tienen una especificidad extraordinaria con poco espacio para la imaginación. Por otro lado, se puede argumentar que los requisitos deben especificar cuál es el problema comercial y no especificar la solución. Sin embargo, creo que está más matizado y la respuesta está en algún lugar de un espectro que es único para cada empresa e industria (no todo el desarrollo de software ocurre en TI).

Me enseñaron que la obtención de requisitos conduce al análisis, que conduce al diseño, que conduce a la arquitectura que conduce a la elaboración o especificación de requisitos , que conduce a algo que puede codificarse. No creo que esto se vaya con agile. El momento de cuándo suceden estas cosas cambia y esa es la diferencia más importante. En el modelo de cascada, la obtención y la elaboración ocurren temprano. En Lean y Scrum, la obtención y la elaboración ocurren en varias etapas con más elaboración a medida que te acercas a la implementación en un sprint. Al igual que el trabajo de diseño emergente.

En nuestra organización, nos estamos inclinando hacia el modelo de epopeyas, características e historias de Leffingwell, no como requisitos, sino como desglose y priorización del trabajo. Los requisitos son una cosa diferente. Los requisitos se gestionan por separado porque estamos obligados a hacerlo para las agencias reguladoras. Y, sin embargo, algunos equipos están desarrollando requisitos dentro de las historias de los usuarios durante el incremento del programa y la planificación del sprint.

Tim W
fuente
2

Los requisitos funcionales suelen ser una especificación formal que le permite saber exactamente si su software funciona o no. La historia de usuario suele ser una forma mucho más informal de describir la necesidad de una historia de usuario. No especifica una especificación rígida para determinar si el software es "válido" o "inválido". Si bien puede probar alguna parte de ella, la verdadera finalización de una historia de usuario (si las hace bien) es cuando su usuario dice "sí, ¡eso resuelve mi problema!". Recuerda el manifiesto ágil:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

En su libro "User Story Applied", Mike Cohn dice específicamente que algunas cosas no se asignan a la historia del usuario y no tiene que usar solo eso.

En mi propio equipo, utilizamos lo siguiente:

  • Historia de usuario : una necesidad comercial de algún tipo de usuario. El énfasis aquí está en la necesidad , y por qué la necesita. Como han dicho otros, lo importante aquí no es especificar cómo se hace, y profundizar en la necesidad real del usuario (por ejemplo: no necesita ver los datos en una tabla, necesita ver el valor exacto de datos, y él está familiarizado con la tabla para hacer precisamente eso).
  • Error : Un comportamiento inesperado del software que perjudica el uso normal. Por lo general, vienen con una "Importancia" (independiente de la prioridad del desarrollo) que califica cuánto afecta el flujo de trabajo del usuario.
  • Deuda técnica. Algo que no impide el uso del software pero que nos perjudicará a nosotros , los desarrolladores, en el futuro. Ejemplo: algunas clases son difíciles de leer, la construcción es lenta, algunos códigos no se prueban en la unidad, el IDE muestra advertencias extrañas ...
  • Mejora : un cambio en el software que no permite nuevos escenarios, pero que ofrece una experiencia más agradable. Ejemplo: cambiar las fuentes, rediseñar un formulario para hacerlo más claro, agregar valores predeterminados razonables a la aplicación, etc.

Los requisitos funcionales no nos permitirían darnos cuenta de que una característica que implementamos no resuelve la necesidad de un usuario, a pesar de que nuestra prueba de pepino pasó e implementamos cada palabra escrita. Una historia es una discusión, y es informal. El punto es que los chicos de la implementación entiendan cuál es el problema. No son una herramienta de contrato. Si haces "scrum pero ... " y tu historia es simplemente una forma divertida de escribir los requisitos del software, entonces sí, no hay diferencia.

El punto no es la historia del usuario, el punto es el gran cambio de paradigma en la forma de abordar el trabajo a realizar. No está haciendo un contrato, está ayudando a algunos de sus usuarios a resolver un problema. Si no ve sus historias de usuario como una herramienta de discusión con un usuario real , entonces no está usando historias de usuario, está usando una sintaxis de requisitos funky .

El resto aquí es mi opinión: la historia del usuario nunca puede tener éxito de manera unilateral. Necesita que su cliente trabaje con él. Water-scrum-fall está condenado a ser un extraño desastre de requisitos pero no requisitos. Si tiene un contrato de oferta fijo con requisitos específicos, no use iteraciones e historias de usuarios, no tiene sentido . Utilice el resto del kit de herramientas ágil: prueba automatizada de unidad / funcionamiento, revisión de código, integración continua, refactorización, etc. Asegúrese de que su software funcione continuamente y de que pueda enviarlo en cualquier momento. Póngalo a disposición del cliente en su forma inacabada para que pueda dar la mayor cantidad de comentarios posible. Si haces eso, amigo mío, incluso si no hiciste "Historia de usuario" y "Scrum", habrías sido más ágil que muchas de las llamadas tiendas "Ágiles".

Laurent Bourgault-Roy
fuente
2

Creo que todos implementarán y etiquetarán todo de manera diferente dependiendo de la experiencia pasada y de cualquier idioma que funcione para esa compañía que hace el trabajo no vale la pena discutir.

Sin embargo, IMO, A User Story sigue el enfoque de Agile de "un cliente en el edificio o el cliente está disponible de inmediato", donde la documentación no es necesariamente necesaria porque los detalles están en la cabeza de los clientes y están fácilmente disponibles para que un SRS formal pueda No se requiere. Ahora, una "Tarea" de una "Historia de usuario" es cómo un desarrollador va a construir las historias de usuario en forma digerible.

Un ejemplo de historia de usuario podría ser:

Como usuario administrador, quiero ver los datos de mis clientes en una cuadrícula

y una "tarea" podría ser:

  1. Cree una cuadrícula que enumere los datos que se mostrarán

  2. Habilite la ordenación en la cuadrícula que ordenará la columna seleccionada

Ahora cada una de las tareas se estima y completa en su respectivo sprint.

Desde una perspectiva "tradicional", donde "el cliente es difícil de conseguir, necesitamos escribir esto para que puedan confirmar que lo tenemos justo antes de comenzar a planificar / codificar", la Especificación de requisitos de software es van a ser las ideas que estuvieron en la cabeza de los clientes y suscitaron y luego se escribieron y formalizaron y luego se basaron y administraron.

En este caso, un "requisito funcional" es el detalle esencial de ese SRS, y una parte de la Idea más grande. Entonces, en mi opinión, una historia de usuario podría verse como (una parte del) "Requisito" formal, y la tarea de esa historia de usuario es un (o uno de los muchos) requisitos funcionales.

En la historia de usuario de ejemplo, el "Requisito" formal sería un documento extenso con diagramas de flujo y, en general, se centrará en la documentación, en oposición al enfoque más "ágil" que se centra en el cliente.

La diferencia es que el "requisito" formal va a estar en la línea de un documento de 10 páginas que describe la sección de administración de la aplicación que indica que se necesitarán algunos listados, seguridad basada en roles, etc. y luego algunos de los elementos funcionales. los requisitos serán "las cuadrículas de listado permitirán la clasificación", "la información del usuario se incluirá en una cuadrícula", etc.

y creo que en estos días los términos están mezclados y mezclados ... lo que no importa en absoluto

hanzolo
fuente
2
La noción de que "el cliente está disponible para que no necesitemos elaborar" es parte de lo que yo llamo "Bad Agile". La verdadera esencia de Agile es que planifica en sprints y ofrece funcionalidades incrementales en lugar de hacer todo en una "gran explosión". Pero para ser realmente ágil a largo plazo, necesitas pruebas, y para escribir o realizar pruebas necesitas especificaciones, que en Agile-land vienen en forma de criterios de aceptación, que son los mismos que los requisitos, organizados por sprint en lugar de sistema o proyecto. La idea de que los "requisitos" son documentos antiguos enormes y polvorientos es solo FUD.
Aaronaught
@Aaronaught estoy de acuerdo. Tiene que haber un punto en el que el alcance sea limitado, particularmente en situaciones donde hay un presupuesto de implementación fijo. Si el presupuesto es fijo pero el diseño del producto no se conoce y el proyecto necesita ponerse en marcha rápidamente, entonces para mí es un trabajo ágil (y si se trata de una actividad de desarrollo de productos de software realizada en sprints, es decir, no es un proyecto verdadero), pero el alcance debe limitarse usando los criterios de aceptación que se incluirían en los requisitos mismos (con algunos cambios semánticos) si fuera con un enfoque en cascada
br3w5
@Aaronaught: tienes toda la razón ... sin embargo, Agile proviene de las metodologías de XP y el proceso que estableciste es un préstamo híbrido de lo mejor de ambos mundos ... por un lado, tienes "luz de documentación" y por otro tienes "documentación pesada". Encontrar el equilibrio será determinado por la compañía que define su proceso ..
hanzolo
@ssbrewster - Estoy de acuerdo contigo también. En la forma pura de cada metodología, cascada y ágil, una requerirá documentación y validación de los requisitos escritos, la otra requerirá muy poca o ninguna documentación y validación de los esfuerzos de desarrollo.
Hanzolo
1
@ssbrewster No se trata solo de restringir el alcance, se trata de poder decir cuándo una historia está realmente hecha. Si no puede tomar esa decisión sin saludar con la mano del negocio, entonces no tiene ninguna posibilidad de obtener productos de calidad constante o de medir con precisión cosas como la velocidad. Preferimos que los criterios de aceptación se documenten en las pruebas de aceptación , pero aún están escritos .
Aaronaught