Hablemos de agilidad...

Muchos habrán escuchado algo sobre las metodologías ágiles. Algunos las adoran y las practican como si fueran una religión, y otros las detestan, las consideran un fraude y califican a los primeros como miembros de una secta. Pues eso es lo que he oído hablar muchas veces sobre metodologías ágiles, y no me agrada. No me agrada esta visión sesgada y extremadamente polarizada sobre la agilidad .

Qué es y qué NO es la agilidad

La agilidad no es desarrollar rápido y no es escribir todo usando Post-its y Sharpies. Tampoco es cobrar caro y no documentar nada. La agilidad es esencialmente adaptarse rápido frente al cambio. Es experimentar constantemente, fallar en pequeña escala, y tomar decisiones en base a hechos reales.

¿De qué cambios estamos hablando? Cambios asociados a la incertidumbre. Justamente es esa la clave del pensamiento ágil: concebir un problema como una fuente de incertidumbres. Si no, no sería un problema. Entonces, ¿por qué deberíamos enfrentarlos usando las metodologías tradicionales? Y con metodologías tradicionales me refiero a gestionar un proyecto, en nuestro caso de software, como si fuera un proyecto de una constructora. ¡NO! Hace varios miles de años que la humanidad realiza construcciones arquitectónicas, y por tanto, es un "problema" conocido. De hecho ni siquiera es un problema. Sabemos muy muy bien como levantar un edificio, y en este caso las metodologías tradicionales son idóneas.

Pero en un proyecto de desarrollo de software nos enfrentamos al verdadero concepto de problema, cuya solución no conocemos, ni menos el camino a ella. No hay "receta" y por lo tanto hay que experimentar, tal como lo hacen los niños, cuyas mentes están libres de esquemas y estructuras rígidas.

Pero en el mundo de los negocios experimentar puede llegar a ser muy costoso e ineficiente. Y es exactamente este ámbito el que es abordado por las metodologías ágiles: "¿Cómo gestionar un proyecto y llegar a la mejor solución minimizando el riesgo?" es la pregunta que trata de responder la filosofía ágil frente a un problema con incertidumbres.

El ciclo de Deming (¿o de Shewhart?)

Como mencioné más arriba, uno de los conceptos centrales del desarrollo ágil es experimentar constantemente y a pequeña escala. Dar pasitos pequeños en la niebla para poder encontrar el camino sin caerse por un barranco, y si hay algún obstáculo, poder cambiar el rumbo. Experimentar en pequeña escala significa que en caso de fallar, también se hace en pequeña escala, disminuyendo el riesgo. Pero experimentar constantemente no significa hacerlo a "tontas y a locas".

El estadístico estadounidense William Edwards Deming, experto en procesos de calidad y muy estudioso del desarrollo y crecimiento de Japón después de la segunda guerra mundial, presentó en ese país en los años 50 el ciclo PDCA: plan, do, check, act, como metodología de mejora continua. A través del "Ciclo de Deming" se puede formalizar un proceso de experimentación (¡aplicable a todo tipo de situaciones!) dividido en 4 pasos:

  • Planificar un cambio o un experimento orientado como una mejora. Implica establecer los objetivos, resultados esperados y pasos seguir.
  • Ejecutar el experimento, preferentemente en pequeña escala, recolectando datos para los próximos dos pasos.
  • Verificar los resultados del paso anterior. Ordenarlos, graficarlos, y obtener conclusiones.
  • Actuar : escoger uno de tres caminos posibles
    1. Si se verificó que lo ejecutado es una mejora y cumple los objetivos, incorporarlo.
    2. Si se verificó que lo ejecutado NO es una mejora, rechazarlo y dejar la situación como estaba.
    3. Si se verificó que lo ejecutado produjo resultados diferentes a lo esperado, entonces hay algo que estudiar y algo que aprender, lo cual sugiere realizar sucesivos ciclos PDCA en el futuro, con ajustes y cambios en la planificación.

Por mi parte, prefiero una metodología similar, pero previa al ciclo de Deming, que es el Ciclo de Shewhart, o PDSA: plan, do, study, act. PDCA y PDSA son casi iguales, de hecho, Deming propuso PDCA en base a lo que enunció Walter A. Shewhart, el creador de PDSA. En éste, el tercer paso no es 'verificar' si no 'estudiar', que enfatiza la importancia de no solo chequear los datos si no de tomar lo nuevo que se ha aprendido y aplicarlo, para cualquiera de los tres resultados obtenidos en el último paso. Por otra parte, personalmente prefiero llamar al cuarto paso 'ajustar' en vez de 'actuar'.

Metodología y pensamiento A3

Es un enfoque estructurado a la resolución de problemas y mejora continua diseñada por Toyota (sí, Japón es un nombre de país que encontrarán recurrentemente en el mundo ágil). El origen de su nombre es porque la metodología se realiza sobre un papel tamaño ISO A3, que era el tamaño máximo de papel que soportaba un fax en su momento.

El proceso A3 se basa en los principios del ciclo PDCA, y formaliza y sintetiza en una sola hoja el experimento a ejecutar (Propuesto para el lector: ¿por qué se hace en una sola hoja?)

La hoja se divide en dos secciones principales:

Cada sección posee subsecciones que describen y ordenan con un poco más de detalle la información necesaria para llevar a cabo el ciclo PDCA:

El reporte se escribe de izquierda a derecha y de arriba hacia abajo. Cuando se comienza a llenar el reporte, quedaría algo más o menos así (ejemplo para un problema en el área de desarrollo de juegos)

Continuará...

En el mundo real, donde la masa no es puntual y hay roce, el reporte A3 se escribe así: