Introducción

Durante mi corta experiencia como desarrollador, me he dado cuenta de que tengo cierta tendencia a valorar el "picar código" sobre otras cosas. Probablemente porque es lo que más divertido me parece de este trabajo, la sensación de resolver un reto de lógica, y también, porque ver como toma forma el código de una aplicación da una sensación directa de avance.

Aun así soy consciente, y trato de recordarme a menudo, que el objetivo final no es programar sino aportar valor. Y aportar valor puede no ser tan obvio a priori, de hecho, depende de muchas variables del contexto en el que estás trabajando.

Mi contexto

Tengo la suerte de que el equipo en el que estoy ahora mismo, está compuesto casi en su totalidad por gente recién incorporada a la empresa colaboradora. Esto significa que además de tener poco contexto del dominio de negocio, aplicaciones internas, sus modelos de datos, etc., somos un equipo que no se conoce y está experimentando y ajustándose a la forma de trabajar que mejor encaje con nosotros. Esto me ha hecho apreciar la importancia de las Metodologías de Gestión de Proyectos (PM - Project Management), especialmente durante las últimas semanas.

Desde que empecé hemos estado usando Kanbanize, una herramienta online para gestionar el flujo de trabajo, y hemos estado hablando de sprints, dailies, planning, retros, backlog, WIP, etc. Terminología que me resultaba familiar, de asignaturas relacionadas con la gestión de proyectos que cursé en el grado, y a la que no daba demasiada importancia.

Pero a medida que pasaba el tiempo, se unía más gente al equipo, los requisitos del desarrollo cambiaban y las stakeholders se preocupaban por la falta de visibilidad de nuestro trabajo y un deadline muy marcado por cambios legislativos acercándose. Cada vez se hacía más evidente la necesidad de ser metódicos en nuestra forma de trabajar y dejar de hacer las cosas de forma "intuitiva" (incluso llegando a ignorar nuestro tablero de Kanbanize).

Esta necesidad es la que me ha dado curiosidad por leer un poco sobre el tema, refrescar conceptos y escribir este artículo, donde repasaré las metodologías Scrum y Kanban, que son las que trata de usar mi equipo.

Scrum

La idea del Scrum es crear equipos autogestionados con diferentes roles, de 10 personas como máximo, que dividen el desarrollo en iteraciones y llevan un seguimiento constante del mismo en cada una, mejorando así la comunicación, el trabajo en equipo y la velocidad a la que se entrega valor al cliente.

Sus características principales son:

• Roles del equipo
  • Product Owner - Representante de los stakeholders, "mediador" entre el cliente y el equipo técnico.
  • Scrum Master - Similar a un Project Manager, es la figura encargada de que se siga rigurosamente la metodología y sirve de apoyo al resto de roles.
  • Developers - Parte técnica del equipo que lleva a cabo el desarrollo.
• Flujo de trabajo
  • Sprints - Intervalos de tiempo o iteraciones en las que se divide el desarrollo, generalmente de 2 semanas, nunca más de un mes.
  • Backlog - "Almacén" de tareas para el equipo: descomposición de requisitos, historias de usuario y casos de uso, bug fixes, etc. Las tareas deben estar ordenadas según su prioridad.
    • Product backlog - Backlog general para todo el proyecto.
    • Spring backlog - Backlog que contiene tareas para realizar en un sprint concreto.
  • Ceremonias
    • Sprint planning - Reunión del equipo previa a un sprint para definir su alcance y acordar un sprint backlog que llevar a cabo.
    • Daily scrum - Reunión diaria de máximo 15 minutos donde se comenta cómo va el desarrollo y si hay algún impedimento que esté bloqueando al equipo.
    • Backlog refinement - Revisión periódica de las tareas del product backlog para comprobar que están correctamente priorizadas y definidas.
    • Sprint review - Presentación del trabajo realizado a los stakeholders.
    • Sprint retrospective - Reflexión sobre cómo se ha desarrollado el sprint: qué ha ido bien, qué ha ido mal, y qué se puede mejorar.

Kanban

Es similar a Scrum pero plantea una forma más flexible de trabajar, sin roles ni ceremonias predefinidos, centrándose en dar visibilidad al trabajo que se está haciendo y tratando de no abarcar demasiado a la vez.

Sus características principales son:

• Tablero Kanban - La herramienta principal de esta metodología para representar de forma visual el flujo de trabajo. Se trata de una serie de columnas que definen distintos estados entre los que se mueven de forma unidireccional las tareas que realiza el equipo. Aunque se puede volver tan complejo como se requiera, puede categorizarse en algo tan simple como:
  • To-Do - Tareas a realizar (como el backlog en Scrum).
  • Work In Progress - Tareas que se están realizando.
  • Done - Tareas que se han realizado.
• Limitación del WIP - Para mejorar la calidad de las entregas, Kanban le da importancia a limitar el número de tareas que se están realizando, de forma que el equipo pueda concentrarse en lo que está desarrollando y, si llega a bloquearse alguna de las tareas del WIP, se trate de resolver ese bloqueo en lugar de seguir abriendo más tareas sin llegar a terminar el resto.
• Medición del tiempo de entrega - Midiendo el tiempo que permanecen las tareas en cada una de las columnas, se pueden extraer métricas que ayuden al equipo a entender cómo están trabajando y qué puntos pueden mejorar.

Scrumban

Parece que es tan popular combinar Scrum y Kanban que es común encontrarse el término "Scrumban" como una tercera metodología. Consiste básicamente en aplicar la flexibilidad, visibilidad y foco en el WIP de Kanban a la estructura de Scrum:

• Los sprints tendrán la menor duración posible, tratando de no superar las 2 semanas.
• La planificación se hace on-demand cuando se va vaciando el backlog del sprint (la columna To-Do en Kanban), a medida que los propios developers escogen sus tareas haciendo pulling.
• Se sigue aplicando la limitación de tareas en WIP de Kanban según la capacidad del equipo.
• Se siguen manteniendo las dailies, retros y reviews de Scrum para mantener un seguimiento de la actividad del equipo y continuar puliendo su forma de trabajar.
• Se puede añadir planificación a medio/largo plazo a Kanban subdividiendo la columna del backlog del producto en otras como una lista de objetivos deseables*,* una lista de tareas con mayor nivel de definición basadas en los objetivos, y una lista de tareas ya refinadas preparadas para incluirse en el backlog del sprint.

Conclusiones

Aunque es útil tener una base teórica como guía para estandarizar la forma de trabajar, y Scrum y Kanban son metodologías populares con un planteamiento sencillo e intuitivo, en la práctica todo puede cambiar y la comunicación no es algo tan trivial como puede parecer.

Yo mismo, he experimentado en primera persona la necesidad de un mínimo de comprensión mutua y comunicación fluida con el cliente -stakeholders en mi caso- para llevar a cabo correctamente metodologías ágiles como estas.

En casos de gran incertidumbre y requisitos no definidos del todo, las metodologías más flexibles parecen funcionar mejor para evitar perder tiempo y recursos en desarrollos que luego acaban desechados porque no casan con los cambios de última hora. Pero adoptar esta mentalidad no sirve de nada si se hace de forma unilateral y el cliente adopta una postura más clásica, en la que cada iteración debe acabar entregando en bloque todo lo desarrollado para que pueda validarse, o todo lo contrario, que se tome la flexibilidad como el poder aplazar la definición concreta de los requisitos.

Es por eso que, aunque parezca una conclusión obvia, lo esencial es comunicarse. Y no se trata de tener razón, sino de escuchar y llegar a un acuerdo que nos beneficie a todos, ya que volviendo al principio: el objetivo final es entregar valor.