Me estoy metiendo en las historias de los usuarios (leí algunos blogs y vi algunas de las presentaciones de Mike Cohn).
Mi comprensión actual es que la historia es una porción vertical del sistema. Las historias no son "Agregar base de datos para que los datos del cliente se almacenen permanentemente" o algo similar horizontalmente.
Las historias son sobre " Qué " en lugar de " Cómo ".
Ahora el proyecto/producto con el que estoy trabajando se puede pensar como una máquina expendedora. Así que digamos que tengo la siguiente historia en el proyecto llamado "máquina expendedora":
Como cliente,
quiero recibir un recibo,
para poder probar mi compra más adelante.
Esta historia parece depender en gran medida de la impresora que puede imprimir físicamente un recibo, pero digamos que el desarrollo ha comenzado pero el hardware aún no ha llegado.
Puedo escribir lógica comercial y GUI, pero no puedo integrarme con la impresora.
Sin embargo, puedo crear una implementación que "imprimiría" el recibo en la salida de la consola.
¿Está bien sacar la tarea de esta historia y considerar que la historia está hecha?
La tarea sería algo como:
"Crear la implementación de la impresora xerox para la interfaz [Impresora]"
Potencialmente, esto puede significar que todas las historias se pueden completar antes de que llegue el hardware, pero nos deja con un montón de tareas (concretas).
Por un lado, se siente bien si el Product Owner (o quienquiera que acepte la historia) comprende y acepta esa restricción/compromiso.
Sin embargo, se puede decir
"¿Cómo es que dices que has completado la historia, pero no puedes hacer una demostración?".
O:
"[Llega el hardware]. Bueno, el hardware está aquí. Instale nuestro software y enviémoslo.
-No, necesitamos 2 semanas para la integración".
En general, parece que se trata de comunicación (segunda 'C' en la tarjeta, conversación y confirmación) y entendimiento común (confirmación).
Mi preocupación es que soy nuevo en esto y esta es la primera y hasta ahora única idea de cómo abordar esta situación y la experiencia muestra que seguir ciegamente las ideas iniciales puede conducir a rincones oscuros.
EDITAR:
he aceptado la respuesta de @Sarov, pero me gustaría dejar lo que aprendí de este hilo:
Yo diría que no.
Como observa, las historias de usuario deben ser cortes verticales. Otra forma de verlo es que deberían, por sí mismos, proporcionar valor .
Solo debe quemar historias una vez que esas historias puedan proporcionar valor.
Sin embargo, es posible que pueda dividir y/o reelaborar historias. Como un ejemplo rápido:
Recuerde que las historias no contienen detalles de implementación. Por ejemplo, podría lograr su historia de otra manera: permitiendo que el usuario ingrese un correo electrónico, para que se le envíe el recibo por correo electrónico.
Entonces podrá terminar la primera historia y crear una segunda:
Como cliente,
quiero poder recibir un recibo sin proporcionar un correo electrónico,
para poder mantener mi correo electrónico privado.
... Lo que podría agregar una opción secundaria de 'imprimir recibo'.
Gran pregunta. Realmente todo se reduce a responder una pregunta crítica: ¿la cantidad mínima de trabajo identificada en esta tarjeta seguirá brindando valor? Esta pregunta debe ser respondida por el equipo de desarrollo y el propietario del producto en conjunto.
Asegurarse de que su trabajo sea independiente de otros trabajos, negociable con su Product Owner, valioso, estimable, pequeño y comprobable es un buen modelo para responder a la pregunta anterior.
¿Está bien sacar la tarea de esta historia y considerar que la historia está hecha?
^ esta es una pregunta para su Product Owner, quien es responsable de maximizar el valor del trabajo que completa su equipo. Apoyarse y refinar su definición de hecho es tan importante como negociar con su OP sobre un trabajo valioso.
En resumen, no hay una respuesta definitiva real a su pregunta que no sea colaborar con su Product Owner para comprender y negociar lo que se considera valioso. Este ejercicio no solo ayudará con esta carta, sino con todas las cartas subsiguientes en el futuro.
Tal vez estoy siendo "contrario" cuando sugiero que no se debe esperar que una (verdadera ...) "historia de usuario" contenga ningún detalle de implementación .
(Después de todo, "su 'usuario' no tiene ni idea de 'cómo funciona su software'". Y, bueno, tampoco sabe todo acerca de cómo su usuario hace su trabajo total. "Y nunca el ' dos se reunirán [totalmente]").
En mi versión modificada de esta popular metodología, "las historias de usuarios son exactamente eso: descripciones de lo que los usuarios reales quieren hacer y ver". Los planes de implementación son elaborados por el equipo, siendo el único grupo que realmente conoce el software.
Los planes de implementación (y cronogramas) son elaborados en su totalidad por el equipo, considerando detenidamente todas las historias de usuarios proporcionadas y, a veces, requieren que se obtengan nuevas (!) historias de usuarios como aclaración. No pido ni espero que los usuarios me den directamente esos planes en sus historias. El equipo concibe y perfecciona los planes, luego los contrasta con las historias para ver si coinciden y para decidir si hemos hecho el mejor trabajo posible para ese usuario.
Todd A. Jacobs
Siim Haas
Todd A. Jacobs
Todd A. Jacobs