En 2001, el Manifiesto por el Desarrollo Ágil de Software articuló la posición de los desarrolladores frente a la gestión de software impuesta desde arriba.
Los principios de ese manifiesto son difíciles de rebatir, y además tienen el mérito de ser refrescantemente simples. Se resume en hacer que el software funcione cuanto antes, trabajar con el cliente como parte del equipo, y responder al cambio, en lugar de intentar planificarlo todo de antemano, hacer la entrega y esperar a que todo se vaya al traste.
Pero avancemos hasta 2017: «ágil» se ha convertido cada vez más en algo que la dirección quiere imponer a los desarrolladores. Y por el camino ha acumulado bastante equipaje.
Como los cerdos de Rebelión en la granja de Orwell, los devotos de Scrum han acabado pareciéndose a los discípulos obsesionados con la metodología contra los que reaccionó el manifiesto ágil original.
Scrum, una metodología específica de gestión de proyectos, se ha vuelto casi sinónimo de la palabra ágil. Como suele ocurrir en las culturas impulsadas por desarrolladores, ha ido acumulando toda clase de protocolos, tácticas y jerga, como una bola de nieve cuesta abajo. Cuando Scrum no cumple con todos sus supuestos beneficios, el argumento habitual es que no lo estás aplicando bien; si no has abrazado cada elemento de Scrum con plena convicción, estás haciendo «falso ágil» y tu proyecto está condenado al fracaso. Vale la pena contrastar esa visión con el Manifiesto Ágil original. Como los cerdos de Rebelión en la granja de Orwell, los devotos de Scrum han acabado pareciéndose a los discípulos obsesionados con la metodología contra los que reaccionó el manifiesto ágil original.
Nada de esto significa que Agile, ni tampoco Scrum, sean malas ideas. Obtener código funcional cuanto antes; hacer demos e iterar dentro de ciclos regulares y acotados en el tiempo; integrar al cliente en el equipo y usar un backlog de funcionalidades para gestionar el cambio — todos son principios que seguimos en Made Media. Pero aquí estamos hablando, en el fondo, del ciclo de desarrollo de software. Hay elementos del diseño de sitios web y aplicaciones que no son estrictamente desarrollo de software. Scrum no tiene demasiado espacio para el diseño a nivel macro. Por eso combinamos procesos de desarrollo ágil con pragmatismo general de proyecto: hacemos el diseño previo justo necesario para no perdernos por caminos improductivos, y no delegamos el control de calidad enteramente en tests unitarios que entienden la calidad únicamente como código.
Esto suele manifestarse cuando el papel del project manager evoluciona hacia preguntar al equipo de producción qué está pasando y actualizar su diagrama de Gantt para que refleje mejor la realidad. La cola de la realidad meneando al perro de ficción.
Agile suele contraponerse a la técnica Waterfall, donde todas las tareas se trazan de antemano en un enorme diagrama de Gantt que, conforme avanza el trabajo real, se parece cada vez más a una obra de ficción. Esto suele manifestarse cuando el papel del project manager evoluciona hacia preguntar al equipo de producción qué está pasando y actualizar su diagrama de Gantt para que refleje mejor la realidad. La cola de la realidad meneando al perro de ficción.
Sí, Waterfall tiene sus problemas. Pero cuando se señala con el dedo a metodologías como PRINCE2 o certificaciones como PMP, los defensores del ágil suelen malinterpretar el verdadero propósito de esas metodologías. PRINCE2, por ejemplo, tiene muy poco que decir sobre la entrega del proyecto. Sus orígenes están en la contratación pública, donde la entrega la realiza muy probablemente un socio externo (¡como nosotros!) y se considera asunto suyo. El verdadero propósito de PRINCE2 no es entregar el proyecto, sino generar suficiente documentación de cobertura de responsabilidades para demostrar que no es culpa del PM cuando el presupuesto se duplica y el producto sigue sin aparecer por ningún lado.
Lo cual no significa que PRINCE2 sea malo en sí mismo. Su propósito es controlar la gobernanza del proyecto, no su entrega. Garantizar que un proyecto se encarga con un caso de negocio. Establecer pautas sobre cuándo hay que dar la voz de alarma. Anticipar y registrar riesgos. Estos controles y contrapesos son importantes cuando tienes que rendir cuentas de tus presupuestos. Se trata del éxito global del proyecto.
Los proyectos web son un negocio arriesgado. El alcance es tan difícil de definir con palabras que nunca sabes del todo qué estás obteniendo — ni siquiera qué quieres — hasta que lo ves. Es una de las razones por las que preferimos los wireframes a las listas de requisitos. Pero nadie te va a dar un cheque en blanco para tu proyecto web, y tendrás que ofrecer a tu junta directiva o a tu patrocinador alguna garantía sobre qué obtienen a cambio de su dinero. Así que, inevitablemente, habrá que comprometerse en firme con funcionalidades, presupuestos y plazos desde el principio. Esto es algo que las metodologías impulsadas por desarrolladores tienden a esquivar. ¿Adivinas por qué? Porque los desarrolladores se sienten cómodos escribiendo código, no haciendo promesas de negocio.
En Made Media somos conscientes de que los presupuestos de los proyectos a menudo han tardado años en conseguirse, y se han asignado con expectativas muy concretas sobre los resultados. Las metodologías de desarrollo ágil no nos eximen del compromiso de cumplir esas expectativas. Trabajando con presupuestos cerrados, tenemos que templar Scrum con algunas realidades comerciales. Estimamos en horas, no en pseudo-abstracciones como los story points. Aunque a veces eso le aguе la fiesta a algún desarrollador.
Así que en Made Media usamos una metodología que toma mucho de Scrum, y algo de DSDM y Kanban. Los clientes son bienvenidos a unirse a las reuniones de planificación de sprint, o incluso a los daily stand-ups si lo desean. Pero una llamada y demo semanal es la base. En lo que respecta a la contratación, gobernanza, informes y responsabilidad del proyecto, nos acercamos más a los principios de PRINCE2. Y no hay ninguna contradicción en eso.
Lecturas recomendadas
- Peopleware Demarco y Lister demuestran que los grandes problemas del desarrollo de software son humanos, no técnicos.
- The Mythical Man-Month imprescindible para quien gestione proyectos complejos.
- Agile Manifesto descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo.
- Scrum un marco de desarrollo de software ágil, iterativo e incremental para gestionar el desarrollo de productos.
- DSDM método de desarrollo de sistemas dinámicos.
- Kanban un sistema de planificación para la fabricación lean.
- Una crítica de Scrum ilustrada con memes de primera.
El mes que viene: Innovación con propósito