miércoles, 14 de noviembre de 2012

Metodologías ágiles. ¿Me las creo o no me las creo?

Últimamente parece que los congresos y otros saraos sobre metodologías ágiles de desarrollo aparecen de debajo de las piedras. Están de moda, está claro. Ante todo, debo reconocer que aunque realmente me encantaría haber podido hacerlo, hasta ahora no he participado nunca en un proyecto en el que se siga alguna metodología ágil. Así que en este artículo parto del desconocimiento y diré irremediablemente un montón de tonterías. En cualquier caso, ya adelanto que las metodologías ágiles me generan tanto entusiasmo como dudas.

En el año 2001, Kent Beck (que básicamente quería vender su libro) convocó a unas cuantas mentes pensantes del desarrollo software y, con una cerveza en la mano, les dijo algo así como: "Señores, ¿están tan hartos como yo de tanta tontería?". El resto se miraron unos a otros, pensando cada uno en ese sufrimiento que les acarreaba el día a día en el trabajo: la incomprensión de sus jefes, ese documento que no vale para nada y nunca se acaba, el echarse las culpas unos a otros... Así que cogieron la petaca de whisky, la apuraron de un trago y todos al unísono gritaron: "¡¡¡Cambiemos el mundo!!!". Vale, seguramente no fue exactamente de esta forma, pero ey, si yo fuera a hacer una película sobre el tema la haría así, ¿qué pasa?.

El caso es que dice la leyenda que estos 17 tipos se pusieron de acuerdo para redactar los 4 principios maestros del desarrollo ágil, recogidos en lo que vinieron a llamar el manifiesto ágil (por cierto, cualquiera que haya estado en una reunión de su comunidad de vecinos sabrá que el que 17 tipos se pongan de acuerdo en algo en una tarde es cuanto menos difícil de creer, pero atribuyamos el mérito al alcohol y créamoslo, que al fin y al cabo da un poco igual si sucedió así o no). Los 4 principios tienen la forma "X mola más que Y", que no es que Y no mole, que si hay que ir se va, pero es que X es la leche y es lo que hay que potenciar. Estos son los 4 principios o valores.

1. Viva la gente (la hay donde quiera que vas)



Como comentaba en mi primer artículo sobre UML, unos años atrás las mentes pensantes del desarrollo de software se estrujaban las meninges buscando una metodología que hiciera el desarrollo tan fácil que cualquier mequetrefe fuera capaz de hacerlo con los ojos cerrados. Se pretendía que el desarrollo no fuera un proceso creativo, sino que siguiendo unos pasos bien definidos se pudiera casi automatizar.

Pero esto no es cierto. Lo cierto es que para hacer un buen diseño, que sea flexible y mantenible, tienes que ser creativo. Tienes que pensar. Y está demostrado que un buen desarrollador cunde más a largo plazo que muchos malos.

Por otra parte, también está demostrado que el rendimiento de una persona que está motivada con lo que hace es infinitamente superior al de la que no lo está. Esto tiene muchas implicaciones. No es fácil estar motivado. Tienes que sentir que controlas completamente el software que estás haciendo, que lo conoces bien, que tienes tu parte de responsabilidad sobre él. Tienes que hacer tareas creativas, no tareas aburridas.

Y aquí llega mi primera duda. Porque la vida real... ¿es así?. ¿No aparecen día sí y día también tareas soporíferamente aburridas, que no se pueden atajar haciendo de otra forma y que además no hay más remedio que hacerlas?. ¿No hay un montón de gente que se ha metido en el desarrollo porque da de comer, pero que realmente ni se sienten especialmente motivados ni les interesa sentirse así, sino que se prefieren limitarse a "cumplir órdenes"?. ¿Dónde encaja todo esto en las metodologías ágiles?.

2. Muerte al papel (efecto Fahrenheit 451)



Tradicionalmente creo que ha habido dos grandes problemas con la documentación. El primero es que muchas metodologías "de las antiguas" requerían una cantidad indecente de documentación. Yo personalmente he trabajado en proyectos en los que el equipo que había se tiraba más de un año haciendo toneladas de documentación, y cuando se querían dar cuenta no habían hecho nada de software real y el tiempo se estaba acabando. Al final resulta que se tiene que hacer todo el desarrollo corriendo y sin que la mayor parte de la documentación existente ayudase demasiado. Es una pérdida de tiempo y de energías, y además, desmotiva.

Pero el segundo problema creo que es aún peor, y tiene que ver con el paso del tiempo. Ocurre porque el software y la documentación son entidades diferentes. Están disociadas. Llega un momento en que, una vez entregada la primera fase del proyecto, dentro del mantenimiento se modifica el software pero no la documentación. ¿Para qué sirve una documentación que no está actualizada?.

Para resolver esto, en mi opinión lo que hay que hacer es integrar la documentación en el propio software. Olvidar la idea del "documento". Un gran ejemplo de esto es el JavaDoc. Pero creo que no basta con eso. Creo que aún nos falta subir más de nivel de abstracción. En mi segundo artículo sobre UML ya mencionaba la importancia de que los diagramas UML estuvieran integrados con el código Java, usando lo que se llamó (entre otros nombres) "live round-trip". Y aún podría ir más allá, porque también tengo mis propias ideas sobre el análisis de requisitos integrado con el código. Pero eso ya lo contaré en otra ocasión (me queda mucho de lo que hablar hasta llegar ahí)...

En este punto de la documentación, la verdad es que mis dudas son menores. Lo único que me pregunto es: ¿la gente estará siendo capaz de medir bien y ser racional con la documentación que se produce para el software?. En esto de la documentación, yo casi siempre lo que he visto han sido extremos: o te obligan a documentar demasiado, o no se documenta nada. Es decir, ¿se estará usando esto como excusa para no documentar nada de nada?. ¿Ni unos mínimos JavaDoc, ni una mínima documentación de intenciones, nada de nada?.

3. El cliente es tu amigo



Tengo que reconocer que la idea es muy buena. Es difícil que el software que se produzca satisfaga al cliente y cumpla sus necesidades cuando el cliente no está ahí siempre que haya alguna duda. Si hay que esperar a que haya una reunión para preguntarle, todo se retrasa. Muchas veces se tira "por el camino del medio", acertando en algunas ocasiones y en otras no. Muchas veces esas reuniones, cuando por fin llegan, se estiran y estiran y cuando sales te das cuenta de que no le has preguntado nada de lo que necesitabas saber (y que te duele la cabeza, además). Pero también muchas, muchas veces, el cliente se para a mirar lo que llevas hecho cuando sólo quedan dos semanas para la puesta en producción. Y entonces decide cambiarlo todo.

La idea, como digo, es buenísima, que el cliente participe dentro del propio desarrollo, que haya una comunicación frecuente con él y pueda resolver todas las dudas rápidamente. Pero... ¿es realista en la mayor parte de las ocasiones?. ¿De verdad los clientes se prestan a colaborar en los proyectos?. En mi experiencia, muchos clientes tienen su propio trabajo que sacar adelante, y consideran que no tienen tiempo para eso. Consideran que es tu problema. No entienden la importancia de ese tema. Ya te han contado qué es lo que necesitan, así que déjales en paz. Por supuesto, hay clientes y clientes. Pero me surgen muchas dudas sobre la resistencia que presentarán muchos clientes en contra de esa colaboración.

4. Be water, my friend



Ya he comentado en alguna ocasión que el desarrollo de un producto de software es un proceso de aprendizaje. Según se va profundizando en él, mejor se va entendiendo, y al hacerlo se van descubriendo nuevas implicaciones del desarrollo. Cosas nuevas que hay que hacer, o cosas que cuestan mucho más de lo que se había pensado al principio porque obligan a cambiar otras cosas o no se pueden plantear como se tenía previsto. Esto hace que los planes a largo plazo (e incluso a medio, y diría que muchas veces hasta a corto) sean difíciles de seguir, porque lo normal es que se descubran cosas nuevas sobre la marcha, y en ese caso siempre hay que acabar sacrificando algo. O el proyecto sale menos rentable, o se resiente la calidad del producto, o (más a menudo de lo que debería, sobre todo en consultoras) lo que se sacrifica es el tiempo de los programadores, que acaban haciendo horas no retribuidas como campeones, apelando al "compromiso con la empresa".

En cualquiera de los casos, se propaga un sentimiento de culpabilidad: "alguien ha hecho algo mal". "Esto no debe seguir así". "A partir de ahora vamos a hacer las cosas bien, y vamos a... planificar más cosas y mejor".

Las metodologías ágiles afrontan este problema dándole más importancia a la "respuesta al cambio" que al plan. Esto tiene una implicación enorme sobre la forma de trabajar de las empresas con sus clientes: requiere cambiar la forma en la que se hacen los contratos con el cliente. Ya no valen contratos cerrados, tipo "me haces todas estas funcionalidades en este tiempo y yo te pago esto". Nos vamos a una facturación por tiempo trabajado. Por un lado eso invalida directamente este tipo de desarrollos con determinado tipo de contrataciones, por ejemplo, cualquier proyecto con la administración pública, que tiene que ser cerrado por definición. Aparte de eso, ¿cuál es el problema de esto?. Que requiere una gran confianza. Confianza del cliente hacia la empresa del desarrollo, para que no piense "estos me están queriendo timar, me están cobrando una barbaridad para lo que están haciendo". Confianza del gestor de la empresa de desarrollo con el equipo que va a programarlo, para que no piense "estos se están pasando el día tocándose las narices, y el cliente se va a cabrear y nos va a dejar tirados".


¿Y en el fondo, no es ese el principal problema que tienen las metodologías ágiles? (aparte del hecho de que hay un conjunto grande de gente y/o situaciones para las que sencillamente no valen). Que requieren confianza. Que requieren querer hacerlo. Confianza del programador en el resto del equipo, confianza en que se está haciendo lo correcto, confianza en que la dirección lo va a soportar, confianza en que el cliente lo va a apoyar. Confianza de la dirección en el equipo de desarrollo, confianza en que va a funcionar bien, confianza en que al cliente le va a gustar. En definitiva, requieren que todos los implicados crean en lo que se está haciendo, desde el cliente que pone el dinero hasta el becario que echa una mano con lo que sea. Requieren que todos crean en el trabajo de ese equipo y de todos y cada uno de sus componentes.

¿Y sabéis qué?. Que yo me creo todo eso. Creo en la sinergia. Creo en que cada persona es capaz finalmente de asumir responsabilidades por sí misma, cuando se le otorga la confianza para que lo haga.

Pero no estoy seguro de que el mundo esté preparado para ello. Me parece un cambio de orientación demasiado grande y que afecta a demasiadas partes. Tengo muchas dudas. Me cuesta creer que las metodologías ágiles se estén usando de forma generalizada.

Así que si estás leyendo esto y has tenido ocasión de trabajar en algún proyecto siguiendo una metodología ágil, por favor, deja un comentario y comparte tu experiencia. Cuéntanos cómo convenciste a tus clientes y a tus jefes. Yo estoy dispuesto a apurar mi petaca de whisky y gritar: "¡Cambiemos el mundo!".


NOTA: Sí, los chistecillos son míos, haciendo un poco el tonto con el Inkscape juntando personajes que he cogido de por aquí y por allá (he procurado que fueran todos de dominio público). La mayor parte proceden de Open ClipArt.

12 comentarios:

  1. Me ha encantado este post, especialmente el que los chistes sean de tu cosecha, un curro fenomenal, ¡felicidades!.
    Si alguien me pregunta qué significado tienen los 4 principios del manifiesto ágil puedes estar seguro de que le recomendaré este artículo.

    ResponderEliminar
    Respuestas
    1. Muchas gracias, Rubén. Veo en tu blog que lees mucho sobre el tema, así que me alegra especialmente que te haya gustado.

      Eliminar
    2. Si, la verdad es que me estoy volviendo un poco monotemático, pero la verdad es que interesan muchísimo, y aunque no resuelvan todos los problemas del desarrollo de software, creo que al menos son una forma distinta de hacer las cosas.

      Eliminar
  2. Creo que lo pasa es que en España tratamos de aplicar las metodologías ágiles a las software factories, dado que es el tipo de empresa más habitual, cuando realmente la metodologías ágiles no son más que una parte, muy importante, pero sólo una parte, de métodologías de más alto nivel como la de Customer Development que tratan de ayudar a start-ups a encontrar un producto y un mercado... y en las start-ups sí se dan las condiciones de motivación, etc, etc que se echan de menos en las software factories españolas.

    ResponderEliminar
    Respuestas
    1. Estimado anónimo, me has pillado. He tenido que rebuscar por Internet para ver qué era eso de las software factories y el Customer Development.

      No sé qué pensar sobre lo que dices, por un lado es verdad que en las startup existen esas condiciones de motivación y que por tanto eso las convierte en un contexto ideal para atrevernos a hacer cosas nuevas, porque "no hay nada que perder". Y más si estamos siguiendo las ideas del Customer Development, claro, porque entonces ya nos hemos quitado de un plumazo las dos partes más chungas de conseguir: tanto el cliente como la empresa están a favor de seguir las metodologías ágiles.

      Pero por otra parte no podemos pensar que para aplicar metodologías ágiles tenemos que ser una startup, porque... ¡en poco tiempo dejaremos de serlo!. Y pasaremos a ser una "software factory", que digo yo que debería seguir usando las mismas metodologías con las que empezó.

      O sea, que aplicar metodologías ágiles en una software factory debería ser también perfectamente posible, aunque sea más complicado por eso del "peso de la tradición" (¿no pesan los años, pesan los kilos?).

      Eliminar
    2. Andrés, gracias por este valiente y honesto artículo.
      A un 80% de acuerdo contigo. De la agilidad se pueden aprender cosas más que interesantes, lo que pasa es que hay mucha tontería y las "metodologías ágiles" están muy hinchadas porque está siendo el elixir crecepelo con el que sobreviven gestores-embaucadores de mediopelo con puesta en escena de gurús expertos en agilismo-kanban-scrum-lean-y-lo-que-sea.

      Un saludo.

      Eliminar
    3. Gracias anónimo, un 80% está muy bien ;-)
      Personalmente me fastidian bastante en el mundo del desarrollo las cosas que se inflan por motivos comerciales. Pasó hace años con los EJB, por ejemplo, y seguramente se hizo mucho daño con ello. Eso sí, puestos a inflar, prefiero que al menos se inflen cosas que den una visión distinta y que tengan sentido e ideas interesantes detrás, como ocurre con esto de la agilidad, porque por lo menos imagino que al final se puede sacar algo de provecho.

      Eliminar
  3. Jesús L. Domínguez Muriel3 de diciembre de 2012, 20:19

    Yo tampoco he trabajado nunca en proyectos "ágiles" (o tal vez sí pero entonces no se llamaban así), pero tengo la impresión de que las metodologías ágiles triunfan porque le hacen mucho más fácil la vida al gestor del proyecto. En realidad, es que casi ni hace falta un gestor de proyecto.

    Planificar un software tipo Microsoft Word, con 50 o 100 programadores picando código uno o dos años antes de que se saque al mercado un producto que tiene que funcionar más o menos bien a la primera, es MUY COMPLICADO. Hace falta una persona que tenga una idea muy clara de toda la arquitectura, de todos los requisitos, y que además sepa organizar a los equipos, azuzar a los que se queden atrás, dar caña para que se desarrolle también el código aburrido, pelear con los de arriba... Chungo chungo.
    Planificar un sprint ágil con un equipo de 5 personas en el que decides en una reunión semanal lo que vas a desarrollar en la siguiente semana es fácil... y además quizás no consigas un buen producto, pero como el cliente ha participado le puedes echar la culpa.

    Y es que el gran problema que le veo yo a esto de las metodologías ágiles, y que Andrés lo describe parcialmente, es que funcionan bien si el equipo está formado por gente muy buena ("A-players" que dicen en Silicon Valley, creo)
    - "Valorar más a los individuos y su interacción que los procesos y herramientas": por supuesto, si los individuos son muy buenos, con cualquier proceso y herramienta van a poder hacer cosas buenas. Es más, si los fuerzas a usar un proceso que no les gusta mal vas.
    - "Valorar más el software que funciona que la documentación extensiva": de nuevo, si los programadores son buenos el código será bueno, bien estructurado, legible, y no requerirá mucha documentación. Que en cualquier caso, a los "A-players" no les gusta escribir porque es aburrido.
    - "Valorar más la colaboración con el cliente que la negociación contractual": bueno, voy a ser un poquitín malo, yo creo que esto lo han inventado para que si el resultado es un churro se le pueda echar la culpa al cliente. Y secundariamente, porque los "A-players" pueden darle la vuelta a lo que dicen los clientes y y negociar con ellos hasta conseguir hacer lo que quieran, pero darle la vuelta a los contratos preparados por abogados de los clientes es más complicado.
    - "Valorar más la respuesta al cambio que el seguimiento de un plan": de nuevo, unos buenos programadores fácilmente pueden adaptar el código a nuevos requisitos. Dile a unos buenos programadores que de repente hay 7 casos especiales en un cálculo de nóminas y rápidamente tendrán unas clases pulcras y bien definidas integradas mediante inyección de dependencias con unos bonitos interfaces. Diselo a unos malos programadores y tendrás un código spaguetti horroroso.

    Así que en una startup puesta en marcha por tres buenos programadores, o en un hackathon de fin de semana, o en una empresa como Google o Apple dispuesta a pagar mucha pasta para conseguir equipos formados sólo por "A-players", la programación ágil mola y funciona.
    En el resto de proyectos... mi impresión es que la metodología ágil funcionará más o menos bien para proyectos pequeños, pero acabará generando rápidamente productos inmantenibles para proyectos grandes.

    Y por cierto, yo también pienso que muy buenos los chistes, Andrés.

    ResponderEliminar
    Respuestas
    1. Lo que dices de los "A-players" es interesante, igual tiene su parte de verdad. Si son jóvenes y con posibilidades no hay problema, pero si son... malos, simplemente malos, va a ser que no.

      Con lo que no estoy de acuerdo es con lo de "echar la culpa al cliente". Se trata de que el cliente esté al tanto desde el principio de todo lo que se va cociendo. Si es así, es difícil que las cosas salgan mal. Lo que pasa es que para eso el cliente tiene que tener fe en el equipo de desarrrollo y estar dispuesto a poner pasta para todo lo que vaya surgiendo...

      Eliminar
    2. Me sumo a la opinión de Jesús.
      El mejor equipo ágil es el que ni necesita ni quiere gestor de proyecto. Pero esto no es fácil. Es posible que sólo sea posible en equipos del tipo que apuntas: un grupo de gente brillante y motivada, como ocurre con un equipo de amigos que están montando una start up.

      A partir de ahí, cuanto menor sea la motivación, la brillantez técnica del equipo y mayor sea el tamaño del equipo y la toxicidad de la cultura de la empresa más se irá alejando lo que hagan de la agilidad; aunque lo quieran compensar con post-it y rituales ágiles, todo tiene un límite.

      Gracias por el artículo Andrés.

      Un saludo.


      Eliminar
    3. Gracias, jpalacio. La verdad es que sería interesante conocer alguna experiencia real de una empresa que no sea startup.

      Eliminar

cookie consent