Kanban vs. Scrum

Kanban vs Scrum

Si se ha preguntado cuáles son las diferencias entre estos dos populares marcos de desarrollo de software, sin duda está leyendo la lección correcta. Déjame adivinar … ¿eres Project Manager o Scrum Master y te han pedido que desveles el misterio? ¿Quizás esta pregunta surgió durante la noche de trivia en su restaurante local y se ha escapado para investigar la respuesta con la esperanza de encontrar una respuesta rápidamente?

Es bastante fácil enumerar las diferencias, pero es útil comprender que ambos fomentan la entrega de software incremental para que su empresa pueda reconocer un retorno de la inversión rápidamente.

Kanban

Kanban es una técnica que ayuda a visualizar el flujo de trabajo. Kanban significa literalmente “tablero” y Toyota lo utilizó mucho para visualizar y fomentar la producción “justo a tiempo”.

Este proceso se adaptó posteriormente para el desarrollo de software. Un desarrollador puede sacar el trabajo de una cola o de una lista de trabajos pendientes y luego enviarlo al siguiente miembro del equipo cuando estén completos. Sin embargo, se imponen límites a la cantidad de trabajo que tienen para que no se conviertan en un cuello de botella.

Melé

En Scrum, un equipo se compromete a una cantidad específica de trabajo que puede completar durante un incremento de 2 a 4 semanas o Sprint. Están facultados para hacer lo que sea necesario para realizar su trabajo y un Scrum Master está presente para ayudarlos a protegerlos de las interferencias externas.

Al final del Sprint, el equipo revisa e inspecciona su trabajo y procesos y realiza cambios, si es necesario.

Diferencias clave

Hay muchas diferencias entre Kanban y Scrum, pero aquí hay 10 diferencias clave entre los dos.

Kanban

1. Kanban se basa en valores Lean .

Lean se enfoca en eliminar cualquier actividad que sea un desperdicio o que no proporcione valor a un cliente. Scrum, que se basa en valores ágiles, no necesariamente elimina las actividades que derrochan. Simplemente le da más valor a algunas actividades que a otras.

2. Kanban reutiliza sus procesos actuales y no requiere un cambio masivo en cómo trabaja su equipo.

Kanban ayuda a los equipos a visualizar sus procesos actuales. Empiece con lo que hace ahora e inspeccione y adapte esos procesos. No existe una forma correcta o incorrecta de configurar un tablero Kanban.

3. Su equipo no está obligado a estimar las tareas.

Las estimaciones no son necesarias porque no hay un plazo fijo en cuanto a cuándo debe obligarse el trabajo. En Scrum, los equipos trabajan en Sprints que tienen un tiempo de 2 o 4 semanas. Es necesario estimar el trabajo, utilizando horas de tarea o puntos de historia en Scrum para ayudar a determinar qué puede encajar dentro de un Sprint.

4. El tiempo de entrega es una métrica para determinar cuándo se puede entregar el software en funcionamiento a un cliente o una parte interesada.

El plazo de entrega comienza cuando se solicita el trabajo y finaliza cuando se completa. El tiempo de ciclo también es una buena métrica. Este es el momento en que el trabajo realmente comienza a cuando se pone en marcha.

5. Kanban no tiene roles específicos o prescritos.

Kanban respeta los roles actuales en una organización. Scrum solo prescribe tres roles.

6. Kanban puede usar un diagrama de flujo acumulativo para informar el progreso.

Un diagrama de flujo acumulativo es un gráfico visual que muestra cosas como el tiempo de entrega y el tiempo de ciclo.

7. Las prioridades Kanban pueden cambiar a diario .

El propietario de un producto es libre de cambiar las prioridades a diario.

8. Kanban es más adecuado para tareas repetitivas.

9. El tamaño del equipo Kanban es irrelevante.

El tamaño del equipo puede ser mayor o menor. Kanban no recomienda un tamaño específico. En Scrum, se recomienda no tener más de 9 personas en el equipo.

10. Los cuellos de botella se revelan rápidamente mediante la visualización.

En un tablero Kanban, hay límites de trabajo en progreso colocados en las columnas. Esto significa que solo una cierta cantidad de tareas puede estar en esa columna al mismo tiempo. Si una columna en particular ha alcanzado su límite máximo de trabajo en progreso durante unos días, queda claro que la actividad representada por esa columna puede necesitar recursos adicionales.

Melé

1. Scrum se basa en valores ágiles .

Scrum se basa en la filosofía Agile que tiene cuatro valores principales y 12 principios subyacentes. No necesariamente tiene como objetivo eliminar todas las actividades innecesarias.

2. Scrum requiere un cambio en los procesos actuales. No sigue el proceso actual de la organización y, a veces, encuentra resistencia porque a algunas personas no les gusta el cambio.

3. Se requiere un equipo Scrum para estimar el trabajo .

Los miembros del equipo de entrega deben estimar el trabajo utilizando puntos de historia o incluso más, en horas de tarea. Esto ayuda a establecer la velocidad.

4. La velocidad es una métrica para determinar cuándo se puede entregar el software en funcionamiento a un cliente o una parte interesada.

La velocidad es la cantidad promedio de puntos de la historia que un equipo puede completar en unos pocos sprints. En Kanban, puede que no sea necesario determinar cuándo se completará una función, ya que Kanban es principalmente para trabajos sin funciones.

5. Scrum solo tiene 3 roles : Scrum Master, Product Owner y miembros del Delivery Team.

6. Scrum puede usar un informe Sprint Burn Down para mostrar la salud de un Sprint.

Un informe de Sprint Burn Up es otro informe que se puede utilizar. Un Burn Up usa puntos de historia donde un informe Burn Down usa horas de tarea.

7. Las prioridades de Scrum no cambian durante un Sprint.

El equipo está protegido por interferencias externas que incluyen cambiar las prioridades del equipo en medio de un Sprint.

8. Scrum es ideal para el desarrollo de nuevos productos o funciones.

Kanban es mejor para tareas pequeñas y recurrentes, como publicar un boletín informativo o actualizar una página web. Scrum es más adecuado para el desarrollo de nuevos productos complejos, como la creación de un nuevo sistema de servicio al cliente.

9. Scrum requiere un equipo pequeño y dedicado.

Scrum requiere que el tamaño del equipo se mantenga pequeño para que el equipo pueda convertirse en una unidad sólida y colaborativa. El equipo se compromete a trabajar en equipo. En Kanban, los miembros del equipo generalmente eligen sus propias tareas y pueden trabajar en elementos individualmente sin requerir demasiado de las habilidades de otra persona.

10. Los cuellos de botella no siempre son obvios hasta su Revisión de Sprint o Retrospectiva .

Durante una retrospectiva o revisión de Sprint, hay una discusión abierta y honesta sobre cómo fueron las cosas durante un Sprint o simplemente en general. Además, Scrum espera que un equipo sea multifuncional, lo que significa que todos deberían poder hacer el trabajo de los demás, lo que elimina la mayoría de los cuellos de botella.

Conclusión

Puede ver que aunque Kanban y Scrum tienen el mismo objetivo en mente, tienen diferencias bastante significativas. Al revisar cada una de la lista de diferencias, encontrará que hacen lo contrario entre sí. Esto no significa que uno sea mejor que el otro, solo diferente. Esperamos que esta lección lo ayude a administrar su próximo proyecto o quizás, ¡gane en su juego de preguntas y respuestas!