Novedades Manual de Scrum

Los cambios en la guía de Scrum

Publicado por

Novedades de la Guia de Scrum Julio 2011

La guía de referencia para el marco de trabajo Scrum, elaborada por Ken Schwaber y Jeff Sutherland ha sido actualizada el pasado 15 de Julio, y no ha sido hasta hoy en la que por diversos medios he conocido de su actualización.
La primera noticia me ha llegado por la Newsletter “Agile Chronicles , a la cual podéis suscribiros si os interesa desde el sitio de versionone.com. y que he estado ojeando esta mañana , muy temprano, cuando he visto el correo nuevo en el Iphone, después de que éste me despertara con su alarma como hace todas las mañanas. Os confieso que como estaba un poco dormido y además es en Inglés, no me he enterado de nada 😉 ( no tanto por lo del Inglés, como por el sueño que tenía después de una tremenda noche de calor en Madrid). Durante la mañana, uno de los miembros del grupo Scrum de Linkedin,  en el que desde que he comenzado con el blog, comparto debates y opiniones, ha lanzado una pregunta abierta sobre el tema: ¿Qué os parecen las novedades de la guía de Scrum?.

Al llegar a casa, y profundizar más en el tema, he leído en detalle los cambios de la guía original y he encontrado un excelente resumen en el blog de Luis Soria , y una vez digeridos los cambios os paso a continuación a dar mi opinión al respecto.

Como dice el artículo son matices lo que cambian , nada de gran impacto en el modelo, pero si que hay cosas significativas.

1-    Uno de los roles de Scrum : “El equipo” , pasa a denominarse Equipo de Desarrollo.

Esta terminología es lo que , al menos yo, en todos mis proyectos vengo usando desde hace muchos años. Para mi el equipo de desarrollo contempla efectivamente todos los perfiles necesarios para “dar vida” al sistema o producto: Los analistas, los arquitectos, los programadores,… En mis equipos, por encima de ellos, siempre han estado los Project Manager ( figura que como tal no está entre los roles de Scrum , pero necesaria como ya he comentado en otros Post , aunque con una obligatoria reconversión). Con este cambio, lo que creo que pretende la nueva guía de Scrum es dejar más claro la separación entre los roles : los “más volcados a la visión global, a los objetivos del negocio, al apoyo y ayuda al equipo de desarrollo“ (Product Owner y Scrum Master) ,  y el equipo de desarrollo multidisciplinar. No supone ningún cambio en la manera de actuar ni en la forma de hacer las cosas. Esto es más que nada una clarificación sin impacto en el marco global.

2-    Cambio de “Compromiso” por “previsión” del trabajo a realizar.

Como bien explica el artículo de Luis Soria, esto no significa ( o al menos no debe significar) que por ser una “previsión” el equipo de desarrollo ya no tenga “compromiso”. No obstante puede haber matices. La previsión de hacer algo es un concepto que está sujeto a que se den las condiciones necesarias para que se haga, pudiendo afectar a la misma, multitud de factores que en el mundo del desarrollo de SW en entornos multiproyecto y  con dependencias externas,  pueden aparecer en medio del Sprint poniendo en serio riesgo el compromiso de alguna de las funcionalidades a realizar en la iteración.
Y esto es lo que normalmente suele ocurrir en los proyectos. Aparecen inconvenientes, dificultades , dependencias y otros hechos tanto internos como externos al equipo que ponen en riesgo el compromiso adquirido.
Si los equipos aplican a rajatabla el cambio de denominación : Compromiso por previsión : ¿tienen entonces una justificación para no haber hecho una funcionalidad del Sprint , pues simplemente han “previsto” y no “han comprometido”.
Nada más lejos de la realidad, aunque en mi opinión hay que tener cierto cuidado con estos términos. Compromiso tampoco significaba antes que el “comprometido” tuviera el 100% de garantías de que el trabajo se realizaría si o si. Los riesgos inherentes al desarrollo y a las dependencias externas existen y existirán con compromiso o con previsión.  La persona del equipo de desarrollo, si es profesional y efectiv@ en su trabajo , siempre hará todo lo que esté en su mano para cumplir , resolverá impedimentos y buscará por encima de todo cumplir con la responsabilidad que se haya auto-asignado como miembro del equipo de desarrollo en los objetivos de Sprint.
Sin embargo, creo que este cambio de denominación acerca más al mundo real el trabajo a realizar en un Sprint, durante el cual, tanto por riesgos no detectados y que vienen de golpe, como por causa de un cambio de prioridades de negocio , el compromiso inicial se convierte en una previsión, y no por ello ha de ser entendido como “un relax” en la responsabilidad del equipo, como explicaba anteriormente.

3. Otros cambios menores , que solo menciono pues simplemente dejan de manifiesto las distintas maneras posibles de realizar seguimiento y descomposición del trabajo a realizar en la entrega  sin establecer la obligatoriedad de un artefacto concreto.

Relase Burndown, Product Burndown, Sprint Burndown : puede usarse cualquier otro tipo de gráficas o indicadores de progreso siempre y cuando su objetivo sea medir el trabajo restante del Sprint y la tendencia del mismo.
Ya no es obligatorio tener una serie de elementos de la Pila de Sprint (Sprint Backlog ítems ) para cada Sprint. A partir de ahora el Sprint Backlog pasa a ser el conjunto de elementos previstos y el plan para llevarlos a cabo de la mejor manea que crea el equipo de desarrollo.
El número mínimo de personas de un equipo de desarrollo pasa a ser de tres personas en lugar de los 5 que definía anteriormente. Esto puede ser válido para equipos que hagan Scrum en proyectos de mantenimiento o pequeños desarrollos evolutivos donde tres personas pueden fácilmente seguir siendo ágiles aplicando las reglas del modelo.

4. Cambia el concepto de «Priorización» del Product BackLog por el de «Ordenación».

Acertado cambio desde mi punto de vista , pues todo sabemos que «casi todo es prioridad 1» 😉 y cuando tienes varias cosas que hacer importantes, la tendencia es marcar con prioridad alta muchas de ellas al mismo tiempo. Con el cambio, se establece el orden como modo para que el Product Owner defina la importancia de cada uno de los elementos del Backlog de Producto. Quizás yo mantendría también la prioridad y para las coincidentes le añadiría el orden.

 

Con lo que si que me muestro crítico de los cambios realizados en con el siguiente y último punto.

5. Sigue sin establecer la obligación de tener una planificación de entregas o versiones (Release Planning).

Realmente deja abierta la posibilidad de que en el proyecto se establezca si se necesita una planificación de las entregas a medio/largo plazo, pero como decía no obliga a ello.
En este punto, mi opinión personal es que sí es necesario que todo el mundo tenga en mente desde la confección de plan inicial, las entregas o Sprints que se van a realizar a lo largo de todo el proyecto, pues es sano para el equipo y para el cliente/usuario conocer y tener una visión general de cuando se esperan los compromisos o previsiones para poder , por ejemplo, dar visibilidad a la dirección de los objetivos globales, planificar las pruebas de aceptación de los usuarios , comunicar y formar a los usuarios para la operación del sistema y en definitiva permitir al Gestor 2.0, saber cuales son los momentos “críticos” del proyecto en los que hay que poner especial cuidado en que las cosas salgan tal y como estaba previsto.

Personalmente lo tengo claro: tener una planificación de los Sprints da lugar a tener visibilidad del proyecto en todos los niveles y permite verificar que las previsiones se van materializando en resultados.

Como conclusión : es bueno que se mantenga actualizado el modelo y que se mantenga vivo permanentemente y actualizado , pues denota el interés de sus creadores en adaptarse a la realidad de los distintos entornos de desarrollo que actualmente coexisten en las organizaciones.Una posición inmovilista,  es contraproducente para el marco de trabajo Ágil , cuyo principal valor es la flexibilidad y la adaptación a los cambios.

¿Y tú qué opinas de los cambios de la guía  Scrum?. ¿Crees que sería necesario introducir alguna variación más en las reglas y/o planteamientos del modelo?

6 comentarios

  1. Hello Website Owner! I really like your blog, I found you on Google so I thought I’d share this tip with you. There is a WordPress SEO add-on that does automated SEO for your pages, automated SEO addons like this one are new in the blog arena so hopping on this now would give your page a huge traffic jump guaranteed. If you’re serious about helping your blog get more popular and make money then check it out @ http://tiny.cc/0ej3z. Peace, keep up the good work.

  2. Hello Website Owner! I found your blog on Google and I really like it. My team provides professional article writing, and we are able to do it for $0.01 per word – that’s $4 for a 400 word article. All of our writers are based in the United States, and all of our articles passes the Copyscape test. If you are interested in using our service, or simply want to give us a try, please check out website out http://www.contentwriters.us

Deja un comentario

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