Respuesta corta
El equipo de desarrollo escribe las cosas técnicas. Scrum te ayuda un poco pero no mucho con el desglose técnico resp. comenzar con una historia de usuario. Scrum es casi el único mundo . El desglose técnico es How-World .
El desglose proporcionado por Scrum es:
- Historia de usuario -> Criterios de aceptación
El desglose que la gente suele usar además de esto es:
- Epic -> Historias de usuarios
- Historia de usuario -> Subtareas
- Criterios de aceptación -> Pruebas de aceptación
Además, el equipo podría escribir Tareas técnicas para las cosas que saben que deben hacerse (es decir, instalar IntelliJ IDEA para todos al comienzo del proyecto) pero que no tienen valor comercial.
Para obtener más orientación sobre cómo desglosar el trabajo, busque XP (programación extrema), código limpio , programación pragmática , ingeniería de software , tarjetas CRC , OOP / OOA / OOD , patrones de diseño , refactorización , trabajo efectivo con código heredado , TDD ( Desarrollo guiado por pruebas , BDD (Desarrollo guiado por el comportamiento), ATDD ( Desarrollo guiado por pruebas de aceptación).
Respuesta larga
Cómo piensa Scrum
Qué mundo y cómo mundo
Hay un mundo del qué y un mundo del cómo . Como se sintió correctamente, User Story es para usuarios , generando valor comercial, también conocido como valor secundario en el mundo de lo que . Scrum es principalmente What-World solamente. Dice poco o nada sobre el How-World , básicamente no más que "How-World es responsabilidad del Dev-Team".
User Story vs Task
Por lo general, los elementos de Backlog que son para How-World no se llaman User Story sino Technical Task o Subtask . Muchas herramientas permiten desglosar la historia del usuario del What-World en Subtareas en el How-World .
Cómo ayuda Scrum y dónde termina esa ayuda
La ayuda de Scrum for the How-World termina en algunos puntos de la reunión de planificación de Sprint :
- [Reunión de planificación de Sprint] El equipo descubre un malentendido de la historia si diferentes compañeros de equipo obtienen diferentes estimaciones de Story Point durante el Poker de planificación -> Discusión.
- [Definición de Listo] El equipo no acepta Historias de usuarios que son demasiado grandes (Puntos de historia demasiado altos). Una regla general que se encuentra en muchas definiciones de Ready es que los puntos de historia deben ser inferiores a la mitad de la velocidad del equipo.
- [Definición de Listo] El equipo no acepta Historias de usuarios sin una descripción suficiente de los Criterios de aceptación. Los criterios de aceptación son suficientes si el equipo tiene suficiente confianza sobre cómo comenzar a escribir las pruebas de aceptación.
Algunos consejos sobre el nivel de Scrum
Me pareció útil hacer un desglose de Historias de usuarios en Subtareas durante las reuniones de Refinamiento de la cartera o al menos la segunda parte de la Reunión de planificación de Sprint (para algunos equipos Reunión de planificación 2 de Sprint ).
Con equipos inexpertos, me resultó útil luchar por historias de usuarios atómicos durante el refinamiento de la cartera y la planificación de Sprint. Una historia de usuario atómica es una historia de usuario que no puede desglosarse en historias de usuario más pequeñas sin perder por completo su valor comercial. En general, las historias de usuario no necesitan ser atómicas, acabo de descubrir que me ayuda con equipos sin experiencia.
Y no haga "(Arquitectura | Diseño | Implementación | Prueba) de la Característica X" como Historias de usuarios. Te recomiendo que incluso intentes evitar esto como una subtarea.
Si tengo Historias de usuarios atómicos y parecen necesitar un mayor desglose aparte de los Criterios de aceptación que se implementarán, significa que algo no está funcionando en el nivel óptimo. O la arquitectura es incorrecta / demasiado complicada, es decir, técnica en lugar de orientada a los negocios. O el equipo no tiene experiencia. O ambos. En cualquier caso, se requerirían medidas para mejorar la situación mediante la capacitación y la difusión de conocimientos.
Más allá de Scrum
El Scrum Master más allá de Scrum
Hoy, el Scrum Master se entiende principalmente como un rol gerencial , y eso es una mierda. Originalmente, el Scrum Master era, y defiendo esto, un rol técnico , no un rol de gestión, al igual que el entrenador en XP .
Es demasiado fácil confiar en Scrum y el Scrum Master y, por lo tanto, caer en una gran brecha porque Scrum no dice casi nada sobre el How-World.
Rotación Scrum Master
Idealmente, el Scrum Master rota entre aquellos desarrolladores experimentados que también tienen suficientes habilidades de gestión y comunicación hasta que todos en el equipo vivan "Inspeccionar y adaptarse" tan profundamente que el Scrum Master se vuelve redundante; nadie y todos serían Scrum Master al mismo tiempo.
Pero cuidado, Scrum Mastery es más como cocinar, no como limpiar la mesa y lavar los platos. Es posible que desee rotar quién limpia la mesa y lava los platos, ya que todos podrían hacerlo. Pero no querrá rotar la cocina sobre todos, porque hay personas que no pueden cocinar o no les gusta cocinar, y desea comer buena comida.
Lo bueno de rotar el Scrum Master entre desarrolladores expertos es que es más probable que el equipo aprenda sobre más métodos.
El equipo autoorganizado
Desde la perspectiva de Scrum, el equipo debe descubrirse a sí mismo, idealmente con la ayuda del Scrum Master .
Scrum también solo habla del equipo de desarrollo . Roles como Arquitecto o Ingeniero principal no existen en Scrum. Eso no significa que estén prohibidos, solo significa que Scrum no dice nada sobre ellos. Scrum proclama un equipo autoorganizado , lo que significa que si el equipo declara un arquitecto, el equipo tiene un arquitecto. Eso no está definido por Scrum, pero es compatible con Scrum. No estoy proclamando arquitectos dedicados (trabajé como arquitecto designado durante años, y aunque me gustó, estoy fundamentalmente en contra de la idea de un arquitecto designado), solo estoy dando un ejemplo.
Prueba de aceptacion
Las historias de usuario tienen criterios de aceptación . Estos criterios de aceptación se convierten en pruebas de aceptación
Otras cosas
Para obtener una lista de más cosas para el desglose, consulte ¿Cómo dividir un proyecto de programación en tareas para otros desarrolladores?
Espero que esto ayude.