Ágil - Definiciones de historias de usuario [cerrado]

Question

Estoy escribiendo una pequeña aplicación para el negocio de mi amigo, y pensé en aprovechar la oportunidad para repasar algo de la capacitación en Gestión de Proyectos Ágiles que hice a principios de año.

Yo (¡y creo que mi organización actual!) siempre he tenido problemas para reunir los requisitos en forma de Historias de usuarios, que toman la forma:

Como [Tipo de usuario] quiero [característica] para que [algún beneficio]

Estoy siempre tentado a perder el principio y el final, y simplemente dejar la función, ¡pero esto se convierte en requisitos que se reúnen a la antigua usanza!

Pero no quiero simplemente ajustarlo, de modo que pueda decir 'Estoy haciendo Agile' ... por ejemplo, si sé que se le presentará al usuario una lista de elementos, entonces la razón es evidente, ¿no es así?

por ejemplo

Como [gerente de tienda] quiero [ver una lista de artículos en existencia] para que ...?

¿Es una práctica normal omitir la cláusula [para que]?

Answer 1

Solíamos perderlo también. Y al dejarlo fuera, extrañamos mucho. Para comprender la característica correctamente y no solo hacer lo correcto, sino HACER LO CORRECTO, es clave saber POR QUÉ la característica, y para eso la siguiente clave es QUIÉN (el rol) En términos DDD, parte interesada. Las partes interesadas pueden ser diferentes, todos los que se preocupan. Desde programadores y administradores de db hasta todos los tipos de usuarios.

Entonces, primero entienda quién es la parte interesada, luego sabe el 50% de POR QUÉ le importa, luego el beneficio, y luego es casi obviamente QUÉ implementar.

Intenta no solo escribir " como usuario " ;. Especificar. "como gerente de la tienda", o incluso "como líder del turno responsable de cerrar el día", necesito ... para que ...

¡¡Tal vez pueda implementar algo diferente que le dará a la misma parte interesada un beneficio aún mejor !!!

Answer 2

Intente, para lograr [Valor comercial] Como [Usuario] necesito [Característica].

El objetivo es centrarse en el valor que ofrece la función. Le ayuda a pensar en sectores verticales, lo que reduce las tareas técnicas puras. que no son visibles No es una transición fácil, pero cuando comienzas a pensar verticalmente, comienzas realmente a reducir el desperdicio en tu proceso.

Otra forma es pensar en las pruebas de aceptación que su cliente podría escribir para asegurarse de que la función funcione. Es un salto corto para luego usar algo como FitNesse para automatizar esas pruebas.

Answer 3

No, en realidad no es obvio: hay muchas razones para querer ver una lista, muchas cosas que puede querer ver con ella: escanee para obtener información, obtenga una visión general, imprímala, copie y pegue en un documento de Word, etc. Y qué es exactamente le dará pistas valiosas sobre detalles razonables de implementación: formateo de la lista, contenido exacto; o incluso una pista de que una característica diferente podría ser una mejor idea para satisfacer esa necesidad. No se sorprenda al descubrir que la razón realmente es "para poder contar el número de entradas" ...

Por supuesto, esto podría no aplicarse a usted. De hecho, mi punto real es que hay razones por las que a las personas se les ocurrió esta plantilla, y también hay razones por las que mucha gente experimentada en realidad no la usa. Y cuando es nuevo en la práctica, no está en una buena posición para evaluar todos los pros y los contras de seguir una práctica, por lo que le recomiendo que simplemente trate de seguirla de cerca por algún tiempo. Puede que te sorprenda su utilidad, o no, en cuyo caso aún aprendiste algo y puedes dejarlo caer con una concisa clara ... :)

Answer 4

User Stories es otra forma de decir que necesita entrevistar a sus usuarios para averiguar qué quieren y qué problemas están tratando de resolver. Que el corazón de tener esto en desarrollo ágil. Si el formulario no funciona para usted, dé un paso atrás y pruebe un enfoque diferente que le parezca más natural o que se adapte mejor a sus capacidades como escritor.

En resumen, no sienta que tiene que estar en una camisa de fuerza. Lo importante es que sigas el espíritu de la metodología.

En este caso específico, desea obtener una lista de los problemas que tiene el usuario, por qué son problemas y qué cree que los ayudará.

Answer 5

Creo que realmente deberías tratar de definir un motivo, incluso si parece obvio. Si no puede encontrar una razón, ¿por qué construir la función en primer lugar? Además, la razón puede señalar otras deficiencias en el diseño que podrían provocar mejoras en otras áreas.

Answer 6

A menudo categorizo ??mis historias por el usuario / persona con el que se relaciona principalmente, por lo tanto, no pongo la identidad del usuario en el título de la historia. Mis historias también son más grandes de lo que sugieren algunas metodologías ágiles. Por lo general, empiezo con un título. Lo uso para fines de planificación. Una vez que me acerco a trabajar realmente en esa historia, la realizo con algunos detalles: idea básica, limitaciones, suposiciones, historias relacionadas, para capturar más información que conozco sobre ella. También mantengo mis historias en una wiki, no en tarjetas de notas. Entiendo la compensación, es decir, puedo pasar demasiado tiempo en detalles antes de que los necesite, pero puedo capturarlo y compartirlo con, típicamente, clientes externos fácilmente.

La conclusión para mí es que Agile es una filosofía, más que una especificación. Hay implementaciones particulares que pueden (fuertemente) sugerir que haga las cosas de cierta manera y que no sea negociable en algunos artículos. Por ejemplo, es difícil decir que estás haciendo XP si no emparejas el programa. Sin embargo, en general, diría que la mayoría de los agilistas diría que debe hacer las cosas que funcionan para usted, de la manera en que funcionan para usted, siempre que sean consistentes con los principios generales, todavía puede llamar usted mismo ágil Los principios generales incluirían cosas como lanzamiento anticipado / lanzamiento frecuente, pruebas unitarias, iteraciones cortas, reconocer que ocurrirá un cambio, retrasar la planificación detallada hasta que esté listo para implementar, ...

Conclusión para mí: si las historias funcionan para usted sin el usuario y la justificación, siempre y cuando comprenda quién es el usuario y por qué quiere algo, hágalo como quiera. Simplemente no requiera una especificación completa antes de comenzar a implementar.