Una de las cosas que hicieron, fue sacar la mote de livianas a la metodología, y llamarlas ágiles. Para mi, ese fue un primer paso para eliminar uno de los primeros malentendidos de dichas metodologías. Llamarlas livianas hacen pensar que son mas fáciles de implementar, o que sirven para proyectos de juguete y no en serio, como las metodologías tradicionales. Por otro lado, llamarlas ágiles demuestra el principal objetivo de esta forma de trabajar: enfocarse en el aprendizaje y adaptación continua, de manera colaborativa con el ambiente.
Luego de horas de charla (y me imagino que también comida y alguna que otra cerveza) definieron 4 guías generales, acompañados de 12 principios, que formaron las bases del crecimiento futuro de las metodologías.
Actualmente, muchos años después, las grandes compañías se atreven a pensar en sumar estas metodologías "novedosas" a sus proyectos. Esto es una buena noticia, pero muchas veces se malentienden los lineamientos o los principios ágiles, lo que lleva al fracaso al corto plazo (en el mejor de los casos), o al largo plazo (lo que se relaciona con mucho tiempo y dinero perdido).
En mi opinión, parte de esos malentendidos se da por la naturaleza humana de buscar siempre el camino mas simple, y no adentrarse demasiado en lo que produce ese camino o en entender completamente lo que se hace. Como dice Douglas McGregor, en su teoría X, el ser humano es vago por naturaleza. No estoy completamente de acuerdo con esto, pero creo que muchas personas (en la lectura del manifiesto ágil se da claramente), paran de investigar o ahondar mas un tema cuando descubren alguna teoría que sirve para fundamentar su pensamiento.
Para explicar mi opinión, primero transcribiré los lineamientos del manifiesto ágil:
- Individuos e interacciones sobre procesos y herramientas
- Software funcionando sobre documentación extensiva
- Colaboración con el cliente sobre negociación contractual
- Respuesta ante el cambio sobre seguir un plan
Luego de los cuales se encuentra la siguiente frase: "Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.". En ningún lado dice que debemos desechar los elementos de la derecha, y solo aplicar los de la izquierda. Pero muchos lo entienden de esa manera, solo porque la parte izquierda puede verse, desde el punto de vista de muchos, como lo único que debe hacerse en un proyecto IT. Y eso no es ágil. Eso es un fracaso.
¿Porque se da esto? Porque los que afirman que son agilistas ya que no documentan, no siguen procesos y no tienen un plan, no siguieron leyendo mas profundamente sobre el manifiesto ágil.
Debajo de los párrafos anteriormente transcritos, se encuentra un link hacia la explicación de la historia del manifiesto (about the manifest). Seguramente esta página tiene muchas menos lecturas que la principal (tal vez sea un problema para muchos que dichos párrafos sean escritos solo en ingles), y eso explica el fracaso de muchos proyectos mal llamados ágiles.
Voy a transcribir un párrafo de dicho texto:
"The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.". Y lo voy a traducir por si ese es el problema:
"El movimiento ágil no es anti-metodología. De hecho, muchos de nosotros quieren devolverle credibilidad a la palabra metodología. Queremos volver a tener un equilibrio. Nosotros adherimos al modelado, pero no al hecho de almacenar algún diagrama en un repositorio corporativo. Adherimos a la documentación, pero no a cientos de páginas nunca mantenidas y raramente utilizadas. Planificamos, pero reconocemos los límites de planificar en ambientes cambiantes.".
Creo que si este párrafo estuviera junto a los lineamientos base, los rechazos a las metodologías ágiles serían mucho menores.
Las metodologías ágiles no se tratan de no tener procesos ni herramientas, sino de tener los que ayuden a los individuos y sus interacciones a ser mas fluidas, eficientes y eficaces. O sea, que ayuden a hacer lo correcto en el menor tiempo posible.
Las metodologías ágiles no se tratan de no tener documentación, sino de documentar lo relevante para comprender el código, que el mismo sea mantenible a futuro y que este siempre actualizada, para ser útil.
Las metodologías ágiles no se tratan de no tener un contrato con el cliente. Se debe tener la visión del cliente para poder tener un proyecto exitoso desde el principio, pero dicha visión no debe usarse como el mantra del proyecto, que nunca puede ser modificado. El alcance, los requerimientos y las necesidades van a cambiar durante el proyecto, debemos aceptarlo y no rechazarlo mediante un contrato y control de cambios.
Por último, usando metodologías ágiles, se planifica, y de una manera mucho mas eficiente que las metodologías tradicionales. Se planifica de a poco, haciendo que cada paso sea seguro. Preguntale sino a un project manager tradicional, cuando va a terminar. Si es sincero, te va a decir que no sabe. Lo mismo pasará con un Product Owner o un Scrum master, por ejemplo, pero luego de tres iteraciones se irá animando a brindar alguna visibilidad mas certera.
Y seguro, en el segundo caso el plan será mas cierto y fácil de seguir.
0 comentarios:
Publicar un comentario