Buscar en Gazafatonario IT

jueves, mayo 08, 2014

Cultura Ágil, ese oscuro objeto del deseo

“El ingeniero de software aficionado siempre está a la búsqueda de algo mágico, algún método o herramienta sensacional que prometa convertir el desarrollo de software en algo trivial. Está en el ingeniero de software profesional saber que no existe tal panacea”.

[Grady Booch, Object-Oriented Analysis and Design]
Cultura Ágil, ese oscuro objeto del deseo
Este artículo fue publicado inicialmente en http://goo.gl/IuJIlY
Vivimos en una era de ofertas pero también de riesgo. ¿Qué tipo de productos queremos que usen nuestros clientes? La filosofía ágil está modificando a pasos aumentados el statu quo del desarrollo del software, con nosotros a bordo o sin nuestra participación. El interrogante es cómo y hasta qué punto seremos capaces de dar el salto hacia lo que ya está aquí: la cultura ágil.

El pronóstico que genera más suspicacia alrededor de la transformación hacia ágil es que va a dividir la comunidad de desarrolladores entre quienes tendremos éxito y quienes no lo tendrán, entre personas felices y personas desventuradas, y entre personas que tendrán una vida (o que volverán a tenerla) y personas que no; y que también fragmentará la gama de usuarios del software entre personas satisfechas y personas insatisfechas: será una segregación ágil. Este movimiento ágil que vive la ingeniería de software brinda la promesa de mejorar las vidas de quienes trasegamos por sus laberintos, pero también entraña la amenaza de segregarnos.
¿Pero a qué viene esta evolución hacia ágil? Primero, se trata de abandonar esa visión microscópica ampliamente difundida de la gestión de proyectos clásica de “comando y control”, enfocada en el cumplimiento de tiempos e hitos intermedios que muchas veces no tienen nada que ver con el producto y mucho menos con el cliente, de proyectos que solo son “vistos” a través de herramientas y procesos predictivos, y comenzar a mirarlos con los ojos del cliente, con el lente del Valor del producto para el negocio, y de las entregas continuas de producto con calidad.
Quienes llevamos ya algún tiempo construyendo software, cargamos en nuestro ADN aquel precepto de Deming de que la calidad de los productos depende en gran medida de la calidad de los procesos que se usan para crear y mantener esos productos. También llevamos a cuesta modelos de gestión de proyectos tipo “Comando y Control” y modelos de ejecución de procesos prescriptivos como CMMI, PMI, COBIT y los incontables ISO numeral.
Ninguno de estos modelos habla de las personas y sus interacciones ni de la trama del producto, ni del impacto que el producto debe generar en quien lo usa y de lo confortable y apoyado que debe sentirse este usuario con ese producto; y tampoco habla de la calidad y de la naturaleza del comportamiento de las personas que construimos el producto. De esto también se trata la cultura ágil.
En la práctica, es posible combinar métodos ágiles con Arquitecturas Orientadas a Objeto o Patrones de Diseño y con Principios de Ingeniería como Historias de Usuario o Casos de Uso 2.0 y Test Driven Development (TDD) o Behavior Driven Development (BDD), para crear productos grandiosos, que tengan “alma”, que tengan argumento, es decir, que sean significativos para el usuario, que le digan algo y que en algún momento del tiempo cambien su estilo de vida.
Ahora bien, estos métodos ágiles, con Scrum a la cabeza, no tienen por qué entrar en conflicto con otros modelos o enfoques de construcción de software, no es la idea de ser ágil o, al menos, no está en el flujo de un proceso de transformación a ágil echar tierra a las prácticas existentes en una organización. Los líderes de los procesos actuales deberían trabajar en conjunto con los nuevos líderes para que estos últimos obtengan los beneficios de ambos universos y aprovechar esa sinergia para mejorar dramáticamente el rendimiento del negocio.
Esto se puede lograr poniendo en práctica algunos de los principios de Lean Software Development, o simplemente Lean. Estos principios, originados en el enfoque de manufactura lean de Toyota, constituyen una filosofía de gestión de procesos ampliamente aceptada en la comunidad ágil y buscan eliminar las entregas tardías tan comunes hoy en los proyectos de software, lo mismo que eliminar cualquier desperdicio, como código y funcionalidad innecesarios, requisitos poco claros, pruebas insuficientes que conducen a una repetición del proceso, al igual que la burocracia y la lentitud en la comunicación interna.
Ser ágil también es aceptar que los proyectos complejos (léase proyectos de TI) están sujetos a cambios, a redefinición de alcance y a oscilaciones en la priorización de los requisitos. Para ser ágiles debemos planificar para el cambio, trabajando a la sombra de un proceso que entienda esto. Ágil también nos puede proporcionar “estimaciones” de costo, o “estimaciones” de tiempo, pero los métodos ágiles son más honestos y nos abastecen con entregables de mejor y mayor valor mucho antes que un proceso “No-ágil”. En breve, ser ágil quiere decir reemplazar la predictibilidad falsa por la eficiencia.
Ser ágil también es acerca del equipo. Los equipos ágiles nos enfocamos en validar continuamente nuestras hipótesis y generar valor lo antes posible. Sabemos que esta es la base para equipos de alto rendimiento que enfrentan alta incertidumbre, como la presente en los proyectos de software. En estos equipos cambiamos la planificación basada en especialidades por un enfoque en la propagación de conocimientos, de experiencia. Además, en los equipos ágiles invocamos continuamente energías innovadoras para encontrar formas mejores de aumentar la productividad y el entusiasmo de los participantes.
Más allá de todo esto es importante entender que los procesos ágiles como Scrum se basan en el empirismo, lo que quiere decir que durante el proyecto aprendemos por Observación en vez de por predicción, es decir, de la experiencia y constantemente nos estamos adaptando para reencausar el proyecto si detectamos variaciones que pueden obstaculizar la consecución de los objetivos trazados.
Finalmente, en el camino hacia ágil hemos aprendido que el compromiso de cambio debe ser colectivo, que la meta de una organización ágil no es el uso del método sino el resultado: mejores equipos, individuos motivados, mayor valor de negocio entregado, moral más elevada, clientes felices, más que satisfechos, y mejores productos.
Esa es nuestra naturaleza, esa es la razón por la que estamos aquí. 
¿Quieres saber más?
Para saber más sobre Lean Software Development, visita el sitio de Mary & Tom Poppendieck: http://www.poppendieck.com/
Para saber más sobre Ágil y Scrum puedes leer estos artículos en mi Gazafatonario:



La Presentación

En este enlace puedes descargar la presentación basada en el artículo: