Les dejo aquí un enlace a un vídeo de introducción a SCRUM en menos de diez minutos. La parte más didáctica es la relativa a las estimaciones. Interesante el resto del vídeo también (algo de publicidad hacia el final)
Atul Gawande, cirujano de un prestigioso hospital, estaba interesado en mejorar la cifra de incidencias y complicaciones que surgen habitualmente en las mesas de operaciones, así que se le ocurrió preguntar cómo lo hacían ellos a otro tipo de profesionales completamente diferente pero del que también dependen muchas vidas.
Durante una visita a Boeing, Gawande preguntó cómo conseguían que todo funcionara correctamente en su trabajo diario. La respuesta fue sencilla: Usaban checklists. Una y otra vez, los pilotos se apoyaban en checklists, no sólo para el despegue y el aterrizaje en condiciones normales sino también para las situaciones de crisis en condiciones de emergencia.
De vuelta a su hospital, Gawande preparó una lista de verificaciones que podía ser comprobada en 2 minutos y la implementó en las salas de operaciones de ocho hospitales. Se aseguraron de que la lista también incluía puntos básicos: Había suficiente sangre disponible o quedaban antibióticos en cantidad adecuada para la operación.
El resultado fue sorprendente, obtuvieron mejores resultados, mejores resultados de forma masiva. Se aseguraron de evitar errores básicos y de no cometer fallos estúpidos. Ahora, incluso la Organización Mundial de la Salud define listas de verificación para la seguridad de los pacientes.
Una simple hoja de papel o archivo MS Excel con una lista de puntos a revisar pueden evitar muchos errores y mejorar la calidad de lo que hacemos. Incluso SCRUM tiene una lista para que auto-comprobemos el nivel de su implementación en nuestra organización.
No existe solo una SCRUM Checklist, existen muchas. La que más me gusta es la SCRUM Checklist de Henrik Kniberg, el autor de SCRUM y XP desde las trincheras. Es muy útil la forma en la que separa lo fundamental y lo esencial de lo solo recomendado en la implementación.
Aún no puedo marcar todas las casillas de esa lista. Como indica Henrik, ¡tendré cuidado con la policía de SCRUM!
Hace unos días hablaba sobre métricas con unos entusiastas de las metodologías ágiles como yo. Comentábamos sobre la necesidad que tenemos todos de facilitar datos a la dirección de nuestra empresa sobre la marcha del proyecto o a nuestros clientes, que están realizando una inversión en nuestro producto y han puesto unas expectativas en él.
Todo esto me hizo recordar el clásico axioma de calidad atribuido a Peter F. Drucker y que dice algo así: «Lo que no se puede definir, no se puede medir, lo que no se puede medir no se puede mejorar, y lo que no se puede mejorar finalmente se deteriora» Hay muchas variaciones de esta frase y muchas versiones diferentes también sobre su autoría. Yo prefiero usarla desde un punto de vista más positivo diciendo «Si se puede medir, se puede mejorar»
Una métrica básica para el seguimiento del proyecto con SCRUM es la suma del trabajo que queda por hacer. Diariamente podemos sumar las estimaciones de las tareas que quedan por hacer en el sprint. Esto nos dará la cantidad total de trabajo restante para terminar la actual iteración (Release Burndown) Con un poco de suerte al día siguiente habremos conseguido terminar algunas tareas más y esta suma será algo más pequeña. Si lo representamos en una gráfica, ésta irá decreciendo hasta alcanzar el eje 0 (cuanta más pendiente tenga la gráfica más velocidad lleva el equipo) Lo mismo podremos hacer con toda la pila del producto si sumamos las estimaciones de todas las funcionalidades que quedan aún por hacer.
Otro gráfica útil y sencilla que podemos utilizar es la CFD (Cumulative Flow Diagram) con la que, tomando los datos del tablero Kanban donde reflejamos la marcha proyecto, vamos anotando cada semana cuantas tareas tenemos y en qué estado están. Si por ejemplo tenemos un tablero sencillo en el que sólo tenemos las tareas en tres estados, ToDo (Por hacer), In Progress y Done, la gráfica mostraría algo como esto:
Al principio del proyecto todas las funcionalidades estarán por hacer (en color azul) y al final del mismo todas habrán alcanzado habrán sido marcadas como realizadas (‘Done’, en color verde)
La representación no está escogida al azar. He observado en varios proyectos que la gráfica suele tomar esta forma característica. Una velocidad baja al principio (poca pendiente) cuando el equipo se está conjuntando, alta velocidad cuando se ha superado la fricción inicial (alta pendiente) y despacio nuevamente hacia el final del proyecto cuando se descubre que todas las tareas no se habían cerrado correctamente y quedan cosas por corregir (no se cumplió correctamente con la definición de ‘Done’)
Hay muchas otras métricas que pueden ser usadas, recomiendo posts interesantes en «5 métricas de desempeño para proyectos de desarrollo ágil y Scrum» y en «Métricas ágiles y cuadro de mandos integral para Scrum» En cualquier caso, uses las métricas que uses, asegúrate de que merece la pena el esfuerzo en registrar los datos y calcularlas. Más métricas no significan mejor gestión.
Hace unos años, cuando comencé a interesarme por SCRUM, solo unos pocos habían oído hablar de este marco de trabajo y la mayoría desconocía sus principios. Ahora en cambio, cada vez con más frecuencia, oigo a más y más profesionales hablar de SCRUM y otras técnicas Ágiles y veo que cada vez con más frecuencia es un requisito imprescindible en muchas ofertas de trabajo. Incluso compruebo que alguna administración pública comienza a exigirlo en sus pliegos de prescripciones técnicas demostrando en el texto que no lo ha puesto solo de oídas sino que lo conoce bien y sabe lo que quiere de él.
Por todo esto he sentido la curiosidad de medir hasta donde están llegando estas metodologías ágiles. De eso va este post. La técnica estadística y los medios usados quizás no sean los más exactos, pero pueden ayudarnos a tomar el pulso al mercado.
En primer lugar he buscado palabras clave como SCRUM, Agile, TDD o PMP en los principales portales de búsqueda de empleo españoles y europeos para permitir su comparación. Este es el resultado:
En los datos de esta tabla sería necesario tener en cuenta el total de vacantes que cada portal publica para conocer su proporción real al compararla con otro país pero Monster no publica estas cifras. Necesario comentar también que en los resultados de búsqueda de ‘Lean’ también se incluyen resultados para ‘Lean manufacturing’ o ‘Lean process improvement’ (Ágil en todo caso)
La conclusión más directa que saco de estas cifras es que debo estar más atento al ‘Lean Software Development’ en el futuro.
Por último he usado Google Trends para mostrar las búsquedas realizadas desde el año 2004 sobre ‘scrum -espn -rugby’ (para eliminar los resultados del deporte), ‘pmp’ y ‘rup’. Esta es la gráfica:
Es curioso observar el descenso en el número de búsquedas de Rational Unified Process y de PMP. En cambio SCRUM sube mucho desde esos años aunque no conserva la misma aceleración que tuvo entre los años 2007 y 2010.
Si te interesa saber más sobre la certificación, estimaciones, ventajas y desventajas de Scrum o cómo gestionar proyectos de forma ágil quizás te interese mi libro: Gestión práctica de proyectos con Scrum.
Si en cambio quieres poner a prueba tus conocimientos de Scrum haciendo un test en español antes de tomar el examen de scrum.org aquí tienes el Test no oficial de Scrum (aplicación realizada con Ruby on Rails y desplegada en Heroku).
Una imagen vale más que mil palabras, al menos eso suele decirse, por esto he creado una presentación con Prezi que explica algunas de las principales ventajas de SCRUM pero también algunos de sus inconvenientes. Échenle un vistazo a la presentación en Ventajas e inconvenientes de SCRUM.
