Mejorando el trabajo en equipo.

Saltando desde el blog de Sebastián Hermida me encontré en abetterteam frente a una buena implementación de una encuesta incluida en el libro Art of Agile Development, de James Shore y Shane Warden.

El cuestionario evalúa el estado de un equipo de desarrollo ágil (se basa en XP, aunque creo que podría aplicarse a otras metodologías, con algunas salvedades) en 5 aspectos: Thinking, Collaborating, Releasing, Planning y Developing.

Hay una corta serie de preguntas Si/No para cada uno de ellos. Al final se presenta un panorama general del estado del equipo y se sugieren prácticas ágiles concretas para mejorar los puntos flojos detectados. También propone la posibilidad de registrarse para evaluar el progreso del equipo.

La encuesta comienza aquí.

Medir la calidad de los requerimientos.

Los requerimientos cambian. Todo cambia.

La revolución de las metodologías ágiles no ha hecho más que establecer el factor cambio como inherente al desarrollo e integrarlo en el proceso (a través de ciclos cortos de desarrollo, reuniones periódicas, programación de a pares, programación orientada al test y un sinnúmero de otras técnicas) en vez de combatirlo (con planeamientos detallados, seguimientos rigurosos, requisitos enciclopédicos, etcétera).

Sin embargo, “eXtreme Programming es un arma peligrosa”:

[…] Se suele utilizar XP menos para desarrollar que para defender lo indefendible y justificar lo injustificable por la supuesta búsqueda de "agilidad" […]

Hablando de requerimientos, tengo la sensación de que muchas veces se esconden gruesos errores bajo una alfombra maloliente etiquetada “cambios en el negocio”. ¿Cuándo hubo un cambio en el negocio y cuándo un error al elaborar los requerimientos?

No estoy hablando aquí de errores de interpretación de un término o de la existencia de ciertas áreas grises en las definiciones, porque errores de ese tipo se van corrigiendo en la medida en que avanzan las iteraciones y el equipo toma conocimiento del negocio.

Estoy apuntando a cuando se producen repetidamente (casi diría sistemáticamente) errores de procedimiento o metodológicos al efectuar los relevamientos o al producir y comunicar los requerimientos. Es decir, errores que afectan a todos y cada uno de ellos porque son fallas de los procedimientos, de la metodología o de las personas involucradas en su producción.

Me mencionaron alguna vez el caso de una empresa en la que los requerimientos llegaban en forma de gráficos perpetrados en un lenguaje pseudo-uml que ningún programador entendía. Finalmente, lo único útil del documento era el nombre del analista. Se fijaban quién era, lo llamaban y (si estaba disponible) le preguntaban qué había que hacer. Pero el problema era que esta charla informal no tenía ningún soporte ni revisión dentro del circuito de desarrollo, y usualmente los requerimientos se… digamos…. “modificaban” durante su transmisión. ¡Un fin de semana largo y su consecuente amnesia podía redefinir sustancialmente el proyecto!

Nótese que en presencia de este tipo de problemas las sucesivas iteraciones pueden alejarnos más y más de lo que el cliente quiere, porque el canal de comunicación entre él y el equipo de desarrollo está roto o tiene demasiado ruido. En nuestro ejemplo, ruido en la forma de dibujos incomprensibles pasados como requerimientos. Más valdría, por ejemplo, formalizar esas “charlas” como una instancia de elaboración de un documento simple y que todo el mundo entienda, tal vez directamente en idioma coloquial y con algunos dibujos hechos a mano.

Si tenemos contacto asiduo con el cliente (deberíamos), los problemas se notarán más temprano que tarde. Él mismo indicará claramente (muy) que no está recibiendo lo que pidió. Pero imaginemos que no sabemos nada del origen de esta discordancia. Puede venir por el lado de los requerimientos, pero no lo sabemos.

De alguna manera hay que medir, al menos aproximadamente, la calidad del proceso de relevamiento y la de los requerimientos mismos. Esto implica analizar, para alguna muestra relevante:

• el ajuste con respecto a la solución finalmente implementada. ¿Estamos contactando a las personas correctas en el cliente?

• el ajuste respecto a lo que el cliente o sus representantes expresaron. ¿Los clientes son bien interpretados?  

• el grado de claridad o precisión que le asignan los desarrolladores (que son finalmente los consumidores de esos requerimientos). ¿Los requerimientos están bien redactados o presentados?

• el grado de ajuste de la herramienta de soporte o metodología utilizada. ¿Es fácil producir un soporte estable para cada requerimiento? ¿Ese soporte los altera de alguna manera? Recordemos que por más ágiles que seamos, deberemos almacenar por lo menos los requerimientos en curso sin que sean modificados (involuntaria y/o inadvertidamente) de manera que alguien pueda consultarlos con seguridad ante alguna duda.

• La calidad del análisis efectuado sobre cada uno. ¿Se detectaron interacciones con otras partes del sistema? ¿Se evaluó bien la coherencia del requerimiento?

El problema está en encontrar indicadores para estas mediciones, ya que me parecen bastante… sutiles.

Por ejemplo, es “normal” que algunas interacciones entre nuevos requerimientos y otras partes del sistema no sean detectadas, ya que el análisis análisis previo es breve y a grandes rasgos. Pero otras interacciones son obvias y que sean pasadas por alto es significativo.

Por otro lado si somos muy ágiles y prima la comunicación informal, medir algunas cuestiones implica “muy poco indirectamente” medir el desempeño. Necesariamente habrá que preguntar “¿Se entiende cuando ZZZ explica lo que hay que hacer?” y esto generaría una recelo excesivo.

Es todo cuestión de encontrar las preguntas… qué novedad.

eXtreme Programming es un arma peligrosa.

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.

El costo del cambio (parte II)

La primera parte (que recomiendo leer antes de seguir) de este artículo, comenzaba el comentario del libro de Kent Beck, Extreme Programming Explained presentando la curva de "costo del cambio" a través del tiempo, y finalizaba proponiéndonos imaginar cómo afectaría al desarrollo de un proyecto el pensar en una curva aplanada o asintótica. ¿Cómo desarrollaríamos? ¿qué factores tendríamos en cuenta en nuestras decisiones? ¿cómo diseñaríamos?

Decir que esa curva es aplanada, implica que el software puede modificarse indefinidamente sin perjudicar su calidad. El costo aumenta ya que -siguiendo las teorías "tradicionales"- cada modificación introduce errores, cierta incoherencia y complejidad al sistema, lo torna cada vez más difícil de entender, aumentando las horas/hombre necesarias para llevarla a cabo. Por otro lado están los costos de modificar un sistema en producción, y sobre todo los riesgos que ello implica. Bien, todos esos terrores desaparecen en nuestro nuevo mundo. Lo mismo me cuesta modificar el sistema hoy que hacerlo mañana.

Aclaremos antes de seguir que utilizamos "cambio" en un sentido amplio, que implica no sólo cambios en el software, sino en la planificación, en el diseño y en la conformación del equipo de trabajo. Ahora sí, ¿cómo nos afectaría esta nueva curva?

En primer lugar, diseñaríamos y planificaríamos "para hoy", ya que no tiene caso adelantarse en el horizonte, gastando más en planificar hoy lo que, de ser necesario, podremos planificar mañana al mismo costo. Y de esta manera no enfrentaríamos el riesgo de que cambios en el negocio o en las tecnologías tiren nuestra planificación y diseño por la borda.

Entregaríamos cada funcionalidad completa en su forma más minimalista, y trabajaríamos sobre los comentarios y propuestas del usuario, que mientras tanto podrá utilizarlo tal cual está, ya que si bien es probable que tenga mayores costos por modificar el sistema en producción, éstos no irán creciendo, y no superarán el riesgo de desarrollar a espaldas de la supervisión del cliente.

Eso en cuanto a nosotros. ¿Y al cliente, cómo lo afecta esta nueva perspectiva?

El punto más interesante es que desde este nuevo punto de vista los cambios en el negocio que afecten al sistema en desarrollo ya no son amenazas sino oportunidades. Cada cambio en la dirección del viento provoca movimientos que el cliente puede aprovechar para incorporar al sistema y adaptarse más rápido que sus competidores. El cliente tiene un sistema funcionando -porque hemos entregado temprano y mínimo-, y un equipo de desarrollo en marcha y dispuesto a cualquier giro brusco, ya que no tiene demasiado invertido en costosos planes para el futuro.

Cualquiera que haya trabajado en una PyME reconocerá en todo o parte esta forma de trabajar o de ver las cosas, más o menos explícita. Talvez intuya en los párrafos anteriores los clásicos requerimientos sorpresa de una semana a otra que hacen que de repente todo el mundo esté trabajando "en otra cosa". De hecho esta es la clásica ventaja competitiva de la PyME frente a, por ejemplo, las grandes consultoras para las cuales cada proyecto implica el movimiento de un ejército de analistas, diseñadores, programadores, etc., y en general una abultada factura.

En este planteo estas prácticas no son automáticamente tildadas de poco profesionales y desorganizadas. Si estos conceptos se han "pegado" es porque manejar el nivel de cambio del que hablamos es terriblemente más difícil que vivir en un ambiente calmo y estático creado por requerimientos inamovibles y diseños absolutistas... El problema es que esos ambientes son imaginarios, y tienden a explotar dejándonos frente a la cruda realidad: el negocio cambió y los requerimientos son diferentes, las nuevas tecnologías han vuelto obsoleto al diseño, y la realidad ha ridiculizado las planificaciiones.

La dificultad para mantener la organización en medio del cambio continuo puede hacer que la rueda gire fuera de control rápidamente y la curva del costo abandone su reciente placidez buscando de nuevo el techo del gráfico. Cuanto más rápido cambiemos más rápido puede desbocarse el proyecto, si no llevamos al mismo tiempo un estricto control sobre las formas de implementar esos cambios.

Volvemos a las PyMEs. ¿Control y organización para el cambio? Bueno, eso sí suena como una utopía. Pero recordemos la primera parte de este artículo: las herramientas han mejorado enormemente, nuestra comprensión de los procesos de cambio ha mejorado, y no es imposible para una empresa pequeña contar con la tecnología y sabiduría necesarias para llevarlo a cabo.

De todas maneras, ¿existe realmente otra posibilidad? No creo que estemos hablando de una opción. Una consultora puede perder un cliente, un proyecto. Puede darse el lujo ocasional -si bien doloroso- de salirse del presupuesto para enfrentar el costo de un cambio no previsto. Y así y todo son mayoría las consultoras -si no todas a este punto- que han adoptado algún tipo de metodología ágil para muchos de sus proyectos. Es decir, el manejo del cambio ya no es siquiera, como hasta hace algunos años, una ventaja competitiva, sino una característica necesaria para sobrevivir.

En la tercera parte repasaremos brevemente el cómo según Kent Beck (pero no demasiado, ya que él lo hace mejor que yo) y buscaremos un punto intermedio entre los cambios radicales que propone y las "metodologías tradicionales".

El costo del cambio (parte I)

Hace un par de entradas recomendé el libro de Kent Beck, "Extreme Programming Explained". Tuve que releer los primeros capítulos en vistas de una clase que tenía que dar sobre "Modelos de desarrollo", en el marco de la Materia "Construcción de Aplicaciones Informáticas" de la Facultad de Ciencias Económicas (UBA).

Lo de arriba no es sólo autobombo (que hay algo de eso, por qué no), sino que quiero subrayar que, dado que el marco es el de las ciencias económicas, me centré exclusivamente en esos aspectos de las bases de la metodología que plantea Kent Beck.

Tuve al releerlo la misma impresión que cuando lo hice por primera vez. Comencé un poco distraído, pero el libro fue atrayendo toda mi atención hasta llegar al capítulo 5, "Cost of Change", después del cual tuve que dejar de leer. Para cualquiera (no demasiado joven) dentro del ambiente de desarrollo de sistemas, ese capítulo se siente como un mazazo que rompe con todo lo aprendido hasta el momento. Voy a comentarlo.

Empieza con un grafiquito muy simple y simpático que todos los que transitaron por alguna facultad recordarán:

Es decir, lo que todos sabemos: el costo de un cambio (actualización, corrección, mejora, lo que sea) crece desde el diseño hasta la puesta en marcha y desde allí se dispara dramáticamente.

Claro, si estoy en diseño y veo la nececidad de cambiar la relación entre dos tablas de la base de datos, el costo de corregirlo será el de un par de minutos con el programa de diseño que esté utilzando para crear el modelo. Si tengo la misma necesidad, pero la base de datos está en producción, llena de registros vitales para el cliente, talvez geográficamente muy lejana, los costos en tiempo y dinero son incomparables.

Por eso la obsesión por la perfección en las primeras etapas del desarrollo, muy marcada en las metodologías tradicionales: los requerimientos deben ser completos, el modelo debe ser perfecto, los programadores deben seguirlo al pie de la letra, tratando de arruinarlo lo menos posible. Como en general no son (somos) gente muy capaz, cometerán (cometeremos) un sinnúmero de errores que nos (les) costarán (¡a uds.!) muchísimo dinero. Así que hay que gastar mucho (pero menos que muchísmo) en testers, control de calidad posterior al desarrollo, y también en estrictos métodos formales de control de la "producción" (la codificación)... me pregunto por qué nunca se puso de moda "debemos gastar mucho dinero en prestaciones para atraer a los mejores prospectos, formación para tener a los mejores programadores y en sueldos altísimos para que se queden con nosotros" si el principio es el mismo (aunque hay que reconocer que estamos mucho mejor que antes).

Se nos ha enseñado que el software se degrada naturalmente con el mantenimiento y las modificaciones, que nuestro esfuerzo de buenas prácticas, claridad, simplicidad y código mantenible es una utopía a la que debemos tender para maximizar el rendimento pero irrealizable por definción, y que el software, como cualquier otro producto, se gasta con el uso y muere.

Pero ese dibujito es largo más viejo que yo. Está basado, me imagino (aunque no lo sé realmente), en los sistemas de producción fabril de donde se derivaron las primeras metodologías para el desarrollo de software. En un principio el desarrollo de software se encuadró en el modelo de desarrollo de cualquier producto, por ser el único que existía: la planificación de la producción, alegoría para la modelización de un sistema, es más valorado (personal de cuello blanco) que la construcción física del producto (obreros de cuello azul), la fábrica, la cadena de montaje, Tiempos modernos y todo eso, alegoría de la codificación del sistema.

Kent Beck plantea (y yo estoy de acuerdo, con matices) que si alguna vez eso fue cierto ya no lo es. Para ponerlo en sus propias palabras:

The software development community has spent enormous resources in recent decades trying to reduce the cost of change—better languages, better database technology, better programming practices, better environments and tools, new notations. What would we do if all that investment paid off? What if all that work [...] actually got somewhere?

Tenemos computadoras con las que podemos compilar enormes sistemas cuantas veces querramos sin costo, programación orientada a objetos, administradores de bases de datos, entornos que nos ayudan a modificar dramáticamente la estructura del sistema con relativa facilidad. Tenemos redes de altísima velocidad, administración remota de equipos, podemos trabajar prácticamente en cualquier lugar del planeta sin movernos de casa.

De hecho esas técnicas ya ni siquiera pueden calificarse de novedosas. Son las que han difundido la computadora fuera de los ámbitos específicos de la profesión y la han convertido en una herramienta de uso común para cualquiera, al permitir una complejización del software inimaginada hace un par de décadas.

¿Y si de repente nos diésemos cuenta de que aquellas teorías sobre las que descansa nuestra forma de pensar el desarrollo de software en realidad son producto de una mirada obsoleta sobre la tecnología y nuestras propias capacidades? ¿Y si este gráfico estuviese al alcance de nuestras manos?

Termino con algunas preguntas: si pudiesemos cambiar el rumbo del desarrollo de un sistema a medida que avanza sin costos exorbitantes, ¿cómo desarrollaríamos? ¿qué factores tendríamos en cuenta en nuestras decisiones? ¿cómo diseñaríamos?

Hasta la segunda parte.

Actualización: segunda parte.

La autopista del desarrollo

De la misma manera en que necesitamos imágenes o alegorías para comprender los sistemas o alguna de sus partes necesitamos una buena imagen de cómo es el proceso de desarrollo. Un concepto más fácil de atrapar y de entender que un paper de buenas prácticas o un libro acerca de alguna nueva metodología. Me tomo muy en serio las frases graciosas al estilo

"Codifica siempre como si la persona que finalmente mantendrá tu código fuera un psicópata violento que sabe dónde vives." (Martin Golding)

porque son más fuertes que un aburrido sermón de media hora sobra por qué tenemos que ser prolijos y claros y etc. etc. etc..

Para el desarrollo de software, la clásica es "la fábrica". El equipo de desarrollo es una "fabrica de software". Entonces entran los requerimientos, vienen los analistas que hacen algo con ellos, se lo pasan a los programadores que hacen otra cosa, que se la pasan a los testers que la prueban y a los de soporte o como-se-llamen que la instalan y el cliente que la usa. Una línea de montaje. Si bien no está tan mal, no me gusta del todo.

Me gusta la idea del desarrollo de software como un viaje en auto. Lo leí por primera vez en "Extreme Programming Explained" de Kent Beck (que recomiendo sobremanera), y siempre me ha quedado dando vueltas en la cabeza. El libro está lleno de imágenes poderosas y es por eso que los conceptos centrales son inolvidables, más allá de que uno esté de acuerdo o no con ellos.

La idea es: todo el equipo de desarrollo está viajando junto con el cliente desde los requerimientos hasta la implementación. Algunos en su propio auto, otros van de a dos o tres, unos van más rápido y otros más lento, pero tenemos que llegar todos.

Primero está el deseo de ir a algún lado. Requerimientos.

Después pensamos "¿podemos ir?". Yo quiero ir a Madrid el mes que viene, me gusta mucho Madrid. Pero desgraciadamente no lo veo muy posible, por lo menos para el mes que viene. Tenemos entonces el estudio de factibilidad.

Después pensamos qué necesito para llegar. No alcanza con decir "salimos mañana". Necesito un auto, dinero, combustible, tal vez un mapa, tengo que hacer la valija, cosas comunes para cualquier viaje. Quiero saber cuándo salimos y cuándo llegamos, y también cuánto me va a costar la gracia. Así que planeamos.

Entonces nos ponemos a pensar en la ruta. Un poco de eso lo hicimos en la etapa anterior, pero ahora agarramos el mapa y nos ponemos a ver en detalle por dónde vamos a ir, si nos conviene tal o cual camino, cómo nos distribuimos en los autos, etc. Diseñamos.

Y llega el día de la partida. Alguno se queda dormido, y llega justo para salir. Otro tuvo un contratiempo y nos alcanza a mitad de camino. Otro decidió que no, que mejor me quedo en casa. Los demás estamos ahí con las valijas en la mano, y los motores en marcha. Miro la valija de mi muy presentable compañera de viaje (¿ven que la planeamiento y el diseño son importantes?). Está muy preparada y me empiezo a dar cuenta de todo lo que me falta. Mejor no pensar en eso. De alguna manera voy a llegar... a algún lado.

Y empieza el viaje y empiezan los problemas. Porque hay un atasco por allá, así que hay que decidirse, ¿nos abrimos o aguantamos? ¿y si cortamos por ese descampado, no iremos más rápido? Que no que mejor vamos por acá, sigamos la ruta, que es lo más seguro.

Que pinchamos, suerte que tenemos rueda de repuesto... te dije que necesitábamos una rueda de repuesto, me dijiste que la conseguías, ¿cómo que había que abaratar? ¿cómo que para mañana? Al final gastamos más y tenemos que esperar.

Que tengo hambre, calor, frío, sueño. Yo así no sigo. No importa, conductores hay por todos lados. Sí, pero ninguno va a querer viajar así. Que vas a ver que alguno que recién aprende se muere de ganas de manejar. Bueno...

Obviamente las cosas no son como las planeamos y diseñamos. Pero no lo hicimos mal, simplemente las cosas nunca son como las planeamos. Por suerte planeamos pensando en eso, ¿no? Ah, ¿no? Ups...

Y el viaje sigue. Algunos manejan mejor y otros peor. Pensemos un poco en eso. Hay distintos tipos de conductores. Están los que respetan a rajatabla todas las normas y carteles. Son capaces de desbarrancarse por hacerle caso a un cartel que estaba dado vuelta. Están los temerarios que zigzaguean entre los vehículos a toda velocidad. Expertos conductores, siempre les sale bien. Está el que habla por celular, escucha música a todo lo que da, mira el paisaje y cada tanto le presta un ojo a la ruta. Está el que va atento a todo, esperando lo inesperado.

Que cada uno valore positiva o negativamente a cada tipo de conductor según su propio criterio. Yo sigo presentando mi opinión, abierto al debate:

Al manejar hay que confiar en ciertas reglas básicas. Cada uno debería seguirlas y confiar en que los demás las siguen también. No puedo frenar siempre por las dudas, aunque el semáforo está en verde. Tengo que creer que el que lo tiene en rojo va a frenar. Sin embargo hay que estar atento en los cruces. Hago señales, que todo el mundo sepa qué es lo que voy a hacer. Sin embargo, alguien más puede estar distraído, así que me aseguro de que me hayan visto. Y así con todo.

En un equipo de desarrollo, el que no sigue las reglas se vuelve peligroso, para él y para los demás. Todos cometemos errores, e incluso todos violamos alguna norma de vez en cuando, a sabiendas. Pero es una cuestión de grados. No es lo mismo el que deja código medio enrevesado dentro de un módulo, sabiendo que no está muy bien, pero que por lo menos está encerrado ahí, que el que para resolver un problema te pone 20 variables globales y hace un nudo que madre de dios. Y no es lo mismo hacerlo y avisar que hacerlo y ocultarlo. Hay cuestiones en un integrante de un equipo de trabajo que lo vuelven extremadamente peligroso, por ejemplo:

• No respetar los acuerdos sin avisar. Vamos a hacer esto de esta manera, ¿ok? Éste es el momento de estar en desacuerdo, o de plantear problemas. Luego, hay que hacerlo así, o avisar que no podemos, pero no hacerlo de otra manera, o no hacerlo en lo absoluto.
• No utilizar el mismo lenguaje que el resto. Claro, si uno quiere decir "A" pero dijo "a" es parecido, pero no es lo mismo, y los malentendidos son terribles. No hay que tener vergüenza de usar el dedo. Cuando no sabemos el nombre de algo, lo apuntamos con el dedo y decimos "esto", pero no lo cambiamos por otro nombre.
• El individualismo llevado al extremo. Yo hago las cosas a mi manera ¿ok? Y lo que a mí me importa es que mi trabajo esté a tiempo y forma, me pongo las anteojeras (como la de los caballos, ésas para no ver a los costados) y le doy para adelante. No está tan mal, salvo que se combine con el primer punto ("digo a todo que sí y después hago lo que quiero"). Hay que defender lo que uno cree, estamos de acuerdo, pero si los demás no lo ven a nuestro modo, hay que adaptarse, con quejas, malhumor, lo que sea, pero adaptarse. Y si no nos podemos adaptar, hay que irse. Seguramente hay otras personas que harán las cosas a mi manera o que se adapten a mí, es cuestión de encontrarlas. Pero si me quedo me vuelvo peligroso.
• Encubrir los problemas, por cualquier motivo.

No se me ocurren más por ahora. Acepto sugerencias. Pero notemos que son cuestiones que no hacen a la idoneidad. Hasta el más principiante desarrollador puede evitar esas actitudes. Son temas que giran alrededor de lo más importante en un equipo de desarrollo: la comunicación. Digo lo que voy a hacer, hago lo que dije que iba a hacer. Las reglas básicas del desarrollo de software tienen que ver con facilitar la buena comunicación entre los miembros del equipo, o por lo menos con no bloquearla.

Cuando la comunicación es buena, surge algo que es maravilloso en un equipo: la confianza. No confianza en que "todo va a salir bien" ni en que "fulano podrá resolverlo". Confianza en saber qué es lo que está pasando, y en saber, o enterarme a tiempo, cómo es que van a reaccionar los demás. Confianza en que no me va a caer un piano en la cabeza (a menos que pase por donde dice "no pasar"). Si X es un apurado que quiere resolver todo de cualquier manera, pero lo dice, y sobre todo acepta cuando se le dice que no lo haga, está ok. Muchas veces es necesario resolver las cosas de cualquier manera. Si a Y no le interesa demasiado el proyecto, y sólo quiere que suene la hora para irse, pero lo dice, perfecto. Sé qué es lo que puedo esperar de él. Y tiene algo invalorable, la sinceridad. Si Z no puede con este problema, pero avisa a tiempo, vemos qué es lo que hacemos.

Tenemos que convivir con los temerarios y con los que van a contramano. Y encima tenemos que vivir con nuestros propios errores, miserias, días malos y demás. Como en un viaje, desgraciadamente no alcanza con manejar bien y estar atento, porque siempre puede venir un loco a 200 por hora, y eso es inevitable. Pero podemos prever y controlar los daños. Siempre hay uno que puede introducir un virus mirando pornografía en el trabajo. Pero si tenemos antivirus sería más raro que eso suceda. Hasta el administrador más avezado puede borrar una carpeta sin querer. Pero si él es el único que tiene permisos para hacerlo, y aparte hay backups periódicos, sería raro perder mucha información. Puede haber alguno al que lo único que le importa es decir que él llegó a tiempo, o que los retrasos no son su culpa, y ocultar el hecho de que para llegar antes entorpeció a todos los demás. Pero si el proyecto está bien armado cada uno trabaja sin poder molestar demasiado al resto (por más que quiera). Y así con todo.

La conclusión es que la imagen de manejar y el viaje es muy buena, y nos brinda directivas de conducta para cuando no sabemos qué hacer. Yo la uso, veo las cosas de esa manera, y funciona. Prueben.

Libros recomendados: Kent Beck. Extreme Programming Explained.

Extreme Programming Explained: Embrace Change. Addison-Wesley, 2000. ISBN 0-201-61641-6. Second edition 2005 with Cynthia Andres. ISBN 0-321-27865-8.

La biblia acerca de las metodologías "ágiles" de programación, tanto para desarrolladores como para líderes de proyecto, analistas, o cualquier interesado. Sus postulados rompen los axiomas más establecidos de las metodologías de desarrollo tradicionales. Estemos de acuerdo o no con sus postulados, es imprescindible conocerlos. El libro está excelentemente estructurado, es corto y muy ameno.