A guide to Agile project management types

La estrategia agile, es una fantástica metodología para la gestión de proyectos, pero da los mejores resultados cuando se comprende plenamente. Es importante examinar no sólo los beneficios, si no también los problemas potenciales que pueden surgir al trabajar de forma ágil.

¿Qué esperar cuando trabajas bajo la metodología de gestión de trabajo agile?

La mayor ventaja de la metodología agile, es su flexibilidad. Se tienen en cuenta los cambios que requiera el cliente, al igual que cualquier circunstancia no planeada, el equipo de trabajo trabaja con un alto grado de respuesta ante cualquier evento.

Otra ventaja es la frecuente comunicación y colaboración con el cliente, y su alto grado de implicación en el proyecto. Gracias a esto, se construye una relación basada en la confianza, entre el cliente y el equipo de trabajo.

El cliente tiene mucha mayor visibilidad del progreso del proyecto. El control de calidad está permanentemente presente. El equipo de trabajo reaccionará casi a tiempo real a cualquier demanda del cliente.

Además, es más fácil controlar los costes del proyecto, porque al final de cada paso, sabrás el presupuesto gastado, y cuánto queda. Así, se decide si continuar, revisar o parar el proyecto si los fondos son insuficientes.

¿Qué problemas pueden surgir al trabajar con Agile?

Ya que en agile se pone especial énfasis en la comunicación, la metodología agile no requiere de mucha documentación, lo que en algunas circunstancias puede ser problemático, como cuando hay cambios en el equipo de trabajo.

El cliente debe ser accesible y tener interés en el proyecto. No todos los clientes tienen el tiempo o el deseo de estar plenamente involucrados en la realización de un proyecto.

El modelo agile no es compatible con empresas con una estructura muy jerárquica, ya que requiere un espíritu muy colaborativo.

Permite un alto control de los costes, pero puede resultar difícil determinar un presupuesto para el proyecto. La flexibilidad tiene un coste, que a veces, no todo el mundo está dispuesto a pagar.

Metodología Agile

¡Ok, entonces tu empresa ha decidido adoptar una metodología agile en la gestión de sus proyectos! Pero dentro de todas las metodologías agile, aún debes elegir cuál es la que mejor se adapta al proyecto que tienes entre manos. Hay muchas métodos agile, y puede ser confuso elegir uno. Seguramente hayas escuchado hablar sobre scrum, pero hay muchos más métodos, cada uno con sus respectivas ventajas. Veamos todas las metodologías agile:

Los métodos de agile más populares:

Scrum

La metodología Scrum quizás sea el método más ampliamente conocido o popular. La metodología scrum ha sido especialmente diseñada para la gestión de proyectos informáticos, y debe su nombre al mundo del rugby. Scrum representa la cercanía que tienen los integrantes de un equipo de rugby. El principio en el que se basa Scrum consiste en la capacidad de modificar la dirección de un proyecto en cualquier momento de su progreso.

El scrum es una fase esencial en el rugby, al igual que lo es en la gestión de proyectos. Si no se tienen todas las condiciones necesarias para asegurar el éxito, el proyecto debe ser reorientado y re-iniciado sobre una mejor base. El cliente está altamente implicado, gracias a la entrega continua de prototipos. Esta gestión dinámica hace posible asegurar que las cambiantes necesidades del cliente se corresponden en exactitud con el producto entregado.

Kanban

Kanban es otro de los métodos más conocidos, su nombre es un término japonés que significa "tarjetas visuales". Se trata de un Manifesto Agile formalizado en 2010 por David Anderson, aunque el método fue desarrollado por Taiichi Ohno, ingeniero de Toyota. Kanban basa su principio en un número limitado de tareas que se pueden efectuar paralelamente, también conocido como "Work in Progress (WIP)". El objetivo último de Kanban es evitar la pérdida de recursos y tiempo, asegurando la mejora continua durante el progreso del proyecto. El equipo deberá definir el límite del WIP para cada paso del proyecto Kanban. El proceso de trabajo se controla visualmente, y para el equipo es fácil suspender alguna tarea para lidiar con los obstáculos.

El método Kanban se compone de 4 fases:

1. Fase diseño
2. Fase implementación: en esta fase el equipo aplica las prácticas Kanban. Usan las herramientas Kanban para identificar el proceso, definir los elementos del trabajo e implementan las reglas de trabajo.
3. Fase de estudio: Juntos el equipo y el diseñador estudian la reacción del sistema a las normas establecidas durante la primera fase de diseño.
4. Fase de mejora: dependiendo de las conclusiones de la fase de estudio, el equipo ajusta el sistema, estabilizan el proceso, re-organizan los elementos de trabajo y fijan el conjunto de normas.

Extreme Programming (XP)

Extreme Programming o XP, es un método de gestión de proyectos ágil, que se ajusta perfectamente a proyectos de desarrollo informáticos. Fue diseñado por Kent Beck para acelerar nuevos desarrollos mientras trabajaba en Chrysler. La idea surgió cuando Kent tuvo que intervenir en el desarrollo de un software de gestión de pagos, que estaba escrito en Smalltalk, el software había acumulado una gran deuda técnica (consecuencia de un desarrollo apresurado), lo que hacía muy difícil el mantenimiento y el desarrollo del programa.

El principio fundamental del método XP, es la implicación absoluta y total de todas las partes que conforman un proyecto, para que estos colaboren cercanamente, además de plazos de entrega muy cortos. La planificación de tareas es muy flexible, y la estimación de gastos se simplifica por los cortos plazos de cada iteración. Las funcionalidades se entregan regularmente en las cortas iteraciones, para que puedan ser testados y validados mediante la entrega de prototipos.

Una recomendación del XP, es que los desarrolladores trabajen en parejas, ya que facilita la escritura de un código fácilmente legible.

Feature Driven Development (FDD)

El Feature Driven Development o el Desarrollo Basado en Funcionalidades, es un método de gestión de proyectos basado en la gestión de riesgos. Los desarrollos se organizan en iteraciones cortas, alrededor de funciones testadas por usuarios. Lo cual significa que el usuario forma parte del desarrollo y que puede seguir el progreso del proyecto y la validación de funcionalidades. No se recomienda ningún método de programación, siendo la funcionalidad el pilar principal del método.

Un proyecto gestionado por FDD se divide en varias fases principales. La primera fase consiste en la creación de un modelo general del producto. Durante la segunda fase se elabora un listado de características/funcionalidades a crear. En esta 2ª fase es crucial la involucración del cliente. Las funcionalidades se agrupan según las características que tengan en común, y después se priorizan. Las dos últimas fase siguen en forma de iteraciones, y lidian con parte del diseño técnico y su desarrollo.

El método FDD da más importancia a la fase del diseño, incluso, aunque esto signifique empezar con una implementación más lenta, todo con tal de obtener un modelo sólido.

Lean Software Development

El método Lean Software Development se basa en 7 principios. Estos principios son:

1. Eliminar el despilfarro: evitar definir requerimientos tempranamente, procesos y funcionalidades innecesarios, cambiar el equipo y así evitar retrasos.
2. Ampliar el aprendizaje: incrementar el número de recursos de aprendizaje al alcance del equipo.
3. Posponer decisiones: retrasar la toma de decisiones hasta el último momento posible. Esto evita discusiones largas que significan pérdida de tiempo y decisiones tempranas equívocas.
4. Liberar pronto: producir entregas de trabajo rápidas y de forma regular, incrementando la posibilidad de feedback del cliente.
5. Empoderamiento del equipo: promocionar la autonomía del equipo, asumir que saben qué y cómo hacer su trabajo, y facilitar el desarrollo de expertos.
6. Construir calidad: la calidad debe ser el corazón de cada equipo, desde el inicio al fin.
7. Optimizar el sistema como un todo: implementación de métodos de medición para optimizar todos los procesos, y gestionar cada iteración.

Con el método Lean, el núcleo es la calidad, por lo que, todos los procesos, el aprendizaje, las tomas de decisiones y la medición del progreso, tienen un objetivo común, la calidad.

Agile Unified Process (AUP) y Rational Unified Process (RUP)

El Proceso Unificado de Rational o Rational Unified Process (RUP), es un método que mezcla prácticas de gestión de proyectos tanto tradicionales como ágiles. Los desarrollos se basan en iteraciones graduales. Cada iteración sigue un ciclo compuesto por 4 fases. Los desarrollos se guían por casos de estudio, y empiezan por las funcionalidades más genéricas, y finalizan con las funcionalidades más específicas.

Y el Proceso Unificado Ágil o Agile Unified Process (AUP), es una versión simplificada del RUP. Se trata de un método de desarrollo de aplicaciones de negocios, que usan las técnicas ágiles conocidas como TDD (test Driven Development), MDD (Model Driven Development) y la gestión del software.

El método AUP se divide en 4 fases:

1. Launch/Lanzamiento: identificación del alcance del proyecto y definición de la arquitectura potencial del sistema, implicación de las partes interesadas del proyecto y elaboración del presupuesto.
2. Design/Diseño: definición de la arquitectura del sistema y demonstración si fuera necesario.
3. Realization/Realización: desarrollo del software o producto, durante un proceso gradual priorizando según las funcionales.
   
4. Delivery/Entrega: validación e instalación del sistema.

Crystal (Clear/Orange)

El método Crystal Clear está especialmente indicado para pequeños equipos de desarrollo. Idóneamente el equipo consiste en un arquitecto y de 2 a 7 desarrolladores, sentados cerca el uno del otro, para facilitar la comunicación. Se alienta el empleo de pizarras blancas para mejorar el acceso a la información por parte de los integrantes del equipo. El ritmo de desarrollo y entrega es rápido (cada 2 semanas o una vez al mes), para que el testeo pueda sucederse rápidamente.

Durante todo el proceso de desarrollo el equipo continuamente debe cuestionarse a si mismos, para mejorar continuamente.

Dynamic Systems Development Method (DSDM)

El método de Desarrollo de Sistemas Dinámicos (DSDM) está basado en 9 fundamentos: involucración del cliente, equipos autónomos y con poder decisión, transparencia y alta frecuencia de desarrollo, comunicación con las partes interesadas, desarrollo iterativo e incremental, testeo continuo y cooperación de todas las partes involucradas.

Este método requiere un análisis de rutina. El proyecto empieza con un estudio de viabilidad, para decidir si es realista o no. Se escribe un informe, y eventualmente se crea un prototipo para demostrar la viabilidad de la aplicación. Si se decide continuar, se realizar un análisis de funcionalidades, en el que se escriben todas las especificaciones. Desde ese momento, comienzan las iteraciones del diseño técnico y el desarrollo. Y finalmente, se entrega la aplicación.

Adaptive Software Development (ASD)

También conocido como ASD es un método de adaptación continua. Se basa en automatizar e industrializar la mayor parte de procesos posible. Se emplean herramientas de modelación, y crea una "fábrica de software", para generar de forma automática todo el código posible. Los talleres de ingeniería del software permite a los desarrolladores modificar las aplicaciones generadas. No hay ningún ciclo estático.

Behavior Driven Development (BDD)

El Behavior Driven Development, se dirige por el comportamiento, y en él se define un idioma común. En vez de describir las funcionalidades técnicas, las funcionalidades a conseguir se describen por los usuarios. Esto también implica, que los usuarios están muy involucrados en el proyecto. El objetivo a alcanzar se describe mediante ejemplos, facilitándole así a los desarrolladores entender el trabajo a realizar. Para describir los escenarios, se emplea la fórmula "given-whe-then", esta misma fórmula se emplea también para test de no regresión. Los escenarios/ejemplos los escriben conjuntamente los usuarios, los desarrolladores y todos las demás partes involucradas en el proceso.

Domain Driven Design (DDD)

El Domain Driven Design es una técnica de diseño de aplicaciones personalizadas. El diseño es el centro del negocio, y no los aspectos técnicos. Permite la constante comunicación entre el equipo técnico y el funcional (desarrolladores de dominio y expertos del dominio), para juntos alcanzar un modelo/prototipo de la aplicación. Se persigue un lenguaje común para incrementar la comprensión entre ambos equipos.

Test Driven Development (TDD)

El Desarrollo Dirigido por Tests, combina esribir pruebas, programación y escribir código. Las pruebas se escriben antes del código, y cada prueba describe un rasgo de la funcionalidad. El desarrollador escribe el mínimo código posible para la prueba, para qué si en el caso de que no funcione, rápidamente se puede ver a que se debe (en el código del test). Conforme progresa el proyecto se debe simplificar el código lo máximo posible, y continuar testándolo.

Disciplined Agile Delivery (DAD)

También conocido como Entrega Ágil Disciplinada, es un método centrado en la toma de decisiones y la industrialización, y pretende simplificar los procesos, mediante iteraciones graduales y la gestión de proyectos agile. Es particularmente eficiente en combinación con scrum o lean. Se trata de una metodología híbrida diseñada para facilitar la adopción de agile en grandes empresas. DAD puede ayudar a preparar equipos para la futura implementación de la filosofía de trabajo agile.

Enterprise Unified Process (EUP)

El método EUP es una extensión de métodos de industrialización como el anteriormente descrito DAD, un derivado del UP, o del Scrum. El método EUP añade dos fases adicionales al final de los ciclos agile:

1. Puesta en producción: la fase de mantenimiento de sistemas ya producidos.
2. Retirada de producción: la retirada de producción de los sistemas producidos.

La fase de retirada puede ponerse en práctica por diversas razones, como por ejemplo cuando un sistema necesita ser sustituido por otro sistema, durante una redundancia del sistema, o porque el sistema haya quedado obsoleto.