Kanban (desarrollo)

Un colaborador importante de este artículo parece tener una conexión cercana con el tema. Es posible que sea necesario limpiarlo para cumplir con las políticas de contenido de Wikipedia, en particular el punto de vista neutral . Por favor, debata más sobre el tema en la página de discusión . ( Agosto de 2022 ) ( Aprenda cómo y cuándo eliminar este mensaje )

Kanban ( en japonés :看板, que significa cartel o cartelera ) es un método lean para gestionar y mejorar el trabajo en los sistemas humanos. Este enfoque tiene como objetivo gestionar el trabajo equilibrando las demandas con la capacidad disponible y mejorando la gestión de los cuellos de botella a nivel de 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 permita la capacidad, en lugar de incorporarlo al proceso cuando se lo solicita.

En el trabajo del conocimiento y en el desarrollo de software , el objetivo es proporcionar un sistema de gestión de procesos visuales que ayude a la toma de decisiones sobre qué, cuándo y cuánto producir. El método kanban subyacente se originó en la fabricación ajustada , ^[1] que se inspiró en el Sistema de Producción Toyota . ^[2] Tiene su origen a finales de la década de 1940 cuando la empresa automotriz Toyota implementó un sistema de producción llamado just-in-time, que tenía el objetivo de producir según la demanda del cliente e identificar posibles faltantes de material dentro de la línea de producción. Pero fue un equipo de Corbis el que se dio cuenta de cómo este método ideado por Toyota podría convertirse en un proceso aplicable a cualquier tipo de proceso organizacional. Kanban se utiliza comúnmente en el desarrollo de software en combinación con métodos y marcos como Scrum . ^[3]

El diagrama aquí muestra un flujo de trabajo de desarrollo de software en un tablero kanban. ^[4]

Los tableros Kanban, diseñados para el contexto en el que se utilizan, varían considerablemente y pueden mostrar tipos de elementos de trabajo ("características" e " historias de usuario " en este caso), columnas que delimitan las actividades del flujo de trabajo, políticas explícitas y carriles (filas que cruzan varias columnas, que se utilizan para agrupar las historias de usuario por característica en este caso). El objetivo es que los participantes y las partes interesadas comprendan claramente el flujo de trabajo general y el progreso de los elementos individuales.

Un tablero Kanban representa la definición de flujo de trabajo del sistema ^[5] y requiere los siguientes elementos mínimos:

• Una definición de las unidades de valor individuales que se mueven a través del flujo de trabajo. Estas unidades de valor se denominan elementos de trabajo (o elementos ).
• Una definición de cuándo se inician y finalizan los elementos de trabajo dentro del flujo de trabajo. Su flujo de trabajo puede tener más de un punto de inicio o finalización según el elemento de trabajo.
• Uno o más estados definidos por los que fluyen los elementos de trabajo desde el punto de inicio hasta el punto de finalización. Todos los elementos de trabajo entre un punto de inicio y un punto de finalización se consideran trabajo en curso (WIP).
• Una definición de cómo se controlará el WIP desde su inicio hasta su finalización.
• Políticas explícitas sobre cómo los elementos de trabajo pueden fluir a través de cada estado desde el inicio hasta el final.
• Una expectativa de nivel de servicio (SLE), que es un pronóstico de cuánto tiempo debería tomar un elemento de trabajo para fluir desde su inicio hasta su finalización.

Las prácticas de Kanban como se describen en la Guía Kanban ^[6] son

• Definición y visualización de un flujo de trabajo
• Gestión activa de elementos en un flujo de trabajo
• Mejorar un flujo de trabajo

Kanban es una estrategia que tiene como objetivo seguir estos pasos para crear sistemas que sean eficientes, efectivos y predecibles.

El método Kanban es una extrapolación especializada y detallada de Kanban. Como se describe en los libros sobre el método Kanban para el desarrollo de software, ^{[7] [3]} las dos prácticas principales del método Kanban son visualizar el trabajo y limitar el trabajo en progreso (WIP). Cuatro prácticas generales adicionales del método Kanban enumeradas en Essential Kanban Condensed son hacer explícitas las políticas, gestionar el flujo, implementar ciclos de retroalimentación y mejorar de manera colaborativa. ^[8]

El tablero kanban en el diagrama anterior resalta las primeras tres prácticas generales del Método Kanban.

• Visualiza el trabajo del equipo de desarrollo (las características y las historias de los usuarios).
• Captura los límites de WIP para los pasos de desarrollo: los valores en un círculo debajo de los encabezados de las columnas que limitan la cantidad de elementos de trabajo en ese paso.
• Documenta políticas, también conocidas como reglas realizadas, ^[9] dentro de rectángulos azules debajo de algunos de los pasos de desarrollo.
• También se muestra cierta gestión del flujo kanban para los pasos de "preparación de la historia del usuario", "desarrollo de la historia del usuario" y "aceptación de funciones", que tienen subcolumnas "en proceso" y "listo". El límite de trabajo en progreso 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.

Kanban gestiona el flujo de trabajo directamente en el tablero Kanban. Los límites de WIP para los pasos de desarrollo proporcionan a los equipos de desarrollo retroalimentación inmediata sobre problemas comunes del flujo de trabajo. ^{[7] [9]}

Por ejemplo, en el tablero kanban que se muestra arriba, el paso de "implementación" tiene un límite de WIP de cinco y actualmente hay cinco épicas ^{[ aclaración necesaria ]} que se muestran en ese paso. No se pueden pasar más elementos de trabajo a la implementación hasta que una o más épicas completen ese paso (pasando a "entregadas"). Esto evita que el paso de "implementación" se vea sobrecargado. Los miembros del equipo que trabajan en la "aceptación de funciones" (el paso anterior) pueden quedarse atascados porque no pueden implementar nuevas épicas. Pueden ver por qué inmediatamente en el tablero y ayudar con las implementaciones de épicas actuales.

Una vez que se entregan las cinco epopeyas del paso de "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 entregan 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.

En una configuración de tablero Kanban, los carriles se utilizan para organizar visualmente el trabajo en diferentes etapas de un proceso, lo que garantiza la claridad y el enfoque. Para una gestión eficiente del flujo de trabajo, es fundamental mantener carriles diferenciados para las fases clave, como requisitos, desarrollo, pruebas y tareas cerradas/completadas. En concreto, las historias de prueba siempre deben ubicarse dentro del carril designado como "Prueba". Esta separación garantiza que las actividades de prueba sean fácilmente rastreables y no se entremezclen con otras historias en desarrollo u otras etapas. Al mantener las tareas de prueba dentro de su propio carril, los equipos pueden identificar rápidamente los cuellos de botella, priorizar los problemas y mantener la integridad del proceso de prueba sin contaminación cruzada de las fases de desarrollo o de requisitos. Esta estructura conduce a flujos de trabajo más claros y mejora la colaboración en equipo.

Este control del flujo de trabajo funciona de manera similar para cada paso. Los problemas son visibles y evidentes de inmediato, y se puede volver a planificar de forma continua. La gestión del trabajo es posible gracias a la limitación del trabajo en curso de forma que los miembros del equipo puedan verlo y realizar un seguimiento en todo momento.

El libro de David Anderson de 2010, Kanban , ^[7] describe una evolución del enfoque desde un proyecto de 2004 en Microsoft ^[10] que utilizaba un enfoque de teoría de restricciones e incorporaba un tambor-amortiguador-cuerda (comparable al sistema pull kanban ), hasta un proyecto de 2006-2007 en Corbis en el que se identificó el método kanban ^{[¿ por quién? ]} . En 2009, Don Reinertsen publicó un libro sobre el desarrollo de productos lean de segunda generación ^[11] 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 contribución temprana provino de Corey Ladas, cuyo libro de 2008 Scrumban ^[3] sugería 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 ^[12] , en el que aplican Kanban a individuos y equipos pequeños, en 2011. En Kanban from the Inside (2014), ^[13] Mike Burrows explicó los principios, prácticas y valores subyacentes de Kanban y los relacionó con teorías y modelos anteriores. En Agile Project Management with Kanban (2015), ^[9] 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, ^[14] 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, que incorpora mejoras y extensiones de los primeros proyectos de Kanban. ^[8]

En 2020, John Coleman y Daniel Vacanti publicaron The Kanban Guide ^[6] para describir las condiciones mínimas necesarias para operar un sistema Kanban. Colleen Johnson, Daniel Vacanti y Prateek Singh publicaron The Kanban Pocket Guide ^[15] en 2022, que ayuda a los profesionales a navegar por las prácticas de Kanban. Will Seele y Daniel Vacanti también publicaron el libro Flow Metrics for Scrum Teams ^[16] en 2022 para llevar los beneficios de las métricas que se usan comúnmente en Kanban a los equipos Scrum.

• Lista de filosofías de desarrollo de software

• Kanban: un cambio evolutivo exitoso para su negocio tecnológico, David J. Anderson. (Estados Unidos, Blue Hole Press, 2010. ISBN 978-0984521401) 
• Scrumban: Ensayos sobre sistemas Kanban para el desarrollo de software Lean, 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, Nueva York: Publicaciones Manning, 2014). ISBN 978-1-617291-05-0 . 
• Lean from the Trenches: Managing Large-Scale Projects with Kanban (Aprender desde las trincheras: gestionar proyectos a gran escala con Kanban), Henrik Kniberg. (Dallas, TX: The Pragmatic Programmers, 2012). ISBN 978-1-93435-685-2 . 
• ¡Deje de empezar y empiece a terminar! Arne Roock y Claudia Leschik. (Estados Unidos: Lean-Kanban University, 2012). ISBN 978-0985305161 . 
• Kanban en el mundo real: hacer menos, lograr más con el pensamiento Lean , Mattias Skarin. (Estados Unidos: Pragmatic Bookshelf, 2015). ISBN 978-1680500776 .