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.
Revisitando el post de Raúl Hernández González con el título ‘Aprendiendo a construir catedrales‘ también he comenzado a darle vueltas a esa conocida historia. En ella, a dos obreros que se encuentran picando piedra para la construcción de una catedral, se les pregunta qué es lo que hacen. Mientras uno responde sobre lo penoso e interminable que es construir el muro en el que está trabajando, el otro responde simplemente que él está construyendo una catedral.
Me he preguntado si se puede ser Ágil cuando uno construye algo tan grande. Creo que la respuesta es que sí. Por lo menos a mí se me ocurren algunas ventajas a ser Ágil cuando se está inmerso en un proyecto del tamaño de una catedral:
Con un framework como SCRUM siempre tendrás presente el objetivo final y las características que se quiere que tenga. En la pila del producto tendrás una lista de requisitos como la construcción de la planta, levantar la bóveda, decorar puertas o ventanales y otras muchas cosas que darán forma a la catedral final.
Pero una vez definido el objetivo hay que ponerse a picar piedra. Al comienzo de cada iteración, el equipo elegirá qué tareas puede acometer de entre la lista de cosas por construir (siempre priorizadas por nuestro cliente). Se definirá un objetivo más pequeño para el Sprint actual por lo que tendremos una nueva meta, mucho más cercana, que no permitirá que desesperemos por lo lejos que está la meta final. Es el momento de coger martillo y cincel.
Al separar las tareas a realizar en pequeños grupos y tratar de resolverlos en periodos fijos de tiempo (timeboxed) cada uno con su propia meta, tiene las ventajas de la estrategia del ‘Divide y vencerás’. Planeas tu objetivo más inmediato y lo que vas a hacer para resolverlo sin abrumarte con todo el trabajo que aún queda por delante. Una gráfica burn-down ayudará también a ver que el trabajo restante va disminuyendo y que, por lento que nos pueda parecer, avanzamos hacia nuestro producto final, la catedral.
Queda claro el marco de trabajo, ahora, manos a la obra …
Una de las cosas que más quebraderos de cabeza suele darnos cuando hemos decidido adoptar SCRUM es cómo hacer estimaciones y cómo nos van a ayudar éstas a saber qué tal vamos y cuándo vamos a finalizar el proyecto. En SCRUM suele estimarse dos veces (sí, dos veces) pero no en la forma tradicional con una única y sesuda estimación en horas/días de trabajo al principio del proyecto.
Esta forma de estimar suele traer algo de polémica pero intentaré explicarlo lo mejor que pueda: Haremos una primera estimación grosso modo en puntos y no en horas en la que partiendo de la lista inicial de funcionalidades a desarrollar estimaremos el esfuerzo o dificultad que supondrá realizar cada una de los requisitos del proyecto. Este esfuerzo lo mediremos o, mejor dicho, lo calibraremos en puntos siguiendo por ejemplo la serie de Fibonacci (1, 2, 3, 5, 8, 13, …) o incluso usando las medidas usadas en las tallas de camiseta (S, M, L, XL, XXL, …)
Si atendemos al concepto de Cono de Incertidumbre, hagamos la estimación que hagamos, le dediquemos el tiempo y metodología que queramos, nuestra estimación será errónea (a menos que conozcamos cada uno de los detalles del proyecto). Rodrigo Corral lo explica muy bien en Gestión de proyectos guiada por la intuición, o por qué gestionar proyectos es tan difícil (el resto del post no tiene desperdicio tampoco) Entonces ¿por qué dedicar tanto esfuerzo? Asignemos 1 o 2 puntos a las funcionalidades sencillas, 3 o 5 a las de dificultad media y 8 o 13 a las de dificultad alta o muy alta (¿necesitas más puntos? quizás deberías descomponer esta funcionalidad en otras más pequeñas)
Esto traerá un considerable ahorro de esfuerzo al estimar y, por qué no, también quitamos estrés al equipo, que tendrá miedo a equivocarse. Con la estimación a alto nivel mediante puntos evitamos algunos de los inconvenientes de las estimaciones en horas: Si indicamos que en una tarea vamos a tardar 40 horas, la regla de que el trabajo se expandirá hasta tomar todo el tiempo disponible se aplicará a esto también. Por otra lado se evitará un fallo común en los que comienzan con SCRUM (sí, yo también lo cometí) y que consiste en pensar que «Si se ha trabajado 40 horas en esta tarea, el burndown graphic deberá bajar en 40 horas» Esto daría una falsa sensación de avance en el proyecto si la tarea no está completamente terminada y aprobada por el cliente.
La segunda estimación la haremos cuando planifiquemos las tareas del sprint. En esta planificación tendremos un mayor conocimiento del proyecto y de lo que implica cada tarea. Podríamos hacer entonces una planificación en horas aunque hay equipos que aún en ese momento usan una estimación en puntos o deciden no estimar en absoluto (ver entrada sobre técnicas de estimación en ScrumAlliance.org)
Estas estimaciones nos permitirán conocer el ROI (retorno de inversión) de cada funcionalidad para que el cliente pueda decidir qué tareas quiere realizar en el siguiente sprint y nos permitirá también, después de algunos sprints, conocer con bastante exactitud cuál es la velocidad del equipo (de nuevo, tema para otro post)
Si te ha gustado este post, puedes encontrar más contenidos que expliquen Scrum de forma práctica y desde su base en mi libro en Amazon Curso práctico de Scrum: Algo más que teoría.
 |
| Libro en Amazon: Curso práctico de Scrum – Algo mas que teoría |
Uno de los principios básicos de SCRUM (y también unos de sus desafíos) consiste en la aceptación de que el cliente puede cambiar de idea sobre lo que necesita. Con SCRUM se intenta dar una respuesta flexible admitiendo que el propio cliente puede no tener completamente definido cuál es el problema y que, a menudo, a medida que avanza el proyecto éste puede darse cuenta de qué es lo que realmente necesita. Por esto, entre otras cosas, SCRUM es denominada como una metodología Ágil.
La lista de requerimientos y funcionalidades creada al principio del proyecto es abierta y puede ser modificada en cualquier momento. Contiene estimaciones aproximadas del esfuerzo que supone el desarrollo de estas funcionalidades y, antes de comenzar cada iteración o sprint, se toma un grupo de estos requerimientos como objetivo para el final del mismo. Dos o tres semanas más tarde, los requisitos serán otros y el nuevo objetivo a alcanzar puede ir en una línea distinta a la definida unos sprints atrás.
Es una nueva forma de trabajar, un tanto difícil de asimilar, tanto para el cliente como para el proveedor. Hay caminos aparentemente más fáciles. Siempre podemos volver a la fórmula tradicional: En primer lugar analizamos el problema durante meses, cuando tenemos claro lo que debe hacerse comenzamos a desarrollar la solución duramente varios meses más. Al finalizar, cruzamos los dedos y entregamos el producto final al cliente.
Después de este punto, quién no ha oído frases como ‘Pero esto no es lo que yo quería, aquí falta …’, ‘No, así no era, no me entendiste bien …’, ‘Sí, está bien, pero voy a llamar al Director que es quién realmente da el visto bueno’ (por supuesto, el Director no ha acudido a ninguna de las reuniones de análisis) Después de los meses de trabajo invertidos y las prisas y el estrés para cumplir las fechas comprometidas, el cliente no ha recibido lo que necesitaba y necesitaríamos trabajar aún más para intentar parchear la solución proporcionada.
La flexibilidad de SCRUM también tiene sus riesgos: ¿Qué sucede si el cliente no termina nunca de añadir nuevas funcionalidades a la pila del producto? ¿y sí el cliente redefine incesántemente cada requisito? Esto será tema para otra entrada del blog.
Se han parado alguna vez a pensar por qué se consiguen, en promedio, tan buenos resultados cuando su usan metodologías ágiles como SCRUM. Según el Informe CHAOS 2011, los proyectos Ágiles tienen una tasa de éxito tres veces superior a los proyectos en Cascada.
¿Cómo se consiguen estos resultados? La lista de ventajas de SCRUM es extensa, hay muchas webs que las describen pero ¿todos los beneficios teóricos de SCRUM tienen igual peso? ¿Hay algunos de ellos que realmente marcan la diferencia?
He trabajado en proyectos en los que SCRUM no pudo ser aplicado al 100%, sólo se mantuvo un ‘SCRUM de supervivencia’ y aún así se notaban sus efectos positivos en los resultados del proyecto. No conozco la respuesta exacta a estas preguntas pero me atrevería a resaltar un par de aspectos como los principales responsables de estas tasas:
