Scrum se actualiza: resumen de las novedades

Logo-Scrum.org_

Renovarse o morir es una realidad omnipresente en el mundo de desarrollo de software, y por supuesto es aplicable a Scrum. Tras más de 20 años de historia, el marco de trabajo ágil más popular recibe una actualización que no altera ningún principio fundamental, pero que sirve para hacer algunas aclaraciones que venían siendo necesarias desde hace tiempo. Y también, tal y como destaca mi compañero/trainer en Scrum.org, Giovanni Bassi, para acentuar más el carácter de marco de trabajo de Scrum frente al de metodología.

La actualización está recogida en la nueva versión de la Guía de Scrum, publicada por Scrum.org el pasado 15 de julio de 2011. La revisión ha sido realizada por los creadores de Scrum, Ken Schwaber y Jeff Sutherland, con aportaciones de David Starr, Jim Coplien y otros colaboradores. La guía de Scrum en sí misma ha sido profundamente renovada, con el objetivo de hacerla más clara y concisa, y de que recoja las reglas de Scrum de forma unívoca. Por esta razón se han dejado fuera de la guía todos los consejos, estrategias, prácticas y técnicas que, aun siendo útiles, no están prescritas por Scrum y por lo tanto son opcionales.

Las modificaciones más importantes a Scrum, que los propios autores han recogido en un documento, son las siguientes:

  • El equipo de personas encargados de realizar el trabajo de crear cada incremento, pasa a ser llamado Equipo de Desarrollo (Development Team). Todos sus integrantes son Desarrolladores, independientemente del trabajo concreto que desempeñen (programación, pruebas, diseño, arquitectura…). Esta modificación, aunque pueda parecer un simple cambio de nombre, tiene diversas ventajas. En primer lugar, reduce la confusión que podía existir hasta ahora, ya que al Equipo de Desarrollo se le venía llamando simplemente Equipo. En Scrum tenemos otro equipo que recibe el nombre de Equipo Scrum (formado por el Equipo de Desarrollo, el Scrum Master y el Product Owner), por lo que la distinción entre ambos queda más clara. Además, pone énfasis en el carácter multidisciplinar del equipo, como grupo de desarrolladores, más allá de la suma de gente con roles concretos.
  • Hasta ahora, decíamos que el Equipo de Desarrollo, durante la reunión de Planificación del Sprint, hace un compromiso en cuanto al trabajo que va a ser completado. El término compromiso ha sido sustituido por previsión, por lo que durante la reunión de Planificación del Sprint, el Equipo de Desarrollo hace una previsión del trabajo que va a ser completado durante el Sprint. Una vez más puede parecer un simple cambio de nombre, pero tiene también su motivación: al hacer un compromiso, estamos ignorando la incertidumbre que está presente en todo Sprint, pretendiendo que completaremos el trabajo comprometido aunque aparezcan cambios o dificultades por el camino. Predicción es un término más adecuado para expresar que intentaremos llegar a completar dicho trabajo, pero que el resultado al final del Sprint puede ser distinto. ¿Quiere esto decir que los Desarrolladores tienen ahora menos responsabilidad, o pueden relajarse en su trabajo? Nada más lejos de la realidad: el Equipo de Desarrollo por supuesto se sigue comprometiendo. Pero el compromiso con una lista de elementos concretos es algo que suele llevarse mal con la incertidumbre y con lo que ocurre en la realidad, mientras que sí hay valor en comprometerse a conceptos como trabajar con profesionalidad, hacer las cosas lo mejor posible e incluso a cumplir el Objetivo del Sprint (Sprint Goal), que proporciona siempre una guía acerca del alcance de cada Sprint.
  • Las gráficas de progreso (Relase Burndown, Product Burndown, Sprint Burndown), dejan de ser obligatorias en Scrum. Seguimos teniendo que medir el trabajo restante cada día del Sprint y la tendencia hacia la consecución del mismo. Pero la herramienta concreta que utilicemos es decisión nuestra. Por supuesto que las gráficas de progreso siguen siendo una alternativa excelente, aunque podemos utilizar cualquier otra herramienta de seguimiento de progreso: otros tipos de gráficas, simples valores numéricos, porcentajes, valoraciones subjetivas o cualquier otra que nos convenga.
  • Scrum no sigue contemplando el concepto de planificación de entregas o versiones (Release Planning). Es algo que indudablemente puede aportar valor en multitud de organizaciones y desarrollos, y en ese caso nos veremos beneficiados de seguir haciéndolo. Pero si las circunstancias de nuestra organización o desarrollo no lo requieren, o simplemente no necesitamos tener una visión a medio/largo plazo de lo que queremos conseguir, podemos simplemente comenzar a trabajar sin tener que preocuparnos de la planificación más allá del horizonte del siguiente Sprint. Este matiz promueve el carácter de marco de trabajo de Scrum, y hace que sea más fácil aplicarlo a multitud de desarrollos en los que la visión a corto plazo es mucho más importante que tener muy claro hacia dónde queremos dirigirnos.
  • Desaparece la obligación de tener una serie de elementos de la Pila de Sprint (Sprint Backlog Items) para cada Sprint. Hasta ahora el Sprint Backlog era la lista de tareas y trabajos concretos resultado de descomponer y analizar de los elementos de la Pila de Producto (comprometidos) previstos para cada Sprint. A partir de ahora, el Sprint Backlog pasa a ser simplemente el conjunto de elementos de la Pila de Producto previstos, junto a un plan para completarlos. La definición de lo que es un plan queda a criterio del Equipo de Desarrollo; por supuesto que podemos seguir utilizando una lista de tareas para reflejar dicho plan, pero se nos abre la posibilidad de usar otras opciones. En muchas ocasiones es complicado hacer un desglose en tareas de un PBI concreto, o no nos aporta mucho valor hacerlo, o son preferibles otros mecanismos para expresar cómo vamos a llevar a cabo el trabajo. En la nueva versión de Scrum tenemos la opción de utilizar tareas o sustituirlas por cualquier otro mecanismo, desde una descripción a alto nivel, un diseño técnico más elaborado (ojo eso sí con la documentación exhaustiva…), o cualquier otra opción con la que nos sintamos cómodos. Una vez más, con esta modificación se resalta el carácter de marco de trabajo frente al de metodología.
  • La Pila de Producto (Product Backlog) debe estar ordenada, en lugar de estar priorizada. Es una vez más un cambio de nomenclatura que seguramente será poco significativo para muchos, y en cambio traerá grandes dificultades a otros, pero como los demás que hemos visto, tiene su motivación. En realidad, la priorización no es más que un tipo concreto de ordenación basada en la importancia relativa o el ROI, pero por lo general estos parámetros no son los únicos a tener en cuenta a la hora de determinar el orden óptimo en el que vamos a entregar las cosas. Intentaré asimismo clarificar más este punto en algún artículo o referencia futura.

Aparte de los cambios enumerados, que son los destacados por los propios autores, la nueva versión de Scrum nos trae algún cambio adicional que creo digno de mención:

  • El mínimo recomendado de personas para formar un Equipo de Desarrollo pasa a ser de 3 personas, en lugar de 5 como ocurría hasta ahora. Aunque la guía deja claro que los límites son orientativos, y que el tamaño óptimo del Equipo de Desarrollo es el máximo aceptable para permanecer ágil, y el mínimo suficiente para poder completar el trabajo.
  • Hay otros cambios menores de nomenclatura; por ejemplo se vuelve a usar Scrum Master en lugar de ScrumMaster, o se sustituye la expresión de Bloque de Tiempo (Timebox) por el de Evento para referirse de forma genérica a las distintas reuniones que se mantienen.
  • La figura del Product Owner y sus responsabilidades quedan mucho más clarificadas y definidas que en anteriores versiones de la guía.

Creo que la actualización de Scrum es una noticia muy buena, ya que demuestra la preocupación de los autores por mantenerlo al día y flexibilizarlo para dar respuesta a las necesidades cambiantes de los desarrollos.

Debajo podéis verme junto a otros compañeros trainers de Scrum.org, junto a Ken Schwaber y David Starr, durante la última reunión en Boston donde tratamos éstos y otros muchos temas interesantes Winking smile.

scrumdotorgmeeting

2 comentarios sobre “Scrum se actualiza: resumen de las novedades”

  1. Muy buen update de Scrum. Si bien creo que los cambios seran dificiles de adoptar, creo en que Scrum tiene que ir adaptandose a las personas y las personas a el. Me llevo, personalmente, lo del ordenamiento del PB en lugar de la priorizacion.

    Cross-Blogging with http://www.agustinpolito.com

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *