lunes, 29 de marzo de 2010

Los Métodos Ágiles

Entre finales de la década pasada y principios de la actual surgieron una serie de métodos de desarrollo de software contrapuestos a la visión clásica de la ingeniería del software. Estos métodos se postulan en contra del control de los proyectos de software basado en la predictibilidad de las tareas a desarrollar, y proponen una orientación de estos que facilite su adaptabilidad de forma continua a las condiciones cambiantes de dichos proyectos.

En su artículo “The New Metodology, Martin Fowler hace una exposición de estos métodos, llamados métodos ágiles. Voy a hacer un pequeño repaso a este artículo a través de la traducción al castellano realizada por Alejandro Sierra.

Según Martin Fowler, la forma más habitual de trabajar en un proyecto de desarrollo de software es a través de la prueba y error con un mínimo plan inicial, y completando el diseño con decisiones a corto plazo. Esto funciona bien para proyectos pequeños pero no para proyectos más grandes, que necesitan de largas fases de prueba a posteriores que desbordan toda planificación.

Para remediar esta situación se dispone de metodologías de desarrollo, que imponen un proceso disciplinado que trata de convertir el desarrollo de software en algo predecible y eficiente, similar a otras ingerierías. Sin embargo, estos métodos introducen mucha burocracia en los proyectos, retrasando su avance.

En opocición a estas metodologías, surgen los métodos ágiles, que se sitúan en medio de las metodologías tradicionales y la falta de metodología. Están más orientados a producir código que documentación debido a sus dos características principales:
  • Son adaptables en lugar de predictivos. En vez de planear todos los aspectos del proyecto tratan de adaptarse en los cambios que se producen durante la ejecución del proyecto.
  • Son orientados a la gente en lugar de al proceso. Tratan de apoyar el equipo de desarrollo en su trabajo, en vez de forzar al equipo a trabajar de una forma estricta.

Las ingenierías tradicionales enfatizan en que hay que planear antes de construir. En ellas, el plan define de forma exacta cómo se llevará a cabo la construcción. La realización del plan es una actividad mucho más exigente que la ejecución, y requiere de personal especializado. La ejecución es algo más mecánico que puede ser llevado a cabo por personal de nivel bajo.

Sin embargo, en desarrollo de software, no es fácil diseñar un plan que convierta el desarrollo en una actividad de construcción predecible. Un diseño en UML no suele ser todo lo completo que sería necesario y suele variar con respecto a la implementación. En estos casos el costo del esfuerzo del plan es mucho mas cercano a la implementación que en proyectos de ingenierías tradicionales.

Por tanto, se observa que en el desarrollo de software la construcción es barata ya que casi todo el esfuerzo está en el diseño, que es un proceso creativo. Como los procesos creativos no se planean fácilmente, la previsibilidad es una meta difícil de alcanzar.

Además, en los proyectos de desarrollo de software, los cambios en los requisitos son habituales, debido a las condiciones cambiantes en las que se dearrollan los proyectos. Además, ya que el desarrollo de software es una actividad de diseño, esta es difícil de planear y cuantificar, por lo que la estimación de los requisitos es difícil, y con ello la posibilidad de obtener un plan predecible.

Es por ello que en desarrollo de software es necesario un proceso que controle esta imprevisibilidad mediante adaptabilidad. Esto se logra mediante el desarrollo iterativo, que permite obtener retralimentación sobre la situación del proyecto en intervalos frecuentes.

De esta forma, se hace evidente tanto la situación actual del proyecto como posibles fallos de entendimiento del mismo o bugs.

Sin embargo, este tipo de desarrollo necesita un tipo de cliente distinto al tradicional. El cliente debe estar involucrado con el equipo, revisando el resultado de las iteraciones y proporcionando información sobre el proyecto de forma constante. Además, el contrato de precio fijo deja de tener sentido.

Ya que no se puede fijar tiempo, precio y alcance, lo normal es fijar precio y tiempo y permitir que el alcance varie de manera controlada. Gracias a las iteraciones, el cliente tiene control a escala fina sobre la evolución del proyecto, pudiendo fijar la dirección del proyecto de acuerdo a sus prioridades. Esta visibilidad sobre el proyecto que otorgan las iteraciones permite controlar también el riesgo.

En un proceso de este tipo se requiere de un equipo eficaz de desarrolladores. Las personas involucradas en un proyecto ya no son recursos reemplazables, debido a que el trabajo que se realiza es algo creativo y en este tipo de trabajo hay grandes diferencias entre las personas. Además, si las personas trabajan en equipo, se establecen sinergias que hacen que el equipo sea más que la suma de sus miembros.

También hay que reconocer a los profesionales de software como profesionales competentes capaces de dirigir su trabajo técnico. La labor de la gerencia será favorecer este trabajo con la menor interferencia posible.

Las metodologías ágiles tambien rechazan las métricas como herramienta de control del rendimiento de las personas, puesto que no se han encontrado métricas fiables en este sentido. Por ello favorecen la gestión delegatoria, donde los que finalmente hacen el trabajo deciden sobre cómo hacerlo.

Pero para llevar esto a cabo no se puede confiar sólo en la parte técnica. Es necesario que los expertos de negocio estén accesibles y pueden resolver las dudas que surjan a medida que el proyecto avanza. Se favorece la comunicación interdisciplinar.

Además, el propio proceso de desarrollo debe evaluarse y someterse a modificaciones que permitan mejorarlo.

Varias metodologías comparten estas bases. Entre ellas, podemos citar:
  • XP.
  • Scrum.
  • Crystal.
  • FDD (Feature Driven Development).
  • DSDM (Dynamic System Development Method).
  • Lean.
  • Etc.

A pesar de todo, es importante resaltar que el uso de estas metodologías no es apropiado para todos los casos. Hay que considerar la naturaleza de cada proyecto y evaluar si encajaría con estos principios o no.

Factores que sugieren un proceso adaptable:
  • Requisitos inciertos.
  • Desarrolladores responsables.
  • Clientes implicados.

Factores que sugieren un proceso predictivo:
  • Equipos grandes.
  • Contratos con alcance y precio fijo.

Sin embargo, no todo son parabienes para estos métodos y su aparición ha suscitado amplios debates entre sus defensores y los defensores de las metodologías tradicionales. Como ejemplo, este artículo de Miguel Ángel Abián y el debate que suscitó dentro de la comunidad JavaHispano.

Referencias:
The New Metodology por Martin Fowler
Traducción al castellano del artículo The New Metodology por Martin Fowler realizada por Alejandro Sierra
Artículo de Miguel Ángel Abián sobre las Metodologías Agiles
Discusión en JavaHispano en torno al artículo de Miguel Ángel Abián
La Falacia de la Ingeniería del Software por Samuel Zarza
Waterfall vs. Agile: Can they be Friends?

7 comentarios:

  1. Probablemente la mejor síntesis sobre metodologías ágiles que he leído: vas al grano y te centras en los puntos clave. Enhorabuena.

    Me parece clave la frase "En estos casos el costo del esfuerzo del plan es mucho mas cercano a la implementación que en proyectos de ingenierías tradicionales.". Estoy contigo en que hay que insistir sin complejos que nuestro trabajo es, en efecto, un proceso creativo... y tiene más de ésto último que de "ingeniería" predecible y reproducible.
    En efecto, estas metodologías requieren un cambio radical de "la industria", ya que requiere un cambio radical en el cliente (implicación absoluta del cliente en el proceso, cambio en el tipo y enfoque del contrato, etc), asume que los "recursos" son personas capaces no reemplazables... Esto no se parece en nada a ningún proceso de cualquier otra ingeniería "tradicional".
    Evidentemente no es el paradigma, pero la presunción y enseñanza de que las metodologías cĺasicas son ingeniería científica desde las universidades, la forma de trabajar de las "cárnicas" (a los que muchos clientes se han mal acostumbrado), y otros aspectos, han hecho mucho daño a la profesión durante años y ahora tenemos que repararlo eliminando la asociación permanente en la conciencia colectiva entre los proyectos software los de de obras civiles. En fin, afortunadamente muchos clientes se han hartado del engaño cínico de las "cárnicas" y su venta de humo mediocre por kilo de peso de programador.

    Voy a referenciar este artículo en el mío "La falacia de la Ingeniería del Software" porque me parece el complemento perfecto para mi exposición.

    Saludos!

    ResponderEliminar
  2. Muchas gracias, Samuel.

    Pero que conste nuevamente que este artículo no es obra mía, sino una adaptación de la traduccción al castellano realizada por alejandro Sierra del artículo de Martin Fowler "The New Metodology".

    También recomiendo que te leas el artículo de Miguel Ángel Abián que cito al final del post, para tener otra visión totalmente crítica con estas metodologías.

    Las metodologías ágiles promulgan una nueva forma de interpretar el desarrollo de software que rompe con la visión tradicional. Y sin embargo, algo habrá de bueno en la forma en que se han hecho las cosas hasta ahora... ¿no?

    Tal vez, la virtud esté en el centro, recogiendo las virtudes de una u otra visión. Pero es difícil reconocer dónde está el término medio y, seguramente, este término medio no es el mismo en proyectos de distintas características.

    Complicado mundo este de las metodologías de desarrollo software...

    ResponderEliminar
  3. Por cierto, te enlazo yo a tí también.

    ResponderEliminar
  4. Gracias por el enlace.

    Vaya curro el de Miguel Ángel. 81 páginas muy bien documentadas y argumentadas.

    Estoy de acuerdo en lo que dices. Y eso es precísamente el mensaje final de lo que quiero decir: que no hay una "bala de plata". No hay una metodología que cubra todos los tipos de proyecto. Por otro lado, el mejor legado que dejará el enfoque ágil (o liviano) es la orientación al equipo, y el hecho de que constate la importancia de las personas como elemento diferenciador de primer orden y no como elementos sustituíbles.

    En mi caso, donde la mayoría de los proyectos en los que participo son pequeños, no son militares ni gubernamentales y con requisitos muy cambiantes, las metodologías y métricas predictivas tradicionales no suponen una solución ni han generado éxitos plausibles.

    ResponderEliminar
  5. Gran artículo sbore metodologías ágiles.
    Me gustaría comentar que en Pamplona se están dando charlas acerca de esta materia. Aquí os dejo el enlace.
    http://www.cein.es/web/es/agendanoticias/agenda/2010/04/13/9935.php

    ResponderEliminar
  6. He incluído un nuevo artículo de referencia. Es el primero de una serie en que contrapone los procesos ágiles y los procesos en cascada.

    Un saludo.

    ResponderEliminar
  7. Hola qué tal? No hay un link más reciente de la traducción? No lo encuentro por ninguna parte.

    Gracias!

    ResponderEliminar