Algunas veces la búsqueda de la agilidad nos lleva al descontrol. Hay una zona gris en donde es fácil mezclar movimientos rápidos con desprolijidad (y sólo logramos ser torpes), eficiencia aparente con trabajo pendiente (y sólo logramos ser eficaces), cumplimiento de plazos con baja calidad (y apenas logramos llegar a tiempo a la fiesta de entrega, vestidos de traje pero sin calzoncillos). Resumiendo, a veces se confunde agilidad con velocidad.
Las presiones del negocio hacen que la búsqueda de la agilidad se vuelva obsesión (y esto es bueno). Tratamos de hacer lo menos posible de la manera más simple posible.
Así, planeamos a medida que avanzamos, nos integramos con el cliente, diseñamos a medida que construimos, construimos pensando en la reutilización y el cambio, integramos continuamente y utilizamos tests codificados en todo el proceso... o al menos eso deberíamos hacer, si seguimos los postulados de XP (Programación extrema, PE o eXtreme Programming, XP), a mi entender la metodología más obsesionada por la velocidad la agilidad.
Por desgracia muchos han leído la entrada en Wikipedia y han googleado, picando de aquí y de allí, pero pocos han leído el libro que da origen a la cosa, Extreme Programming Explained, de Kent Beck. No conozco a nadie que haya participado en un equipo ágil tal cual lo define el libro, aunque sí a algunos integrantes de equipos que de "ágiles" sólo tienen la etiqueta (no está mal tener sólo la etiqueta, siempre que uno sea consciente de ello).
Para que quede claro, antes de comenzar con el sarcasmo o de tirar ejemplos concretos: la belleza de XP radica en que es un sistema, y no una colección de partes que pueden reordenarse o intercambiarse a voluntad. Sin embargo, es esta belleza lo que lo vuelve peligroso puesto en manos de algún monito. Ya me explico.
Se suele utilizar XP menos para desarrollar que para defender lo indefendible y justificar lo injustificable por la supuesta búsqueda de "agilidad", opinando de oídas sobre un punteo de conceptos centrales. La frase "...pero XP recomienda..." debería estar prohibida en equipos que no implementan XP. Ahora sí, repartamos palos.
Monito de contacto con el cliente + Tijeritas + XP = Los requerimientos son cambiantes, toda documentación más allá de lo indispensable una pesada carga para el equipo que no aporta valor al cliente y la comunicación informal la más conveniente siempre. Entonces, como estamos muy apurados y tendríamos que haber empezado ayer, no pasemos los requerimientos por escrito. Esto es ágil.
Todos los antecedentes son correctos, eso es innegable. Pero eso no vuelve verdadera la afirmación. Lo que sigue al "entonces" es una barrabasada.
Por empezar, incluso en XP uno de los documentos requeridos (y en XP no hay muchos) es, justamente, el que especifica un requerimiento: la historia del usuario. Pensemos cuánta importancia tiene este documento que en la metodología más minimalista es requerido. Y no sólo eso. XP obliga a que el documento realmente exista, por ejemplo al centrar en él el proceso de planificación. Casi todas las tareas de XP se centran alrededor de éste documento.
Los requerimientos no son parte del sistema, los requerimientos **definen** al sistema. Por si no queda claro: yo puedo crear un sistema sin diseño, sin computadoras, sin código, sin empleados, sin nada. Puedo crear un sistema tan sólo diciéndole al cliente "haga esto y lo otro y luego esto otro". Si me pongo filosófico, puedo decir que puedo crear un sistema con sólo pensarlo (al fin y al cabo es una construcción teórica), y ni siquiera necesito comunicarlo para que exista.
Pero no puedo crear un sistema sin requerimientos, el objetivo es parte de la definición de sistema, explícitamente. En un sistema informático, los requerimientos son el objetivo, y por tanto son lo que hace que el sistema funcione. ¡En serio! A ver: tengo un programa que cada vez que lo ejecuto hace que Windows tire un BSOD... ¿Funciona? No sé, a ver los requerimientos... "es un sistema contable": entonces no, no funciona; "es un virus": entonces funciona perfectamente.
Ahora un poco más en serio: la memoria nos juega malas pasadas, los charcos se secan, a las palabras se las lleva el viento. Cuando surge una duda sobre un requerimiento, enormes porciones del sistema se tambalean. Si esperamos que los requerimientos cambien velozmente, tendremos que pensar en algo para no confundir los de la semana pasada con los de la anterior. Esto me ha sucedido: llega el requerimiento "A", luego el requerimiento "B = not A", luego el "A", luego el "B"... y así ad eternum. Si los cambios están separados por un par de meses jamás nos daremos cuenta de que en realidad la solución es poner un parámetro en la configuración... puedo hacer los cambios velozmente, pero que nadie me diga que eso es ser ágil.
El desarrollo de software no es más que un teléfono descompuesto entre el cliente y un algoritmo. La metodología no es más que un desesperado intento por arreglarlo. XP lo intenta minimizando la cantidad de "nodos" en la línea: el cliente mismo está al lado de los codificadores, escribiendo los requerimientos.
Conclusión: el monito de contacto ocupa un lugar clave en donde una palabra, apenas un pequeño malentendido, puede tener consecuencias imprevisibles. Sea precavido: domestique a su monito de contacto (recuerde que la letra, con sangre... entra).
Monito analista + Cuchillo dentado + XP = Los diseños se refinan durante la codificación, ya que sólo obtenemos una comprensión acabada del problema al resolverlo. Es un proceso iterativo. Por eso vos empezá programando con lo que más o menos te acabo de contar, después te paso el diseño y vemos. Esto es ágil.
De vuelta, correctos antecedentes con una conclusión mágica que sólo guarda una relación aparente con ellos.
En XP diseño y codificación van de la mano no porque sean procesos iterativos e incrementales (que se entienda: sí que son iterativos e incrementales, sólo que no es lo central en relación a éste aspecto de XP en particular), sino porque en XP parte del diseño (tal como se lo define tradicionalmente) se amalgama con la codificación, a fin de lograr una comunicación más directa entre el desarrollador y el cliente. No hay una actividad de diseño sin parte de codificación ni viceversa, por tanto un analista, a menos que pueda codificar, no podrá diseñar en un equipo XP (siempre hablando en el sentido clásico del término "diseñar").
En XP se especifica claramente que la historia del usuario le llega directamente a un par de programadores quienes, para empezar, la estiman por su cuenta (mientras el analista nos va a buscar un café), luego la planifican con el líder del proyecto (mientras el analista va por el azúcar... siempre se olvida del azúcar) y que finalmente van codificando y "elaborando el diseño" a medida que codifican (mientras el analista descansa un rato antes de volver a la máquina expendedora)...
Pero bueno, ya que éste analista trabaja en un equipo que no adopta XP, que haga el análisis que corresponde en vez de justificarse en cualquier cosa y pasarle un garabato de compromiso a un pobre programador que encima terminará haciéndole el trabajo, ya que el caradura no tendrá mejor idea que acercarse luego y preguntar "¿cómo lo resolviste?"... eso si alguna vez elabora los famosos documentos.
Luego hay un error en el código y no hay forma de saber qué es lo que el sistema debería hacer... ah, y es culpa del programador, que no siguió con las especificaciones (que él mismo le pasó -sin querer- al analista).
Para terminar esta sección, un divague futurista... un monito analista no debería ensalzar demasiado a XP. Esta metodología nos lleva por una senda que puede llegar a determinar su anulación en proyectos pequeños, tal vez en medianos y en una de esas en grandes. Lo rebaja a la categoría de ayudante de redacción (del cliente al elaborar las historias del usuario) y diseñador y ejecutor de tests funcionales... y yo me arriesgo a decir que incluso este último papel está un poco amenazado: la mayoría de los tests se pueden automatizar (sí, incluso muchos funcionales), así que si al analista no se le ocurren tests nuevos todo el tiempo, el pobre hombre ya no sirve para nada... perdón, sí sirve, está el tema del café... bueno, logramos acomodarlo, ¡bien por él! Sólo un analista es capaz de justificar su inacción utilizando una metodología que en una de esas lo deja sin trabajo (bueno, si lo pensamos bien... esto le da la razón al analista y a la metodología).
Monito programador + anteojos de recorte de la realidad + XP = El código es la documentación. Hay que diseñar a medida que se codifica. El código es compartido. Hay que tener coraje para hacer un refactory cuando es necesario. Así que no documento ni comento, charlo un rato con el analista y luego hago lo que mejor me parece donde mejor me parezca. Migré el front-end desde Java a .Net porque leí en un blog que la nueva versión es muy superior. Luego lo volví a Java (recodificando, no hacia atrás) ya que en otro blog aprendí varios temas de performance que me hicieron cambiar de idea. Luego descubrí Silverlight así que lo implementé (me quedó muy bonito) pero finalmente me enteré de que sigue en beta... me pareció que no era estable, así que en definitiva quedó en .Net. ¡Qué semana productiva! ¡Aprendí un montón!... Y es más ágil.
En el equipo en el que trabaja el monito de arriba no se programa de a pares, no hacen programación orientada al test, no se integra continuamente, no hay un representante del cliente en el equipo y no se elaboran historias del usuario ni se hace el juego de la planificación.
Pero al tipo le encanta XP (¡programadores al poder!) e intenta aplicarlo en todo lo que puede, porque es más ágil.
Usted, señor programador, que leyó hasta aquí con una sonrisa en los labios y con un ocasional "sí, es así, exactamente" en voz alta... usted, que seguramente le ha advertido al analista (que pasó frente a su escritorio en busca de un café) "tenés las horas contadas"... usted, gran orangután, es el peor de todos.
Porque es justamente usted, el programador, el que tendría que entender que no se puede pretender que un sistema funcione si le extirpamos arbitrariamente un pedazo de código y lo reemplazamos por otro que funciona bien... en otro sistema.
Porque seguramente usted se da cuenta de que así no funciona. Pero en vez de impulsar un cambio integral o buscarse un equipo más acorde a sus expectativas (o a su ansiedad) prefiere ser el engranaje que gira solo al doble de velocidad que los demás... muy ágilmente, por supuesto.
XP, como cualquier metodología, conforma un sistema. Cada punto de XP tiene una razón de ser dentro de ese sistema, no es una simple recomendación que "deberíamos" adoptar. Sólo por ejemplo: la codificación/diseño se apoya en la programación de a pares, que asegura que el diseño sea discutido al menos por dos integrantes del equipo. El refactory frecuente se apoya en la codificación orientada al test, ya que sin testeo automático es una actividad peligrosa. El minimalismo en la documentación funcional se apoya con la integración de un representante del cliente en el equipo al que se lo puede consultar continuamente, si no fuese así podría perderse mucho tiempo en la resolución de ambigüedades... todo tiene que ver con todo.
Por supuesto que hay que adaptar la metodología a cada caso particular. Y que sí se puede implementar parcialmente. Por ejemplo, sé que la programación de a pares es un punto usualmente resistido. Entonces, hay que compensar la no-adopción de esa práctica con algo... no sé, habría que probar. Podrían ser reuniones para fijar estándares de codificación, o revisiones formales del código, o una instancia informal de revisión del diseño... las posibilidades son infinitas. Tal vez algún comentarista con más experiencia en equipos XP pueda aportar un poco más sobre este punto.
Lo que queda claro es que la metodología es un sistema. Y, como a todo sistema, hay que conocerlo para modificarlo o adaptarlo, tomar esas modificaciones o adaptaciones con el debido cuidado, probarlas, etc... y no tomar frases sueltas para hacer mal lo que de todas maneras no había que hacer.
Silencio de radio estos días, ¿lo notaron? Tal vez sí –eso espero-, ya que corté un período de extrema verborragia que abarcó las últimas semanas, aunque –reconozco- con más relleno que ideas.
Rara vez es explicitado en manera alguna –decía- y cuando lo es –cuando pretende serlo- se materializa en forma de frases de compromiso que rara vez tienen que ver con la cosa real que dicen reflejar. Es un poco como la visión a la que tanta importancia le dan las normas de calidad: pocos saben qué es y de poco sirve saberlo -salvo para certificarse en algo- pero no se puede tener éxito sin ella. Análogamente, los negocios exitosos no son los que saben qué es un paradigma sino los que tienen un paradigma exitoso. Siempre es bueno racionalizar, poder poner en palabras, explicitar, pero lo indispensable es tener qué explicitar.
Para los que han tenido esta experiencia -como parte de una visita formal o no- ha sido casi reveladora. Día a día, inevitablemente y de forma intuitiva, encerrados tras una muralla de código, los programadores derivan, imaginan, se forman una imagen del negocio para el cual programan. Lo hacen a partir de los requerimientos, del diseño propuesto para las pantallas, de las funcionalidades. Pero es muy difícil que esta imagen, condicionada por su experiencia y sus propios paradigmas, coincida con la realidad.
