Como alguien que todavía es nuevo en ágil, no estoy seguro de entender completamente la relación o diferencia entre la historia del usuario, la característica y la épica.
Según esta pregunta , una característica es una colección de historias. Una de las respuestas sugiere que una característica es realmente épica. Entonces, ¿las características y las epopeyas se consideran lo mismo, que es básicamente una colección de historias de usuarios relacionadas?
Nuestro gerente de proyecto insiste en que hay una estructura jerárquica:
Epic -> Características -> Historias de usuarios
Y que, básicamente, todas las historias de usuarios deben caer dentro de esta estructura. Por lo tanto, todas las historias de usuarios deben estar incluidas en una función general y todas las funciones deben estar incluidas en una epopeya.
Para mí, eso suena incómodo. ¿Alguien puede aclarar cómo se relacionan las historias de usuarios, las características y las epopeyas? ¿O hay un artículo que describe claramente las diferencias?
fuente
Respuestas:
Son un término muy genérico en realidad. Hay muchas maneras de interpretarlos, variando en la literatura y cómo la gente los ve. Toma todo lo que digo con un gran grano de sal.
Por lo general, un Epic comprende una funcionalidad muy global y no muy bien definida en su software. Es muy amplio. Por lo general, se desglosará en una historia o característica de usuario más pequeña cuando intente darle sentido y hacer que encajen en una iteración ágil. Ejemplo:
Epic
: permite al cliente administrar su propia cuenta a través de la Web
La característica y la historia del usuario son funciones más específicas, que puede probar fácilmente con las 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 su software:
Característica
: edición de la información del cliente a través del portal web
Las historias de los usuarios tienden a expresar lo que el usuario quiere hacer:
Historia de usuario
Como empleado bancario,
deseo poder modificar la información del cliente
para poder mantenerla actualizada.
No creo que haya realmente una jerarquía entre los dos, pero puede tener una si lo desea o si se ajusta a cómo trabaja. Una historia de usuario puede ser una justificación específica para una función, o una forma específica de hacerlo. O puede ser al revés. Una característica puede ser una forma de realizar una historia de usuario. O pueden denotar lo mismo. Puede usar ambas: Historias de usuarios para definir qué aporta valor comercial y características para describir la restricción del software.
Historia de usuario : como cliente, quiero pagar con las tarjetas de crédito más populares La
función admite la API XML GOV-TAX-02 del gobierno.
También está la cuestión del escenario, que generalmente es una forma en que se ejecutará una historia de Característica / Usuario. Por lo general, se asignan 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 $
Luego recibo 100 $ en efectivo
Y mi saldo es 1900 $
Así es como definimos esos términos donde 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 derecha o un político de izquierda. Depende de donde vivas. En Canadá, lo que se considera de derecha puede considerarse de izquierda en los Estados Unidos. Es muy variable.
En serio, no me preocuparía demasiado por eso. Lo importante es que todos en el equipo acuerden una definición para que puedan entenderse entre sí. Algunos métodos, como scrum, tienden a definirlos de manera más formal, pero elige el que mejor funcione para ti y deja el resto. Después de todo, ¿no es ágil con las personas y las interacciones sobre los procesos y las herramientas y el software de trabajo sobre la documentación completa ?
fuente
Epic : Una historia de usuario muy grande que finalmente se divide en historias más pequeñas.
Historia del usuario: una definición de nivel muy alto de un requisito, que contiene información suficiente para que los desarrolladores puedan producir una estimación razonable del esfuerzo 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 de software o biblioteca (por ejemplo, rendimiento, portabilidad o funcionalidad).
http://en.wikipedia.org/wiki/Software_feature
fuente
Le advierto que no aplique una jerarquía demasiado rígida a estos términos. Intentamos hacer eso en mi trabajo anterior. Dos veces. Ambos intentos fueron diferentes y en ambas ocasiones descubrimos que nos habíamos limitado innecesariamente. La única constante fue la definición de una historia de usuario . Desde una perspectiva de planificación, una historia es el componente básico de un proyecto. Los términos más grandes (épico, característica, etc.) son efectivamente solo etiquetas . Las etiquetas son una manera fácil de permitir que exista una historia como parte de múltiples Epics y múltiples características al mismo tiempo. No vale la pena el esfuerzo mental para ser más estricto que eso.
Las etiquetas funcionan para Stack Exchange y también pueden funcionar para usted.
fuente
La forma en que trabajamos con epopeyas, historias y características es la siguiente
Al principio del ciclo del proyecto, creamos Epics . Estos son puntos de funcionalidad de alto nivel, casi centrados en el marketing. El tipo de cosas que puede usar en un resumen ejecutivo, como,
Esto lleva a epopeyas como
Estos se escriben como historias de usuarios (p. Ej., Como cliente, quiero navegar por el catálogo de productos, para poder tomar una decisión de compra informada), pero solo sirven como un comienzo para diez para lo que realmente se desarrollará y lanzará.
Estas epopeyas se desglosan en Historias de usuarios . Estos son viajes reales de usuarios de extremo a extremo, de alcance muy limitado y definidos de una manera que puede estimarse y planificarse de forma independiente, y desarrollarse , probarse y lanzarse en un ciclo de lanzamiento.
La historia del usuario es la unidad de entrega. Es la historia del usuario que está completa o no completa, se activa o no se activa.
Un Epic puede generar una gran cantidad de historias de usuarios, no todas se desarrollarán o lanzarán al mismo tiempo.
Como ejemplo, la epopeya de Examinar catálogo de productos puede dividirse en
Una vez más, cada uno de estos se escribiría en el formato, por ejemplo, como cliente, quiero navegar por la jerarquía de categorías, de modo que pueda buscar productos y profundizar en el producto más adecuado para mis necesidades.
En general, para la mayoría de nuestros proyectos, tenemos decenas de épicas y cientos de historias.
Ahora, a medida que avanzamos en el ciclo de vida de la historia, etiquetamos estas historias con Feature s. Por ejemplo, todas las historias de navegación y búsqueda, inventario y precios se etiquetarán con, por ejemplo, 'catálogo de productos'. Las historias de Place Order relacionadas con el pago con tarjeta de crédito pueden estar etiquetadas con una etiqueta de 'tarjeta de crédito' y aquellas relacionadas con el pago con PayPal se etiquetarán con la etiqueta 'paypal'.
Estas etiquetas sirven para agrupar las historias que pertenecen juntas, no porque sean diferentes tipos de realizar la misma actividad (por ejemplo, todas las historias de orden de lugar) sino porque deben publicarse juntas.
Por ejemplo, la historia de "hacer un pedido pagando con tarjeta de crédito" pertenece a la misma epopeya que la historia de "hacer un pedido pagando con PayPal", pero no es necesario que se publiquen juntos.
Mientras que la historia de "hacer un pedido pagando con tarjeta de crédito", la historia de "procesar una devolución reembolsando en una tarjeta de crédito" y la historia de "permitir que los clientes administren sus tarjetas de crédito guardadas en su cuenta" parecen pertenecer el uno al otro . Todos habrían sido etiquetados con la etiqueta de función 'tarjeta de crédito'. es decir, todos pertenecerían a la función "Tarjeta de crédito". No es muy útil liberar la capacidad de realizar un pedido pagando con tarjeta de crédito, si no es posible procesar un reembolso de devolución en PayPal, o si no es posible administrar sus tarjetas de crédito guardadas en su cuenta
Nota : Como regla general, eso es. Esto es, al final, una decisión comercial. Si el tiempo de comercialización es importante, puede haber una razón legítima para comenzar con uno de estos y no con el otro.
Por lo tanto, las epopeyas sirven para descomponerse en historias (relacionadas, pero separadas) que se pueden desarrollar de forma independiente, mientras que las características sirven para agrupar historias que deberían publicarse juntas.
Se podría decir que las epopeyas se descomponen en historias de usuarios, y las historias de usuarios se componen en características. Las historias que pertenecen a una función suelen aparecer en Epics. Por lo tanto, las epopeyas y las características son ortogonales, no en una jerarquía estricta.
En nuestra forma de trabajar, una vez que las epopeyas se han desglosado en historias, pierden su propósito. No estimamos ni planificamos Epics. No rastreamos el progreso en Epics. No lanzamos Epics. Estimamos, planificamos y rastreamos Historias de usuarios. Y lanzamos Características.
fuente
Estoy de acuerdo, como muchas respuestas, en que realmente no hay respuestas correctas, ya que estos son solo términos que pueden variar según el campamento Agile en el que se base y definitivamente puede hacer su propio campamento siempre y cuando todos en su equipo, incluidas las partes interesadas externas Entiende lo que significan. Es solo una forma de organizar su requerimiento.
La respuesta que me gusta es del campamento de Mike Cohn y es bastante simple.
http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes
En realidad, evita el término "Característica". Supongo que es principalmente porque era un término común en el mundo tradicional de la cascada. Muchos campamentos ágiles tienden a usar términos diferentes para enfatizar las diferencias.
Entonces, en la definición de su PM, Feature está en algún lugar en el medio de la jerarquía de Epic-Story.
Aquí está mi gráfico de información de esta definición de mi artículo de InfoQ http://www.infoq.com/articles/visualize-big-picture-agile ;-)
fuente
Las características y las epopeyas no son lo mismo.
En las fases de planificación, las discusiones dan como resultado Historias de usuarios que generalmente se identifican como Épicas porque el esfuerzo para implementar soluciones para ellos es demasiado grande para lograrlo en unos pocos días. Las características del producto se identifican durante esta fase. Pero eso es solo un subproducto de la discusión. Las características se utilizan para planificar una hoja de ruta del producto, que es una discusión separada.
Las epopeyas se toman y se analizan más a fondo, lo que resulta en historias de usuarios para cada epopeya. Las características y las epopeyas se utilizan para impulsar los debates en las sesiones de refinamiento y planificación de Sprint . En ese momento, las Historias de usuarios que salen de esas discusiones se refinan , priorizan y, en la planificación de Sprint , se aceptan en sprints para su implementación.
fuente
Es solo un problema de descomposición. Son solo historias, excepto con diferentes tamaños.
Personalmente prefiero no etiquetar sus tamaños, pero si lo haces, también está bien. Pregúntele a PM cuál es la definición en su espacio de trabajo.
fuente
Nuestra organización tiene más de 2.000 desarrolladores, por lo que la respuesta a esta pregunta es importante para una comunicación fluida y clara entre los cientos de equipos ágiles que tenemos trabajando juntos en nuestro producto común. Para una organización muy pequeña, puede tener una estructura muy simple que ni siquiera necesita ser jerárquica (como han respondido otros). Sin embargo, para las organizaciones grandes, definitivamente existe la necesidad de una jerarquía organizada, escalada y consistente, y ahí radica el problema en tratar de hacer una jerarquía de algo que no sea estrictamente jerárquico.
Por cierto, nos referimos a cada uno de estos niveles dispares como "elementos de trabajo". Algunas organizaciones (incluidos algunos de los encuestados anteriores) se refieren a niveles dispares como Historias o Historias de usuarios (y también lo hemos hecho en el pasado), pero encontramos esto demasiado ambiguo, por lo que ahora nos referimos a ellos genéricamente como Elementos de trabajo.
Lo mejor que hemos hecho "oficialmente" hasta ahora es seguir la estructura SAFe de Dean Leffingwell de Temas de Inversión y Épicas de Negocios que está en la parte superior (y en segundo lugar desde la parte superior) de la jerarquía, luego Características debajo de eso, y finalmente Historias bajo Características. Según Agile, las tareas siempre están en Historias, por lo que tenemos cuidado de no reutilizar ese término más arriba. Elegimos seguir SAFe para al menos tener ALGUNA consistencia en todos nuestros equipos.
Pero esto todavía es insuficiente para nuestras necesidades. Definimos una característica como un producto claramente valioso para un consumidor de nuestro producto de software (es decir, enumeramos estas características en nuestros anuncios de próximas versiones). Y definimos una Historia como una cantidad menor de alcance y trabajo que puede ser entregado en un Sprint por un solo equipo de desarrollo de Agile. También estamos COMENZANDO a seguir la definición SAFe de Tema de inversión y Épica empresarial en el nivel de Cartera (y no por debajo de este nivel). Y estamos COMENZANDO a NO utilizar nuestras definiciones ANTIGUAS de "Tema" y "Épico".
Ahora estamos evolucionando lentamente en esta dirección, pero las ruedas del progreso se mueven lentamente. Todavía estamos luchando por cómo dividir el trabajo en trozos pequeños para que podamos definir el trabajo y que varios equipos lo hagan sin problemas. Para hacer esto, vemos la necesidad de una "Subfunción" que es más pequeña que una Característica pero más grande que una Historia. Las Subcaracterísticas se pueden usar para fragmentos de trabajo realizados en una Característica por CADA equipo INDIVIDUAL, o fragmentos de trabajo realizados por un equipo ÚNICO en diferentes momentos (en diferentes Sprints, o incluso en Versiones diferentes).
También necesitamos múltiples niveles jerárquicos entre Feature y Business Epic, pero aún no hemos resuelto este, aparte de llamarlos "Temas", que sabemos que no es el término correcto, ya que se confunde fácilmente con los Temas de inversión SAFe. Para algunos proyectos grandes (lanzamientos) tenemos hasta 5-8 niveles jerárquicos diferentes, cada uno dividiendo el trabajo en trozos cada vez más pequeños. Puede pensar en estos Temas como "Grupos de funciones", pero ese tampoco es necesariamente el término correcto.
Creo que es importante tratar de usar términos que ofrezcan claridad en lugar de ambigüedad. Entonces, cualquiera que se refiera a una Historia significa la unidad de trabajo más pequeña que se puede hacer en un Sprint (excepto las Tareas bajo la Historia), y Sub-Característica significa la unidad de trabajo más pequeña en una Función que puede hacer un solo equipo. Del mismo modo, un grupo de características es un nivel jerárquico superior a la característica. Por encima de eso, se vuelve un poco confuso, por lo que generalmente los llamamos Temas y permitimos Temas como padres e hijos de otros Temas. Intentamos restringir los niveles de Características, Subfunciones e Historia a un solo nivel cada uno (las Características no deben ser elementos secundarios de otras Características), pero todavía no tenemos un 100% de éxito en restringir esto.
Sé que podríamos usar "Etiquetas" para organizar algo de esto, pero las etiquetas no nos dan la estructura de desglose del trabajo organizativo que necesitamos para clasificar el trabajo entre todos nuestros equipos. Por definición, las etiquetas son ambiguas (relaciones de muchos a muchos), pero una jerarquía es estrictamente de uno a muchos.
La conclusión es que esto todavía es un trabajo en progreso para nosotros, y todavía estamos luchando con eso. ¡Pero si nos adherimos a las definiciones SAFe de Tema, Epopeya, Característica e Historia nos lleva a avanzar en la dirección correcta!
fuente
La jerarquía de la cartera de productos depende en gran medida del tamaño del producto y su modularidad (número de áreas de producto definidas).
Para proyectos pequeños: Epic> Story es más que suficiente; y llamas a la "característica".
Los proyectos grandes pueden ser similares a: Novela> Tema> Épico> Característica> Historia
El mejor ejemplo podría ser el siguiente:
Novela =
Tema de MS Office = MS Word / MS Excel ...
Epic = Tablas / Directorio de fuentes ...
Características = Tabla básica / Esquema de color de tabla / Operaciones con celdas ...
Historias (para ' Característica básica de tablas dentro de la épica de tablas) = Agregar tabla / Dibujar tabla / Insertar sin formato / Insertar columna ...
Lo que creo que es beneficioso tener en cuenta al definir su propia escala para el trabajo atrasado es:
1. Historia: a) siempre factible dentro de un sprint; b) no siempre es comprobable para los usuarios finales
2. Epic / Feature: a) no se ajusta a la duración de un sprint y debe descomponerse; b) siempre debe ser comprobable para los usuarios finales; c) siempre se puede enviar, se puede monetizar: calcule el ROI para ello
3. Al considerar agregar o no Epic> sección Característica o apegarse a Epic> Historia: recomendaría insertar la función entre Epic y Story solo cuando: Epic no no se ajusta incluso a 1 Release, por lo que debe definir el elemento de envío que se ajuste a la duración de 1 Release .
Espero que esto sea útil.
fuente
En nuestra organización tenemos lo siguiente:
Tema = Se utiliza para agrupar una colección de historias.
Epic = Describe una gran historia de usuario (en verdad, un requisito) que debe desglosarse en historias de usuario
Características = Hace lo que dice en la lata, describe una característica del producto requerido
Historia del usuario = Este es el nivel de detalle más bajo del que se derivan las tareas.
fuente