Justificación Económica del Modelo Ágil

Mas allá de la justificación tradicional que tienen las metodologías ágiles, existe una justificación económica, que si bien es dificil de medir con exactitud, no debe ser obviada.

El modelo en cascada tradicional entrega valor al usuario recién a partir de la publicación de la versión 1.0 o su equivalente. Esto ocurre cuando el producto está terminado, fue testeado en su completitud y fue aceptado por el usuario. Para llegar a este punto, han transcurrido seguramente varios meses. De hecho, debe haber finalizado el proyecto, o encontrarse en una instancia de transición o algo similar.

En el modelo ágil, se realiza una entrega temprana, pudiendo validar las expectativas del usuario, pero sobre todo, pudiendo transformar el producto de software en una pieza que, si bien incompleta, ya puede ser utilizada, y por lo tanto, comenzar a entregar valor. Obviamente, es de vital importancia detectar no sólo las dependencias con otras funcionalidades (no tiene sentido entregar un auto sin motor, pero con el sistema de cierre centralizado funcionando) sino también, qué es lo que en forma parcial ya puede comenzar a entregar valor.

Sucesivas entregas iran incrementando el valor del software entregado. A diferencia del modelo en cascada, deberemos esperar a que se cumpla un nuevo proyecto, por ejemplo, versión 2.0 para recibir la nueva versión. Posiblemente, esta última versión resuelva funcionalidades de nuevos requerimientos, no necesariamente estará incrementando valor. En el modelo ágil, con entregas cortas, el valor se irá incrementando con cada entrega, aumentando así, la superficie de valor agregado.

La Ventana Rota y la calidad del software

Hace tiempo se hizo famosa la teoría de la ventana rota. Básicamente, lo que dice es que si hay una ventana rota y no es reemplazada, la gente que pase caminando por ahí va a pensar que a nadie le importa y que no es responsabilidad de nadie. Rápidamente aparecerán más ventanas rotas, expandiendo la sensación de anarquía, enviando la señal de que nada de lo que pase tendrá importancia, de que colapsó el sistema. En una ciudad, problemas menores como graffitis, basura en las calles, etc. son equivalencias de la ventana rota, invitaciones a crímenes mayores.
Una forma de prevención, es resolver estos problemas cuando todavía son menores.

¿Qué relación tiene todo esto con el desarrollo de software?
La percepción de la calidad. ¿Cuántas veces por poner foco exclusivamente en los errores mayores no nos fijamos en detalles que hacen a la calidad que perciben los usuarios?

Algunos ejemplos:
• Tab Order (cómo va pasando el control entre los campos de una pantalla al presionar la tecla tab)
• Palabras con errores de tipeo o faltas ortográficas
• Campos sobre los que no controlamos el formato de ingreso
• Mensajes de error sin tratar, por ejemplo: mostrando la excepción que arrojó la base de datos sin explicar qué es lo que significa

¿Cuál es el resultado de todo esto?
Estamos dando la impresión de que estos temas (posiblemente otros más) no son importantes para nosotros, no nos preocupan, no nos interesan.
¿Cuál es la solución?
En primera instancia resolverlos. Si bien los errores deben ser tratados con prioridad, dejar errores que no tienen costo de reparación muestran que el control ha colapsado.
En segunda instancia, si no damos a basto con las correcciones por estar con bugs críticos, mostrarle al usuario a través de un issue tracker que los tenemos identificados, que los consideramos como errores que deben ser corregidos, y que están en nuestro roadmap.

¿Cómo vender un proyecto ágil?

Esta es una pregunta recurrente que surge en casi todas las charlas de metodologías ágiles.
Sabemos que realizar una propuesta o definir un alcance cerrado es un riesgo.
Según el Standish Group, la mayoría de los problemas del desarrollo de software no son técnicos, sino que están entre otros, en los requerimientos.

¿Relevamos mal? ¿Deberíamos dedicar más recursos? ¿Lograr mayor compromiso del usuario por lo acordado?
No necesariamente. Muchas veces el relevamiento es adecuado, el usuario lo entiende y lo acepta.
¿Qué pasa entonces? La realidad que sustenta el alcance cambia: cambian las necesidades, la tecnología, la legislación, etc.
¿Es esto evitable? No, y tampoco debemos esperar que no ocurra. Justamente lo contrario: la capacidad de adecuarnos, de ser ágiles para cambiar el rumbo, es la principal ventaja de las metodologías ágiles. Por eso lo de "abrazar el cambio"

Vuelvo a la pregunta inicial: ¿cómo convencemos a nuestros clientes, los usuarios, de trabajar en el marco de un proyecto ágil en lugar de uno con alcance cerrado?
Recuerdo la respuesta de Tobias Mayer en la primer capacitación de SCRUM que se dictó en Latinoamérica. Fue más o menos algo así: "Este es un problema comercial, no del proyecto" Scrum resuelve la problemática de los proyectos, no los comerciales.
La respuesta de Tobias es cierta. Pero no nos deja satisfechos. Es que estamos, en general, en una instancia previa. Antes de convencer a nuestro cliente, debemos convencer a nuestros comerciales, a nuestra dirección.

¿Cómo podemos hacerlo?

• lo primero: buscar entregas cortas que puedan ser puestas en producción rápidamente.
• acordar un alcance macro (por un tiempo macro) del alcance del sistema a ser revisado en cada iteración.
• identificar qué es imprescindible: Siempre hay dos o tres cosas que tienen que estar sí o sí. Que dan forma al desarrollo que estamos planeando. Una vez que las identificamos, resolverlas en las primeras instancias.
• concientizar a los usuarios que un alto porcentaje de software desarrollado nunca llega a usarse.
• dar libertad al usuario para suspender el proyecto al final de cada iteración, sea porque se alcanzó la funcionalidad más importante, o porque se perdió el objetivo del sistema. Esto es parte de ser ágil.

Tablero de Control o Collar de ahorque

Y la pregunta es siempre la misma: ¿para qué sirven los planes de proyecto?

No quiero caer en el error que si somos ágiles, es peso del que podemos prescindir. Nada más errado. Ser ágil no quiere decir ser desordenado.

Todo proyecto debería tener un plan acordado entre las partes, principalmente, el cliente (se interno o externo) y nosotros. Es el punto en el que nos pusimos de acuerdo sobre cómo vamos a ejecutar y controlar el avance del proyecto.

Ahora: ¿el proyecto tiene que atarse al plan o el plan atarse al proyecto?

¿Es un tablero de comandos? Podemos imaginar el de un auto, donde indica temperatura del motor, nivel de combustible, aceite, etc
¿Es un collar de ahorque? ¿Dentro del plan todo, fuera del plan nada?

Como siempre, no hay una respuesta única. Si la hubiese, no existiría la pregunta….

Peter Drucker decía que un plan es un conjunto de buenas intenciones más que un compromiso. Creo que esto podría reformularse de la siguiente forma: "un plan sirve para saber que hay que actuar en cuanto deja de cumplirse"

Ya sabemos que escribir un plan para no seguirlo y olvidarlo no es ágil: es estúpido, simplemente, una pérdida de tiempo.

¿Y al revés? ¿Cómo detectamos cuando queremos forzar la realidad: el alcance, el desarrollo, al cliente a restringirse a ese plan que le hicimos firmar con sangre?

Algunos indicadores:

• Cuando empezamos a discutir sobre lo que se quiso decir en el plan. Indicador: estamos queriendo volcar el plan para nuestro lado y así ganar la discusión.
• Cuando no vemos alternativas al plan. No es que es la mejor opción. No estamos encontrando alternativas. Como diría un scrum master: Es el arte de lo posible. Siempre hay soluciones alternativas. El plan no deben ser orejeras que nos impidan ver otras posibilidad, incluso si se encuentra fuera del plan.
• Cuando en las reuniones siempre hay alguien que lo pueda recitar de memoria: los talibanes del plan. Esto no ayuda. Nuevamente, el plan es una guia, pero nunca… nunca la realidad

Ok, el plan dejó de cumplirse… y ahora?
¡Ahora a escribir un nuevo plan!