400430405. La disciplina Ágil

Últimamente, es corriente que los tradicionalistas arguyan que el desarrollo de software Ágil no es disciplinado, una crítica dura que hay que abordar porque no hay nada más lejos de la realidad. Sospecho que la gente que utiliza esos argumentos o bien no entienden Ágil o buscan excusas para no adoptar las técnicas ágiles. Este mes, voy a describir la disciplina necesaria para los desarrolladores de Ágil, a compartir mi criterio para establecer si un equipo es Ágil, y a argumentar que el desarrollo tradicional da un falso sentido de disciplina.

Muchos tradicionalistas confunden los métodos de codificar-y-arreglar con métodos Ágiles, y están en lo cierto en que el grupo de codificar-y-arreglar no es muy disciplinado. Para complicar el problema, los que codifican-y-arreglan a menudo dicen ser ágiles, porque no escriben documentación ni hacen inspecciones de código.

(Muchos tradicionalistas confunden los métodos de codificar-y-arreglar con métodos Ágiles, y están en lo cierto)]

Cuando los tradicionalistas sepan cómo distinguir los equipos Ágiles de los equipos de “codificar-y-arreglar” – y la sección que se incluye más abajo sobre “Cómo distinguir a los Ágiles de los que Codifican-y-Arreglan” debería servir de ayuda – verán que estaban equivocados en que Ágil no es disciplinado. Lo cual es importante, porque les permitirá pensar en Ágil de forma equitativa, y lo que es más importante, puede que los haga empezar a preguntarse cuán disciplinados son los métodos tradicionales en la práctica.

La disciplina de la Entrega regular

El mayor motivador de disciplina dentro de los métodos Ágiles es la entrega regular de software que funcione. Cuanto más breve sea la iteración, mayor es la disciplina que se necesita para hacerla funcionar, y curiosamente la encuesta del 2007 que realizó Dr. Dobb’s sobre la Adopción de Ágil, ([www.ddj.com/architect/200001986) muestra que un 85 por ciento de los equipos Ágiles prefieren interacciones de entre una y cuatro semanas de iteración.

Proporcionar valor comercial concreto y mesurable en forma de software que funcione en cada iteración es realmente duro, porque realmente hay que hacer el trabajo que corresponde. Los profesionales de las TT.II. indisciplinados se esconden tras la documentación detallada, las revisiones y otras formas cuestionables de “valor ganado” tradicional, que son poco menos que promesas de entregar algo en algún momento en el futuro.

Hay varias técnicas ágiles que podemos adoptar para salir de la indisciplinada rutina del “valor ganado” tradicional. En primer lugar, podemos hacer un poquito de modelado de alto nivel, para empezar, que nos de la información que necesitamos para las decisiones iniciales en materia de planificación y arquitectura. (www.agilemodeling.com/essays/amdd.htm).

Eso a menudo requiere horas o días mas que semanas o meses, porque nos concentramos en el modelado y no en escribir amplia documentación. En segundo lugar, no conviene construir en exceso nuestro software para soportar algún requisito mítico futuro que puede que nunca sea aplicable, sino más bien trabajar en el orden de prioridades según las definen las partes interesadas en el software (más abajo se amplia esta información).

En tercer lugar, se adopta el método “inmediato” o “just-in-time” (JIT) para planificar, en lugar de la falsa seguridad de una planificación inicial detallada. Planning Poker de Mike Cohn (www.planningpoker.com) es un ejemplo perfecto, porque permite que quienes están realizando el trabajo puedan planificarlo con facilidad en base a JIT. Curiosamente, la encuesta sobre Adopción de Ágil mostró también que el cuarto producto de trabajo más útil en los proyectos ágiles es un plan detallado de iteración, y sin embargo el menos útil fue un gráfico detallado de Gantt.

La disciplina de la calidad

Los desarrolladores ágiles adoptan para el desarrollo el método de comprobar primero, mediante el cual se escribe un único test de forma iterativa y a continuación sólo el suficiente código de producción para completar ese test. Fácil de decir, pero en la práctica requiere bastante disciplina porque es muy fácil asumir que o bien uno mismo u otra persona hará las comprobaciones más tarde.

Es también fácil de asumir que estamos escribiendo un código estupendo y que realmente no necesitamos escribir una prueba para este código “obviamente simple” que muy claramente podría no tener ningún problema.

Como ya he descrito en Agile Testing Strategies (www.ddj.com/development-tools/196603549), muchos equipos ágiles prefieren tener un equipo independiente de comprobación que haga las comprobaciones de investigación paralelamente con los trabajos de construcción. Ello requiere disciplina por parte del equipo de desarrollo, porque los que realizan las pruebas les proporcionaran con regularidad casos de defectos que deberían tratarse como nuevos requisitos a priorizar, y colocados en su pila de trabajo según corresponda. Los defectos auténticos, frente a las potenciales características nuevas, deberían ser abordados por el equipo inmediatamente, para evitar el aumento de su deuda técnica.

((La gestión de este tipo de “caos” requiere una importante disciplina por parte de los comprobadores de investigación))

Los equipos tradicionales con frecuencia dejan que se amontonen los defectos a lo largo del proyecto, si es que los llegan a detectar, con la intención de abordarlos en algún otro momento teórico posterior; lo que es una forma de trabajar muy arriesgada, cara e indisciplinada. Siguiendo este método, probablemente los desarrolladores no les provean de especificaciones detalladas, ya que no se requieren para el equipo de investigación.

En lugar de eso, a los encargados de realizar las pruebas se les da una nueva compilación de forma regular, al menos una vez por iteración, aunque es mejor cada noche, para que puedan trabajar con la versión más reciente del sistema disponible. La gestión de este tipo de “caos” requiere una importante disciplina por parte de los comprobadores de investigación.

Hay varias técnicas de desarrollo relacionados con la calidad que requieren mucha disciplina. En primer lugar, es frecuente que los agilistas sigan unas convenciones de codificación compartidas, así como estándares de bases de datos e incluso guías para la documentación también compartidas, lo que requiere que los desarrolladores ágiles se atengan a las normas acordadas en lugar de simplemente seguir su método preferido.

En segundo lugar, se necesita de gran disciplina para re-factorizar sólo lo que se necesita, justo entonces, para la tarea entre manos en vez de arreglar muchas cosas que habría que hacer en algún momento. En tercer lugar, la disciplina de requerir que las compilaciones se vayan haciendo con éxito en lugar de continuar con el desarrollo de la nueva funcionalidad es absolutamente esencial, porque fomenta la convergencia del código dentro del equipo y un enfoque contínuo sobre la calidad.

La disciplina de la implicación activa de las partes interesadas

Las partes interesadas – inclusive las partes interesadas a nivel comercial, el personal de operaciones y de apoyo, y otros profesionales del mundo de las TT.II. – están implicados de forma activa en proyectos Ágiles. Idealmente, las partes interesadas se implican todos y cada uno de los días a lo largo de la vida del proyecto, participando de forma activa en el trabajo de modelado y comprobación, e incluso a veces en el desarrollo (sí, las partes interesadas pueden aprender a realizar un prototipo e incluso a escribir código de producción).

Este nivel de implicación les permite ver el funcionamiento interno de los trabajos de desarrollo de software, motivando a los desarrolladores a actuar de forma más profesional y disciplinada. También motiva a los desarrolladores a concentrarse en las prioridades reales de las partes interesadas, y no en sus propias prioridades personales.

La implicación activa y efectiva de las partes interesadas requiere una definición clara de los derechos y responsabilidades dentro del equipo. Las partes interesadas son generalmente responsables de suministrar información y tomar decisiones de forma oportuna, y de priorizar los requisitos. Los desarrolladores deben suministras estimaciones exactas de forma oportuna, comprometerse y atenerse a dichas estimaciones y explicar las compensaciones de carácter técnico que conllevan las distintas decisiones.

Las partes interesadas y los desarrolladores deben respetar las decisiones tomadas por otras personas del equipo incluso cuando no están de acuerdo. Por ejemplo, a un desarrollador podría no gustarle cómo se han priorizado los requisitos, pero debe seguir trabajando en ellos en ese orden, y a una parte interesada puede no gustarle la estimación dada por un desarrollador para una cuestión específica del trabajo, pero aún así tiene que respetarla. Como podemos imaginar, para seguir esas filosofías se necesita disciplina en todo momento y por parte de todos los implicados.

Es interesante observar que al proporcionar al software que funciona todas las iteraciones y la participación activa y de apoyo de las partes interesadas, éstas conocen mejor el estado real de un proyecto de desarrollo de software. Ello permite que las partes interesadas a nivel comercial puedan dirigir las TT.II. de manera efectiva, el tema de la columna del próximo mes.

Disciplina a escala

Hay varias prácticas “Ágil a Escala” que necesitan un grado de disciplina que se ve pocas veces en los equipos tradicionales. En primer lugar, los equipos Ágiles no sólo hacen un poquito de modelado inicial de la arquitectura al comienzo de un proyecto, también hacen el trabajo necesario para demostrar que la arquitectura funciona a principios del ciclo de vida. Esta práctica, corriente en el Proceso Unificado, reduce el riesgo técnico porque no asume que la arquitectura funciona sólo porque los arquitectos dicen que funcionará.

Necesita de una mayor disciplina que el método tradicional de modelado detallado inicialmente porque se hace evidente muy pronto si el equipo realmente reúne las características necesarias para producir un sistema que funcione.

En segundo lugar, la identificación de requisitos de un servicio de calidad (QoS) como son las cuestiones de seguridad y usabilidad, para después convencer a las partes comerciales interesadas de que los entrelacen con su pila de elementos de trabajo priorizados, requiere de gran destreza y disciplina. Sería indisciplinado no abordar esos requisitos, pero sería casi tan malo invertir meses al comienzo de un proyecto para abordarlos antes de producir algo que tenga valor comercial. Si, es divertido trabajar en atractivas plataformas técnicas, pero no es para eso para lo que nos pagan realmente las partes comerciales interesadas.

La tercera cuestión sobre escalabilidad rodea la mejora del proceso del software (SPI por Software Process Improvement). El método Ágil consiste en tomarse tiempo de manera regular (al menos una vez por iteración) para considerar la efectividad del trabajo conjunto del equipo y, si se puede, hacer algo para mejorar las cosas. La continua aplicación del método SPI les permite a los equipos Ágiles aprovecharse de sus conocimientos de forma inmediata, mejorando su productividad durante todo el proyecto. Sería indisciplinado no intentar en ningún momento la SPI, o esperar hasta finalizar el proyecto para identificar las “lecciones aprendidas” en análisis post-mortem del proceso que sirven poco más que para darle a la gente una sensación de cierre tras su tradicional marcha fúnebre.

La disciplina del trabajo en equipo

Los agilistas, cuando se les da la oportunidad, normalmente no trabajan solos, porque saben que hay demasiado riesgo en ello. Se necesita disciplina para seguir prácticas de no-solo, como la programación en pareja y modelar con otros, porque es demasiado fácil asumir que uno es lo suficientemente listo como para hacer el trabajo sólo y rápido. También se necesita disciplina para ser responsable de todo el equipo, y no sólo de la pequeña parte que nos corresponde, lo que motiva a trabajar estrechamente con otra gente y por lo tanto a aprender de ella en entornos distintos a los nuestros.

Se necesita disciplina por parte de la dirección para quitarse de en medio y permitir que la gente se organice, incluso cuando está claro que el equipo con toda probabilidad va a cometer un error, y no intentar planificarle todo con detalle. Proporcionarle a la gente oportunidades de aprendizaje como este puede ser frustrante a veces, pero es totalmente esencial para hacer crecer a nuestra plantilla.

Otro aspecto de la disciplina en la gestión de proyectos ágiles es el hecho de mantener una reunión diaria rápida, para fomentar la comunicación dentro del equipo sobre cuestiones que realmente importan, como lo que cada uno está haciendo y con qué problemas se están encontrando. Eso nos obliga a enfrentarnos a y resolver los problemas cuando surgen, en lugar de empapelarlos con informes de estado abiertamente optimistas.

[(Ágil es mucho más disciplinado que el desarrollo tradicional, que a su vez es más disciplinado que el desarrollo de codificar-y-arreglar)]

El desarrollo de software Ágil, cuando se hace como es debido, es muy disciplinado. Ágil es mucho más disciplinado que el desarrollo tradicional, que a su vez es más disciplinado que el desarrollo de codificar-y-arreglar. Si alguien nos dice que Ágil no es disciplinado, debemos preguntar si se han visto implicados en un proyecto Ágil, y de ser así, si cumplieron los criterios definidos más arriba. Todavía tengo que encontrarme con experiencia Ágil y tradicional en el mundo real que me diga que la tradicional es más disciplinada, y me parece que los tradicionalistas están arrojando piedras sobre su propio tejado al argüir eso.

Quisiera agradecer a Ted Rivera de IBM por sus detallados comentarios sobre el borrador inicial de este artículo, y a Bill Krebs, también de IBM, por todo lo que he ido aprendiendo de él en las conversaciones que hemos mantenido entorno a este tema.

DDJ