Guía Scrum | 33. Tableros Scrumban y 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. Los 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. Combinando lo mejor de ambas metodologías, apareció una técnica llamada Scrumban. Es popular en proyectos que combinan el desarrollo de productos con la prestación de servicios, donde los Sprints largos y las reuniones Scrum relativamente formalizadas no siempre son adecuadas.

Tableros Scrumban y Kanban en Scrum – índice:

1. Introducción
2. Kanban frente a 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 administrar la producción continua de tal manera que no se crearan inventarios y excedentes, sino que se procesaran los recursos de manera continua. A principios del siglo XXI, David J. Anderson adaptó Kanban a las necesidades del desarrollo de software.

Kanban frente a Scrum

La forma general de trabajar en Kanban se diferencia de Scrum principalmente en que presenta un enfoque menos formal. En Kanban, no hay pautas tan detalladas sobre, por ejemplo, trabajar en Sprints, roles de Product Owner, Scrum Master y Development Team. Esto es posible porque Kanban se enfoca en la continuidad de tareas como brindar un tipo de servicio específico, 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 relativos a las formas de trabajo comunes a ambos métodos pueden formularse de la siguiente manera:

1. El trabajo debe ser fluido y sin tiempo 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 fluido de tareas. Forman una cola, de la cual los desarrolladores eligen (extraen) algunas tareas para completar.
2. El equipo debe centrarse solo en las tareas seleccionadas : utilizando la terminología de Kanban, el equipo debe "reducir el trabajo en curso". En Scrum, el equivalente de esto son las Historias de usuario elegidas del Product Backlog para colocarlas 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 suelen aparecer en los equipos Scrum.

Tableros Kanban en Scrum

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

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

A continuación puede 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 para completar, generalmente hay una columna adicional titulada "seleccionado para completar" entre las columnas "para completar" y "en progreso" . Mientras que la columna "pendientes" sirve como el Backlog del producto, sobre el cual escribimos aquí, la columna "seleccionado para completar" sirve como el Sprint Backlog, que describimos en detalle en este artículo.

La segunda adición común es una columna "en revisión" o "para aprobación". Suele insertarse entre las columnas que contienen las tareas “en proceso” y las “completadas”. Contiene tareas completadas por el equipo de desarrollo que está esperando la aprobación del propietario del producto. La tarea del Product Owner es verificar su cumplimiento con los criterios de aceptación y obtener su aprobación final por parte del Cliente. En esta situación, solo las tareas finalmente aceptadas se mueven a la última columna.

Scrumban

Debido a la gran popularidad de Scrum y Kanban, apareció su híbrido, que combina lo mejor de ambas formas de trabajar. Scrumban funciona mejor en organizaciones que conectan la creación de Productos con la prestación de servicios, lo que a menudo implica 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 las métricas comúnmente utilizadas en Scrum, como el Burndown Chart. Sin embargo, utiliza los pilares Scrum de la necesidad de mejora continua de los procesos de trabajo y su adaptación a las condiciones y necesidades del cliente.

Sin embargo, cuando se trabaja en Scrumban, el trabajo no se divide en Sprints. Las reuniones 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 se produce. Las historias de usuario se colocan directamente en la primera columna del tablero Kanban que contiene las tareas pendientes. Por lo tanto, sirve como Sprint Backlog, sobre el cual escribimos con más detalle en este artículo. Al igual que en Sprint Backlog, las tareas más urgentes se colocan en la parte superior de la lista de tareas pendientes. Sin embargo, para proyectos más complejos, el Gerente de Proyecto puede mantener una lista de tareas por hacer separada correspondiente al Product Backlog, de la cual él o ella selecciona qué tareas colocar en la primera columna.

Al mover tareas de la primera a la segunda columna, se aplica la regla "Pull" . Significa que las tareas no se delegan a un desarrollador en particular. Cada persona elige una tarea de la cola y la ejecuta de forma independiente.

El número de tareas colocadas en la columna del medio, "para completar", generalmente está limitado según el tamaño del equipo, de modo que, si es posible, todos se ocupan de una sola tarea a la vez.

Resumen

Scrum y Kanban, aunque se usan para propósitos similares, son formas diferentes de trabajar. Scrum funciona mejor en proyectos creativos e innovadores realizados por pequeños equipos Scrum. Kanban, por otro lado, se creó para operar en un entorno continuo y sin tiempo de inactividad para brindar servicios similares. Scrum a menudo usa tableros Kanban como un método para visualizar el trabajo que se está realizando. La combinación de ambos dio como resultado Scrumban, que funciona mejor como marco para las organizaciones que venden sus productos y brindan servicios basados ​​en ellos al cliente.

Si le gusta nuestro contenido, únase a nuestra comunidad de abejas ocupadas en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autora: Carolina Becker

Como Project Manager, Caroline es experta en encontrar nuevos métodos para diseñar los mejores flujos de trabajo y optimizar procesos. Sus habilidades organizativas y su capacidad para trabajar bajo la presión del tiempo la convierten en la mejor persona para convertir proyectos complicados en realidad.

Ver todas las publicaciones

Guía Scrum:

1. Glosario de términos básicos, roles y nociones
2. ¿Qué es Scrum?
3. valores de scrum
4. ¿Cómo implementar Scrum en tu empresa?
5. Equipo Scrum: ¿qué es y cómo funciona?
6. ¿Quién es un propietario del producto?
7. Los errores más comunes del Product Owner
8. ¿Quién es el Scrum Master?
9. Características de un buen Scrum Master
10. Los errores más comunes de Scrum Master
11. ¿Qué estadísticas y métricas debe rastrear el Scrum Master?
12. Cooperación entre el propietario del producto y Scrum Master
13. Equipo de desarrollo en Scrum
14. Los errores más comunes de los Desarrolladores
15. artefactos de scrum
16. Escalamiento Scrum
17. Pila de Sprint
18. ¿Qué es la cartera de productos?
19. ¿Qué son las historias de usuario?
20. Creando la mejor historia de usuario con INVEST
21. Los errores más comunes de las historias de usuario
22. Criterios de aceptación de historias de usuario
23. Estimación y puntos de historia en Scrum
24. Planificación de póquer
25. Juego de estimación en equipo
26. Definición de incremento
27. Eventos de scrum
28. ¿Qué es Sprint en Scrum?
29. Compromisos del equipo Scrum: objetivo del producto, objetivo del Sprint y definición de finalización
30. ¿Qué es un gráfico Burndown?
31. ¿Cómo crear e interpretar un gráfico de evolución?
32. Ventajas y desventajas del Burndown Chart
33. Tableros Kanban en Scrum y Scrumban
34. Velocidad en Scrum - Velocidad del Equipo de Desarrollo
35. Scrum diario
36. Planificación de Sprint
37. Revisión de Sprint
38. ¿Qué es una retrospectiva de Sprint?
39. Errores comunes durante una Retrospectiva de Sprint
40. Nutrición de la cartera de productos