Guía de Scrum | 33. Scrumban y tableros Kanban en Scrum

Scrum y Kanban son métodos de trabajo en equipo que comparten muchas similitudes. Sin embargo, también hay diferencias que nos gustaría discutir hoy. Las tableros Kanban también son adoptados a menudo por los Equipos Scrum. Esto se debe a que son muy prácticos para visualizar el trabajo en equipo y su progreso. Al combinar lo mejor de ambas metodologías, apareció una técnica llamada Scrumban. Es popular en proyectos que combinan el desarrollo de productos con la entrega de servicios, donde los Sprints largos y las reuniones de Scrum relativamente formalizadas no siempre son adecuadas.

Scrumban y tableros Kanban en Scrum – tabla de contenido:

1. Introducción
2. Kanban vs Scrum
3. Tableros Kanban en Scrum
4. Scrumban
5. Resumen

Introducción

Kanban es un método pionero en Japón. Se originó en la década de 1950 y fue principalmente una herramienta para gestionar la producción continua de tal manera que no se crearan inventarios y excedentes, sino para procesar recursos de manera continua. A principios del siglo XXI, Kanban fue adaptado a las necesidades del desarrollo de software por David J. Anderson.

Kanban vs Scrum

La forma general de trabajar en Kanban difiere de Scrum principalmente por proporcionar un enfoque menos formal. En Kanban, no hay pautas tan detalladas sobre, por ejemplo, trabajar en Sprints, roles de Product Owner, Scrum Master y Equipo de Desarrollo. Esto es posible porque Kanban se centra en la continuidad de las tareas como proporcionar un tipo específico de servicio, que son más repetibles y no requieren una planificación tan compleja.

Sin embargo, el propósito y las formas de trabajar son similares. El objetivo de Kanban es entregar el producto de la más alta calidad al cliente a tiempo. Los principios que conciernen a las formas de trabajar comunes a ambos métodos se pueden formular de la siguiente manera:

1. El trabajo debe ser fluido y sin tiempos de inactividad – en Scrum, esto se logra mediante la sucesión continua de Sprints, mientras que en Kanban el trabajo es continuo debido al flujo suave de tareas. Forman una cola, de la cual los desarrolladores eligen (tiran) algunas tareas para completar.
2. El equipo debe centrarse solo en tareas seleccionadas – utilizando la terminología de Kanban, el equipo debe “reducir el trabajo en progreso”. En Scrum, el equivalente a esto son las Historias de Usuario elegidas del Product Backlog para poner en el Sprint Backlog.
3. El progreso de las tareas debe ser visible para todas las personas involucradas – en Kanban se visualizan mediante tableros, que también son presentados a menudo en los Equipos Scrum.

Tableros Kanban en Scrum

Un tablero Kanban es una herramienta ampliamente utilizada para visualizar el trabajo en equipo. Es una tabla con varias columnas. En cada una de ellas, hay tareas con un cierto estado. La categorización de las tareas se basa en una regla simple: una tarjeta con una descripción de la tarea – o su equivalente virtual – se coloca en una de las columnas. La versión mínima de los tableros Kanban contiene tres columnas:

• Por hacer
• En progreso
• Completado – a la última columna van las tareas que cumplen con la Definición de Completación, sobre la cual escribimos aquí.

A continuación, puedes encontrar un ejemplo de un tablero kanban de un sistema de gestión de proyectos todo en uno – Firmbee.com

Comúnmente, hay más columnas. Si hay más tareas por completar, generalmente hay una columna adicional titulada “seleccionadas para completar” entre las columnas “por completar” y “en progreso”. Mientras que la columna “por hacer” sirve como el Product Backlog, del cual escribimos aquí, la columna “seleccionadas para completar” sirve como el Sprint Backlog, que describimos en detalle en este artículo.

La segunda adición común es una columna “bajo revisión” o “para aprobación”. Generalmente se inserta entre las columnas que contienen las tareas “en progreso” y las “completadas”. Contiene tareas completadas por el Equipo de Desarrollo que están esperando la aprobación del Product Owner. La tarea del Product Owner es verificar su cumplimiento con los criterios de aceptación y obtener su aprobación final del Cliente. En esta situación, solo las tareas finalmente aceptadas se mueven a la última columna.

Scrumban

Debido a la enorme popularidad de Scrum y Kanban, apareció su híbrido, combinando lo mejor de ambas formas de trabajar. Scrumban funciona mejor en organizaciones que conectan la creación de Productos con la provisión de servicios, a menudo involucrando la implementación del Producto en el Cliente. Debido a la reducción de reuniones y comunicación, el Equipo puede ser más grande.

Scrumban pone menos énfasis en métricas comúnmente utilizadas en Scrum, como el Gráfico de Quema. Sin embargo, utiliza los pilares de Scrum de la necesidad de mejora continua del proceso de trabajo y adaptarlos a las condiciones y necesidades del cliente.

Cuando se trabaja en Scrumban, sin embargo, el trabajo no se divide en Sprints. Las reuniones de Scrum se llevan a cabo cada 3, 6 o 12 meses.

La programación del trabajo sigue el principio “On-Demand”, es decir, a medida que ocurre. Las Historias de Usuario se colocan directamente en la primera columna del tablero Kanban que contiene tareas “por hacer”. Así, sirve como el Sprint Backlog, del cual escribimos en más detalle en este artículo. Al igual que en el Sprint Backlog, las tareas más urgentes se colocan en la parte superior de la lista de tareas por hacer. Sin embargo, para proyectos más complejos, el Gerente de Proyecto puede mantener una lista de tareas por hacer separada que corresponda al Product Backlog, de la cual selecciona qué tareas colocar en la primera columna.

Al mover tareas de la primera a la segunda columna, se aplica la regla “Pull”. Esto significa que las tareas no se delegan a un Desarrollador en particular. Cada persona elige una tarea de la cola y la ejecuta de manera independiente.

El número de tareas colocadas en la columna del medio, “por completar” suele estar limitado dependiendo del tamaño del equipo, para que, si es posible, todos se ocupen de solo una tarea a la vez.

Resumen

Scrum y Kanban, aunque se utilizan para propósitos similares, son diferentes formas de trabajar. Scrum funciona mejor en proyectos creativos e innovadores realizados por pequeños Equipos Scrum. Kanban, por otro lado, fue creado para operar en un entorno continuo y sin tiempos de inactividad para proporcionar servicios similares. Scrum a menudo utiliza tableros Kanban como un método para visualizar el trabajo que se está realizando. La combinación de ambos resultó en Scrumban, que funciona mejor como un marco para organizaciones que venden sus productos y proporcionan servicios basados en ellos al cliente.

Si te gusta nuestro contenido, únete a nuestra comunidad de abejas trabajadoras en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.