Scrum Master 3 - fe de erratas
Fe de erratas y actualizaciones de la guía de Scrum Master
En la versión 4.0
Desmontando la gestión de proyectos
Localización
- Página 19 (nueva versión del manual).
- Página 26 (versión anterior del manual).
| o al simple uso de técnicas de gestión visual kanban para mantener un flujo continuo de tareas. |
| o al simple uso de técnicas de gestión visual kanban para mantener un flujo continuo de trabajo. |
Diferenciando prácticas de principios y valores
Localización
- Página 21 (nueva versión del manual).
- Página 28 (versión anterior del manual).
| Cuando se empieza a trabajar con scrum, como con cualquier otra herramienta, es recomendable leer el manual y seguir las instrucciones; es decir, adoptar el marco estándar: el que se explica en la primera parte de este manual, con los roles, artefactos y eventos que lo configuran.
Conviene no engañarse: si el foco está puesto en el proceso y no en el conocimiento tácito de las personas no se está haciendo agilidad, sino ingeniería concurrente. Cuando se alcanza un flujo de avance iterativo, se puede intentar ir más allá. Llega el momento de desaprender las prácticas y de apoyarse en los principios y valores de scrum, adaptando éste y otras técnicas y marcos a las características concretas del proyecto o del equipo. En la mayoría de empresas ágiles estas prácticas se pueden adaptar, y de hecho se adaptan. |
| Cuando se empieza a trabajar con scrum, como con cualquier otra herramienta, es recomendable leer el manual de Scrum Master y seguir las instrucciones; es decir, adoptar el marco tradicional o estándar. En esta primera parte explicamos en qué consiste, y cuáles son los roles, artefactos y eventos que lo configuran. El marco es, por así decir, una plantilla, pero no un molde. No son reglas que deban seguirse al pie de la letra para garantizar velocidad o calidad, sino de un buen punto de partida para empezar a trabajar de forma iterativa.
Conviene no engañarse: si nuestro foco está puesto en el proceso, en seguir las reglas, y no en el conocimiento tácito o talento de las personas, no se está haciendo agilidad, sino ingeniería concurrente. La agilidad requiere confianza en las capacidades del equipo. Las herramientas y procesos que se usan deben ayudar a gestionar el trabajo; no a las personas. Ya que el objetivo final es que los equipos sean capaces de autogestionarse. Cuando se alcanza un flujo de avance iterativo, se puede intentar ir más allá de un marco estándar de scrum. Llega el momento de desaprender las prácticas y de apoyarse en los principios y valores de scrum, adaptando éste y otras técnicas y marcos a las características concretas del proyecto o del equipo. En la mayoría de empresas ágiles estas prácticas se pueden adaptar, y de hecho se adaptan. |
El ciclo scrum
Localización
- Página 24 (nueva versión del manual).
- Página 31 (versión anterior del manual).
| Se comienza con la visión general del resultado que se desea, y a partir de ella se especifica y da detalle a las funcionalidades que se desean obtener en primer lugar.
Cada ciclo de desarrollo o iteración (sprint) finaliza con la entrega de una parte operativa del producto (incremento). La duración de cada sprint puede ser de una hasta seis semanas, aunque se recomienda que no exceda de un mes. En scrum, el equipo monitoriza la evolución de cada sprint en reuniones breves diarias donde se revisa el trabajo realizado por cada miembro el día anterior, y el previsto para el día actual. Estas reuniones son de tiempo cerrado, de 5 a 15 minutos máximo, se realizan de pie junto a un tablero o pizarra con información de las tareas del sprint y el trabajo pendiente en cada una. Se denominan «reunión de pie» o «scrum diario» (en inglés stand-up meeting, daily scrum o morning rollcall). |
| Se comienza con la visión general del resultado que se desea, y a partir de ella se especifica y da detalle a las funcionalidades que se desean obtener en primer lugar.
Cada ciclo de desarrollo o iteración (sprint) finaliza con la entrega de una parte operativa del producto (incremento). La duración de cada sprint puede ser de entre 1 y 3 semanas. Lo más habitual es que tengan siempre la misma medida, marcando una cadencia, pero ésta puede ir evolucionando o ajustarse. Vídeo explicativo: El marco de desarrollo scrum (→ «Referencias bibliográficas»). |
Roles: desarrollador
Localización
- Página 28 (nueva versión del manual).
- Página 35 (versión anterior del manual).
| Cada uno de los profesionales que realizan el «incremento» (→ «Artefactos») de cada sprint.
Se recomienda que haya entre 3 y 9 desarrolladores. Más allá de 9 resulta difícil mantener la comunicación directa, y se manifiestan con más intensidad los roces habituales de la dinámica de grupos, que comienzan a partir de 6 personas. Son profesionales multifuncionales, que trabajan de forma solidaria con responsabilidad compartida. Es posible que algún desarrollador esté especializado en áreas concretas, pero la responsabilidad del desarrollo recae sobre todos por igual. Las principales responsabilidades, más allá de la autogestión y uso de tecnologías ágiles, son las que marcan la diferencia entre un «grupo de trabajo» y un «equipo»:
|
| Cada uno de los profesionales que realizan el «incremento» (→ «Artefactos») de cada sprint. Aunque se les denomine «desarrolladores» en scrum esto no significa que se hable siempre de programadores. Es un término que engloba a las personas cuyo trabajo contribuye directamente a «desarrollar» o construir el «incremento».
Se recomienda que haya entre 3 y 9 desarrolladores. Más allá de 9 resulta difícil mantener la comunicación directa, y se manifiestan con más intensidad los roces habituales de la dinámica de grupos, que comienzan a partir de 6 personas. Son profesionales multifuncionales, que trabajan de forma solidaria con responsabilidad compartida. Es posible que algún desarrollador esté especializado en áreas concretas, pero la responsabilidad del desarrollo recae sobre todos por igual. Las principales responsabilidades, más allá de la autogestión y uso de tecnologías ágiles, son las que marcan la diferencia entre un «grupo de trabajo» y un «equipo»:
|
Artefactos más extendidos
Localización
- Página 29 (nueva versión del manual).
- Página 37 (versión anterior del manual).
* Pila del producto / product backlog: Registra y prioriza los requisitos desde el punto de vista del cliente. Empieza con una visión inicial del producto y crece y evoluciona durante el desarrollo. Los requisitos suelen denominarse «historias de usuario», que se descomponen en «tareas» de menor tamaño, normalmente de un día de trabajo como máximo.
|
* Pila del producto / product backlog: lista priorizada de las necesidades del cliente, expresadas como historias de usuario. Al principio del proyecto refleja el MVP (producto mínimo viable) o la visión inicial. Es un documento vivo: durante el desarrollo, crece y evoluciona.
Enlace de interés: Cómo crear un backlog, Scrum Manager Podcast (→ «Referencias bibliográficas»). |
Otros artefactos
Localización
- Página 29 (nueva versión del manual).
- Página 38 (versión anterior del manual).
* Gráfico de avance o burn down chart: indica el trabajo pendiente y la velocidad a la que se están completando las tareas para deducir si se completarán todas en el tiempo estimado. Los desarrolladores lo actualizan a diario.
|
* Gráfico de avance o burn down chart: indica el trabajo pendiente y la velocidad a la que se están completando las unidades de trabajo, para deducir si se completarán todas en el tiempo estimado. Los desarrolladores lo actualizan a diario.
Enlace de interés: Definition of Done, Scrum Manager Podcast (→ «Referencias bibliográficas»). |
Unidad de trabajo
Localización
- Página 30 (nueva versión del manual).
Se ha añadido el concepto unidad de trabajo.
Pila del producto
Localización
- Página 31 (nueva versión del manual).
- Página 39-40 (versión anterior del manual).
| Las más prioritarias deben estar lo bastante detalladas como para descomponerse en tareas y pasar al siguiente sprint.
Las tareas de priorización, detalle y preestimación de las historias, previas al sprint, se suelen llamar «refinado» o «preparación». El propietario del producto y los desarrolladores pueden realizarlas en cualquier momento, de forma colaborativa, pero nunca deberían consumir más del 10% de la capacidad de trabajo del equipo. Más tarde los desarrolladores realizarán una segunda estimación más detallada, en la «reunión de planificación del sprint» (→ «Eventos»), al descomponer las «historias» en «tareas». La responsabilidad de estimar el esfuerzo previsible para cada elemento de la posterior lista de tareas (→ «Pila del sprint») es de los desarrolladores. (→ «Medición y estimación ágil»). Las historias de usuario de la pila del producto que pueden ser incorporados a un sprint se denominan «preparadas» o «ready». Se aplica este término (o similar) para indicar que el propietario del producto y el equipo de desarrollo están de acuerdo en que la historia está lista para ser seleccionada para el sprint. Es decir: está definida, preestimada, es asumible por sí misma en un único sprint, y se han establecido los criterios para considerarla terminada, así como la persona responsable de verificar que se cumplen. |
| Las más prioritarias deben estar lo bastante detalladas como para incluirse en el sprint. Acordar una DoR puede ayudar. A la labor de priorizar, detallar y preestimar las historias, se le suele llamar «refinado» o «preparación». Se trata de una tarea colaborativa; el propietario del producto y los desarrolladores pueden realizar una reunión de refinado en cualquier momento, sin que esto consuma nunca más del 10% de la capacidad de trabajo del equipo. Conviene recordar que las estimaciones, el esfuerzo previsible para cada elemento de la pila del sprint, son a juicio de los desarrolladores, ya que son quienes realizarán el trabajo (→ «Medición y estimación ágil»).
Las historias de usuario de la pila del producto que pueden ser incorporados a un sprint se denominan «preparadas» o «ready». Se aplica este término (o similar) para indicar que el propietario del producto y el equipo de desarrollo están de acuerdo en que la historia está lista para ser seleccionada para el sprint. Es decir: está definida, preestimada, es asumible por sí misma en un único sprint, y se han establecido los criterios para considerarla terminada, así como la persona que los verificará. |
Pila del sprint
Localización
- Página 32-33 (nueva versión del manual).
- Página 41-42 (versión anterior del manual).
| La «pila del sprint» o «sprint backlog» es la lista de todas las tareas necesarias para construir las historias de usuario que se van a realizar en un sprint. En ella las historias de usuario se descomponen en unidades de tamaño adecuado para monitorizar el avance a diario, así como para identificar riesgos y problemas sin procesos de gestión complejos.
Todo el equipo colabora en la confección de esta pila, durante la «reunión de planificación del sprint» (→ «Eventos»), indicando para cada tarea el esfuerzo previsto para realizarla. Para calcular el «esfuerzo» de cada tarea en «puntos» o «tiempo ideal» (→ «Medición y estimación ágil») es habitual emplear técnicas como la estimación de póquer (→ «Prácticas para flexibilizar scrum», «Estimación de póquer»). Las tareas de mayor tamaño se dividen en otras, de modo una sola nunca dure más de un día de trabajo. Si la pila del producto es territorio del propietario del producto, la pila del sprint es territorio de los desarrolladores. Son los únicos que pueden modificarla durante el sprint. Proporciona además comunicación visual directa y sobre ella el equipo de desarrollo revisa a diario el avance del sprint. Lo ideal es que se encuentre en un tablero o pared en el mismo espacio físico donde se trabaja, para que sea visible por todos. Algunos soportes habituales son tableros físicos, hojas de cálculo compartidas, y herramientas colaborativas de gestión de proyectos tales como Todoist, Flow o Trello. Lo apropiado es utilizar el formato más cómodo para todos, teniendo en cuenta los siguientes criterios:
|
| La «pila del sprint» o «sprint backlog» es la lista de todas las unidades de trabajo (historias, tareas…) para completar el incremento. En ella las historias de usuario se descomponen en unidades de tamaño adecuado para monitorizar el avance a diario, así como para identificar riesgos y problemas sin procesos de gestión complejos.
Todo el equipo colabora en la confección de esta pila, durante la «reunión de planificación del sprint» (→ «Eventos»), indicando para cada unidad de trabajo el esfuerzo previsto para realizarla. Es habitual estimar este esfuerzo en «puntos» o «tiempo ideal» (→ «Medición y estimación ágil») empleando técnicas como la estimación de póquer (→ «Prácticas para flexibilizar scrum», «Estimación de póquer»). Durante la reunión de planificación los desarrolladores pueden, si así lo deciden, dividir las historias en tareas más pequeñas. En tal caso se aconseja que una tarea no dure más de un día de trabajo. Si la pila del producto es territorio del propietario del producto, la pila del sprint es territorio de los desarrolladores. Son los únicos que pueden modificarla durante el sprint. Proporciona además comunicación visual directa y sobre ella el equipo de desarrollo revisa a diario el avance del sprint. Lo ideal es que se encuentre en un tablero o pared en el mismo espacio físico donde se trabaja, para que sea visible para todos. Algunos soportes habituales son tableros físicos, hojas de cálculo compartidas, y herramientas colaborativas de gestión de proyectos tales como Todoist, Flow o Trello. Lo apropiado es utilizar el formato más cómodo para todos, teniendo en cuenta los siguientes criterios:
|
Eventos
Localización
- Página (nueva versión del manual).
- Página (versión anterior del manual).
| Example |
| Example |
Reunión de planificación del sprint
Localización
- Página (nueva versión del manual).
- Página (versión anterior del manual).
| Example |
| Example |
Scrum diario
Localización
- Página (nueva versión del manual).
- Página (versión anterior del manual).
| Example |
| Example |
Medición y estimación ágil
Localización
- Página (nueva versión del manual).
- Página (versión anterior del manual).
| Example |
| Example |
En la versión 3.07
Errata (DoR)
Localización
Página 20 Dice: y la definición de hecho (DoR) Debe decir: y la definición de hecho (DoD)
Enlace a vídeo explicativo del gráfico burn down
Localización
Página 68 Dice: https://www.youtube.com/watch?v=alafvKVTICA Debe decir: https://www.youtube.com/watch?v=hveuhx7rZgw
En la versión 3.06 y corregidas en la 3.07
Revisión del sprint
Localización
Página 52.
Dice:
"Reunión realizada al final del sprint para comprobar el incremento. Lo habitual es que dure una o dos horas; en caso de incrementos de especial relevancia o complejidad, puede extenderse hasta 4 como máximo. Asiste todo el equipo scrum y todas las personas implicadas en el proyecto que lo deseen. Esta reunión marca, a intervalos regulares, el ritmo de construcción, y la trayectoria que va tomando la visión del producto. Al ver y probar el incremento, el propietario del producto y el equipo en general obtienen feedback relevante para revisar la pila del producto. Se identifican las historias de usuario que se pueden considerar «hechas» («done») y las que no. Reunión realizada el final del sprint para enseñar el incremento y recoger sugerencias."
Por la experiencia y sugerencias de la comunidad profesional Scrum Manager, no es necesario considerar "hechas" (done) las historias en esta reunión, y en muchas circunstancias puede resultar aconsejable no vincularlo a la revisión del sprint.
Nueva redacción :
"Reunión realizada al final del sprint para enseñar el incremento y recoger sugerencias. Lo habitual es que dure una o dos horas; en caso de incrementos de especial relevancia o complejidad, puede extenderse hasta 4 como máximo. Asiste todo el equipo scrum y todas las personas implicadas en el proyecto que lo deseen. Esta reunión marca, a intervalos regulares, el ritmo de construcción y la trayectoria que va tomando la visión del producto permitiendo un espacio donde recibir sugerencias de los interesados que permitan seguir evolucionando el producto. El equipo presenta las historias de usuario que planificaron, las que han desarrollado, las que no y los impedimentos encontrados. Es importante situar las expectativas de los interesados en la realidad al principio de la reunión."
Dice:
Protocolo recomendado:
- El equipo expone el objetivo del sprint, la lista de funcionalidades que se incluían y el incremento desarrollado.
- El equipo hace una introducción general del sprint y demuestra el funcionamiento de las partes construidas. Se abre un turno de preguntas y sugerencias. Esta parte genera información valiosa para que el propietario del producto y el equipo en general puedan mejorar la visión del producto.
Nueva redacción :
Protocolo recomendado:
- El equipo expone el objetivo del sprint, la lista de funcionalidades que se incluían y las que se han desarrollado.
- El equipo hace una introducción general del sprint y demuestra el funcionamiento de las partes construidas. Se abre un turno de preguntas y sugerencias. Esta parte genera información valiosa para que el propietario del producto y el equipo en general puedan mejorar la visión del producto.
Resultados del scrum diario
Localización
Página 50 -> Tabla de entradas y resultados del scrum diario. En la columna "resultados" dice: "Información del avance de cada miembro del equipo". Debe decir "Identificación de posibles necesidades e impedimentos" Capítulo: Aprendiendo las prácticas estándar -> Artefactos -> Otros artefactos
En la versión 3.052 y corregidas en la 3.06
Desvinculación de la clasificación de implicados y comprometidos con los roles del marco scrum
Localización
Página 29.
Nueva redacción:
Comprometidos e implicados Durante el desarrollo del proyecto son muchas las personas que intervienen y aportan valor al desarrollo, si bien con diferentes niveles de compromiso y responsabilidad, en función de lo cual se suele diferenciar entre «comprometidos» e «implicados». Comprometidos: intervienen directamente en la construcción del producto o el desarrollo del servicio. Implicados: otras partes interesadas: dirección, gerencia, comerciales, marketing, operadores del sistema que se desarrolla, soporte a usuarios, etc. En círculos de scrum es frecuente llamar a los primeros (sin ninguna connotación peyorativa) «cerdos» y a los segundos «gallinas». El origen de estos nombres está en la siguiente historia, que ilustra de forma gráfica la diferencia entre compromiso e implicación en el proyecto: Una gallina y un cerdo paseaban por la calle. La gallina preguntó al cerdo: -¿Quieres abrir un restaurante conmigo? El cerdo consideró la propuesta y respondió: -Sí, me gustaría. ¿Cómo lo llamaríamos? -Huevos con Jamón. El cerdo se detuvo, hizo una pausa y contestó: -Pensándolo mejor, creo que no voy a abrir un restaurante contigo. Yo estaría realmente comprometido… mientras que tu estarías sólo implicada.
Revisión del texto del diagrama de árbol para retrospectiva
Localización
Página 75.
Sobre la participación del propietario del producto en la retrospectiva.
Localización
Página 53.
Se eliminan las consideraciones acerca de la conveniencia de la participación en las retrospectivas del propietario del producto cuando no se trata de un miembro implicado, por encontrarnos más en una implementación más de ingeniería concurrente que de "Agilidad" con condiciones contractuales que pudieran desaconsejarlo. Se elimina por ser una consideración que excede el ámbito de formación estándar del marco scrum.
Actualización de contenido en el tema de estimación ágil: NoEstimates
actualiza el tema de estimación ágil, reflejando algunas de las críticas y alternativas más frecuentes al uso de puntos de historia. Éstos siguen formando parte del temario que explica el marco estándar de scrum, y las alternativas se han incluido entre las «Prácticas para flexibilizar scrum», en dos apartados:
- Estimación sin puntos de historia.
- NoEstimates.
En ambos casos se destacan ventajas e inconvenientes, explicando en qué contextos pueden resultar más adecuados.
En la versión 3.051 y corregidas en la 3.052
Mejora de la definición del gráfico de producto o burn up chart
Localización
Capítulo: Aprendiendo las prácticas estándar -> Artefactos -> Otros artefactos
- Dice ... "si el gráfico de avance mide lo que falta, el de producto mide cuánto se ha construido o completado". Nueva redacción: "El gráfico de producto o gráfico “burn up” es una herramienta de planificación propia del propietario de producto, que presenta visualmente la evolución previsible del producto.
Desvinculación de la validación de historias de usuario con la reunión de revisión del sprint
Localización
Descripción de la reunión "Revisión del sprint" (página 47 de la edición en PDF)
- Dice "Esta reunión marca, a intervalos regulares, el ritmo de construcción, y la trayectoria que va tomando la visión del producto. Al ver y probar el incremento, el propietario del producto y el equipo en general obtienen feedback relevante para revisar la pila del producto. Se identifican las historias de usuario que se pueden considerar «hechas» («done») y las que no." Se cambia a: "Esta reunión marca, a intervalos regulares, el ritmo de construcción, y la trayectoria que va tomando la visión del producto permitiendo un espacio donde recibir sugerencias por parte de los interesados que permitan seguir evolucionando el producto."
Gazapo: falta cierre de interrogación
Localización
- Dice "¿Por qué es valioso este sprint". Debe decir "¿Por qué es valioso este sprint?" (Página 41 de la edición en pdf)
En la versión 3.05 y corregidas en la 3.051
Actualización: ISO 15504 ha sido reemplazado por ISO 33000
Localización
Capítulo: Introducción -> El Manifiesto Ágil
- Dice "...SPICE (proyecto inicial de ISO 15504)..." Debe decir "...SPICE (proyecto inicial de ISO 15504, a su vez precursor de ISO 15504)"
Año en la nota bibliográfica de Extreme Programming Explained
- Tiene como año de publicación 2000 y debe tener 1999
Enlace a FAQ de scrummanager.com
Localización
Apéndices.
- El enlace está desfasado.
Supresión del término grooming
- Para aludir a la preparación o refinado de la pila de producto se elimina como sinónimo "grooming" al quedar en desuso en la comunidad angloparlante por las connotaciones que le ha dado al término la acepción de abuso de menores.
Actualización de la imagen del marco de scrum
Localización
Pág. 27 (versión pdf)
- Actualización del nombre del rol del equipo de desarrollo por desarrollador.
Uso homogéneo del término auto-gestión en relación al modo organizativo del equipo scrum
- Se mantiene el término auto-organización al hacer referencia a las fuentes que se refieren a los equipos ágiles como "auto-organizados".
- Origen de scrum. Los autores de la definición de los equipos scrum (Nonaka y Takeuchi "The New New Product Development Game") usan la denominación "self-organizing project teams"
- Manifiesto ágil. El manifiesto ágil prefiere también el término "self-organizing" ("The best architectures, requirements, and designs emerge from self-organizing teams")
- En el resto se adopta la tendencia a preferir el término auto-gestionados. (Scrum Manager recomienda abordar el grado de autonomía de los equipos de forma coherente con la cultura de la orgnanización. V. Scrum Level)
En la versión 3.04 y corregidas en las 3.05
Fecha del Manifiesto Ágil
Localización
Capítulo: Introducción -> El Manifiesto Ágil
- Dice "En marzo de 2001" y debe decir "En febrero de 2001"
En la versión 3.03 y corregidas en la 3.04
Imagen ejemplo pila del sprint
Localización
Capítulo: Artefactos -> Pila del sprint. La imagen de ejemplo resulta confusa por indicar erróneamente en la cabecera de las columnas de tareas "Pila del producto"
En la versión 3.02 y corregidas en la 3.03
Participación de Product Owner en la reunión retrospectiva
Localizaciones
- Figura "LAS REGLAS DE SCRUM"
- Capítulo Eventos -> Retrospectiva del sprint. Actualiza en su descripción la recomendación de la participación del product owner:
"En la retrospectiva del sprint participan: el equipo de desarrollo, el scrum master y el propietario de producto. Es importante que el propietario de producto se considere “equipo” más que “cliente”. Que la persona que desempeña el rol sea participativa y conocedora de los principios y valores de scrum. Si esto no fuera así, el scrum master debe actuar como facilitador para lograr su compromiso y participación o, si la situación lo requiere, no incluirlo en la retrospectiva."
WIP
Localización
Capítulo: Prácticas para flexibilizar scrum - kanban- (página 71 de la edición impresa y 64 de la edición PDF)
En el cuarto párrafo dice "WIP (work in progress)" y debe decir "WIP (work in process)
Rol interesados
Localización
Capítulo: Prácticas para flexibilizar scrum - kanban- (página 31 de la edición impresa y 27 de la edición PDF)
En el esquema de componentes del ciclo estándar de scrum falta en el apartado de roles la mención de los "interesados".
En la versión 3.01 y corregidas en la 3.02
DoD / DoR
Localización
Capítulo: Artefactos, "Otros artefactos"
Las definiciones de "Definition of Ready (DoR)" y "Definition of Done (DoD) están cruzadas.