IV. Entrega ágil, gobernanza sólida.

En 2001, elManifiesto original para el desarrollo ágil de software articulaba una postura de los desarrolladores contra la gestión descendente del software.

Los principios de ese manifiesto son difíciles de discutir y, además, son refrescantemente sencillos. Se reducen a conseguir que el software funcione lo antes posible, trabajar con el cliente como parte del equipo y responder a los cambios, en lugar de intentar planificarlo todo de antemano, entregarlo y esperar a que salga terriblemente mal.

Sin embargo, en 2017, "ágil" se ha convertido cada vez más en algo que la dirección quiere imponer a los desarrolladores. También ha adquirido mucho bagaje por el camino.

Como los cerdos de Rebelión en la granja de Orwell, los devotos de Scrum empiezan a parecerse a los discípulos de la gestión de proyectos 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 convertido casi en sinónimo de la palabra Ágil. Como suele ocurrir con las culturas impulsadas por los desarrolladores, ha adquirido todo tipo de protocolos, tácticas y jerga, como una bola de nieve que rueda cuesta abajo. Cuando Scrum no ofrece todos sus supuestos beneficios, el razonamiento habitual es que no lo estás haciendo bien; a menos que hayas abrazado de todo corazón cada elemento de Scrum, entonces estás haciendo "falso ágil" y tu proyecto está condenado al fracaso. Merece la pena contrastar este punto de vista con el Manifiesto Ágil original. Al igual que loscerdos en Rebelión en la granja de Orwell, los devotos de Scrum empiezan a parecerse a los discípulos de gestión de proyectos obsesionados con la metodología contra los que reaccionaba el manifiesto ágil original.

Esto no quiere decir que Agile o Scrum sean malos. Obtener código funcional lo antes posible, realizar demostraciones e iteraciones dentro de ciclos regulares con plazos establecidos, incorporar al cliente en el equipo y utilizar una lista de tareas pendientes para gestionar el cambio son principios que seguimos en Made Media. Pero en realidad, estamos hablando del ciclo de desarrollo de software. Hay elementos de diseño de sitios web y aplicaciones, que no son estrictamente hablando de desarrollo de software. Scrum realmente no tiene mucho lugar para el diseño a nivel macro. Así que combinamos los procesos de desarrollo ágil con el pragmatismo general del proyecto, haciendo sólo lo suficiente por adelantado el diseño para evitar ir por agujeros de conejo improductivos, y no delegar la garantía de calidad por completo a las pruebas unitarias que ven la calidad estrictamente a través de una lente de código.

Esto suele manifestarse cuando el papel del jefe de proyecto se convierte en preguntar al equipo de producción qué está pasando y actualizar su diagrama de gantt para que refleje mejor la realidad. La realidad mueve la cola de la ficción.

Agile suele contrastarse con la técnica Waterfall, en la que todas las tareas se trazan previamente en un diagrama de gantt gigante, que cada vez se parece más a una obra de ficción a medida que el trabajo real se pone en marcha. Esto suele manifestarse cuando el papel del director del proyecto pasa a ser el de preguntar al equipo de producción qué está pasando y actualizar su diagrama de gantt para que refleje mejor la realidad. La realidad mueve la cola de la ficción.

Así que sí, la cascada tiene sus problemas. Pero a menudo, al señalar con el dedo una metodología como PRINCE2 o certificaciones como PMP, los partidarios de la metodología ágil malinterpretan el verdadero propósito de esas metodologías. PRINCE2, por ejemplo, tiene muy poco que decir sobre la ejecución de proyectos. Sus orígenes se remontan a la contratación pública, donde lo más probable es que la entrega la realice un socio externo (¡como nosotros!) y se considere asunto del socio externo. El verdadero propósito de PRINCE2 no es entregar el proyecto, sino entregar suficiente documentación C.Y.A. para demostrar que no es culpa del PM cuando el presupuesto se duplica y el producto sigue sin aparecer.

Lo cual no quiere decir que PRINCE2 sea malo en sí mismo. Su propósito es intentar controlar la gobernanza del proyecto , no su ejecución. Garantizar que un proyecto se encarga con un estudio de viabilidad. Proporcionar directrices sobre cuándo se debe dar la alarma de que no todo va según lo previsto. Prever y registrar los riesgos. Estos controles y equilibrios son importantes cuando se responde ante los presupuestos. Se trata del éxito global del proyecto.

Los proyectos web son una empresa arriesgada. El alcance es tan difícil de definir con palabras que nunca estás seguro de lo que vas a conseguir, o incluso de lo que 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 vas a tener que dar a tu junta directiva, o a tu patrocinador, algunas garantías sobre lo que vas a obtener por su dinero. Así que, inevitablemente, habrá que comprometerse de antemano con características, presupuestos y plazos. Esto es algo que las metodologías basadas en el desarrollo tienden a eludir. ¿Adivina por qué? Porque los desarrolladores se sienten cómodos escribiendo código, no haciendo promesas comerciales.

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 definidas sobre los resultados. Las metodologías de desarrollo ágil no pueden eximirnos de nuestro compromiso de cumplir esas expectativas. Al trabajar con presupuestos fijos, tenemos que atemperar Scrum con algunas realidades comerciales. Calculamos en horas, no en pseudoabstracciones como puntos de historia. Incluso si a veces eso hace áspera la vibra de un desarrollador.

En Made Media utilizamos una metodología que bebe mucho de Scrum y un poco de DSDM y Kanban. Los clientes pueden participar en las reuniones de planificación de sprints, o incluso en las reuniones diarias si lo desean. Pero la base es una llamada semanal y una demostración. En lo que respecta a la puesta en marcha del proyecto, la gobernanza, la elaboración de informes y la rendición de cuentas, seguimos más el modelo PRINCE2. Y no hay contradicción en ello.

Lecturas obligatorias

• Peopleware Demarco y Lister demuestran que los principales problemas del desarrollo de software son humanos, no técnicos. 
• The Mythical Man-Month (El Mítico Hombre-Mes ), para cualquiera que gestione proyectos complejos.
• Agile Manifesto descubrir mejores formas de desarrollar software
  haciéndolo y ayudando a otros a hacerlo.
• Scrum es un marco de desarrollo de software ágil, iterativo e incremental para gestionar el desarrollo de productos.
• DSDM Método dinámico de desarrollo de sistemas.
• Kanban, un sistema de programación para la fabricación ajustada.
• Una crítica de Scrum ilustrada con memes de primera.

Próximo mes: Innovación con un propósito