Una historia de usuario se puede definir en una oración como:
As a <type of user> I want <some goal> so that <some reason>
Solo Google para la "fórmula de la historia del usuario" y los primeros enlaces proponen esta fórmula.
Mi pregunta es, ¿cuál es el propósito de esa cláusula? ¿Está ahí para los gerentes? ¿Existe para que los gerentes de proyecto y las partes interesadas puedan comprender mejor la prioridad del elemento? ¿Por qué está ahí?
Nota: He trabajado con as a <type of user> I want <some goal>fórmula, y funciona muy bien. No he notado ningún problema en mi trabajo al implementar este formato, que es más breve.
user-story
Saeed Neamati
fuente
fuente
Respuestas:
El propósito es evitar el trabajo innecesario al obligar al usuario / cliente a proporcionar un beneficio comercial sólido y tangible como una razón para la existencia de esta característica.
No es extraño que se agreguen características solo porque alguien pensó que sonaba genial, o porque otro software lo tiene, por lo que el nuestro también debe tenerlo. Más a menudo que no, esos son al menos completamente innecesarios, si no activamente dañinos.
Sin embargo, generalmente es fácil detectar esas características, porque las personas que las proponen generalmente tendrán problemas para proporcionarles una razón comercial convincente.
Hay una técnica llamada Popping The Why Stack , en la que tomas la parte "de modo que" y preguntas "¿Por qué?", Luego tomas esa respuesta y preguntas "¿Por qué?" de nuevo, recursivamente. Si, después (digamos) de tres a cinco "Por qué", no ha llegado a "porque nos hará ganar dinero" o "porque nos ahorrará dinero" (preferiblemente con una descripción precisa de cómo exactamente eso va a suceder), entonces no vale la pena implementar la característica.
Algunas personas creen que esto es tan importante que realmente lo ponen primero en la plantilla de la historia:
Hay un gran ejemplo de una charla de algunas personas de Thoughtworks: uno de sus clientes quería que los informes impresos formateados de una manera muy peculiar. Cuando el consultor preguntó "Por qué", dijeron que de esa forma eran más fáciles de volver a escribir. Entonces, en lugar de implementar la función de formateo de informes, simplemente transfirieron los informes a través de la red. Sin la cláusula "para que", todavía estarían imprimiendo esos papeles en un departamento, enviándolos por correo al otro departamento y volviéndolos a escribir.
fuente
El "para que" proporciona una razón para el objetivo.
Por ejemplo, el objetivo podría ser mostrar las cifras de ventas del mes pasado. Podría trabajar con eso, pero una razón por la que necesita saber por qué desea mostrarlos para poder cumplir con los requisitos más profundos. ¿Qué quieren hacer con las cifras de ventas o prospectos? Conocer esta información le dará más información sobre la aplicación y más posibilidades de diseñar una interfaz de usuario que permita al cliente hacer lo que quiera.
Otro uso de la razón es priorizar historias. Si tienes dos historias:
pero solo tienes los recursos para hacer uno, ¿cuál haces? Sin la razón, solo estarías adivinando y es posible que no entregues la correcta a tiempo. Aunque esto es menos importante ya que el cliente debería decirle qué hacer primero, pero en ocasiones ese no es el caso.
fuente
Además de lo que se ha dicho, proporcionar una razón para los requisitos le permite juzgar la validez del requisito. El usuario puede querer cosas por la razón equivocada. Tener el "para que" aclare la razón, por lo tanto, permite al analista validar que la solicitud se satisface mejor de esta manera.
Ejemplo:
AI quiere poder seleccionar empleados de una lista de todos los empleados de la compañía
BI quiero poder seleccionar empleados de una lista de todos los empleados de la compañía para poder eliminar a los que dejaron la compañía hace 5 años.
(B) no tiene sentido incluso en una organización mediana, pero puede validar el requisito del usuario y proponer otra forma para que el cliente cumpla con el requisito.
fuente