Como alguien que todavía es nuevo en el mundo ágil, no estoy seguro de entender completamente la relación o la diferencia entre historia de usuario, característica y épica.
Según esta pregunta, una característica es una colección de historias. Una de las respuestas sugiere que una característica es en realidad una epopeya. Entonces, ¿las características y las epopeyas se consideran la misma cosa, es decir, básicamente una colección de historias de usuario relacionadas?
Nuestro director de proyecto insiste en que hay una estructura jerárquica:
Épica -> Características -> Historias de usuario
Y que, básicamente, todas las historias de usuario deben caer dentro de esta estructura. Por lo tanto, todas las historias de usuario deben caer bajo una característica paraguas y todas las características deben caer bajo una épica.
Para mí, eso suena incómodo. ¿Puede alguien aclarar cómo se relacionan las historias de usuario, las características y las epopeyas? ¿O hay algún artículo que describa claramente las diferencias?
En realidad son un término muy genérico. Hay muchas maneras de interpretarlos, variando en la literatura y en cómo los ve la gente. Toma todo lo que digo con un enorme grano de sal.
Por lo general, un Epic comprende una funcionalidad muy global y no muy bien definida en su software. Es muy amplia. Por lo general, se dividirá en historias de usuario más pequeñas o características cuando se trata de dar sentido a ella y hacer que encajen en una iteración ágil. Ejemplo :
Epic
Las características y las historias de usuario son funcionalidades más específicas, que se pueden probar fácilmente con pruebas de aceptación. A menudo se recomienda que sean lo suficientemente granulares como para caber en una sola iteración.
Las características suelen describir lo que hace el software:
Característica
Las historias de usuario tienden a expresar lo que el usuario quiere hacer :
**Historia de usuario Como empleado del banco quiero ser capaz de modificar la información del cliente para poder mantenerla actualizada.
No creo que haya realmente una jerarquía entre las dos, pero puedes tener una si quieres o si se ajusta a tu forma de trabajar. Una historia de usuario puede ser una justificación específica para una característica, o una forma específica de hacerla. O puede ser lo contrario. Una característica puede ser una forma de realizar una historia de usuario. O pueden denotar la misma cosa. Se pueden utilizar ambas: las historias de usuario para definir lo que aporta valor al negocio y las características para describir las limitaciones del software.
Historia de usuario: como cliente, quiero pagar con las tarjetas de crédito más populares Característica soportar la API XML GOV-TAX-02 del gobierno.
También está la cuestión de los escenarios, que suelen ser la forma en que se ejecutará una característica o historia de usuario. Suelen asignarse limpiamente a una prueba de aceptación específica. Por ejemplo
Escenario : Retirar dinero Dado que tengo 2000$ en mi cuenta bancaria Cuando retiro 100$ Entonces recibo 100$ en efectivo Y mi saldo es de 1900$.
Así es como definimos esos términos donde yo trabajo. Esas definiciones están lejos de ser una definición matemática o un término estandarizado. Es como la diferencia entre un político de derechas o un político de izquierdas. Depende de dónde se viva. En Canadá, lo que se considera de derechas puede considerarse de izquierdas en Estados Unidos. Es muy variable.
En serio, yo no me preocuparía demasiado por ello. Lo importante es que todos los miembros del equipo se pongan de acuerdo en una definición para poder entenderse. Algunos métodos como scrum tienden a definirlos de manera más formal, pero escoge lo que te funcione y deja el resto. Al fin y al cabo, ¿acaso no se trata de personas e interacciones por encima de procesos y herramientas y de software de trabajo por encima de documentación exhaustiva?
Epico: Una historia de usuario muy grande que eventualmente se descompone en historias más pequeñas.
**Historia de usuario: definición de muy alto nivel de un requisito, que contiene la información suficiente para que los desarrolladores puedan hacer una estimación razonable del esfuerzo necesario para implementarlo.
http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx
Característica: Una característica o capacidad distintiva de una aplicación o biblioteca de software (por ejemplo, rendimiento, portabilidad o funcionalidad).
Es sólo una descomposición de problemas. Son sólo historias, sólo que con diferentes tamaños.
Personalmente prefiero no etiquetar sus tamaños, pero si lo haces también está bien. Pregúntale a tu PM cuál es la definición en tu espacio de trabajo.