Introducción

En esta serie de artículos trataré de ser lo más sintético posible para no aburrir con la lectura.

Voy a escribir sobre hechos que he vivido y personas con las que he tenido el honor de interactuar, trabajar y aprender.

La intención de escribir estos artículos no es abrir un debate. Tomando al Martín Fierro (1) diré que lo hago porque creo, con toda humildad, que “si hablo de este modo por encontrarlo oportuno, no es para mal de ninguno, sino para bien de todos”.

Resumen del Capítulo Uno: Génesis

En la entrega anterior escribí sobre la génesis de Agile (ágil) y agility (agilidad) que se dió en el marco del USA DoD/NSF Agility Forum en la Universidad de Leihigh en 1990 ante la necesidad de, tomando como base la teoría general de los sistemas aplicada a las empresas, identificar un problema emergente que fuese común y fuese clave para competir en el futuro (un horizonte de 25-30 años hacia adelante) y que se convertiría en el siguiente diferenciador, ya que una vez que Lean (15) se difundiera y se utilizara ampliamente dejaría de ser un diferenciador. Es decir, Agile nació como alternativa superadora a Lean.

En este capítulo escribiré sobre “el Mundo Paralelo” que se estaba desarrollando con el mismo fin: pensando en el cliente, cómo generar los productos con la calidad esperada para agregar el valor esperado y de esta forma diferenciarse para alcanzar los objetivos básicos de supervivencia, crecimiento y desarrollo.

Mundos Paralelos.

Sin intención de meterme con la historia de las computadoras, me permito decir que considero que la primera computadora apta para el uso comercial aparece entre 1950 y 1957. Pero es con la llegada de los lenguajes de programación, allá por 1960, dónde comienza a visualizarse a la computadora como herramienta para resolver el problema que se generaba en el ámbito empresarial debido al trabajo intensivo de realizar cálculos generalmente ligados a la administración de los negocios. Esos cálculos convertían datos en información que era clave para la toma de decisiones.

Las personas que trabajaban en los centros de cómputo entendían los cálculos (o al menos lo intentaban) y generaban una solución basada en software que los realizaba eliminando el trabajo intensivo.

Durante muchos años, quizá hasta mediados de los 80, el usuario final, el que esperaba recibir el resultado de los cálculos, no tenía posibilidad de interactuar con la máquina o, si lo hacía, solo podía ver el resultado final. Para utilizar una palabra de moda, hasta mediados de los 80, el usuario final no podía ser “empoderado” ya que el estado de la informática en su conjunto no lo permitía. Y los resultados obtenidos, la mayoría de las veces, no eran los esperados.

Por aquel entonces se escuchaban dos “frases célebres”: el usuario final decía “nunca recibo lo que necesito” y el personal del centro de cómputos decía “el usuario nunca sabe lo que quiere”. En definitiva, a diferencia de lo que pasaba con otros productos, en líneas generales no se lograba cumplir con los conceptos básicos de calidad. Al menos con entregar “lo que se espera y es apto para su uso” desde la percepción del usuario final.

El grupo de los trabajadores de los centros de cómputo que se dedicaba a generar los productos de software eran conscientes de que esa “grieta” entre lo que se obtiene y lo que se espera debía ser cerrada porque de esta forma no se liberaba el valor esperado. Comenzaron a pensar de qué manera, con los recursos informáticos disponibles, se podía imitar las mejores prácticas relativas a la calidad que se utilizaban en otros dominios tales como la manufactura. Y comenzó a tomar fuerza la idea de incorporar prácticas de la ingeniería para crear productos de software enfocados en liberar valor para el cliente final a través de lograr el nivel de calidad necesario.

Empezaron a descubrirse “nuevas formas de desarrollar software” a través de diferentes ciclos de vida (cascada, espiral, iterativo, etc.,) y nuevos métodos a partir de esos ciclos de vida (por ejemplo, Desarrollo Rápido de Aplicaciones, RAD (2) en inglés).

Acá una simple reflexión al margen. Se confunde ciclo de vida secuencial (sequential) con ciclo de vida cascada (waterfall) y este último se ha ganado muy “mala prensa”. Humildemente recomiendo buscar la publicación original de Royce (3) porque creo que muchos van a sorprenderse. O al menos, muchos dejarán de “pegarle palos” al ciclo de vida en cascada esgrimiendo razones muchas veces sin sustento y perdiendo oportunidades al utilizar otros ciclos de vida que no se ajustan al proceso de generar la solución esperada.

Nace la OOSPLA.

Cómo se sabe, la intención primaria de generar un producto de software es realizar modelos de la realidad. Ya muy temprano, allá por el año 1967, se comenzaron a generar leguajes de programación que permitieran modelar la realidad representándola a través de objetos, dónde los objetos son entidades que poseen comportamiento y características. Esta posibilidad, sumada a la evolución que había hecho la informática hacia las interfaces gráficas, las computadoras personales y los dispositivos tales como el ratón (mouse), permitió acercar al usuario final con los programadores para achicar la brecha que permitiera mitigar el “nunca obtengo lo que necesito” y “el usuario no sabe lo que quiere”. Es decir, todo lo relacionado a la orientación a objetos aparecía, sin duda, como la respuesta a la búsqueda de “nuevas formas de desarrollar software” con foco en el cliente.

En 1986 se realiza la primera conferencia de OOPSLA (4) (Programación, sistemas, lenguajes y aplicaciones orientados a objetos) que se llevó a cabo en Portland, Oregón. OOPSLA era una conferencia anual de investigación creada por el Grupo de Interés Especial para Lenguajes de Programación (SIGPLAN) que pertenece a la Asociación de Maquinaria de Computación (ACM) y fue la usina de todo lo relacionado a Agile y agility.

Ahí se debatía, se trabajaba, se vivía todo aquello que se visualizaba cómo el futuro de la generación de productos de software porque como alguien predijo en aquellos días “en el futuro, todas las empresas y organizaciones, sin importar el dominio en el que actúen o el producto o servicio que ofrezcan, serán empresas de tecnología y software”.

Todos aquellos que tuvimos la oportunidad de participar estábamos “codo a codo” con aquellos que hoy son considerados “cellebrities” del mundo Agile. Y todas esas personas estaban interesadas en la retroalimentación para aprender y mejorar y escuchaban y debatían cada punto que les acercábamos.

En la OOSPLA se generaron muchas de las cosas que son la base de todo lo que hoy se utiliza. Y pasar esto por alto, es el peor error que se puede cometer, en mi humilde opinión. Si me permiten, recomiendo enfáticamente leerlos. Cito algunos que me parecen un hito:

• Tom Gilb, considerado “el padre” de Agile, presenta su método EVO (5) mostrando el próximo paso hacia la creación de productos de software con foco en el cliente.
• Mary y Tom Poppendieck presentan “Lean Software Development” (6) que produce “un antes y un después” en los métodos de construcción de productos de software tomando las prácticas de calidad de “Lean Manufacturing” (15).
• Alistar Cockburn presenta “Crystal Clear” (7). Ahora que tanto se habla de mindset, equipos auto-administrados, etc. Alistar presentó en ese momento una posible solución al complejo mundo de generar equipos orientados a la utilización del enfoque ágil. Y funciona.
• James Coplien presenta “Patrones Organizacionales para el Desarrollo de Software Ágil” (8) mostrando que ágil es un tema de estructura (arquitectura) organizacional, ya que las organizaciones son sistemas abiertos y adaptables y que, adaptando la cita del gran Ortega y Gasset, “uno es uno y su circunstancia”.
• Rebecca Wirfs-Brock presenta el Diseño Basado en Responsabilidades (9) que es la base de varios de los temas que hoy se consideran casi un “estándar de facto”, tales como las historias de usuario (user stories).
• Ken Schwaber presenta SCRUM (10) (dicho sea de paso, si buscan el paper de la primera versión verán que es casi “irreconocible”) un método que se había desarrollado y probado junto con Jeff Sutherland con el aporte de Mike Beedle.
• Kent Beck, que ya había revolucionado el mundo de los métodos colaborativos presentando XP (11), presenta TDD (12).
• Durante la conferencia del año 2000, después de mucho debatir y sostener posiciones, los que luego se reunirán para crear el “Manifiesto por el Desarrollo Ágil de Software” (13), se ponen de acuerdo en unir esfuerzos y compatibilizar enfoques y visiones porque al final del día, como ellos mismos dijeron, tenían un objetivo común: darle al cliente lo que el cliente necesita.

Y sin duda estoy dejando de lado muchos otros hitos pero sobre todo muchas otras personas que fueron clave en la creación y evolución de las “nuevas formas de desarrollar software” hacia lo que luego se denominó o etiquetó como Agile, entre otros Ivar Jacobson, Grady Booch, James Rumbaugh, Kenny Rubin, Adele Goldberg, Arie Van Bennekum, Ward Cunningham, Marin Fowler, Ron Jeffries, Steve Mellor, Dave Thomas y otros. Recomiendo buscar los trabajos de estas personas porque contienen las respuestas a la mayoría (por no arriesgar escribiendo “a todos”) los inconvenientes y desafíos que se presentan cuando se intenta utilizar Agile para la generación de cualquier tipo de solución, basada en software o no.

Y en el tema del Manifiesto, comentarios adicionales que me parecen clave para entender de qué se trata todo esto:

1. La palabra “software” aparece en el nombre por una razón. Si no, solo se llamaría “Manifiesto Ágil” y nada más.
2. Muchas veces se pasa por alto, no se presta atención, no se trata de entender el párrafo final de la enumeración de las razones del Manifiesto, que dice: “Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda”.
3. La mayoría de las veces veo que se pasa por alto, no se presta atención, no se trata de entender el apartado “Sobre el Manifiesto”, sobre todo su párrafo nueve que dice:

“El movimiento Agile no es anti-metodología, de hecho, muchos de nosotros queremos devolverle credibilidad a la palabra metodología. Queremos restablecer el equilibrio. Adoptamos el modelado, pero no para archivar algún diagrama en un repositorio corporativo polvoriento. Aceptamos la documentación, pero no cientos de páginas de tomos que nunca se mantienen y que rara vez se usan. Planificamos, pero reconocemos los límites de la planificación en un entorno turbulento. Aquellos que calificarían a los defensores de XP o SCRUM o cualquiera de las otras metodologías ágiles como "hackers" ignoran tanto las metodologías como la definición original del término hacker.”

Por qué es importante entender esto

Es importante porque la utilización de los conceptos Agile y agility en software siempre estuvieron totalmente de acuerdo con el origen que, como escribí en el capítulo uno de esta entrega, son el foco en la calidad y el cliente en el marco de la concepción sistémica.

Tomando en su origen las prácticas de la manufactura Lean (15) evolucionaron hacia encontrar formas que permitieran generar productos de software que alcanzaran y superaran las expectativas de los usuarios finales, aún aquellas inesperadas y no planificadas de antemano porque, como bien señala la primera ley de las “Leyes de la Evolución del Software” de Lehman (14), la conocida como “Ley del Cambio Continuo”, “Un programa que se usa en un entorno real necesariamente debe cambiar o se volverá progresivamente menos útil y menos satisfactorio para el usuario”. Es decir, al mismo instante que se entrega una solución ya está cambiando. Pero no solo la solución, cambia el sistema en su conjunto. Y Agile se trata no solo de reaccionar si no de tomar ventaja generando esos cambios. Al final del día, es la regla básica de los sistemas (sistemas, no solo sistemas-software). Por lo tanto, no tiene sentido pensar que la utilización del enfoque Agile en el software estuvo disociado del origen que se dio a nivel empresarial buscando una alternativa a Lean (15). O lo que es peor, en mi opinión, no tiene sentido intentar disociarlo buscando definiciones o explicaciones que intenten diferenciarlo del origen de alguna forma. Hecho que lleva al fracaso de cualquier intención de utilizar Agile para ganar en agility como estrategia para sobrevivir, crecer y desarrollarse.

Referencias

1. “El Gaucho Martín Fierro”, Martín Fierro - Wikipedia

2. Kerr, James M.; Hunter, Richard. “Inside RAD: How to Build a Fully Functional System in 90 Days or Less”. McGraw-Hill. ISBN 0-07-034223-7.

3. "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26 (August): 1–9.

4. Object-oriented Programming, Systems, Languages, and Applications (OOPSLA), Object-oriented Programming, Systems, Languages, and Applications (OOPSLA) (sigplan.org)
5. Gilb, Tom, "Evolutionary Development", SIGSOFT Software Engineering Notes. 6 (2): 17. ISSN 0163-5948

6. Poppendieck, Mary; Poppendieck, Tom. “Lean Software Development: An Agile Toolkit”. Addison-Wesley Professional. ISBN 978-0-321-15078-3.

7. Cockburn, Alistair, “Crystal Clear: A Human-Powered Methodology for Small Teams”  Addison-Wesley Professional ISBN 978-0201699470

8. Copilen, James O; Neil Harrison. “Organizational Patterns of Agile Software Development”, Pearson; ISBN-13 ‏ : ‎ 978-0131467408

9. Wirfs-Brock, Rebeca; McKean, Alan.  “Diseño de objetos: roles, responsabilidades y colaboraciones”, Addison-Wesley,  ISBN 0-201-37943-0

10. scrum.doc (jeffsutherland.org)

11. Beck, Kent. “Programación eXtrema explicada: Aceptando el cambio”. Addison-Wesley. ISBN 978-0321278654

12. Beck, Kent. “Desarrollo guiado por pruebas: Mediante Ejemplos”, Addison-Wesley., ISBN 978-0321146533

13.  Manifiesto por el Desarrollo Ágil de Software (agilemanifesto.org)

14. Lehman, Meir M. “Programs, Life Cycles, and Laws of Software Evolution”. Proc. IEEE 68 (9): 1060-1076.
15.  Womack, James P.; Jones, Daniel T.; Roos, Daniel (1990), “Machine that Changed the World”, New York: Rawson Associates, ISBN 9780892563500