Unidad de trabajo: Difference between revisions
| Line 3: | Line 3: | ||
*'''[[Historia de usuario]]:''' una descripción corta, simple y específica del valor que un producto o servicio debe proporcionar al usuario final, escrita desde la perspectiva de éste. Se generan durante las conversaciones entre desarrolladores y propietario de producto para lograr una visión alineada, y sirven para recordar lo hablado. | *'''[[Historia de usuario]]:''' una descripción corta, simple y específica del valor que un producto o servicio debe proporcionar al usuario final, escrita desde la perspectiva de éste. Se generan durante las conversaciones entre desarrolladores y propietario de producto para lograr una visión alineada, y sirven para recordar lo hablado. | ||
*'''Historia técnica:''' similar a la historia de usuario, pero en casos de funcionalidades que no son visibles directamente por el usuario final. Por ejemplo, refactorizaciones o implementación de medidas de seguridad. | *'''Historia técnica:''' similar a la historia de usuario, pero en casos de funcionalidades que no son visibles directamente por el usuario final. Por ejemplo, refactorizaciones o implementación de medidas de seguridad. | ||
*'''[[Tarea]]:''' unidades de trabajo más pequeñas | *'''[[Tarea]]:''' unidades de trabajo más pequeñas que las dos anteriores. Son actividades que deben completarse para cumplir con una historia, como escribir código, diseñar interfaces, realizar pruebas… | ||
Cuando una historia es demasiado grande y está muy poco definida se suele denominar «épica» o '''«[[Epic|epic]]»'''. Las epics, como las historias y tareas, son requisitos ágiles, pero debido a su tamaño y falta de detalle '''no sirven como unidades de trabajo'''. Un ejemplo de epic puede ser, por ejemplo, desarrollar un nuevo sistema de gestión de tickets. | Cuando una historia es demasiado grande y está muy poco definida se suele denominar «épica» o '''«[[Epic|epic]]»'''. Las epics, como las historias y tareas, son requisitos ágiles, pero debido a su tamaño y falta de detalle '''no sirven como unidades de trabajo'''. Un ejemplo de epic puede ser, por ejemplo, desarrollar un nuevo sistema de gestión de tickets. | ||
Latest revision as of 12:04, 30 May 2024
La «unidad de trabajo» es el elemento que el equipo utiliza para gestionar el trabajo dentro de un sprint. Las unidades más usadas son las historias de usuario, las historias técnicas y las tareas.
Unidades más usadas
- Historia de usuario: una descripción corta, simple y específica del valor que un producto o servicio debe proporcionar al usuario final, escrita desde la perspectiva de éste. Se generan durante las conversaciones entre desarrolladores y propietario de producto para lograr una visión alineada, y sirven para recordar lo hablado.
- Historia técnica: similar a la historia de usuario, pero en casos de funcionalidades que no son visibles directamente por el usuario final. Por ejemplo, refactorizaciones o implementación de medidas de seguridad.
- Tarea: unidades de trabajo más pequeñas que las dos anteriores. Son actividades que deben completarse para cumplir con una historia, como escribir código, diseñar interfaces, realizar pruebas…
Cuando una historia es demasiado grande y está muy poco definida se suele denominar «épica» o «epic». Las epics, como las historias y tareas, son requisitos ágiles, pero debido a su tamaño y falta de detalle no sirven como unidades de trabajo. Un ejemplo de epic puede ser, por ejemplo, desarrollar un nuevo sistema de gestión de tickets.
Cuándo descomponer las historias en tareas
Cuando se empieza a trabajar usando scrum, es habitual descomponer las historias en tareas. Esto permite ver el avance día a día, lo cual puede ser especialmente útil en equipos con miembros con menos experiencia, por ejemplo para evitar entrar en puntos muertos.
Sin embargo, conforme se va ganando experiencia, descomponer cada historia en tareas puede resultar tedioso o incluso generar cierta parálisis. Si los desarrolladores son capaces de gestionar su trabajo durante el sprint directamente a nivel de historia, obligar a descomponer en tareas se vuelve una microgestión innecesaria. Usar unas unidades u otras depende del contexto.