Mi experiencia con el desarrollo Agile no es tan dilatada como quisiera, pero llevo algo más de un año adentrándome en este terreno y he tenido tiempo de conocer varios aspectos en torno a esta metodología.
Por otro lado, durante este tiempo he adquirido la suficiente experiencia real como para llegar a múltiples reflexiones sobre la Agilidad y haberme dado cuenta de que en ocasiones, perdemos el foco con el que nace el Desarrollo Agile.
Como comentamos en su día, el Manifesto Ágil se compone de 4 valores y 12 principios. Ya tratamos los 4 valores y hoy vamos a tratar los 6 primeros principios, mediante una breve reflexión personal sobre cada uno de ellos.
1.Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
Del primer principio, creo que es importante comentar, que debemos satisfacer al cliente ya que éste es quién decide sobre el proyecto. Pero esto no quiere decir que se deba hacer a cualquier precio. Es crucial destacar el hecho de realizar entregas de valor, no cualquier avance dentro del desarrollo, sino el que mayor valor aporte en el momento y contexto en que nos encontremos, de manera temprana y continua.
2.Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Este principio puede ser de los más difíciles de comprender e interiorizar por distintos motivos:
- Tener que aceptar desde un principio el grado de incertidumbre al que se va a exponer el trabajo (que siempre es difícil)
- El gran contraste con el modelo tradicional de presupuestos cerrados
- La posible confusión de su interpretación con la idea de no planificar
- Superar las barreras mentales de que se pueden tomar los cambios en etapas tardías. Esto no es una “ofensa” al trabajo ya realizado ni al esfuerzo dedicado. Se puede identificar como trabajo perdido, en lugar de un trabajo necesario para llegar al aprendizaje y a la conclusión de que es necesario un cambio.
3.Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
Lo más destacable de este principio, muy ligado al primero, reside en el requisito de que la entrega frecuente sea de software funcional, no de software a medias o de múltiples cosas empezadas o de tareas que se mantienen durante meses, sino de software funcional que permita comprobar la realización de un trabajo, y sobre todo, la posibilidad de obtener feedback sobre algo real.
4.Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
Este principio, yo lo interpreto entre otras muchas variables que derivan de él, como:
- La mejor manera de conseguir un equipo alineado
- Con unos objetivos claros
- Un conocimiento común del propósito con el que se realiza el trabajo
- La búsqueda constante de Feedback para conseguir el mayor rendimiento posible del trabajo realizado
- Evitar numerosas gestiones intermedias que lejos de aportar valor a un trabajo, la distorsionan, dificultan o incluso impiden
5.Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan y confiarles la ejecución del trabajo.
El Desarrollo de software (y no me refiero solo a la programación) es una actividad de base intelectual y las personas somos seres con inteligencia emocional, por lo que la motivación aumenta de manera increíble nuestro potencial de llevar a cabo tareas donde el intelecto, ya sea lógico o creativo, juega un papel tan importante como en el desarrollo de software. Bajo mi punto de vista, este principio fomenta buscar la mejor experiencia de cada persona con su trabajo, consiguiendo el mayor potencial de cada uno, y por tanto, mejores resultados.
La motivación 3.0 defiende 3 pilares sobre los que claramente este principio se ve reflejado: Autonomía, Maestría y Propósito.
6.El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
Considero éste el principio más claro de todos, con el que cualquiera podría estar de acuerdo, pero uno de los más complicados de aplicar y que menos o peor se aplican en la realidad. No hablamos sólo de evitar la documentación extensiva como medio de comunicación, hablamos de tener una conversación, una discusión, un debate, pero hablamos también de toda la información que somos capaces de transmitir y recibir mediante el lenguaje no verbal, gestos, tonos de voz, miradas, dibujos, etc.
Una conversación cara a cara de 5 minutos, es mucho más efectiva tanto a la hora de explicar como de entender, de poner en común una idea o de buscar un alineamiento común, o incluso de poder percibir lo más relevante. Compartir un montón de textos escritos, dibujos en un documento, audios o sonidos puede ser muy tedioso y menos efectivo por la falta del vínculo, empatía o por la rapidez de interacción entre participantes que se da en una conversación.
Esto no hay que confundirlo con evitar cierta documentación, interrumpir y distraer constantemente a nuestros compañeros o justificar el “reunirnos para hablar” sin preparar previamente la reunión y objetivos que queremos lograr después de la reunión presencial.
En el siguiente enlace podéis continuar con la lectura y reflexión de Los 12 principios del Manifiesto Agile (Parte II).
