jueves, 22 de marzo de 2012

Agilismo en pocas palabras


"Agilismo en pocas palabras" es un oxímoron. La nube de palabras de la figura, aunque incompleta, nos da una idea de cuan fructífero ha sido el movimiento ágil en terminología. Me centraré en 3 puntos que considero básicos: definición, historia y aprendizaje.




1. ¿Qué es ser ágil?
No es fácil definir con precisión qué es ser ágil (o no serlo). Sin embargo, hay algunas referencias relevantes para hacerse una idea del agilismo y de su nivel de aplicación. La primera es el Manifiesto Ágil, los 4 fundamentos y los 12 principios, todos ellos muy sensatos, pero se trata de una declaración de intenciones muy general. Otra referencia, o más bien idea, es la que suguiere Kent Beck en su metodología Extreme Programming; el resultado más significativo se conseguirá mientras más prácticas ágiles se apliquen y mientras se apliquen en mayor profundidad, pues existe sinergia entre las prácticas, se contribuyen y se potencian entre ellas. Extreme Programming propone 12 prácticas. El límite en cuanto a la NO aplicación de prácticas que pueda llevar a la descalificación "NO eres ágil" tampoco está claro. Scrum se centra más en promover los roles, la disciplina de las reuniones y el time-boxing (duración estricta de cada evento: reuniones y Sprint). El planteamiento de Scrum es más radical, no deja margen, con lo cual siendo muy sencillo en cuanto comprenderlo, es prácticamente imposible aplicarlo al 100 %. Extreme Programing y Scrum ponen énfasis en conseguir un proceso iterativo e incremental con entregas frecuentes. Sin embargo, los seguidores de Kanban, en su aplicación más pura, abogan más por el flujo del trabajo que por trabajar dentro de los plazos de una iteración, lo cual podría ser efectivo cuando no existen plazos rigurosos de entrega. Está claro que no existe un criterio riguroso para determinar al grado de agilidad de un equipo, y la verdad es que NO desearía que se inventara :-), ya tenemos CMMI para ese tipo de mediciones :-). El agilismo es un medio no el fin, con lo cual lo realmente importante es aprovechar las prácticas ágiles hasta donde se quiera o se pueda. Más que determinar si se es o no ágil, y siguiendo el plantemiento Extreme Programming, lo importante es intentar aplicar la mayor cantidad de prácticas ágiles y cada una en mayor profundidad. En mi post  Carta de Prácticas ágiles. Arma tu propio menú ágil presento un catálogo de 42 prácticas ágiles cogidas de los métodos ágiles más populares (Kanban, Lean Development, Scrum y Extreme Programming) y expresadas de forma genérica para su mejor comprensión en ámbitos distintos a desarrollo de software.

2. Breve historia del agilismo en software
Si bien la mayoría de propuestas metodológicas ágiles ya estaban maduras a mediados de los 90's, fue cerca del 2000 cuando comenzaron a destacar en la comunidad de ingeniería de software. Extreme Programming fue la primera en hacerse notar y comenzar a mover la maquinaria de difusión (libros, conferencias, sitios web, etc.). En el 2001 los gurús ágiles redactaron el Manifiesto Ágil lo cual dio un impulso y reconocimiento mayor al movimiento ágil. A partir de allí, Extreme Programming fue perdiendo terreno y Scrum inicio su avance hasta ser actualmente el método ágil más popular. Mi explicación a esto es sencilla, es mucho más difícil conseguir aplicar las 12 prácticas de Extreme Programming que los conceptos de Scrum (Sprints, Product Backlog, Reuniones, etc.). Las prácticas de Extreme Programming son la mayoría muy técnicas (Refactoring, Pruebas, Integración Contínua, etc.), lo cual requiere bastante formación y herramientas de apoyo. Si bien en Scrum los conceptos se plantean con mucho radicalismo, es sabido por todos que no se aplican todos ni en profundidad, pero no es difícil "lanzarse" y comenzar con ellos aunque sea parcialmente. Paralelamente, durante la última década Lean Development ha inundado la jerga ágil con terminología proveniente de Lean Manufactoring. Se trata de conceptos muy interesantes muchos de ellos extraídos del archi-mencionado Sistema de Producción de Toyota, entre ellos Kaizen, Kanban, Pull System, JIT, Muda, 5S, etc, una larga lista de términos, muchos de ellos enfatizados usando su nombre original en japonés :-). La extrapolación de Lean Manufactoring a desarrollo de software da mucho juego, hay bastantes ideas a priori aprovechables. Sin embargo, no hay que olvidar es que su contexto original son los sistemas de producción (con operarios y máquinas), todos los ejemplos originales se refieren a líneas de producción, movimiento de piezas, etc. Me sorprende cuando esto se pretende impulsar sin más en el ámbito del software. Por ejemplo, el WIP (Work in Progress) indudablemente debería ser reducido o tener un límite en una cadena de producción, pero en desarrollo de software, bastaría con supervisar dicho número y tomar decisiones puntuales al respecto en lugar de intentar encontrar el número mágico para aplicarlo en cada actividad impidiendo que se pueda superar. Por último, en la última década han aparecido decenas de herramientas que claman apoyar la gestión ágil de proyectos de desarrollo de software. La gran mayoría de estas herramientas no cubren aspectos esenciales a la hora de implantar prácticas ágiles, tales como: mecanismos para abordar adecuadamente entornos multi-proyecto, integración de prácticas ágiles de diferentes métodos, kanban configurables (workflows flexibles y configurables), y obviamente, tampoco entran en cuestiones de proceso o cómo usar la herramienta en un contexto de proyecto-producto-equipo-cliente específico.

3. Aprendizaje y Certificaciones de Ágilidad
Es fundamental que exista información que facilite el aprendizaje del agilismo. Sin embargo, no existe un cuerpo de conocimiento consensuado, y probablemente nunca existirá, con lo cual sólo tendremos como referencia la declaración de intenciones del Manifiesto Ágil, y los libros más destacados de los gurús ágiles. El resto de desbordante información acerca de agilismo, disperso en miles de sitios web, grupos de discusión, blogs, etc., si bien es interesante, tiene una fuerte carga de subjetividad e interpretación. Además, en este caso existe mucho sesgo hacia el discurso o la anécdota triunfalista, mezclado usualmente con mensajes con interpretación radical de los conceptos y prácticas. Pero se hizo la luz! :-), aparecieron las Certificaciones de Agilidad (con los correspondientes cursos preparatorios y la "necesaria" maquinaria comercial al respecto). Estamos en plena "guerra" de certificaciones ágiles. La más antigua de la Scrum Alliance que ofrece entre otras una de las más conocidas certificaciones CSM:Certified ScrumMaster. Ken Schwaber, uno de los fundadores de la Scrum Alliance, se separó de ella y formó Scrum.org  (para ofrecer otras certificaciones similares) con el propósito de combatir el "Flacid Scrum". Otro gurú Alistair Cockburn también creó su propia certificación en ICAgile. En España se creó el Scrum Manager para otorgar una certificación con ese mismo nombre. Recientemente el PMI se incorporó a las certificaciones ágiles con el PMI-ACP (PMI-Agile Certified Practitioner) que a priori podría malinterpretarse como una tendencia a modificar o interpretar el PMBOK para adaptarlo al agilismo. Sin embargo, el PMI-ACP es una certificación en contenido muy similar a las otras y que no esta vinculada ni implica cambios para el PMBOK. El tema de las certificaciones es muy polémico, y no voy a entrar en detalles al respecto. Un curso introductorio, de un par de días, como el que suele ofrecerse como preparación para las certificaciones ágiles, no viene mal a nadie para iniciarse en el agilismo. El uso (o abuso) que se le quiera dar a un examen y al correspondiente certificado ya es otra cuestión. Sin embargo, el riesgo evidente es que estos cursos caigan en el triunfalismo habitual o al menos en la falta de crítica hacia los problemas y desafíos reales asociados al agilismo.

Finalmente, en mi opinión el aspecto menos tratado y quizás el más necesario actualmente es el desafío de la implantación exitosa del agilismo, especialmente en equipos que tienen instaurados métodos de trabajo más cercanos al estilo tradicional. Como lectura al respecto recomiendo "Getting Started en agilismo" y "Tres claves para comenzar a implantar prácticas ágiles"

Patricio Letelier