top of page

Una perspectiva de pensamiento lean de scrum


ARTÍCULO: este artículo analiza los diferentes elementos de scrum, un marco de desarrollo de software ágil, visto desde el punto de vista del pensamiento Lean tradicional.


Scrum es un proceso de desarrollo basado en iteraciones y mejoras incrementales que fue creado inicialmente para la gestión de proyectos de software. Sin embargo, muchas de sus características se pueden comparar con principios y herramientas lean y creo que comprender esta relación es fundamental para ayudarnos a alinear el desarrollo de software con la estrategia de la empresa y, en el proceso, generar más valor para nuestros clientes.

La idea principal detrás de scrum, que lo diferencia del modelo en cascada, es proporcionar una serie de entregas a lo largo del proceso de diseño de software. De esta manera, el equipo de desarrollo recibe comentarios continuos de los clientes sobre partes más pequeñas y manejables del producto final y puede mejorarlas (y aprender) mediante pequeños ciclos PDCA.


El concepto de scrum fue desarrollado a principios de la década de 1990 por Jeff Sutherland, con John Scumniotales y Jeff McKenna, y por Ken Schwaber, quienes utilizaron este marco en sus empresas de software y allanaron el camino para su difusión en todo el mundo del software.


La siguiente figura (cortesía de Joost van der Schoot - http://vdschoot.com/agile/scrum/ ) muestra todas las etapas del proceso y las interacciones entre los involucrados:

Veamos ahora algunos de los componentes principales de scrum desde una perspectiva lean “tradicional”.


LOS ROLES EN SCRUM

  • El propietario del producto (PO) representa al cliente en la empresa que está desarrollando el producto. Esta persona es responsable de desarrollar y mantener un Product Backlog (un documento muy detallado que enumera todos los requisitos del producto), definir prioridades dentro del proceso de desarrollo y negociar todos los ajustes posibles a lo largo del camino.

Desde un punto de vista lean : la figura del PO representa una forma inteligente de acelerar el flujo de información entre el cliente y los desarrolladores. Esto reduce el riesgo de retrabajo que tan a menudo aparece en proyectos de desarrollo que no son scrum. Un concepto lean muy importante, que podría estar relacionado con el papel de un PO, es genchi gembutsu ("ir a ver") : conocer bien al cliente y garantizar que, en el gemba, el equipo de desarrollo esté trabajando en la característica correcta del producto y a las especificaciones del cliente es fundamental para el éxito de cualquier iniciativa.

  • El scrum master (SM) es el líder del equipo de desarrollo y establece la relación entre los desarrolladores y el PO. Su función incluye eliminar barreras que obstaculizan el progreso del equipo (por ejemplo, conflictos internos) e involucrar al departamento de infraestructura en caso de que algún componente de hardware deje de funcionar.

Desde un punto de vista lean : las personas son clave para el éxito de una organización. Lean nos enseña que cada líder debe estar en constante contacto con su equipo y conocer lo suficiente a cada miembro para comprender los problemas que encuentra cada día. Esto permite el flujo y por tanto la satisfacción del cliente.

  • El equipo scrum es el grupo de personas que desarrolla el producto, garantiza que su calidad sea excelente y asume la responsabilidad de la entrega al cliente. Aunque tengan un líder, el equipo debe ser autogestionable y multifuncional. La literatura sugiere ampliamente que el número de personas para un equipo scrum debe estar entre cinco y nueve. En su presentación en la Cumbre Lean IT del año pasado en París, Jeff Sutherland dijo que, en su opinión, un equipo ideal debería estar formado por cinco personas.

Desde un punto de vista lean : tener equipos multifuncionales, nos dice lean, permite un flujo rápido de información, porque no sucede esperar la contribución de un miembro del equipo de otra función. Lean Institute Brasil lleva más de 16 años formando personas y tendemos a recomendar que los equipos (por ejemplo para completar un mapa de flujo de valor) no superen los siete miembros.


LAS REUNIONES DE SCRUM

  • Reunión de planificación del Sprint (ocho horas): el Scrum Master, el equipo y el PO participan en esta reunión con el objetivo de diseñar un Sprint Goal (la entrega de una pieza de software funcional) y un Sprint Backlog (la lista de elementos del backlog que el equipo deberá entregar). Las tarjetas de póquer se utilizan comúnmente para asignar puntos a cada historia de usuario o tarea, para comprender cuánto tiempo y recursos llevará desarrollarla: cada miembro elige una tarjeta con el número que mejor indica la cantidad de esfuerzo requerido. A veces es necesario jugar algunas rondas para conseguir una repetición suficiente de una determinada cantidad de puntos. Es importante no utilizar nunca promedios, sino la estimación que se eligió con mayor frecuencia.

Desde un punto de vista lean: las reuniones pueden ser un gran desperdicio en el proceso. Por tanto, tiene sentido contar con un Scrum Master que se asegure de que todos aprovechen al máximo el tiempo asignado a las reuniones y no pierdan la concentración. En las organizaciones lean, las reuniones de pie normalmente las dirige y facilita una sola persona. Otro paralelismo con la filosofía lean está representado por el hecho de que a las personas que realizan el trabajo se les pide que estimen (con las cartas de póquer) cuánto tiempo les llevará completarlo; nadie está mejor capacitado para estimar cuánto esfuerzo requiere una historia de usuario. (una descripción de una característica del producto vista por el usuario) o tarea requerirá que las personas que realizan el trabajo. Esta es una enseñanza crítica del pensamiento Lean: las personas deben estar capacitadas para resolver problemas y mejorar el trabajo, porque son las que están más cerca del proceso.

  • La reunión diaria (15 minutos) se lleva a cabo al inicio de la jornada laboral y cuenta con la participación de todo el equipo. Todos los miembros se reúnen y responden una serie de preguntas: "¿Qué hice ayer?" “¿Qué haré hoy?” y “¿Qué problemas me impiden continuar con mi trabajo?”

Desde un punto de vista lean : en su libro de 2008 The Toyota Product Development System , Jim Morgan y Jeffrey Liker hablan de reuniones rápidas y frecuentes, que en este contexto se utilizan para determinar si el proyecto va según lo planeado. Esto garantiza que los problemas potenciales se encuentren rápidamente y se resuelvan fácilmente.

  • Revisión de sprint (hasta cuatro horas). Participan el SM, el equipo y el PO, con el objetivo de entregar una parte funcional del producto final. Si es necesario, pueden participar otras personas involucradas en el proyecto (como el cliente). El objetivo de la revisión es evaluar la característica del producto frente al objetivo del sprint.

Desde un punto de vista eficiente : la OP debe gestionar una lista de verificación para asegurarse de que todo se haga de acuerdo con las necesidades del cliente. En el pensamiento lean a menudo hablamos de asegurarnos de que toda la información sea “completa y correcta” en el futuro.

  • La retrospectiva del sprint (hasta 3 horas) se produce entre el SM y el equipo con el objetivo de evaluar lo que sucedió durante el desarrollo del producto y comprender cómo hacerlo mejor en el futuro.

Desde un punto de vista lean – En lean, el término utilizado para este tipo de actividad es nemawashi , que significa “reflexión”. El espíritu kaizen siempre debe estar vivo dentro de un equipo.


LOS ARTEFACTOS DEL SCRUM

  • El product backlog es una colección de historias de usuarios que conformarán el producto. Cada historia de usuario puede contener una o más funciones que se entregarán al cliente. Desde un punto de vista lean : esto puede considerarse como un stock de información (el inventario es el mayor de todos los desperdicios en lean), que debe reducirse para acercarse lo más posible al flujo continuo. La información por lotes nos hará más vulnerables a la reelaboración y menos receptivos a los cambios en las demandas del mercado.

  • El sprint backlog es una lista específica de tareas que el equipo debe realizar para entregar la parte de un producto al cliente. En este contexto, una historia de usuario puede convertirse en una o más tareas.

Desde un punto de vista eficiente: dividir la historia del usuario en tareas más pequeñas hará que sea más fácil encontrar una solución y exponer los problemas. Esta es una de las principales lecciones que nos enseña lean: desglosar un problema y analizar cada parte nos permitirá llegar a su causa raíz.

  • Se utiliza un gráfico de evolución para verificar el progreso y realizar un seguimiento de la cantidad de trabajo real y estimada en un sprint. Ayuda a los equipos de scrum a determinar si se debe alcanzar el objetivo de un sprint. Este gráfico debe actualizarse diariamente para que se tomen decisiones en relación a lo que se debe lograr. También hay algo llamado tablero de tareas que muestra claramente lo que está desarrollando cada equipo.

Desde un punto de vista lean: una de las mayores lecciones del pensamiento lean es hacer que el trabajo sea lo más visual posible. Este enfoque ayudará a crear mecanismos a prueba de errores conocidos como poka yoke .


CONCLUSIÓN

Comprender la relación entre los marcos es muy importante y no hay duda de que el pensamiento scrum y lean tienen mucho en común (como se demostró anteriormente).

Scrum está ayudando a muchas empresas de todo el mundo a eliminar el desperdicio en la fase de desarrollo de diversos tipos de productos (principalmente software). Creo que su característica más exitosa es quizás el hecho de que crea un entorno en el que las personas son valoradas y comprometidas, lo que resulta ser el mensaje central del pensamiento Lean.

Tengo la esperanza de que este artículo contribuya a aumentar el entendimiento mutuo entre las comunidades scrum y lean, y a demostrar cuán compatibles (incluso complementarias) son las dos.


 

ACERCA DEL AUTOR.

Rodrigo Aquino ha trabajado en TI durante 16 años y ocupó el cargo de Coordinador de Tecnología de la Información en Lean Institute Brasil durante más de tres años.




RODRIGO AQUINO

Palabras: Rodrigo Aquino , Coordinador de TI, Lean Institute Brasil

TRANSCRIPCIÓN: Areli Álvarez Lean Construction México®

286 visualizaciones

Entradas Recientes

Ver todo

Comments


  • Facebook
  • Twitter
  • YouTube
bottom of page