Revisando los principios del manifiesto por el Desarrollo Ágil de Software

Han pasado diez años desde que diecisiete expertos de la industria del software: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas dieron a conocer el Manifiesto por el Desarrollo Ágil de Software. Desde entonces se han publicado decenas de libros con la palabra ágil en el título y se han promovido nuevas prácticas y métodos abanderados por este movimiento.

Aunque usted no lo crea, durante estos años he seguido de cerca las diferentes propuestas de XP, Scrum, lean, kanban y otras, para ver cuál es su aportación a los procesos de desarrollo de software llamados “tradicionales”. Aprovechando este décimo aniversario del Manifiesto, citaré sus valores para compartir mis comentarios y reflexiones. Tal como lo establece la parte inicial del Manifiesto [1], éste promueve la valoración de:

Individuos e interacciones sobre procesos y herramientas

Fue un reclamo muy legítimo contra la idealización del papel de los procesos y las herramientas en el desarrollo de software. En muchas organizaciones fue más importante obtener la “certificación” en un modelo de procesos o contar con la herramienta más sofisticada, que cuidar que su gente estuviera motivada y capacitada para obtener beneficios tangibles al adoptarlos en su trabajo. Los desarrolladores tienen que sentir que los procesos y las herramientas realmente les sirven y facilitan su trabajo para poder aceptarlos. La interacción y colaboración dentro de los equipos de trabajo tampoco fue muy destacada en los procesos tradicionales, más bien se consideraba que era algo implícito. Llamar la atención sobre este tema fue, en mi opinión, una aportación muy importante del Manifiesto.

Software funcionando sobre documentación extensiva

Creo que este valor es el que más frecuentemente se ha interpretado mal. Nadie duda que el software funcionando es lo más importante, pero el papel de la documentación quedó en el entredicho. Muchos lo han entendido como “al diablo con la documentación, solo el código que se ejecuta es valioso”. Esta gente tiene una visión del ciclo de vida del software muy limitada. Se imagina que el autor del código va a ser su único amo hasta que el software se retire de la operación. Sabemos que la realidad no es así. Salvo los sistemas que fracasan, los que son exitosos sobreviven por mucho a sus autores. Nuevos desarrolladores tienen que darles mantenimiento y adecuarlos a las nuevas necesidades de los usuarios o negocios. Para que esta labor se pueda realizar, sin costo excesivo, es indispensable la documen tación de diferentes aspectos del sistema. Es cierto que para sistemas muy pequeños y simples, la documentación puede ser muy básica, pero para los sistemas complejos, del cuyo funcionamiento dependen organizaciones enteras, la documentación tiene que abarcar todos los aspectos cruciales del sistema para ayudar a comprenderlo. Me atrevo a decir que la complejidad de la documentación debe ser directamente proporcional a la complejidad del sistema de software. En mi opinión la pregunta no es ¿qué tan extensa debe ser la documentación? sino ¿qué es lo que hay que documentar para poder comprender un sistema de software para darle el mantenimiento?

Colaboración con el cliente sobre negociación contractual

Creo que la facilidad de poner en la práctica este valor es la que más depende del contexto. Cuando un grupo de desarrollo de software está incrustado como un área interna en una organización, tiene un solo cliente que es la propia organización para la cual trabaja. En este caso la colaboración muy estrecha entre ambos aparentemente debe ser fácil sin que haya un contrato muy estricto de por medio. Esto no es tan claro cuando el grupo de desarrollo es un proveedor externo a la organización. En este último caso el contrato y su negociación es inevitable. Entonces ¿qué mensaje nos quieren transmitir con este valor? Tal como yo lo entiendo, por un lado, sea el cliente interno o externo, la relación con sus representantes tiene que ser mucho más estrecha de lo que nos obligaban los modelos tradicionales de procesos. En estos modelos, se habla de revisiones y validaciones con el cliente, pero se deja a la interpretación la frecuencia y la profundidad de estas actividades.

Por otro lado, queda abierta la pregunta sobre ¿cómo expresar las condiciones de los contratos para que el cliente tenga la flexibilidad de ajustar sus necesidades en cualquier momento y que el proveedor no quiebre a raíz de éstos ajustes?

En este punto, el Manifiesto nos puso el dedo en la yaga. La relación cliente-proveedor en el desarrollo de software no puede tener bases tradicionales (uno exige y paga al otro por cumplir). Esta relación debe ser de colaboración con beneficios mutuos.

Respuesta ante el cambio sobre seguir un plan

Las solicitudes de cambio por parte del cliente, que pueden causar la modificación del plan, ya han existido en procesos tradicionales. La insistencia de los autores del Manifiesto en este punto puede ser a consecuencia de que los contratos típicos exigían esta rigidez de seguir un plan previamente acordado sin ofrecer mucha margen para los cambios.

Pero también sospecho que es un llamado a los propios desarrolladores, a los que se desesperan cuando un cliente les cambia la “jugada” y ellos ya pensaron que el sistema está casi listo. Los autores del manifiesto les quieren decir que su enojo no tiene sentido. A fin de cuentas el sistema debe de servir al cliente y a los usuarios, y por lo tanto tienen que apechugar los cambios aunque les duela.

La letra pequeña ...

Al finalizar la parte del Manifiesto dedicada a los valores, encontramos algo que es como las letras chiquitas de los contratos:

“Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.”

Y aquí está el gato encerrado. Los autores dicen que aunque valoran más los elementos de la izquierda también consideran de valor las partes de la derecha de sus enunciados, es decir: procesos y herramientas, documentación extensiva, negociación contractual y seguir un plan. Así que no rechazan por completo de las aportaciones de los métodos tradicionales sino claman por agregarles mayor cuidado de: individuos e interacciones, software funcionando, colaboración con el cliente y respuesta ante el cambio.

A la distancia de diez años creo que la propuesta de los agilistas fue muy importante para el avance de la comprensión de la forma de trabajar de los desarrolladores de software. De ninguna manera invalidan la aportación de las propuestas anteriores, más bien las enriquecen poniendo énfasis en los aspectos que no han tenido suficiente atención.

A las nuevas generaciones de desarrolladores y a los directivos de sus organizaciones los invito a reflexionar sobre estos valores del Manifiesto por el Desarrollo Ágil de Software para que complementen su forma de trabajar actual con las prácticas que les hagan falta, sea de métodos ágiles o sea de métodos tradicionales. Seguro les va a servir esta reflexión.

Referencias:

[1] Manifesto for Agile Software Development. http://agilemanifesto.org