Friday, 29 March 2013

Cómo ayuda SCRUM a construir catedrales

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 ...

Sunday, 24 March 2013

Estimaciones con SCRUM

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 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.


Es un ebook en formato Kindle pero no te preocupes si no tienes un lector de libros electrónicos. Una vez comprado seleccionas que lo quieres leer en Kindle Cloud Reader y desde entonces podrás leerlo siempre que quieras sólo con ir a la página read.amazon.com. En tu ordenador de casa, en un tablet o en tu móvil, donde quieras. 

Friday, 22 March 2013

Entregar lo que el cliente necesita

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.


Sunday, 17 March 2013

¿Por qué funciona esto de SCRUM?

 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:
  1. El cliente prioriza sus requisitos y sabe lo que va a obtener al cabo de unas semanas. En cada reunión de demo el cliente comprueba lo que se ha conseguido y si le sirve o no para cumplir con sus necesidades. En la siguiente iteración puede replanificar sus requisitos y orientarlos hacia la siguiente meta que quiere alcanzar. No debe esperar a que el equipo trabaje durante meses para tomar el pulso al proyecto y ver si el resultado va por el camino deseado.
  2. El equipo conoce exactamente cuál es la siguiente meta parcial que se quiere alcanzar en cada Sprint y qué tareas le llevarán a ello. ¿Alguien imagina si todas las cuotas de nuestra hipoteca las debiésemos abonar en un único pago anual? Muchos serían serían poco previsores y se pasarían los últimos meses apretándose el cinturón para intentar arañar unos euros que les permitiesen cumplir el plazo de pago. Otros guardarían a un lado una cantidad mensual o semanal con la que llegar a la fatídica fecha sin ahogos de última hora. Esta es una filosofía muy parecida a la que conseguimos con las entregas parciales en cada demo del Sprint.
Seguro que se pueden encontrar otras muchas ventajas importantes. En mi opinión pocas lo serán tanto como estas dos ¿qué opinan?

¿De qué va a ir todo esto?

Como un entusiasta más de metodologías ágiles como SCRUM, Kanban o Lean Software Development me he animado a crear este blog para contar en él lo que he aprendido en estos años sobre la gestión de proyectos, el desarrollo del software y la calidad del mismo.

Además de aportar mi parecer sobre la industria del software o la gestión de proyectos y servicios tecnológicos quisiera que el blog sirva también para encontrar recursos e información sobre todas estas metodologías y técnicas. No llegará a ser un compendio exhaustivo pero espero que lo encuentren de utilidad.

No pretendo con este blog evangelizar sobre estas prácticas ni teorizar sobre las mismas. Tampoco voy a llenar estas entradas de nombres de artefactos, stakeholders, backlogs sprints planning o burndown graphics ¡Dios me libre! Si algo me gusta de estas metodologías es que no necesitas formarte durante meses  para empezar a aplicarlas. Sólo debes entender sus principios para luego probar, fallar, mejorar, volver a probar, volver a fallar y así continuar mejorando (Kaizen lo llamaría)