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

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.