Kanban
Aplicación de la metodología kanban en el desarrollo de software
Empieza gratis con la plantilla de kanban de Jira
Consulta el trabajo que más importa y haz que progrese para maximizar la eficiencia.
¿Qué es kanban?
Kanban es un marco de trabajo muy popular a la hora de implementar un desarrollo de software ágil y de DevOps. Requiere una comunicación en tiempo real sobre la capacidad y una total transparencia del trabajo. Los elementos de trabajo se representan visualmente en un tablero de kanban, lo que permite a los miembros del equipo ver el estado de cada uno en cualquier momento.
Artículos sobre kanban
Aprender a usar kanban con Jira Software
Instrucciones pormenorizadas sobre cómo dirigir un proyecto de kanban, priorizar el trabajo, visualizar el workflow y minimizar el trabajo en curso con Jira Software
Probar el tutorialTableros de kanban de Jira: agilidad y eficiencia
El tablero de kanban de Jira Software está diseñado para que los usuarios puedan mejorar de forma continua la duración del ciclo y aumentar la eficiencia.
Consíguelo gratisLa metodología de trabajo kanban es sumamente importante entre los equipos de software ágiles y de DevOps de hoy en día, pero se remonta a hace más de 50 años. A finales de los años 40, Toyota empezó a optimizar sus procesos de ingeniería a partir del modelo que utilizaban los supermercados para llenar las estanterías. Los supermercados almacenan únicamente los productos suficientes para suplir la demanda del cliente, una práctica que optimiza el flujo entre el supermercado y el cliente. Como las existencias coinciden con las pautas de consumo, el supermercado aumenta considerablemente su eficacia en gestión de existencias reduciendo la cantidad de excedentes que debe mantener en cualquier momento. Mientras tanto, el supermercado puede seguir garantizando que ese producto que el cliente necesita siempre esté disponible.
Cuando Toyota aplicó este mismo sistema en sus fábricas, el objetivo era ajustar mejor sus enormes niveles de existencias con el consumo real de materiales. Para comunicar los niveles de capacidad en tiempo real en la fábrica (y a los proveedores), los trabajadores tenían que pasarse una tarjeta, o "kanban", entre equipos. Cuando se vaciaba un contenedor de materiales que se estaba utilizando en la cadena de producción, se pasaba un kanban al almacén con la descripción de los materiales que hacían falta, la cantidad exacta de esos materiales, etc. El almacén tenía otro contenedor de estos materiales a la espera, que luego enviaba a fábrica y, a su vez, enviaba su propio kanban al proveedor. El proveedor también tenía un contenedor de estos materiales a la espera, que enviaba al almacén. Si bien la notable tecnología de este proceso ha evolucionado desde los años 40, este mismo proceso de fabricación de "justo a tiempo" (JIT, por sus siglas en inglés) sigue siendo la esencia.
Kanban para equipos de software
Actualmente, los equipos dedesarrollo de software ágil pueden aprovechar esos mismos principios de JIT ajustando la cantidad de trabajo en curso (WIP) a la capacidad del equipo. Los equipos tienen así opciones de planificación más flexibles, resultados más rápidos, un enfoque más claro y transparencia a lo largo del ciclo de desarrollo.

Aunque los principios básicos del marco son atemporales y se pueden aplicar a casi todos los sectores, los equipos de desarrollo de software han obtenido unos resultados especialmente positivos con la práctica ágil. Esto se debe, en parte, a que los equipos de software pueden comenzar practicando con poco o ningún gasto cuando asimilan los principios básicos. A diferencia de la implementación de kanban en una fábrica, cosa que implicaría cambios en los procesos físicos y la suma de materiales considerables, los únicos elementos físicos que necesita un equipo de software son un tablero y las tarjetas, e incluso esos pueden ser virtuales.
Tableros Kanban
El trabajo de todos los equipos de kanban gira en torno a un tablero kanban, una herramienta que se usa para visualizar las tareas y optimizar el flujo de trabajo entre los miembros del equipo. Aunque los tableros físicos gozan de popularidad entre algunos equipos, los tableros virtuales constituyen una función esencial de cualquier herramienta de desarrollo de software ágil para garantizar la trazabilidad, la colaboración sencilla y la accesibilidad desde varias ubicaciones.
Independientemente de si el tablero del equipo es físico o digital, su función es garantizar que el trabajo del equipo se visualice, que su workflow se unifique y que se identifiquen y resuelvan inmediatamente todos los factores que lo bloqueen y de los que dependan. El tablero de kanban básico tiene un workflow de tres pasos: Por hacer, En curso y Hecho. Sin embargo, dependiendo del tamaño, la estructura y los objetivos del equipo, el workflow se puede asignar para cumplir el proceso único de cualquier equipo determinado.
La metodología kanban se basa en una transparencia total del trabajo y una comunicación en tiempo real de la capacidad. Por lo tanto, el tablero de kanban debería considerarse la única fuente fiable de información sobre el trabajo del equipo.

Tarjetas kanban
En japonés, "kanban" se traduce literalmente como "señal visual". Para los equipos de kanban, cada elemento de trabajo se representa en una tarjeta distinta del tablero.
El objetivo principal de representar el trabajo como una tarjeta en el tablero de kanban es que los miembros del equipo realicen el seguimiento del progreso del trabajo mediante el workflow de una manera muy visual. Las tarjetas kanban presentan información vital sobre ese elemento de trabajo concreto y proporcionan una visibilidad completa a todo el equipo sobre quién está a cargo de ese elemento de trabajo concreto, una breve descripción del trabajo que se está haciendo, la duración estimada que llevará esa unidad de trabajo, etc. Las tarjetas de los tableros de kanban virtuales a menudo presentan también capturas de pantalla y otros datos técnicos de valor para el destinatario de la asignación. Al permitir que los miembros del equipo vean el estado de cada elemento de trabajo en cualquier momento determinado, así como todos los detalles relacionados, se garantiza un aumento de la dedicación, un seguimiento completo y una identificación rápida de los factores que lo bloquean y de los que dependen.
Las ventajas de kanban
Kanban es una de las metodologías de desarrollo de software más populares adaptadas por los equipos ágiles en la actualidad. Kanban presenta varias ventajas adicionales en la planificación de tareas y el rendimiento de equipos de todos los tamaños.
Planificar la flexibilidad
Un equipo de kanban solo se centra en el trabajo que está en curso. Cuando el equipo finaliza un elemento de trabajo, saca el elemento siguiente de la parte superior del backlog. El propietario del producto tiene la libertad de establecer nuevas prioridades de trabajo en el backlog sin interrumpir al equipo, ya que cualquier cambio fuera de los elementos actuales de trabajo no afecta al equipo. Siempre que el propietario del producto mantenga los elementos de trabajo más importantes en la parte superior del backlog, el equipo de desarrollo tendrá la seguridad de estar aportando el máximo valor a la empresa. Así pues, no hacen falta las iteraciones de longitud fija que encontramos en scrum.
Los propietarios del producto perspicaces siempre involucran al equipo de desarrollo cuando estudian la introducción de cambios en el backlog. Por ejemplo, si las historias de usuario de la 1 a la 6 están en el backlog, la estimación de la historia de usuario 6 se puede basar en la finalización de las historias de la 1 a la 5. Siempre es conveniente confirmar los cambios con el equipo técnico para no llevarse sorpresas.
Duraciones de ciclos reducidas
La duración del ciclo constituyen una métrica fundamental para los equipos de kanban. La duración del ciclo es la cantidad de tiempo que tarda una unidad de trabajo en viajar a través del flujo de trabajo del equipo, desde el momento en que se inicia el trabajo hasta que se lanza. Optimizando la duración del ciclo, el equipo puede realizar pronósticos con seguridad sobre la entrega del futuro trabajo.
Solapar conjuntos de habilidades se traduce en ciclos con una duración más corta. Si solo hay una sola persona que posee un conjunto de habilidades concreto, se acabará convirtiendo en un cuello de botella en el flujo de trabajo. Así pues, los equipos emplean prácticas recomendadas básicas como la revisión del código y la mentoría para compartir sus conocimientos. Al compartir habilidades, los miembros de los equipos pueden asumir trabajos diferentes, lo que optimiza aún más la duración del ciclo y favorece que, si hay un cuello de botella de trabajo, todo el equipo se puede volcar en él para que el proceso vuelva a fluir sin problemas. Por ejemplo, no solo los ingenieros de control de calidad realizan pruebas; los desarrolladores también se involucran.
En un marco de kanban es responsabilidad de todo el equipo asegurar que el trabajo progresa de forma fluida.
Menos cuellos de botella
Las multitareas son un lastre para la eficiencia. Cuantos más elementos de trabajo haya en curso, más se cambia el contexto, lo cual entorpece el camino para finalizarlo. Por ello, un principio fundamental de kanban es limitar la cantidad de trabajo en curso. Los límites del trabajo en curso resaltan los cuellos de botella y los respaldos en el proceso del equipo debido a la falta de concentración, personas o habilidades.
Por ejemplo, un equipo de software típico podría tener cuatro estados de flujo de trabajo: Por hacer, En curso, Revisión del código y Hecho. Podrían optar por establecer un límite de trabajo en curso de 2 en el estado de revisión del código. Puede parecer un límite bajo, pero tiene un buen motivo: los desarrolladores normalmente prefieren escribir código nuevo que perder tiempo revisando el trabajo de otra persona. Un límite bajo alienta al equipo a prestar especial atención a las incidencias en el estado de revisión y a revisar el trabajo de otros antes de generar sus propias revisiones del código. En última instancia, con esto se reduce la duración del ciclo general.
Métricas visuales
Uno de los valores fundamentales es hacer un fuerte énfasis en la mejora constante de la eficiencia y la efectividad con cada iteración de trabajo. Los diagramas ofrecen un mecanismo visual para que los equipos se aseguren de seguir mejorando. Cuando el equipo puede ver los datos, es más fácil detectar obstáculos en el proceso (y eliminarlos). Hay dos informes que los equipos de kanban utilizan habitualmente: los gráficos de control y los diagramas de flujo acumulado.
Un gráfico de control muestra el tiempo del ciclo de cada incidencia, así como una media acumulada del equipo.
El objetivo del equipo es reducir la cantidad de tiempo que tarda una incidencia en recorrer todo el proceso. Ver cómo se reduce la duración del ciclo media en el gráfico de control es un indicador de éxito.
Un diagrama de flujo acumulado muestra el número de incidencias que hay de cada estado. El equipo puede detectar bloqueos fácilmente al percibir un aumento del número de incidencias en cualquier estado determinado. Las incidencias en estados intermedios, como "en curso" o "en revisión", no se han lanzado aún al cliente, y un bloqueo en esos estados pueden aumentar la probabilidad de que se generen conflictos de integración en masa si el trabajo no se fusiona de forma ascendente.
Entrega continua
La entrega continua (CD) es la práctica de publicar trabajo para los clientes con frecuencia. La integración continua (CI) es la práctica de compilar y probar el código de forma automática y gradual a lo largo del día. En combinación, forman una canalización de CI/CD que resulta esencial para que los equipos de desarrollo (en especial, los de DevOps) puedan lanzar software más rápidamente, a la vez que se garantiza una gran calidad.
Kanban y CD se complementan perfectamente porque ambas técnicas hacen hincapié en la entrega del valor justo a tiempo (y una por una). Cuanto más rápido pueda un equipo entregar innovación al mercado, más competitivo será el producto. Los equipos de kanban se centran exactamente en eso: optimizar el flujo de trabajo hacia los clientes.
Scrum frente a kanban
Kanban y scrum comparten algunos de los mismos conceptos, pero tienen enfoques muy diferentes. No deben confundirse entre sí.
Scrum | Kanban | |
Cadencia | Sprints de longitud fija periódicos (por ejemplo, dos semanas) | Flujo continuo |
Metodología de publicación | Al final de cada sprint, si lo aprueba el propietario del producto | Entrega continua o a discreción del equipo |
Funciones | Propietario del producto, experto en scrum, equipo de desarrollo | No existen funciones. Algunos equipos cuentan con la ayuda de un orientador ágil. |
Métricas clave | Velocidad | Tiempo del ciclo |
Filosofía de cambios | Los equipos deben evitar cambios en la previsión durante el sprint. De lo contrario, se sacrifica el aprendizaje sobre la estimación. | Los cambios pueden suceder en cualquier momento. |
Algunos equipos mezclan las ideas de kanban y scrum para formar "scrumban". De scrum toman los sprints de longitud fija y las funciones; de kanban, la atención a los límites del trabajo en curso y la duración del ciclo. Para los equipos que estén iniciándose en la metodología ágil, sin embargo, recomendamos encarecidamente elegir una metodología u otra y trabajar con ella durante un tiempo. Ya podrás hacer experimentos más adelante.
Empieza gratis con la plantilla de kanban de Jira
Consulta el trabajo que más importa y haz que progrese para maximizar la eficiencia.
¿Listo para empezar?
Instrucciones pormenorizadas sobre cómo dirigir un proyecto de kanban, priorizar el trabajo, visualizar el flujo de trabajo y minimizar el trabajo en curso con Jira Software.
Leer el tutorialDiseño ágil: proceso y directrices para un diseño colaborativo
El diseño colaborativo itera sobre el diseño del producto al buscar las perspectivas de los clientes y los desarrolladores al inicio de un proyecto. Obtén más información.
Leer el artículo