¿Qué métodos ágiles existen?

Cuando entré en el mundo de Scrum se me encendió una luz la cual espero que no se me apague nunca. Pero al mismo tiempo se me presentaron muchas sombras de ignorancia. Así que hice un barrido de los marcos de trabajo ágiles existentes para tener una idea de su objetivo y tener más seguridad en la toma de decisiones. Os hago una pincelada de cada una de ellas para que os suene y si alguna en particular os encaja podáis ampliar conocimientos a través de los artículos que los gurús comparten con nosotros, los simples mortales.

Scrum

Es el marco de trabajo ágil más famoso. El corazón del Scrum es el Sprint (me ha quedado un poco título de película) y es que todo gira entorno al Sprint. El Sprint es simplemente un periodo fijo de tiempo que puede ir desde la semana hasta el mes y que se va repitiendo. Dentro de este periodo de tiempo tendrán lugar las sesiones Scrum que nos ayudarán a construir nuestro producto. Puede que haya sido demasiado simplista pero ha sido apropósito y es que Scrum es una propuesta de forma de trabajar que te deja espacio para moldearla a las necesidades del producto, del equipo y del entorno. Intento hacer un resumen rápido que podréis ampliar por vuestra cuenta si os interesa.

El producto que vamos a crear se detalla dentro del Product Backlog que consiste en una pila de requerimientos explicados a través de Historias de Usuario. Podriamos decir que cada historia de usuario es una funcionalidad a desarrollar aunque esta funcionalidad debe poderse desarrollar dentro del Sprint, debe poderse iniciar y finalizar en este periodo fijo de tiempo. Si no da tiempo debemos dividir la historia de usuario hasta que de tiempo de hacerse.

Un equipo Scrum se compone de 3 roles:

• El product owner. Es el propietario del producto, por tanto es el propietario de Product Backlog. Es quién tiene el conocimiento de qué de debe hacer y con qué prioridad por lo que siempre debe tener el Product Backlog ordenado y informado.
• El scrum master. Es la persona que ayuda al equipo en todo lo que puede. Lo ayuda a seguir los principios de Scrum, lo ayuda a desbloquear impedimentos, lo guía en la búsqueda de soluciones, lo ayuda a resolver conflictos.
• El equipo. Es el responsable del desarrollo del producto. Dentro del equipo participarán los perfiles necesarios para poder realizar la construcción del producto de forma independiente.

Como os he comentado en Scrum se iteran Sprints y dentro de cada Sprint tienen lugar varias sesiones:

• Sprint Planning. Esta sesión la lidera el Product Owner y es donde en base a la priorización del Product Backlog se decide las historias de usuario que se crearán durante ese Sprint.
• Daily Meeting. Sesión diaria que realiza el equipo para sincronizarse en los desarrollos y notificar los bloqueos e impedimentos surgidos. En esta sesión deben asistir los miembros del equipo de desarrollo aunque es recomendable que también participe el Scrum Master para poder ayudar a resolver los impedimentos lo antes posible.
• Sprint Refinement. Sesión en la el Product Owner explica al equipo cuales serán las siguientes historias de usuario prioritarias para que el equipo de desarrollo las empiece a analizar y pueda resolver dudas o plantear impedimentos. Si estas sesiones se realizan con calidad la Sprint Planning se ve muy beneficiada ya que hay mucho trabajo avanzado.
• Sprint Review. Al terminar el Sprint se realiza una sesión liderada por el equipo donde este muestra el trabajo realizado al Product Owner y a cualquiera que pueda aportar valor a la revisión del producto entregado. El objetivo de asegurar que se vamos por buen camino.
• Retrospectiva. Después de la Review se realiza otra sesión para comentar entre todos cómo se ha vivido el Sprint. El objetivo es detectar puntos del trabajo en equipo que se pueden mejorar y proponer acciones a realizar para que esa mejora se produzca.

Lean Startup

Este método de trabajo me atrajo porqué contiene la palabra «Startup» y para alguien con mi clásica trayectoria esta palabra es muy atractiva y exótica.

Su principal objetivo es ayudar a la definición de productos y modelos de negocio con el menor riesgo posible. Para ello la clave es la experimentación: testear con el cliente lo antes posible la hipotesis de negocio para verificar si funciona o no.

Para definir el producto inicial se basa en el Mínimo Producto Viable (MVP) que consiste en definir las funcionalidades mínimas que creemos que debemos ofrecer al cliente para que el producto creado sea el que el cliente necesita. [De hecho el MVP se puede aplicar a la vida, yo lo he aplicado a las reformas que he realizado en casa y he conseguido la funcionalidad que quería gastando la mitad del presupuesto.]

Una vez tenemos este MPV en el mercado entramos en el avance por ciclos. El ciclo es muy simple: negocio plantea una propuesta de valor, se incorpora en el producto, se entrega al cliente y se evalúa a través de métricas el éxito de la propuesta. De esta forma si la propuesta no gusta al cliente podemos cambiarla lo antes posible. De este cambio de rumbo se llama Pivotar.

Kanban

Por si no lo había dicho antes es mi método favorito porqué te muestra de forma clara y organizada todo el flujo de trabajo. Se usa mucho para gestionar productos en los que es muy complicado planificar el trabajo: interrupciones, cambios, dependencias,…

La herramienta central de Kanban es su panel. En él se refleja el flujo de todo el trabajo organizado por columnas, cada columna es un estado por el que pasa el ítem del backlog. El Backlog se situa en la columna de la izquierda y cada ítem irá avanzando por cada estado a medida que se vaya completando hasta que esté terminado (último de los estados).

Este panel tan visual hace que todos los implicados tengan la misma visión de la situación del producto. Además facilita la detección de problemas y cuellos de botella por lo que se puede actuar antes sobre los impedimentos aumentando la eficiencia y la calidad.

Esta metodología es muy aconsejable si se quiere cambiar gradualmente a un método de trabajo ágil.

Dynamic Systems Development Method (DSDM)

Creada en los 90s en el Reino Unido este marco de trabajo se centra en la gestión de desarrollos de software con recursos y fecha de entrega fijos. Es decir, se sabe qué equipos se van a destinar al producto y la fecha en la que se debe realizar la entrega, la variable es la funcionalidad entregada. Esta funcionalidad se prioriza a través de la técnica MOSCOW, Must-Could-Would, dónde los requisitos básicos que seguro se deben implementarse son los Must, los requesitos que estaría genial que se implementaran serían los Could y los requisito que serían un «plus» serían los Would. El producto contendrá todos los requisitos que se hayan podido desarrollar hasta la fecha tope siguiendo este orden. Con ello se consigue tener el mejor producto posible con los recursos y tiempo pactados. [Uuuummm… esta estrategia es la que utilizaba yo en la universidad para planificarme el estudio de los exámenes :)]

El ciclo de desarrollo de DSDM está compuesto de 5 fases:

• Pre-proyecto: aunque esta fase no pertenezca propiamente a la gestión de desarrollo se incluye como fase para constatar que a nivel de organización el proyecto es adecuado y tiene un objetivo definido.
• Estudio de viabilidad: en esta fase se detallará un poco más a fondo el proyecto, lo justo para poder validar su viabilidad. Se involucrará a las personas necesarias para poder revisar el proyecto desde la perspectiva técnica – ver si se pueden alcanzar los objetivos del proyecto – y desde la perspectiva de negocio – ver si es rentable.
• Creación de los cimientos. En esta fase deben quedar muy claros el retorno comercial del proyecto y los elementos clave que nos permitirán alcanzarlo. Con esta información se deberá realizar un plan a alto nivel de cómo se gestionará el proyecto, cómo se desarrollará y cómo se diseñará.
• Desarrollo evolutivo. En esta fase es dónde de forma iterativa se irá construyendo el producto. Se seguirán los principios de entrega a tiempo y desarrollo iterativo (el desarrollo se realiza en períodos de tiempo de duración fija).
• Despliegue. Aunque al finalizar cada fase de desarrollo se entreguen desarrollo listos para subir a producción pueden que estos no puedan publicarse y deban esperar a estar alineados con las estrategias de negocio. También puede darse que haya varios desarrollos implicados y deban alinearse entre sí para poder realizar la publicación. Lo ideal sería poder realizar publicaciones lo antes posible para recibir comentarios de los clientes cuanto antes.
• Post-desarrollo: fase en la que se analiza los beneficios del proyecto. Al igual que la fase de Pre-Proyecto no es propia de la gestión del proyecto pero se incluye para dar visión a los niveles superiores.

eXtreme Programming

Este método ágil se centra en el desarrollo de software cuyos requisitos no están muy cerrados. Las iteraciones son de periodos muy cortos y la creación del producto se realiza de forma incremental a todos los niveles. por eso en cada iteración se realizará un ciclo completo de análisis, diseño, desarrollo y pruebas. Su piedra angular son las pruebas: propone que las pruebas las definan los programadores mientras van programando y que se implementen pruebas automáticas lo antes posible.

XP se basa en cinco valores: comunicación, simplicidad, feedback, coraje y respeto. Como estos valores son demasiado abstractos se definieron 14 principios útiles para realizar un mejor desarrollo. Juntando los valores y los principios XP propone 13 prácticas primarias y 11 prácticas corolario.

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.

Lean Software development

Lean Software Development no es tanto un método ágil como una adaptación del “Lean Manufacturing” de Toyota al desarrollo software ágil.

El lean software development se rige bajo 7 principios fundamentales, que al aplicarse correctamente en el desarrollo de software dan como resultado sistemas más eficientes: reducción del tiempo de entrega y mejora de la calidad.

1. Eliminar desperdicios. Tan sencillo como suprimir todo aquello que no le aporte valor al cliente. Si el cliente no lo necesita directamente no se debe hacer.
2. Ampliar el aprendizaje. Los miembros del equipo deben tener la mente abierta a aprender sobre la marcha, deben sentirse cómodos en ir aprendiendo a mesura que se vayan detectando las necesidades. Se dispone de un plan pero se debe estar preparado para aceptar los cambios sea cual sea su orgien.
3. Decidir lo más tarde posible. Este principio me ha costado de entender ya que parece totalmente contraproducente pero tiene toda la lógica. Indica que las decisiones se deben tomar cuando ya te vas a poner con ello, lo más tarde posible. Así evitar revisar decisiones al llegar cambios de última hora. Mejor esperar al último momento cuando ya se tiene todo claro y no hay lugar a cambios.
4. Entregar tan rápido como sea posible. Cómo en cualquier modelo ágil las funcionalidades se intentarán lo antes posible para poder validarlas.
5. Potenciar el equipo. Un equipo motivado es importantísimo para conseguir que el proyecto avance a buen ritmo. Empoderar al equipo de desarrollo es clave; que participen en la valoración de esfuerzo de las tareas y que aporten su visión en la priorización de las mismas no sólo da robustez a la toma de decisiones sino que hace que las personas sientan que su opinión es valiosa.
6. Crear la integridad. La calidad debe ser considerada en todo momento para que los defectos sean detectados lo antes posible. Pruebas de integración, pruebas automatizadas, pruebas de usabilidad,… la calidad debe estar presente de forma constante en todo el proceso.
7. Visualizar todo el conjunto. No debemos perder la visión del global. Es importante abrir el foco más allá de nuestro equipo para visualizarlo dentro del entorno global de nuestra organización para lograr una optimización completa.

Feature Driven Development (FDD)

Lo podríamos traducir por «desarrollo basado en funcionalidades» y fue creado a finales de los 90. Este framework ágil se entra en el diseño y la construcción del producto, es decir, en el desarrollo y está basado en conceptos incrementales e iterativos poniendo mucho foco en la calidad.

FDD define 5 procesos dónde los 2 primeros se realizan de forma secuencial (serían como el Sprint 0 de Scrum) y los demás son iterativos: 

• Develop an overall model (Crear el modelo global). Al inicio el equipo debe centrarse más en el alcance general del producto y el contexto que en el contenido detallado. En esta fase se deben analizar los requisitos a alto nivel: el público objetivo, contexto dónde se utilizará su software, el contenido imprescindible que debe tener el producto y un primer esbozo de la experiencia de cliente.
• Build a feature list (Crear una lista de características). A continuación, el equipo identificará qué funcionalidades son las necesarias para cumplir con el modelo global. Los desarrolladores participarán en esta fase para aportar su visión técnica.
• Plan by feature (Planificar por función). La fase de planificación es fundamental en FDD. El equipo debe realizar un plan a alto nivel para organizar las entregas. Debe hacerlo teniendo en cuenta la priorización y las dependencias de las funcionalidades.
• Design by feature (Diseñar). En esta fase se debe diseñar de forma simultánea y colaborativa las funcionalidades seleccionadas. Se realizará de forma iterativa y siempre le seguirá la fase de construcción.
• Build by feature (Construir). La construcción también se realiza de forma simultánea individualmentes y una vez finalizados todos los componentes se ensamblan. En esta fase se realizarán pruebas unitarias, pruebas integradas y revisión de código. Una vez terminada la construcción si quedan funcionalidades por crear se vuelve a la fase de diseño.

Repito lo que os he comentado al principio, aquí sólo os expongo muy por encima los objetivos y dinámicas de estas metodologías, yo no soy ninguna experta, si alguna os encaja os emplazo a ampliar la información en blogs y webs de expertos.