agile - uso - Ágil-Definiciones de historia de usuario
plantillas scrum (6)
A menudo clasifico mis historias por el usuario / persona con el 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.
Para mí, la conclusión 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 la publicación anticipada / publicación a menudo, pruebas unitarias, iteraciones cortas, reconocer que se producirán cambios, retrasar la planificación detallada hasta que esté listo para implementar, ...
En pocas palabras: si las historias funcionan 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.
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.
¡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 [función] para que [algún beneficio]
Siempre estoy tentado de perderme el principio y el final, y simplemente dejo la función, ¡pero esto se convierte en requisitos que se reúnen a la antigua!
Pero no quiero simplemente ajustarlo, para poder decir ''estoy haciendo Agile'' ... por ejemplo, si sé que se le presentará al usuario una lista de elementos, entonces el motivo es evidente por sí mismo, ¿no es así?
p.ej
Como [Store Manager], ¿quiero [ver una lista de Stock Items] para que ...?
¿Es una práctica normal omitir la cláusula [así que]?
Creo que deberías intentar definir un motivo, aunque parezca 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.
Intente, para lograr [Valor comercial] Como [Usuario] Necesito [Característica].
El objetivo es enfocarse 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 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 garantizar que la característica funcione. Es un salto corto para luego usar algo como FitNesse para automatizar esas pruebas.
No, en realidad no es obvio, hay muchas razones para querer ver una lista, muchas cosas que quizás quiera con ella, escanearla para obtener información, obtener una visión general, imprimirla, copiarla y pegarla en una documento de Word, etc. Y exactamente qué es lo que le dará consejos valiosos sobre los detalles de implementación razonables: 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 puede 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 se sorprenda por la utilidad de esto, o no, en cuyo caso todavía aprendió algo y puede dejarlo con una clara concisión ... :)
Solíamos perderlo también. Y al dejarlo fuera, nos perdimos mucho. Para entender la función correctamente y no solo hacer las cosas bien, sino HACER LO CORRECTO, es clave saber POR QUÉ la característica, y para eso, la siguiente clave es QUIÉN (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 comprenda, quién es el interesado, entonces usted sabe 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", necesito ... para que ...
¡Tal vez pueda implementar algo diferente que le dará al mismo interesado un beneficio aún mejor!
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 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 sientas que tienes 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á.