Cerrar

Kanban

Aplicación de la metodología kanban en el desarrollo de software

¿Qué es kanban?

Kanban es un marco de trabajo muy popular a la hora de implementar un desarrollo de software ágil. Requiere una comunicación en tiempo real sobre la capacidad y una transparencia del trabajo total. Los elementos de trabajo se representan visualmente en un tablero kanban, lo que permite a los miembros del equipo ver el estado de cada uno en cualquier momento.

Kanban articles

[CONTINUED]

Kanban is enormously prominent among today's agile software teams, but the kanban methodology of work dates back more than 50 years. In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match consumption patterns, the supermarket gains significant efficiency in inventory management by decreasing the amount of excess stock it must hold at any given time. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock.

When Toyota applied this same system to its factory floors, the goal was to better align their massive inventory levels with the actual consumption of materials. To communicate capacity levels in real-time on the factory floor (and to suppliers), workers would pass a card, or "kanban", between teams. When a bin of materials being used on the production line was emptied, a kanban was passed to the warehouse describing what material was needed, the exact amount of this material, and so on. The warehouse would have a new bin of this material waiting, which they would then send to the factory floor, and in turn send their own kanban to the supplier. The supplier would also have a bin of this particular material waiting, which it would ship to the warehouse. While the signaling technology of this process has evolved since the 1940s, this same "just in time" (or JIT) manufacturing process is still at the heart of it.

Kanban para equipos de software

Agile software development teams today are able to leverage these same JIT principles by matching the amount of work in progress (WIP) to the team's capacity. This gives teams more flexible planning options, faster output, clearer focus, and transparency throughout the development cycle.

Kanban Board | Atlassian agile coach

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 sobre el trabajo del equipo.

Agile Kanban Board | Atlassian agile coach

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.

The benefits of 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

A kanban team is only focused on the work that's actively in progress. Once the team completes a work item, they pluck the next work item off the top of the backlog. The product owner is free to reprioritize work in the backlog without disrupting the team, because any changes outside the current work items don't impact the team. As long as the product owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business. So there's no need for the fixed-length iterations you find in scrum.

PRO TIP:

Savvy product owners always engage the development team when considering changes to the backlog. For example, if user stories 1-6 are in the backlog, user story 6's estimate may be based on the completion of user stories 1-5. It's always a good practice to confirm changes with the engineering team to ensure there are no surprises. 

Shortened time cycles

Cycle time is a key metric for kanban teams. Cycle time is the amount of time it takes for a unit of work to travel through the team’s workflow–from the moment work starts to the moment it ships. By optimizing cycle time, the team can confidently forecast the delivery of future work.

Solapar conjuntos de aptitudes se traduce en tiempos de ciclo más cortos. Cuando hay una sola persona que posee un conjunto de aptitudes, esa persona se convierte en un obstáculo del workflow. Así, los equipos que se valen de buenas prácticas básicas como la revisión del código y la formación, ayudan a transmitir los conocimientos. Con las habilidades compartidas, los miembros del equipo pueden asumir trabajos heterogéneos, cosa que optimiza más aún el tiempo de ciclo. También favorecen que, si hay una copia de seguridad del trabajo, todo el equipo se puede volcar en él para que el proceso vuelva a fluir sin problemas. Por ejemplo, no solo los técnicos de control de calidad realizan pruebas. Los desarrolladores también arriman el hombro.

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, una propuesta clave 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.

For example, a typical software team might have four workflow states: To Do, In Progress, Code Review, and Done. They could choose to set a WIP limit of 2 for the code review state. That might seem like a low limit, but there's good reason for it: developers often prefer to write new code, rather than spend time reviewing someone else's work. A low limit encourages the team to pay special attention to issues in the review state, and to review others work before raising their own code reviews. This ultimately reduces the overall cycle time.

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.

Pro Tip:

The team's goal is to reduce the amount of time an issue takes to move through the entire process. Seeing the average cycle time drop in the control chart is an indicator of success. 

Agile control chart | Atlassian agile coach

Un diagrama de flujo acumulado muestra el número de incidencias que hay de cada estado. El equipo puede detectar bloqueos fácilmente viendo un aumento del número de incidencias en cualquier estado determinado. Las incidencias en estados intermedios, como "en progreso" 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 combina de forma ascendente. 

Diagrama de flujo acumulado

Entrega continua

We know that continuous integration–the practice of automatically building and testing code incrementally throughout the day–is essential for maintaining quality. Now it's time to meet continuous delivery (CD). CD is the practice of releasing work to customers frequently–even daily or hourly. Kanban and CD beautifully complement each other because both techniques focus on the just-in-time (and one-at-a-time) delivery of value.

The faster a team can deliver innovation to market, the more competitive their product will be in the marketplace. And kanban teams focus on exactly that: optimizing the flow of work out to customers

Scrum frente a kanban

Kanban and scrum share some of the same concepts but have very different approaches. They should not be confused with one another. 

 

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
Cambio de filosofía 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". Toman los sprints de longitud fija y las funciones de scrum, y la atención a los límites del trabajo en curso y el tiempo del ciclo de kanban. 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. 

Dan Radigan
Dan Radigan

La metodología ágil ha influido mucho en mí, tanto en el aspecto profesional como en el personal: he aprendido que las mejores experiencias se basan en el modelo ágil, tanto al programar como en la vida real. Mis intereses suelen moverse entre la tecnología, la fotografía y el motociclismo. ¡Sígueme en Twitter! @danradigan

Up Next
Paneles