Métodos ágiles más usados

En este post hablaremos de los métodos ágiles más usados.

Ya conoces los valores que definen el agilismo, a saber:

  • Individuos e interacciones sobre procesos y herramientas
  • Software funcionando sobre documentación extensiva
  • Colaboración con el cliente sobre negociación contractual
  • Respuesta ante el cambio sobre seguir un plan

Pues bien, si ya decidiste ser agile y te comprometiste con estos valores ya sea en tu empresa o en ese proyecto que está a punto de nacer, ¿por dónde empezar? ¿cómo llevar a la práctica eso de ser ágiles?

En resumen, ¿qué métodología agile uso?

En la práctica hay varias metodologías y marcos de trabajo basados en los principios agile. En este artículo te resumiré los métodos ágiles más populares.

No te preocupes si no entendiste mucho, ya iremos profundizando en estos métodos ágiles en siguientes artículos hasta que termines siendo un experto y los puedas poner a funcionar perfectamente en tu empresa. No pretendas ser agile de un día para otro…

Programación eXtrema: aplicando las mejores prácticas de programación

La Programación eXtrema (eXtreme Programming), conocida también por su acrónimo XP, es de las primeras metodologías de desarrollo de software que podríamos considerar agile, aunque en su concepción no se usase aún este apelativo.

Comenzó a gestarse en la década de los 80, pero no fue hasta el año 1999 cuando Kent Beck, su creador, la formuló en su libro Extreme Programming Explained: Embrace Change.

XP se puede resumir como un compendio de las buenas prácticas de programación que existían hasta el momento de su creación, cuyo núcleo era la filosofía de trabajo del lenguaje orientado a objetos Smalltalk. A partir de ahí XP ha seguido evolucionando a través de la incorporación de las buenas prácticas de la moderna programación. De hecho, el 2004 Kent Beck publicó la segunda edición de su libro.

Pero además de estas buenas prácticas de programación, XP terminó añadiendo varias prácticas de gestión heredadas de Scrum, de modo que existe un gran paralelismo entre Scrum y XP hasta el punto de que forman un muy buen tándem.

De hecho, XP es compatible con cualquier otro marco de trabajo ágil, ya que las prácticas de XP no contravienen a los ciclos de vida de dichos métodos.

Características de XP

Quizá lo más significativo que podemos decir de XP es que nació para responder con solvencia a los cambios de alcance en un proyecto software, independientemente de cuán avanzado esté el proyecto. Esto la hace ideal en proyectos que presentan requisitos vagos y cambiantes donde habrá que adaptarse a los cambios con naturalidad.

Como segunda característica podemos decir que XP pone especial foco en las personas, tanto en los que desarrollan como en los clientes.

El modelo de trabajo es iterativo (trabajamos mediante iteraciones de una semana) e incremental (vamos añadiendo funcionalidad iteración tras iteración, yendo siempre de lo más prioritario a lo menos).

Prácticas utilizadas en XP

Al principio de cada iteración se realizará una planificación (iteration planning) de lo que se pretende abordar en esa iteración. Al final de cada iteración se obtendrá feedback del cliente de modo que estemos siempre alineados con sus expectativas.

En cada iteración se realizará un ciclo completo de análisis, diseño, desarrollo y pruebas, siempre a través de las reglas y prácticas recomendadas por XP.

XP aboga por poner énfasis en las pruebas, que se escribirán por los propios desarrolladores a medida que codifican, incluyendo pruebas automatizadas que se ejecutarán continuamente, de esta forma, el error se detecta lo antes posible y no se produce un efecto bola de nieve que termine por generar una deuda técnica.

Además, se realizará integración continua. Todo ello orientado a un software robusto. Estas dos características de XP son especialmente relevantes y se usan en mayoría de métodos ágiles.

Se realizarán stand-up meetings diarias de coordinación de equipo.

Al final de cada iteración se generan unos entregables funcionales.

A modo de resumen, te dejo este esquema de XP:

Ciclo de vida de XP

XP se aplica a partir de trece prácticas primarias (o sea, imprescindibles) y onde prácticas corolario (anexo que se aplicaría cuando el grado de madurez con el que se aplican las primarias permite dar un paso más).

Prácticas XP Primarias

  1. Trabajar con Historias de Usuario (o sea, requisitos redactados con lenguaje “cliente”).
  2. Realizar ciclos semanales de desarrollo (iteraciones).
  3. Realizar revisiones trimestrales para evaluar estado del equipo, proyecto y procesos y analizar posibles impedimentos.
  4. Trabajar con holgura, es decir, no saturar de trabajo al equipo al planificar cada iteración.
  5. El equipo debe sentarse junto.
  6. El equipo debe contar con todos los perfiles para poder desarrollar el producto.
  7. Tener la información sobre el proyecto y las tareas a realizar en el puesto de trabajo al alcance de todo el equipo.
  8. Mantener la energía en el trabajo a un ritmo sostenible evitando distracciones que conduzcan a echar más horas de trabajo.
  9. Realizar frecuentemente programación en parejas (pair programming), ¡dos cabezas piensan mejor que una!
  10. Diseño evolutivo o incremental a medida que vamos desarrollando. Refactorizar código con frecuencia.
  11. Realizar las pruebas antes de programar. (TDD – desarrollo dirigido por pruebas).
  12. Integración continua, aproximadamente cada dos horas.
  13. El producto debe poder compilarse y probarse en 10 minutos automáticamente.

Prácticas XP Corolario

  1. Participación real de los clientes. Por supuesto, esto implica todo un cambio cultural en la organización.
  2. Despliegue incremental. Modificar las funcionalidades poco a poco.
  3. Negocie el alcance del contrato a lo largo del desarrollo, incluso negociando varios contratos de duración corta cada uno con su alcance.
  4. Pagar por funcionalidad desarrollada en vez de por entrega.
  5. Continuidad de los equipos para que no se pierda expertise.
  6. Reducir los equipos, dividiéndolos en caso de tener demasiados miembros.
  7. Análisis de las causas de los problemas para eliminarlos de raíz.
  8. Código y pruebas, manteniéndolos continuamente.
  9. Código compartido, el código es de todos y cualquiera puede modificarlo.
  10. Código base único, evitando en la medida de lo posible desarrollos paralelos.
  11. Despliegue diario.

Scrum: el método agile más popular

Scrum es el referente dentro de los métodos ágiles. No digo que sea el mejor ni el más adecuado, ya que eso dependerá de cada proyecto y del gusto personal de cada uno, pero lo que sí es indiscutible es que es el método agile más utilizado.

A lo largo de este blog utilizaremos Scrum como el principal método ágil y gran parte del contenido versará sobre Scrum.

Características de Scrum

Scrum es un método iterativo e incremental:

Iterativo

Porque iremos trabajando de forma cíclica mediante breves periodos que irán de 1-4 semanas tal que tras cada ciclo o iteración generaremos un entregable. En Scrum a estas iteraciones las llamamos en Sprints.

Incremental

Porque en cada iteración o Sprint iremos mejorando y añadiendo funcionalidades a las realizadas en las iteraciones previas, siempre partiendo de la base que las funcionalidades principales deben ir desarrollándose antes que las menos prioritarias.

Hay que señalar que Scrum no es una metodología como tal, sino un framework o marco de trabajo. Esto lo que viene a significar es que Scrum te da una serie de pautas de trabajo, pero no aconseja ninguna práctica en particular a la hora de llevarlo a cabo.

Por ejemplo, Scrum te indica que realices reuniones (Retrospectivas) para evaluar el rendimiento del equipo una vez acabado el Sprint y tratar de mejorar de cara a la siguiente iteración, pero la guía se queda en algunas pautas y poco más. No esperes que te lleve de la mano ni te diga cómo realizar exactamente una retrospectiva.

Esta forma de proceder tiene sus pros y sus contras: Scrum da mucha flexibilidad a la hora de aplicarlo, pero esta laxitud hace que no siempre su implementación en los proyectos sea la correcta. Por eso, la experiencia de los participantes del proyecto es vital a la hora de aplicar un Scrum óptimo.

Cómo funciona Scrum

El esquema de trabajo de Scrum es el siguiente:

Scrum

Ahora no incidiré mucho en este flujo de trabajo, pues ya habrá tiempo de profundizar. Podemos resumirlo en que partimos de un Product Backlog, que es una pila que contiene todos los requisitos de negocio (PBIs – Product Backlog Items), definidos y priorizados por el Product Owner de tal forma que el Equipo de Desarrollo sepa en qué debe trabajar.

Eventos de Scrum

Al principio de cada iteración (recuerda, llamada Sprint en la jerga Scrum, y que durará de 1-4 semanas) se realizará una reunión de planificación o Sprint Planning para que el Equipo de Desarrollo sepa qué y cómo abordar los requerimientos del Product Backlog que corresponderán a ese Sprint y los irá desarrollando a lo largo de éste. El trabajo a realizar en ese Sprint se puede sintetizar en un objetivo o Sprint Goal. Las tareas a realizar durante ese Sprint formarán una lista de trabajo denominada Sprint Backlog.

Diariamente, el equipo tendrá una reunión de no más de 15 minutos llamada habitualmente Daily Scrum, que servirá para sincronizarse, no perder foco del trabajo a realizar en dicha jornada y levantar cualquier posible impedimento que puede afectar o frenar el trabajo.

Al final del Sprint se celebrará una reunión llamada de Revisión o Sprint Review en la que el Equipo de Desarrollo mostrará el trabajo realizado durante el Sprint (denominamos a este entregable incremento) y recibirá feedback del Product Owner y de los usuarios y demás participantes del proyecto.

Por último, antes de dar carpetazo a ese Sprint y comenzar con la siguiente iteración, se celebrará una reunión llamada de Retrospectiva o Sprint Retrospective en la que se revisará cómo se ha estado trabajando durante el Sprint, con la idea de buscar en qué mejorar para la próxima iteración. En Scrum, la mejora continua es imprescindible.

Roles de Scrum

Hay tres roles principales en Scrum: el Equipo de Desarrollo (los que construyen el producto), el Product Owner (representante de negocio y de los usuarios que proporciona los requerimientos que recoge el Product Backlog y los priorizará conforme a las necesidades del producto) y el Scrum Master (experto en el método Scrum que hará, entre otras cosas, de coach para el Equipo de Desarrollo y el Product Owner).

Lo dejo aquí, ya iremos profundizando en posteriores artículos.

Métodos ágiles Lean

No me enrollo aquí. Los métodos ágiles basados en la filosofía Lean dan para un siguiente post. ¡No te lo pierdas!

Te puede interesar:

Si te quedaron dudas puedes dejarlas en la sección de comentarios, estaré encantado de responderte.

Y si el artículo te ha resultado útil, te agradeceré mucho que lo compartas en alguna de las siguientes redes sociales. ¡Nos vemos en el próximo post!

Deja un comentario