Metodologías ágiles de gestión de proyectos (Scrum, DSDM, Extreme Programming – XP…)

Tradicionalmente las metodologías de gestión de proyectos como PMBOK y PRINCE2 han tenido una fuerte orientación predictiva. Es decir, a partir del detalle del producto que se quiere elaborar (análisis funcional/técnico, requerimientos funcionales/técnicos, etc.), se definen fases/actividades perfectamente planificadas en el tiempo en base a los recursos disponibles. A partir de esta proyección inicial, el objetivo durante el transcurso del proyecto es conseguir que se cumpla aquello que se había previsto: calendario, costes y calidad.

Este tipo de metodologías ha resultado ser útil, mejorando la calidad y reduciendo las desviaciones en los proyectos que son aplicadas. No obstante, pueden presentar determinados inconvenientes:

  • El jefe de proyecto puede no tener conocimientos técnicos y dedicarse exclusivamente al control siguiendo los procedimientos establecidos y limitándose a la generación de informes, actas, diagramas de Gantt, WBS, etc… herramientas que facilitan la gestión pero que no forman parte del objetivo del proyecto. Un jefe de proyecto con estas características no podrá participar activamente en la toma de decisiones técnicas.
  • En proyectos largos, ceñirse a un plan estático puede provocar que el producto final ya no se cubra la totalidad de las necesidades del cliente dado que estas han cambiado desde el inicio. Por tanto, durante el propio desarrollo del producto, es posible que se deban ampliar las características diseñadas inicialmente con tal de que no sea obsoleto antes de su salida al mercado.
  • Incertidumbre: vivimos en un entorno rápido e inestable, donde cumplir el plan inicial no garantiza el éxito. La idea de “producto terminado” puede perder su sentido en determinados sectores (p.ej. software), dado que el producto siempre está en evolución. La capacidad de adaptación a partir de la retroalimentación e incorporación de nuevas ideas es fundamental.

En definitiva, la creación de valor mediante la adaptación a las necesidades cambiantes aparece en un primer plano frente a la tradicional idea de diseñar un plan y cumplir unos calendarios/requerimientos estáticos.

Los proyectos gestionados con metodologías ágiles se inician sin un detalle cerrado de lo que va a ser construido. A nivel comercial, los proyectos pueden ser vendidos como servicios y no como productos.

Manifiesto ágil

Los propulsores de las metodologías ágiles firmaron un manifiesto donde se expresaban las ideas fundamentales del estilo de gestión:

  • Valorar a las personas y su interacción, por encima de los procesos y las herramientas: procesos de calidad con personas y relaciones mediocres no daran buenos resultados.
  • Valorar el software que funciona, por encima de la documentación exhaustiva: la documentación es necesaria dado que permiten la transferencia del conocimiento, pero su redacción debe limitarse a aquello que aporte valor directo al producto/servicio.
  • Valorar la colaboración con el cliente, por encima de la negociación contractual: si bien son necesarios, los contratos no aportan valor a los productos/servicios. Las metodologías ágiles integran al cliente en el proyecto y mantienen como objetivo aportar el mayor valor posible en cada iteración.
  • Valorar la respuesta al cambio, por encima del seguimiento de un plan: Anticipación y adaptación enfrente de planificación y control.

A partir de los 4 valores básicos se pueden extraer diversos principios que matizan la filosofía detrás de la gestión ágil:

  • La principal prioridad es satisfacer al cliente mediante entregas tempranas y continuas de valor: periodos de 15 a 60 días.
  • Los requisitos cambiantes son bienvenidos.
  • Integración de los conocedores del negocio en el propio proyecto.
  • La motivación y el talento son aspectos clave, por tanto la confianza y el apoyo al equipo humano es fundamental.
  • Potenciar las conversaciones en persona por encima de la comunicación escrita.
  • El producto funcional (p.ej. software operativo) es la principal medida del progreso: centrar el interés en el grado de finalización funcional o el tiempo previsto de finalización, no en el tiempo transcurrido contra el planificado.

Características básicas

Las características básicas de los proyectos gestionados con metodologías ágiles son las siguientes:

  • Incertidumbre: la dirección indica la necesidad estratégica que se desea cubrir (sin entrar en detalles), ofreciendo máxima libertad al equipo de trabajo.
  • Equipos auto-organizados: no existen roles especializados
    • Autonomía: libertad para la toma de decisiones.
    • Auto-superación: de forma periódica se evalúa el producto que se esta desarrollando.
    • Auto-enriquecimiento: transferencia del conocimiento.
  • Fases de desarrollo solapadas: Las fases no existen como tal sino que se desarrollan tareas/actividades en función de las necesidades cambiantes durante todo el proyecto. De hecho, en muchas ocasiones no es posible realizar un diseño técnico detallado antes de empezar a desarrollar y ver algunos resultados. Por otra parte, las fases tradicionales efectuadas por personas diferentes no favorece el trabajo en equipo y pueden llegar a generar más inconvenientes que ventajas (p.ej. un retraso en una fase, afecta a todo el proyecto).
  • Control sutil: establecimientos de puntos de control para realizar un seguimiento adecuado sin limitar la libertad y creatividad del equipo. Así mismo, se recomienda:
    • Evaluar el ambiente laboral, siendo fundamental la elección de personas que no generen conflictos.
    • Reconocer los méritos mediante un sistema de evaluación justo y entender los errores como puntos de mejora y aprendizaje.
    • Potenciar la interacción entre el equipo y el negocio, para que puedan conocer las necesidades de primera mano.
  • Difusión y transferencia del conocimiento: alta rotación de los miembros de los equipos entre diferentes proyectos. Por otra parte, potenciar el acceso libre a la información y documentación.

Elección del estilo de gestión: ¿Predictivo o ágil?

Personalmente me gusta bastante los ejemplos que se exponen en el libro Flexibilidad con Scrum (Juan Palacio). La gestión predictiva equivale a la persona que decide irse de viaje y planifica con exactitud que ciudades, vuelos y hoteles va a visitar o reservar. Por otra parte, la gestión ágil corresponde a una persona que sabe que quiere conocer un país y que empezará la visita por la capital, pero deja la decisión de que ruta seguir para cuando haya llegado.

Si falla algún elemento del plan de la primera persona (p.ej. cancelación de un vuelo) debe buscar una alternativa para superar el obstáculo y poder así continuar con lo planificado inicialmente (p.ej. llegar a tiempo al espectáculo de una ciudad determinada para el cual ya había reservado las entradas). Mientras que la segunda persona, a medida que se encuentra cambios en el camino, se adapta con el objetivo de cumplir su propósito inicial: conocer el país.

No se trata de elegir un modelo como el mejor, simplemente habrá casos en los que convendrá una gestión predictiva (p.ej. la construcción de un puente) y otros en los que la opción ágil puede ser más beneficiosa (p.ej. desarrollo de software). El software es mucho más maleable, adaptable y fácil de reconstruir. Sin embargo, en la construcción de un puente no se pueden destruir parte de los cimientos para volver a rehacer con un diseño diferente a mitad de proyecto.

Otro aspecto importante es identificar donde se encuentra el valor en el sector donde va a tener lugar el proyecto. Podemos considerar 3 elementos fundamentales entre los cuales se reparte el valor:

  • Personas
  • Tecnología
  • Procesos

Vuelvo a utilizar un ejemplo del libro Flexibilidad con Scrum (Juan Palacio). Montar un mueble del IKEA, puede ser un proyecto donde hay una persona, tecnología (el destornillador) y procesos (el manual de instrucciones). Podemos tener el mejor destornillador y el mejor manual, sin embargo el resultado dependerá siempre de las capacidades de la persona. Por tanto, en este caso el valor se reparte en primer lugar en la persona y en segundo en la tecnología y procesos.

Otro ejemplo, un cocinero que trabaje en un Mc Donalds es fácilmente reemplazable dado que lo importante en ese negocio es la tecnología y los procesos (es donde esta el valor). Mientras que un cocinero de un restaurante de autor resulta fundamental (valor) enfrente del resto de elementos.

La gestión predictiva tiende a valorar más los procesos (p.ej. planes preestablecidos, modelos de comunicación y autorización estrictos, etc.), mientras que la gestión ágil da una mayor importancia a las personas (p.ej. dando libertad, confianza y autonomía al equipo, potenciando la motivación, participación y creatividad, etc.)

Metodologías ágiles disponibles

Actualmente, la metodología ágil más popular para la gestión de proyectos es Scrum. Se presenta como contrapunto a PMBOK y PRINCE2, siendo utilizada tanto para desarrollo de software como para otro tipo de productos.

Por otra parte, también se disponen de metodologías específicas para el desarrollo de software que pretenden ser alternativas a estándares como ISO/IEC 15504, ISO/IEC 12207 y CMMI. Por ejemplo:

  • Dynamic Systems Development Method (DSDM): Metodología ágil más veterana y la que más se aproxima a los métodos tradicionales, su implantación incluso permitiría alcanzar un nivel 2 de madurez según CMMI.
  • Extreme Programming (XP): La metodología ágil más radical y popular. XP se centra en el ciclo de vida del desarrollo de software.
  • Agile Modeling: Metodología para el modelado y la generación de documentación que se encuentra alineado con los principios del desarrollo ágil y que puede ser utilizado como substituto del UML estándar.
  • Feature Driven Development (FCC): Metodología de desarrollo de software orientada a la generación de valor para el cliente.

Si bien las metodologías tradicionales de desarrollo de software como CMMI o ISO 15504 presentan procesos que cubren todas las necesidades de los sistemas de información, las metodologías ágiles listadas abarcan áreas complementarías entre si. Por ese motivo, es posible aplicar diversas de ellas en conjunto (p.ej. Scrum, XP y Agile Modelling).

Conclusiones

Las metodologías ágiles presentan un enfoque diametralmente opuesto a las metodologías predictivas, ofreciendo un enfoque más adecuado para determinados proyectos como el desarrollo de software. No obstante, es importante no caer en el extremo y dar por malo todo aquello que sea de un bando u otro.

Aunque optemos por el uso de metodologías ágiles, resulta interesante conocer las herramientas y técnicas predictivas dado que es posible que podamos incorporar alguna de ellas exitosamente (y viceversa). La convergencia entre ambos modelos puede dar lugar a una gestión eficiente y eficaz.

Bibliografía

Flexibilidad con Scrum (Juan Palacio).

12 thoughts on “Metodologías ágiles de gestión de proyectos (Scrum, DSDM, Extreme Programming – XP…)

  1. Interesant no como metodologia de desarrollo e el articulo…

    Mirar la posibilidad de reconsiderar a CMMI (y otros estandares mencionados en su articulo) que no es una metodologia para el desarrollo de software, es un marco de referencia para determinar el nivel de mdurez de una organizacion que desarrolla software

    Gracias

  2. Hola,

    La idea del artículo es muy interesante, pero lamento decirte que PMBOK no es una metodología de dirección de proyectos, sino una guía de conocimientos basada en las mejores prácticas. De hecho, dentro del modelo PMBOK se considera que uno de los activos de la organización es contar con una metodología de dirección de proyectos, que puede depender del producto a entregar, incluso es posible usar una metodología propia.

    Para la idea que planteas con respecto a la retroalimentación de la especificación del producto, debo decirte que una de las bases del modelo PMBOK es la elaboración progresiva del alcance y por tanto del plan de gestión del proyecto durante el ciclo de vida del proyecto, por lo que no comparto tu idea de que la especificación del producto no pueda cambiar, lo unico que propone PMBOK es que cualquier cambio en las especificaciones debe estar aprobado dentro de un proceso de gestión de cambios, y que los planes subsidiarios que componen el plan de gestión del proyecto contemplen las consecuencias de ese cambio.

    Para finalizar debo comentarte que es un error común confundir el ciclo de vida del desarrollo del software con los grupos de procesos del PMBOK, y por eso todos hemos encontrado al principio inconsistencias entre este modelo y el desarrollo de software, la cosa se simplifica cuando dividimos un proyecto en fases y aplicamos los grupos de procesos del PMBOK a cada una de las fases del proyecto (requerimientos, diseño, desarrollo, …)

    Espero haber ayudado.

    Un saludo,

  3. ME PARECE QUE ESTE ARTICULO TIENE INFORMACION MUY IMPORTANTE SOBRE LAS METODOLOGIAS Y SUS CARACTERISTICAS.

    LO VEO IMPORTANTE YA QUE ESTOY EN LA INVESTIGACION DE UNA METODOLOGIA PARA EL DESARROLLO DE MI PROYECTO DE GRADO Y ESTE ARTICULO ME UBICO UN POCO MAS SOBRE LO QUE QUIERO DESARROLLAR Y DE QUE FORMA GRACIAS…

  4. Me parece que hay un error en la descripción de Agile Modeling, ya que la misma no reemplaza de ninguna forma a UML; a lo que se refiere el Agile Modeling es a aplicar valores, principios y prácticas “ágiles” a otras metodologías de desarrollo de software, a fin de complementarlas.
    Espero que haya sido de ayuda. Sino dirigirse a http://www.agilemodeling.com

  5. De acuerdo con Manuel.

    Además, opino que las metodologías ágiles solamente funcionarían para proyectos pequeños y donde, efectivamente, el equipo de proyecto (incluido cliente y usuario) esté integrado por personas con capacidades interpersonales adecuadas. Lamentablemente, la realidad nos dice que esto último se poquísimas veces.

  6. UML no es una metodología, es un lenguaje para representar nuestros diseños que, como comentas, se usan también en las metodologías agiles “(…)la documentación es necesaria dado que permiten la transferencia del conocimiento, pero su redacción debe limitarse a aquello que aporte valor directo al producto/servicio (…)”, y lo mejor para hacer una documentación legible, no ambigua y abstracta es usar UML

  7. Me parece un poco deliberado la forma es como se presenta la metodología predictiva, si bien es cierto que la agilidad te prepara para cambios como le dices eso a un cliente que esta pagando por un proyecto en una fecha determinada. A veces las personas se aprovechan de la confianza que se les da o de los cambios para no entregar a tiempo y eso se traduce en perder dinero y la confianza del cliente. Hay que ser más fexibles y aprovechar los beneficios que brindan ambas metodologías.

Leave a Reply to Lucy Cancel reply

Your email address will not be published. Required fields are marked *