Kanban (desarrollo) - Kanban (development)

Kanban ( japonés :看板, que significa letrero o valla publicitaria ) es un método esbelto para administrar y mejorar el trabajo en los sistemas humanos . Este enfoque tiene como objetivo administrar el trabajo equilibrando las demandas con la capacidad disponible y mejorando el manejo de los cuellos de botella a nivel del sistema .

Los elementos de trabajo se visualizan para brindarles a los participantes una visión del progreso y el proceso, de principio a fin, generalmente a través de un tablero Kanban . El trabajo se extrae según lo permite la capacidad, en lugar de introducirlo en el proceso cuando se solicita.

En el trabajo del conocimiento y en el desarrollo de software , el objetivo es proporcionar un sistema de gestión de procesos visual que ayude a la toma de decisiones sobre qué, cuándo y cuánto producir. El método Kanban subyacente se originó en la manufactura esbelta , que se inspiró en el sistema de producción de Toyota . Tiene su origen a fines de la década de 1940, cuando la empresa automotriz Toyota implementó un sistema de producción llamado just-in-time; el cual tenía como objetivo producir de acuerdo a la demanda del cliente e identificar posibles desabastecimientos de material dentro de la línea de producción. Pero fue el ingeniero de Microsoft David J. Anderson quien se dio cuenta de cómo este método ideado por Toyota podría convertirse en un proceso aplicable a cualquier tipo de empresa que necesite organización. Kanban se usa comúnmente en el desarrollo de software en combinación con otros métodos y marcos como Scrum .

Evolución y documentación del método

El libro de 2010 de David Anderson, Kanban , describe una evolución del enfoque desde un proyecto de 2004 en Microsoft utilizando un enfoque de teoría de restricciones e incorporando una cuerda de amortiguación de tambor (comparable al sistema de tracción kanban ), a un proyecto de 2006-2007 en Corbis en el que se identificó el método kanban. En 2009, Don Reinertsen publicó un libro sobre desarrollo de productos lean de segunda generación que describe la adopción del sistema kanban y el uso de la recopilación de datos y un modelo económico para la toma de decisiones de gestión. Otra de las primeras contribuciones provino de Corey Ladas, cuyo libro Scrumban de 2008 sugirió que kanban podría mejorar Scrum para el desarrollo de software. Ladas vio Scrumban como la transición de Scrum a Kanban. Jim Benson y Tonianne DeMaria Barry publicaron Personal Kanban , aplicando Kanban a individuos y equipos pequeños, en 2011. En Kanban from the Inside (2014), Mike Burrows explicó los principios, prácticas y valores subyacentes de Kanban y los relacionó con teorías y modelos anteriores. En Gestión ágil de proyectos con Kanban (2015), Eric Brechner ofrece una descripción general de Kanban en la práctica en Microsoft y Xbox . Kanban Change Leadership (2015), de Klaus Leopold y Siegfried Kaltenecker, explicó el método desde la perspectiva de la gestión del cambio y brindó orientación para las iniciativas de cambio. En 2016, Lean Kanban University Press publicó una guía condensada del método, incorporando mejoras y extensiones de los primeros proyectos kanban.

Tableros Kanban

Muestra Kanban Board.png

El diagrama aquí muestra un flujo de trabajo de desarrollo de software en un tablero Kanban. Los tableros Kanban, diseñados para el contexto en el que se usan, varían considerablemente y pueden mostrar tipos de elementos de trabajo ("características" e "historias de usuario" aquí), columnas que delimitan las actividades del flujo de trabajo, políticas explícitas y carriles (filas que cruzan varias columnas, usadas para agrupar historias de usuarios por función aquí). El objetivo es hacer que el flujo de trabajo general y el progreso de los elementos individuales sean claros para los participantes y las partes interesadas.

Como se describe en los libros sobre Kanban para el desarrollo de software, las dos prácticas principales de Kanban son visualizar su trabajo y limitar el trabajo en progreso (WIP). Cuatro prácticas generales adicionales de Kanban enumeradas en Essential Kanban Condensed son hacer políticas explícitas, administrar el flujo, implementar ciclos de retroalimentación y mejorar de forma colaborativa.

El tablero Kanban del diagrama anterior destaca las tres primeras prácticas generales de Kanban.

  • Visualiza el trabajo del equipo de desarrollo (las características y las historias de usuario).
  • Captura los límites de WIP para los pasos de desarrollo: los valores encerrados en un círculo debajo de los encabezados de las columnas que limitan la cantidad de elementos de trabajo en ese paso.
  • Documenta las políticas, también conocidas como reglas terminadas, dentro de rectángulos azules debajo de algunos de los pasos de desarrollo.
  • También muestra parte de la gestión del flujo Kanban para los pasos "Preparación de la historia del usuario", "Desarrollo de la historia del usuario" y "Aceptación de funciones", que tienen subcolumnas "En curso" y "Listo". El límite de WIP de cada paso se aplica a ambas subcolumnas, lo que evita que los elementos de trabajo abrumen el flujo de entrada o salida de esos pasos.

Gestionar el flujo de trabajo

Kanban gestiona el flujo de trabajo directamente en el tablero Kanban. Los límites de WIP para los pasos de desarrollo brindan a los equipos de desarrollo comentarios inmediatos sobre problemas comunes del flujo de trabajo.

Por ejemplo, en el tablero Kanban que se muestra arriba, el paso "Implementación" tiene un límite de WIP de cinco y actualmente se muestran cinco epopeyas en ese paso. No se pueden mover más elementos de trabajo a la implementación hasta que uno o más épicos completen ese paso (pasando a "Entregado"). Esto evita que el paso de "Implementación" se vea abrumado. Los miembros del equipo que trabajan en "Aceptación de funciones" (el paso anterior) pueden quedarse atascados porque no pueden implementar nuevas epopeyas. Pueden ver por qué inmediatamente en el tablero y ayudar con las implementaciones épicas actuales.

Una vez que se entregan las cinco epopeyas en el paso "Implementación", las dos epopeyas de la subcolumna "Listo" de "Aceptación de funciones" (el paso anterior) se pueden mover a la columna "Implementación". Cuando se entreguen esas dos epopeyas, no se pueden implementar otras epopeyas (suponiendo que no haya nuevas epopeyas listas). Ahora, los miembros del equipo que trabajan en la implementación están estancados. Pueden ver por qué de inmediato y ayudar con la aceptación de funciones.

Este control de flujo de trabajo funciona de manera similar para cada paso. Los problemas son visibles y evidentes de inmediato, y se puede volver a planificar continuamente. La gestión del trabajo es posible al limitar el trabajo en progreso de una manera que los miembros del equipo puedan ver y rastrear en todo momento.

Métricas Kanban

Kanban usa métricas específicas para medir la capacidad del equipo y estimar la duración del proyecto.

La velocidad del equipo define cuántas tareas puede realizar un equipo en un período de tiempo determinado, por ejemplo, una semana o una iteración. La velocidad se calcula periódicamente y para ayudar con la precisión de la velocidad calculada, los equipos tienen como objetivo crear tareas de tamaño similar. Conocer la velocidad del equipo ayuda a predecir mejor cuándo terminará un proyecto.

Tiempo de ejecución y ciclo
Tiempo de ejecución y ciclo

El tiempo de ejecución y ciclo define el tiempo medio que se tarda en completar una tarea. El tiempo de entrega se calcula desde que el equipo recibe una solicitud del cliente y el tiempo de ciclo se calcula desde que el equipo comienza a trabajar en una tarea. El tiempo de entrega se usa para comprender cuánto tiempo tiene que esperar un cliente por su producto y el tiempo de ciclo se usa para comprender qué tan rápido el equipo produce un producto.

Las métricas ágiles procesables utilizan el tiempo de ciclo para predecir mejor cuándo se terminará cada elemento del proyecto. Creadas por Daniel S. Vacanti en 2015, las métricas ágiles procesables miden cuánto tiempo tomó completar el 50%, 85% y 95% de las tareas. Y use esta información para ayudar al equipo a predecir y controlar mejor las fechas de entrega de las tareas.

Ver también

Referencias

Otras lecturas

  • Kanban: cambio evolutivo exitoso para su negocio de tecnología, David J. Anderson. (Estados Unidos, Blue Hole Press, 2010. ISBN  978-0984521401
  • Scrumban: Ensayos sobre sistemas Kanban para el desarrollo de software ajustado, Corey Ladas. (Estados Unidos, Modus Cooperandi Press, 2009. ISBN  9780578002149
  • Gestión ágil de proyectos con Kanban (Mejores prácticas para desarrolladores) , Eric Brechner. (Estados Unidos: Microsoft Press, 2015). ISBN  978-0735698956 .
  • Kanban en acción , Marcus Hammarberg y Joakim Sunden. (Shelter Island, NY: Publicaciones Manning, 2014). ISBN  978-1-617291-05-0 .
  • Lean from the Trincheras: Gestión de proyectos a gran escala con Kanban, Henrik Kniberg. (Dallas, TX: Los programadores pragmáticos, 2012). ISBN  978-1-93435-685-2 .
  • ¡Deje de comenzar, comience a terminar! Arne Roock y Claudia Leschik. (Estados Unidos: Universidad Lean-Kanban, 2012). ISBN  978-0985305161 .
  • Kanban del mundo real: haga menos, consiga más con el pensamiento ajustado, Mattias Skarin. (Estados Unidos: Pragmatic Bookshelf, 2015). ISBN  978-1680500776 .