Scrum Master 3 - fe de erratas

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).

Dice:

o al simple uso de técnicas de gestión visual kanban para mantener un flujo continuo de tareas.

Nueva redacción:

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).

Dice:

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.

Nueva redacción

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.

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:

1. El equipo expone el objetivo del sprint, la lista de funcionalidades que se incluían y el incremento desarrollado.
2. 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:

1. El equipo expone el objetivo del sprint, la lista de funcionalidades que se incluían y las que se han desarrollado.
2. 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.