Descubriendo metodologías ágiles: el a-gilismo


am i stupid

Am I stupid?


Querido Internet:

Esta es mi definición de agilismo

(de a-, gilí e -ismo)

a-
(Del gr. ἀ-, priv.).
1. pref. Denota privación o negación. Acromático. Ateísmo. Ante vocal toma la forma an-. Anestesia. Anorexia.

gilí.
(Del caló jili, inocente, cándido, der. de jil, fresco).
1. adj. coloq. Tonto, lelo. U. t. c. s.

-ismo.
(Del lat. -ismus, y este del gr. -ισμός).
1. suf. Forma sustantivos que suelen significar doctrinas, sistemas, escuelas o movimientos. Socialismo, platonismo, impresionismo.

En resumen, significa dejar de hacer el gili. Y es que después de varios años involucrado en la dirección técnica de equipos y proyectos desde distintos departamentos, una de las cosas que más he echado en falta es una forma de dirigir poyectos que esté basada en el comportamiento real de las personas.

Y tras descubrir las metodologías ágiles hace algún tiempo me dí cuenta que llevabamos muchos años haciendo en los proyectos lo que dice la definición de arriba, el lelo.

¿Cuántos de vosotros os habéis encontrado con un cliente que una vez comienza un proyecto decide cambiar de idea sobre lo que quiere, o solicita cambios de alcance o de orientación? En estas circunstancias las metodologías predictivas de gestión de proyectos se centran en encorsetar al cliente, impedir los cambios o reducirlos al máximo, o hacer que estos cambios resulten muy caros para el cliente.

¿Y en qué nos escudamos? Decimos que el cliente no sabe lo que quiere, que cambia de opinión, que no lo tiene claro, que nos pide imposibles y que todo lo que hemos ido haciendo no vale para nada y tenemos que volver a empezar tras cada reunión de seguimiento del proyecto. “Es normal que los proyectos se retrasen, si cada semana se nos piden cosas diferentes así no hay quien se aclare”.

Como project managers sabemos que es nuestra responsabilidad ejecutar los proyectos con el tiempo, alcance y coste definidos, pero la realidad nos dice que solamente un tercio de los proyectos se pueden considerar exitosos. Esto hace que el trabajo de project manager sea muy frustrante, estresante y muchas veces poco reconocido.

Y aquí es cuando descubres las metodologías ágiles de desarrollo de software, y te das cuenta que es lo que has estado buscando desde hace mucho tiempo, por varios motivos:

  • El cambio de especificaciones no solamente hay que dejar de intentar evitarlo, sino que además se considera bueno y enriquecedor para el proyecto. A medida que avanza el desarrollo de un proyecto el cliente sabe más sobre él y lo que quiere obtener, y sus peticiones pueden cambiar.
  • Las metodologías ágiles definen un rol específico que representa al cliente, en el caso de Scrum es el Product Owner. En las metodologías predictivas el cliente solamente se representa mediante el catálogo de requisitos, pero no hay una persona con un rol específico que lleve la voz del cliente.
  • De todas las funcionalidades que se desarrollan en un proyecto, el 64% no se usa nunca, el 16% se usa raras veces y el 20% restante es verdaderamente útil. Demos prioridad a las tareas que aporten valor al negocio y el resto ya veremos si es realmente necesario implementar.
  • En la mayoría de proyectos tenemos como condicionante el coste (precio cerrado) y el plazo de entrega, y en muchos también el alcance. Las metodologías ágiles (bien implementadas) gestionan este problema bastante bien.
  • Porque es el equipo de desarrollo el que decide hasta donde puede hacer en cada iteración, y se compromete a cumplirlo, y ellos son los que más saben del día a día del desarrollo del proyecto.
  • Porque permite controlar de forma más eficiente las posibles desviaciones del proyecto, haciendo que la vida del gestor de proyecto sea más fácil.
  • Y por último, aunque con toda seguridad lo más importante, porque la satisfacción del cliente es mayor cuando está involucrado y tiene poder de decidir sobre el proyecto, y además recibe entregables incrementales y perfectamente funcionales de forma periódica.

El carácter latino nos invita además a este tipo de comportamientos. Siempre preferimos empezar a andar y mientras tanto abrir el mapa, y ya vamos viendo poco a poco cómo vamos hacia donde queremos ir. Scrum y otras metodologías ágiles aprovechan este comportamiento en favor del producto final y de la satisfacción del cliente.

No olvidemos que Scrum como tal no define una forma concreta de desarrollar, sino unas serie de mecanismos para organizar equipos de trabajo en entornos ágiles, y de hecho esta metodología de organización de personas se tiene que complementar con otras que son puramente de desarrollo. Scrum habitualmente se combina con eXtreme Programming, pero también da buenos resultados con otras.

Hay gran cantidad de información en Internet sobre Scrum y metodologías ágiles en general, pero yo creo que es de obligada lectura la obra de Henrik Kniberg “Scrum y XP desde las trincheras”, traducida al castellano por uno de los grandes conocedores y “evangelizadores” de la agilidad, Angel Medinilla.

¿Qué otras fuentes de información recomendarías tú?

Suyo afectísimo.

Anuncios
Esta entrada fue publicada en Agilidad, Project Management y etiquetada , , , , . Guarda el enlace permanente.

6 respuestas a Descubriendo metodologías ágiles: el a-gilismo

  1. Pingback: Hipótesis incorrectas en desarrollos tradicionales, o ‘creique’ y ‘penseque’ | Querido Internet

  2. anllogui dijo:

    Por muchas vueltas que le doy, siempre llego a la misma conclusión. Las metodologías ágiles se adaptan muy bien para desarrollos de productos propios. Pero a la hora de salir al cliente, la cosa se complica.

    A menos que tengas mucha confianza con éste, aplicar scrum en particular es muy difícil. Un cliente quiere que le des un precio cerrado. Con scrum solo puedes uno orientativo. Quizás se deba a la poca cultura de desarrollo por parte de los clientes, que quieren todo llave en mano y olvidarse. No lo sé.

    ¿Has intentado aplicar scrum con este tipo de cliente?

    • Habitualmente en administración pública las contrataciones se hacen basándose en un pliego cerrado, en el que se especifica tiempo, alcance y coste en función de los criterios de quien redactó los pliegos. Además, en muchos procedimientos (según el importe), la oferta es pública y se puede presentar cualquier empresa que esté cualificada. En muy pocos casos se exige usar Scrum u otra metodología ágil para el proyecto. Aquí se puede usar Scrum internamente sin “necesidad” de decírselo al cliente, con un Product Owner interno.
      En empresas la cosa se complica. En mi opinión lo mejor es preguntarles estas tres cosas: ¿Qué problema tienes? ¿Cuánto dinero tienes? ¿Cuándo quieres tenerlo solucionado? Y en función de las respuestas ofrecerle un plan con un equipo de trabajo dimensionado para ese proyecto. Evidentemente, como en toda propuesta, ganarás si tienes su CONFIANZA, como bien dices tu mismo en el comentario.

      En mi opinión los clientes no quieren todo llave en mano, lo que quieren es una solución a sus problemas, con las menores sorpresas posibles. Es importante que nos transmitan sus requisitos en la forma de necesidades de negocio, no de funcionalidades del sistema; es nuestro trabajo decir cómo solucionaremos este problema.

      También coincido contigo en que la parte más complicada de Scrum es vender Scrum. Porque el cliente lo que dice es: “¿Cómo?, ¿Que me vas a poner un equipo de trabajo, y vas ha hacer hasta donde llegues y no hasta donde yo te diga? ¿Que no sabes lo que vas a tener hecho el mes que viene?” Convencerles de que la incertidumbre y el responder al cambio es mejor que seguir un plan establecido, que puede ser más o menos bueno, es lo más difícil.

      A mí me gusto mucho este artículo de Agustin Cuenca (ASPGems) cuando lo leí. Espero que te inspire.

  3. Pingback: Articulo Indexado en la Blogosfera de Sysmaya

  4. Pablo gómez dijo:

    Como me gusta leer sobre esto! ;-). Será que los malos técnicos nos escudamos en las metodologías para hacernos más fácil el sufrido camino del desarrollo?, jejejeje
    Mira este vídeo, te gustara… http://www.youtube.com/watch?v=Ew_ZZE2_kWA

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s