Hace 16 años, en 2001, se reunieron en Utah diecisiete profesionales del software críticos con los modelos de desarrollo de software que se llevaban hasta entonces. Los consideraban demasiado pesados o rígidos. En esa reunión estaba gente como los fundadores de Scrum o Kent Beck y Martin Fowler. Habían quedado para hablar sobre nuevas técnicas y procesos para desarrollar software.
De esa reunión salió un manifiesto con una serie de valores y principios que debían cumplir los nuevos métodos alternativos (y ágiles) que estaban proponiendo:
Valores detrás del movimiento ágil.
Estos valores que rigen los principios ágiles son:
Individuals and interactions over processes and tools
Se pone el énfasis en los individuos y los equipos de trabajo más que en los procesos rígidos que hayamos establecido para comunicarnos entre todos o para hacer las cosas. Poniendo a los miembros del equipo de trabajo en el centro de las decisiones obtendremos un plus de productividad mayor que si es un proceso el que dicta qué hacer y no hacer en cada momento.
Tampoco las herramientas son importantes. Nos basta un tablero o unas hojas de papel con las listas del producto y del sprint o unos pequeños post-it. Las últimas herramientas, más caras (y difíciles de usar) herramientas en gestión de proyectos no nos van a dar una gran ayuda a la hora de resolver nuestro trabajo. Por esto, rara vez, una implementación de Scrum aconseja usar una u otra herramienta. Eres libre de elegir la que quieras siempre que seas consciente que esa no es la decisión más importante en tu proyecto.
Working software over comprehensive documentation
Esto significa que valoramos más un software que funciona y que está libre de errores que una exhaustiva documentación que documenta con pelos y señales cada sección de la aplicación. Esto no quiere decir que ignoremos o pasemos de la documentación. La documentación sigue siendo necesaria pero, por favor, no la pongamos por encima de loa verdaderamente importante, que es el código funcionando. Un código chapuza o de difícil mantenimiento funciona igual si tiene mucha o poco documentación. Prestémosle nuestro tiempo a mejorar el código y no a documentarlo. Nos pagan por línea de código funcionando no por tonelada de papel con documentación.
Customer collaboration over contract negotiation
Esta es uno de los problemas más enraizados en el desarrollo de software hoy en día. Los proyectos salen mal, se pasan de horas, se retrasan las fechas de entrega y para evitarnos las posibles discusiones con los clientes ponemos paños calientes sobre el problema preparando una batería de cambios que han solicitado y que no estaban en el contrato inicial.
Probablemente el cliente no entenderá que los cambios solicitados sean tan importantes como para justificar un retraso tan grande y aquí comienzan las negociaciones sobre el contrato: ‘Yo no te haré la integración con el sistema SAP porque me has saturado con pequeños cambios en las funcionalidades anteriores’ a lo que el cliente contesta ‘Sin esa integración el proyecto vale poco o nada por lo que no voy a abonar los pagos pendientes hasta que esté hecha hasta la última coma del contrato’.
En una negociación no seas el primero el poner el arma encima de la mesa. El cliente siempre tendrá una arma más poderosa que la tuya y ambos saldrán perdiendo. Sobre todo tú que perderás un posible futuro cliente y ganará en malas referencias.
Es más fácil tener la lista del producto sobre la mesa desde el inicio cuando comenzaron a pedir cambios que probablemente sí que les hacían falta hacer. Sobre esa lista del producto anotar los nuevos cambios y pedirle al cliente que saque de la lista otra serie de funcionalidades de igual valor que ya no le resulten tan importantes. Seguro que de buen grado encontrará funcionalidades a las que ya no le ve tanto sentido y que estará encantado de quitarlas con tal de que les hagas las que sí les hacen falta realmente.
