Metodologías LEAN – Cómo gestionar la incertidumbre. Scrum + Kanban

¿Qué es LEAN?

Es una manera de entregar valor a un cliente(cliente, colaborador, empleado) aplicando una mejora continua a través de procesos optimizados. El objetivo es realizar pequeñas mejoras en procesos que se pueden obtener rápidamente y que permite resultados visibles a corto plazo, es decir, menos es más.

Todo ello empezó con la historia de la producción de Toyota. Desarrollaron un sistema de producción llamado «Lean Manufacturing» que permitió la reducción de costes y la mejora de la eficiencia de la productividad siguiendo un modelo de producción ajustada, es decir, producir lo necesario, en el tiempo adecuado y en la cantidad necesaria. Véase en el libro: “Las claves del éxito de Toyota”.

Curiosamente, el término “Lean Manufacturing” no se hizo popular hasta la llegada de James Womack con su libro “La máquina que cambió el mundo” en los años 90.

15 años después, un tipo llamado Eric Ries volvió a examinar la metodología LEAN adaptándola a personas interesadas en llevar su negocio de manera ágil y asertiva. Eric definió su libro “The Lean Startup” como una manera de abordar el lanzamiento de negocios y productos basados en el aprendizaje validado, experimentación científica e iteración con el cliente.

Cómo consecuencia de Lean, nacieron las conocidas metodologías ágiles o Agile.

Metodología Scrum + Kanban

Scrum es la metodología ágil más usada en todo el mundo y el que más equipos de desarrolladores usan. Su uso requiere de una serie de pautas a seguir. Es fácil de entender pero es más complicado de implementar.

Los principales objetivos de esta metodología son: trabajar en equipo, realizar entregas de entre 2 a 4 semanas, mejorar la productividad y calidad del producto, alineamiento entre el cliente y el equipo de desarrollo, anticipación de resultados, flexibilidad y adaptación, y reducción de riesgos.

Roles Scrum

Product Owner. Es el cabecilla encargado de priorizar los objetivos a seguir para maximizar el trabajo del equipo. También se encarga de saber lo que quieren los clientes y es el representate de los stakeholders(personas interesadas en el proyecto: desarrollo, negocio, etc). Construye el correcto producto. Valores: proactividad, negociador, foco, comunicador, etc.

Scrum Master. Es el árbitro y jefe de equipo. Su tarea es la de asegurar que se cumplen las buenas prácticas y valores seguidos por la metodología Scrum. Dirige la rápida construcción del producto. Valores: protector, discreto, empático, inspirador, accesible, etc.

Scrum Team. Más conocidos como desarrolladores, están a cargo del diseño, desarrollo y mantenimiento del producto.

Sprint Planning

Un sprint es una prolongación en el tiempo dónde se definirán una serie de tareas a realizar. En función de la magnitud del proyecto y dificultad, los sprints tienen una duración de entre 1 y 4 semanas. Por defecto son 2 semanas.

Backlog o requerimientos de producto. Es un listado de tareas global con sus características que define todo lo necesario para el correcto funcionamiento y desarrollo del producto.

Sprint planning meeting. Volviendo al punto anterior, se procede a realizar una reunión. Se define el número de tareas a realizar durante ese sprint y se priorizan. El scrum master se encargará de leer las tareas y a posteriori, los desarrolladores usando scrum poker cards, votarán cada una de las tareas a realizar haciendo referencia a la dificultad y tiempo de elaboración de dicha tarea. Estas siguen la serie de Fibonacci. Una vez cerrado el sprint backlog, el equipo se compromete a cumplir dichas tareas.

Finalizado el meeting, las tareas a realizar se agrupan en un Kanban. Kanban es un método para gestionar el trabajo. Se pinta una tabla con cuatro columnas: To Do List, In Progress, Testing y Done. Para las stand up meeting, con frecuencia se pinta el kanban en una pizzarra y con post-it se pegan las tareas. En el caso digital, se emplea Trello, Jira(más corporativo) o Jira + Trello.

  • To Do List: Agrupa todas las tareas de dicho sprint. Cada desarrollador se asigna una o varias tareas.
  • In Progress: Una vez arrancada una tarea, el desarrollador trasladará dicha tarea a esta columna indicando que está en fase de desarrollo.
  • Testing: Finalizada la tarea, se pasará a dicha columna para realizar las pruebas correspondientes. Normalmente son pruebas de funcionalidad y e2e (end to end).
  • Done: Una vez realizado el sprint review indicado más abajo, se procederá al cierre de la tarea.

Stand up meeting. Reuniones diarias de máximo 15min en la que los integrantes del equipo de desarrollo se cuentan los avances hechos hasta ese momento y cuales se realizarán durante el mismo día. Esto hace que el equipo esté en sintonía en todo momento. A veces, algún integrante de negocio también participa en estas reuniones, ya sea el business Analyst o product owner.

Sprint Review. Reunión de 2 a 4h realizada el último día del sprint. En ella se junta el equipo de desarrollo, scrum master, el business analyst y product owner para revisar el cierre del sprint. Se hace una comprobación minuciosa de que las tareas realizadas hayan cumplido al pie de letra lo indicado en la misma dentro del producto. Dichas tareas quedarán cerradas y las que no o las que están pendientes, se dará un margen hasta la siguiente reunión o la finalización de ese día que consta como cierre del sprint.

Sprint Retrospective. Una vez llegada a esta reunión, si las tareas del sprint no se han finalizado, se procede a pasarlas al siguiente sprint y queda como una mancha para el equipo de desarrollo, dado que no ha podido cumplir las expectativas que se propuso al inicio del sprint. Otras veces, esta reunión se produce nada más finalizar la sprint review.

En esta reunión, con el objetivo de mejorar la productividad y calidad del producto que se desarrolla, el equipo analiza como ha sido su manera de trabajar durante el sprint, si está consiguiendo los objetivos o no, qué cosas debería mejorar y lecciones aprendidas. De esta manera, se consigue mejorar la comunicación, motivación y productividad del equipo.

Este proceso es cíclico hasta la finalización del proyecto.

Herramientas: Jira, Confluence, Trello.

Bibliografía: «Las claves del éxito de Toyota – Jeffrey K Liker « , “La máquina que cambió el mundo – James Womack«,»The Lean Startup – Eric Ries», «España Lean Startup«, «Por un scrum popular – Tobias Mayer & Alan Cyment«, «Running Lean – Ash Maurya«,

Víctor García de Paredes

Acerca del autor «Víctor García de Paredes»


Desde pequeño he querido hacer grandes cosas en la vida aunque me costó muchos años saber lo que realmente quería hacer. Estudié informática por decisión de mis padres dado que como muchos niños, no sabía qué quería ser de mayor. Tampoco fui buen estudiante, pero siempre conservé una mentalidad emprendedora. Con el tiempo y a base de mucho trabajo, me convertí en un apasionado de las tecnologías y todo lo que conlleva el emprendimiento. Tengo un amor incondicional por aprender cosas nuevas y compartirlas con los demás. Por ello y mucho más diseñé Tecnodumis!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *