Agile - Definiciones de historia de usuario

Question

Estoy escribiendo una pequeña aplicación para el negocio de mi amigo, y pensé que aprovecharía la oportunidad para repasar algunos de los cursos de capacitación en gestión de proyectos ágiles que hice al inicio del año.

I (y pienso, mi organización actual!) Siempre han luchado con los requisitos de recolección en forma de historias de los usuarios, que tienen la forma:

Como [Tipo de usuario] Quiero [Función] de modo que [algún beneficio]

Estoy siempre tentado a perder el principio y el final, y simplemente dejar la función, pero esto simplemente se convierte en requisitos de recopilación de la manera antigua!

Pero no solo quiero que quepa, para 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 por sí misma, ¿no es así?

p. Ej.

Como [Administrador de tiendas] Quiero [ver una lista de Elementos de stock] para que ...?

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

Answer 1

Solíamos perderlo también. Y al dejarlo fuera, nos perdimos mucho. Para comprender la función correctamente y no solo hacer las cosas bien, sino HACER LO CORRECTO, es clave saber POR QUÉ la función, y para eso, la siguiente clave es WHO (la función) En términos DDD, parte interesada. Los interesados ​​pueden ser diferentes, todos a quienes les importa. Desde programadores y administradores de bases de datos a todos los tipos de usuarios.

Entonces, primero entienda quién es el interesado, entonces conoce el 50% de POR QUÉ le importa, luego el beneficio, y entonces ya es casi obvio QUÉ implementar.

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

Tal vez pueda implementar algo diferente que le otorgue al mismo interesado aún mejor beneficio !!!

Answer 2

Creo que deberías tratar de obtener una razón definida, incluso si puede parecer obvio. Si no puede encontrar una razón, entonces, ¿por qué crear la característica? También la razón puede señalar otras deficiencias en el diseño que podrían provocar mejoras en otras áreas.

Answer 3

A menudo clasifico mis historias por el usuario/persona con las que se relaciona principalmente, por lo que 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. Usualmente, comienzo con un título. Lo uso para fines de planificación. Una vez que me acerco a trabajar realmente en esa historia, la llevo a cabo con algunos detalles (idea básica, restricciones, suposiciones, historias relacionadas) para capturar más información que conozco sobre ella. También guardo mis historias en una wiki, no en tarjetas de notas. Entiendo la compensación, es decir, puedo dedicar demasiado tiempo a los detalles antes de que los necesite, pero puedo capturarlos y compartirlos con, normalmente, clientes externos.

La conclusión para mí es que Agile es una filosofía, más que una especificación. Existen implementaciones particulares que pueden (fuertemente) sugerir que usted hace las cosas de cierta manera y pueden no ser negociables en algunos artículos. Por ejemplo, es difícil decir que estás haciendo XP si no emparejas el programa. En general, sin embargo, diría que la mayoría de los agilistas dirían que deberían hacer las cosas que funcionan para ustedes, en la forma en que trabajan para ustedes, siempre y cuando sean consistentes con los principios generales, aún pueden llamar usted mismo ágil. Los principios generales incluirían cosas como lanzamiento temprano/lanzamiento a menudo, pruebas unitarias, iteraciones cortas, reconocer que el cambio sucederá, retrasar la planificación detallada hasta que esté listo para implementar, ...

Conclusión para mí: si las historias trabaje para usted sin el usuario y la razón de ser: siempre que comprenda quién es el usuario y por qué quiere algo, hágalo como lo desee. Simplemente no requiere una especificación completa antes de comenzar a implementar.

Answer 4

User Stories es otra forma de decir que necesita entrevistar a los 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 ti, da un paso atrás y prueba un enfoque diferente que te parezca más natural o que se adapte mejor a tus capacidades como escritor.

En resumen, no se siente como que tiene que estar en una chaqueta recta. 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é creen que los ayudarán.

Answer 5

No, en realidad no es obvio, hay muchas razones para querer ver una lista, muchas cosas que podría desear: escanear para obtener información, obtener una visión general, imprimirla, copiar y pégalo en un documento de Word, etc. Y exactamente qué es lo que te dará pistas valiosas sobre los detalles razonables de implementación: formateo de la lista, contenido exacto; o incluso una sugerencia 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 en realidad es "para que pueda contar el número de entradas" ...

Por supuesto, esto de hecho no se aplica a usted. De hecho, mi punto real es que hay razones por las que las personas idearon esta plantilla, y también hay razones por las que muchas personas con experiencia no la usan. Y cuando eres nuevo en la práctica, no estás en una buena posición para evaluar todos los pros y los contras de seguir una práctica, por lo que te recomiendo que simplemente trates de seguirlo de cerca durante un tiempo. Puede que le sorprenda su utilidad, o no, en cuyo caso todavía aprendió algo y puede dejarlo con una clara concisión ... :)

Answer 6

Probar, lograr [valor comercial] como [usuario] I Necesito [Característica].

El objetivo es centrarse en el valor que ofrece la característica. 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 en forma vertical, comienzas a ser realmente capaz de 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 característica funcionaría. Es un salto corto para luego usar algo como FitNesse para automatizar esas pruebas.