“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]
Este artículo fue publicado inicialmente en http://goo.gl/IuJIlY |
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: