Chess - antoniomartel.com

Archivos por Etiqueta: Ágil

Regla del 80/20

¿Podemos ser más productivos? ¿Cómo podemos centrarnos en las tareas que nos harán más eficientes? Hace muchos años, aproximadamente un siglo, un tal Pareto comprobó de forma casual que sólo el 20% de las vainas que tenía plantadas en el campo producían el 80% de los guisantes de su cosecha y que el 80% restante producían tan solo el 20% restante de los guisantes. Curioso por esta relación comprobó también que podía aplicar esta regla a otros campos descubriendo, por ejemplo, que en su época el 20% de la población disponía del 80% de la riqueza y que tan solo quedaba un 20% de la riqueza total para el 80% más pobre de la población.

Este principio, basado en el conocimiento empírico, es usado desde entonces para mejorar la eficiencia y la  productividad en la economía, en la distribución comercial, en el marketing, en las ingenierías y, como no, también en el desarrollo de software.

Cuando comenzamos a desarrollar nuestro producto basándonos en una lista enorme de requisitos y funcionalidades a desarrollar, sabemos que sólo el 20% de esas funcionalidades serán usadas por el 80% de los usuarios y que una cantidad enorme del resto de las funcionalidades que desarrollemos sólo será usada en un 20% de las ocasiones.

Aplicando también este principio al tiempo de desarrollo podemos deducir que si tardásemos alrededor de 10 meses en la construcción de un producto, en tan solo 2 de esos meses conseguiríamos desarrollar el 80% de las funcionalidades requeridas y que, por tanto, nos llevaría unos 8 meses resolver el 20% de las funcionalidades más complejas y difíciles. Esto nos lleva a preguntarnos ¿serán usadas esas funcionalidades? ¿son realmente imprescindibles?

Si lográsemos identificar las funcionalidades más importantes y las mantuviésemos los más simple que nos fuera posible (otro principio: KISS) ¿no lograríamos quitarnos de encima 8 meses de trabajo y entregar un producto muy efectivo en tan solo 2 meses?

Ya sabemos que el 20% por ciento de nuestro esfuerzo producirá el 80% de los resultados ¿no sería bueno sentarnos por un momento para pensar a qué le vamos a dedicar nuestro tiempo? Merecerá la pena, seguro.

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 …

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.

¿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)

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad