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»:
|
==
Localización
- Página (nueva versión del manual).
- Página (versión anterior del manual).
| Example |
| Example |
==
Localización
- Página (nueva versión del manual).
- Página (versión anterior del manual).
| Example |
| Example |
==
Localización
- Página (nueva versión del manual).
- Página (versión anterior del manual).
| Example |
| Example |
==
Localización
- Página (nueva versión del manual).
- Página (versión anterior del manual).
| Example |
| Example |
==
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.