He escuchado muchas veces que las tareas son básicamente subconjuntos de historias de usuarios y se derivan de las historias de usuarios, por lo que en la escala de la cantidad de trabajo que se necesita para terminarlas, una tarea siempre es más pequeña que una historia de usuario.
Tengo curiosidad, sin embargo, si podría haber algún caso, cuando una tarea no se deriva de una historia de usuario, por lo tanto, puede contener una mayor cantidad de trabajo que algunas historias de usuario en la cartera de productos.
¿La tarea siempre se descompone de la historia del usuario?
No.
Las tareas a menudo se separan de una historia de usuario, pero eso no significa que una tarea solo pueda existir como parte de las historias de usuario y, por lo tanto, siempre tienen un tamaño más pequeño. Las tareas pueden existir por sí mismas.
Has etiquetado la pregunta Scrum. Las historias de usuario no son algo específico de Scrum. Tu Product Backlog no se compone solo de historias de usuarios. Puede tener epopeyas, historias, errores, tareas, picos o lo que necesite su producto. Scrum llama genéricamente a todos estos elementos de la cartera de productos .
Al trabajar con historias de usuarios, algunos equipos prefieren dividirlas en tareas, pero eso no es obligatorio, es una preferencia. A veces, incluso es problemático porque pueden dividir la historia horizontalmente en cosas como "construir las consultas de la base de datos", "construir el back-end", "construir el front-end", "revisión de código", "pruebas", etc., lo que puede crear silos de desarrollo dentro del equipo en lugar de que todos encuentren una manera de colaborar en la historia y, al mismo tiempo, encuentren el equilibrio adecuado para trabajar individualmente. A mí, por ejemplo, no me gusta dividir las historias en tareas. Algunos argumentan que las tareas le permiten ver mejor el progreso dentro del sprint, y su gráfico de quemadose ve mejor, pero no lo encuentro útil porque si tienes una historia dividida en 5 tareas, si solo terminas 4 de ellas, la historia no se completa de ninguna manera. Pero yo divago...
Volviendo a que la tarea es más grande que una historia, sí es posible . Como dije, una tarea puede ser un elemento de la cartera de productos al igual que una historia de usuario. Podría tener algunas tareas técnicas pendientes que son más grandes que algunas historias.
Digamos que tienes una historia para iniciar sesión. El equipo podría terminar eso en medio día. Pero también tienen una tarea técnica para actualizar las bibliotecas del marco y algunos de sus métodos quedaron obsoletos entre versiones. Ahora el equipo necesita hacer pequeños cambios aquí y allá y eso les lleva todo el día. La tarea del marco en este ejemplo es dos veces más grande que la historia de inicio de sesión del usuario.
Puede sentir la diferencia al comprender el motivo de la existencia de la historia de usuario.
La historia de usuario representa el valor de negocio entregable al cliente y es el elemento básico en la cartera de productos. La historia del usuario se escribe en la etapa de recopilación de requisitos y luego se inyecta en un sprint específico, después de eso, el equipo Scrum tiene que implementar esta historia, la implementación se realiza explorando las tareas técnicas requeridas para esa historia.
Creo que la tarea es solo una tarea, es una actividad técnica, pero User Story es un deseo del usuario. Encuentre más Scrum.org
Recuerde: las "historias de usuario (!) " son exactamente eso... un requisito comercial/de software, expresado desde el punto de vista del usuario.
Los "usuarios", sin embargo, tienen pleno derecho a "esperar que un sistema 'funcione', sin preocuparse por cómo funciona". No tienen idea de cómo los sistemas que utilizan están diseñados internamente... ni se debe esperar que lo hagan. Por lo tanto, debe haber una traducción del "dominio centrado en el usuario" expresado por una "historia" y el "dominio centrado en la tecnología" que se requiere para implementarlo .
Este paso de traducción consiste en la formulación de tareas, planes de prueba, etc. Todo llevado a cabo por expertos técnicos que están completamente familiarizados con el sistema subyacente. Ciertamente incluirá consideraciones puramente técnicas que "el usuario no conoce ni le importa". Después de todo, su trabajo es conducir el automóvil, no construirlo . Sus "historias", por lo tanto, son meras entradas.
El valor de la idea de la "historia de usuario" es que se esfuerza por proporcionar las aportaciones del usuario a los diseñadores "en sus propios términos". Porque de lo contrario es muy fácil para un diseñador perder de vista las perspectivas del usuario. Pero, la idea nunca tuvo la intención de sugerir que el usuario final de alguna manera se había convertido en un experto técnico en las "tripas" de cualquier sistema.
Daniel
Banik