La primera versión del scrum
En 1995, Ken Schwaber presentó por primera vez los cimientos de lo que el Scrum conocemos hoy en día. Coescribió con Mike Beedle el Desarrollo de Software Agile con Scrum en 2001; luego publicarán este libro en 2004.
Jeff Sutherland y Ken Schwaber ofrecen la Guía scrum en 2001 disponible de forma gratuita en Internet; este último experimenta algunos cambios de vez en cuando. La última versión es de noviembre de 2017 y ofrece algunos ajustes.
¿Qué es Scrum?
Este marco ágil funciona en un enfoque incremental e iterativo.
Los ciclos de desarrollo son deliberadamente cortos e iterativos; estamos en gran parte en iteraciones de dos semanas (algunos hacen más de 4 semanas) que llamamos sprints.
En Scrum, es muy importante tener ciclos de proyecto ágiles estructurados con fases cortas, rítmicas e iguales.
Estas iteraciones cortas son esenciales para permitirse la capacidad de adaptar rápidamente los procesos para ver el alcance del proyecto; aprovechamos estas iteraciones muy cortas para obtener la máxima retroalimentación de los clientes (al final de cada iteración) que eventualmente puede incrementar el producto de nuevos desarrollos.
Aquí está un diagrama que presenta este marco:
Los 3 pilares del scrum
Transparencia
El Scrum requiere que todos los aspectos del proceso sean compartidos con todos los responsables de la toma de decisiones y la visión general de los acontecimientos a todos los observadores.
Además, el scrum hace hincapié en la necesidad de ser transparente sobre el estado de las iteraciones o el producto en su conjunto. De hecho, la transparencia es esencial para garantizar que todos los actores del proyecto se muevan juntos en la misma dirección.
Por mi parte, no dudo en poner una gestión visual completa para ayudar a completar la transparencia. Esta práctica no es en sí misma impuesta por el marco, sino que resulta ser la más eficaz para ser transparente.
Inspección
Es esencial hacer un seguimiento de la evolución y los objetivos del equipo. Esta inspección se realiza a través de:
gestión visual de una manera transparente
revisión donde el equipo hace un punto al final de la iteración del trabajo realizado
con el diario (reunión de equipo de la mañana pequeña para alinear a todos en el progreso del sprint)
Tenga cuidado de entender que el propósito principal de esta inspección es que el equipo pueda tomar buenas decisiones; no está destinado a informar a los gerentes potenciales. Esta es una inspección para los propios equipos y sólo para ellos.
Algunos equipos de scrum utilizan indicadores de seguimiento para realizar un seguimiento del progreso de un sprint o/y desarrollo de productos:
Burndown Chart - saber cómo construir
Burnup Chart: gráfico de flujo acumulativo de seguimiento del proyecto
Adaptación
El Scrum recomienda adaptar los procesos y el entorno de trabajo para proporcionar al equipo un contexto óptimo. La ceremonia de la retrospectiva al final del sprint permite definir áreas de mejora en el equipo con el fin de estar en un proceso real de mejora continua.
El equipo scrum será capaz de probar nuevas prácticas que deciden si adoptar o no en función de los resultados; tampoco dudará en eliminar prácticas que se han vuelto obsoletas.
Los 3 papeles clave de Scrum
El scrum ofrece tres roles clave diferentes:
Product Owner
Scrum Master
El equipo de desarrollo
Tenga en cuenta que cualquier persona que no es propietario del producto ni Scrum Master es parte del equipo de desarrollo. El equipo de desarrollo no solo está formado por desarrolladores.
En casos excepcionales, el maestro scrum y/o el propietario del producto también pueden considerarse parte del equipo de desarrollo si tienen tareas que realizar relacionadas con la realización del producto.
Comprensión de las responsabilidades
Estas tres funciones tienen responsabilidades complementarias que a veces se entienden muy mal. Aquí hay un dibujo que aclara el posicionamiento de estos 3 roles clave:
Y a menudo, los roles de propietario del producto y maestro scrum son muy mal entendidos.
El propietario del producto es responsable del trabajo pendiente, pero no es responsable de las representaciones; por lo tanto, no tiene que probar el resultado del trabajo del equipo de desarrollo. De hecho, es el equipo de desarrollo el que es 100% autónomo en la realización que debe garantizar que las representaciones se correspondan perfectamente con la necesidad descrita.
Del mismo modo, el maestro scrum no es de ninguna manera un gestor de proyectos, y mucho menos un gerente jerárquico del equipo; de hecho, es el custodio de los procesos scrum, su implementación y ayuda al propietario del producto y al equipo de desarrollo a tomar toda su autonomía en sus respectivas responsabilidades. El maestro del scrum tampoco es el anfitrión de las ceremonias; de hecho, puede dirigir una ceremonia a petición de los otros papeles de forma temporal.
Las principales reuniones
El scrum ofrece diferentes ceremonias (reunión) para acelerar todos los sprints (iteraciones) como habíamos visto brevemente a continuación.
Un sprint consiste en:
sprint planning
Inicio del sprint
El equipo comienza un sprint planeando el trabajo a realizar.
se fija una meta de sprint
define el plan para lograr este objetivo
sprint review:
Finalizar el sprint
El equipo revisa la ruta tomada durante el sprint
El equipo invita a los usuarios/clientes a retroalimentación sobre el producto con los últimos desarrollos "realizados"
sprint retrospective
Después de la revisión
el equipo hace un balance en conjunto para buscar áreas de mejora
daily scrum
el equipo de desarrollo se está reúne para hablar sobre lo que hizo ayer, lo que se hara hoy y si hay una alerta.
todas las mañanas
Artefactos ágiles de scrum
Este marco propone 4 artefactos (incluyendo 1 relacionado con la transparencia) que los equipos necesitan saber.
Product backlog
El product backlog representa la agrupación de todas las cosas que se deben hacer en el producto para que evolucione; es responsabilidad del propietario del producto. A diferencia de los métodos de ciclo de V/cascada, el trabajo pendiente está evolucionando constantemente para tener en cuenta los muchos comentarios obtenidos.
El atraso del producto es 100% responsabilidad del propietario del producto. Sin embargo, puede obtener ayuda del equipo de producción si la necesita.
El scrum nos recuerda la importancia de que el propietario del producto y el equipo de producción trabajen juntos en su refinamiento; esto permite que todas las peticiones escritas sean mejor entendidas por todos los actores del proyecto... Y así los logros son mucho más fluidos. Llamamos a este principio scrum: refinamiento de trabajo pendiente del producto.
Sprint backlog
El trabajo pendiente sprint representa todos los elementos que son apoyados por el equipo de desarrollo durante el sprint actual; también contendrá el plan para entregar estos artículos en un entorno estable. Consideramos que cada sprint tiene su propio atraso sprint.
Es muy importante entender que el atraso sprint está vinculado a la realización del producto; por lo tanto, sólo el equipo de producción es responsable de ello. Si el propietario del producto quiere cambiarlo, tendrá que hacerlo con el acuerdo del equipo de producción.
Incremento
El incremento representa todos los elementos que se "hacen" en el sprint actual añadido al incremento del sprint anterior. En pocas palabras, este es el producto en un estado estable con todas las adiciones que tenemos al final de cada sprint.
Scrum en conclusión
Recuerde que este no es un método en sí mismo, sino un marco ligero al que se deben agregar las prácticas adecuadas para mejorar el entorno de equipo.
Entonces, ¿listo para configurar este marco ágil?
Comentarios