Historia de usuario vs requisito

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?

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.

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 )

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.

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.

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.

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.

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".

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