Skip to content

Latest commit

 

History

History
270 lines (171 loc) · 10.9 KB

kanban.md

File metadata and controls

270 lines (171 loc) · 10.9 KB

Kanban

  • Kanban es un método para mejorar los procesos usados por los equipos ágiles. Los equipos que usan Kanban empiezan analizando y comprendiendo la forma que utilizan para construir el software, y lo utilizan para mejorar este proceso.

  • Kanban nos ayuda a ir cambiando el prisma de ¿Qué hacen las personas? a ¿Cómo va el trabajo?. En la línea de los valores ágiles, Kanban refuerza los valores de Colaboración y Respeto.

  • El objetivo de Kanban es conseguir pequeñas mejoras en el proceso de desarrollo, empezando por el sistema que actualmente usa el equipo y persiguiendo cambios evolutivos obtenidos colaborativamente a través de experimentos.

  • Kanban utiliza elementos de la metodología lean, como el lead time (tiempo de terminación) o el flujo para medir el funcionamiento del equipo.

  • El equipo de la izquierda está estresado; no tienen claras las prioridades. Nadie está seguro de en qué están trabajando los compañeros y las tareas se acumulan.

  • El equipo de la derecha ha mejorado significativamente el tiempo de puesta en producción de las nuevas características y existe un funcionamiento común entre marketing, negocio y operaciones.

  • El tablero Kanban sirve para representar las distintas fases del proceso por las que deben de pasar los ítems de trabajo. Puede haber filas opcionales para distintos tipos de trabajos. Las tarjetas del tablero representan los ítems de trabajo.

  • Un ítem de trabajo representa una parte del trabajo que debe terminarse. En la aplicación de Kanban a equipos de desarrollo puede representar:

    • Una funcionalidad (historia de usuario) a desarrollar.
    • Un conjunto de líneas de código a incorporar en el proyecto mediante un pull request.
    • Un diseño gráfico a realizar.

  • El tablero Kanban indica en qué lugar del proceso está cada ítem de trabajo en el contexto de las demás. Permite al equipo identificar colas, cuellos de botella e incluso falta de carga de trabajo, promoviendo la colaboración. Busca hacer visible lo invisible.

    • Cuando algo se hace visible es más fácil identificar un problema y conseguir una solución. Esto se acentúa en equipos con distintas especialidades, donde cada uno tiene una idea distinta de las dependencias y los riesgos.

    • Los ítems de trabajo se mueven por las columnas del tablero Kanban indicando el cambio de su estado.

  • El tablero se actualiza en tiempo real por los miembros del equipo. Los cuellos de botella se identifican en reuniones diarias.

  • Al limitar el trabajo en proceso (WIP, Work In Progress) la gente se centra en terminar cosas, en lugar de empezar muchas cosas o comprometerse a demasiado trabajo a la vez.

  • Se siguen reglas explícitas para mover una tarjeta. Esto obliga a discutir y acordar las políticas del proceso.

  • Veamos un ejemplo de cómo cambian de estado los ítems de trabajo respetando el límite de WIP de cada columna. Cuando una columna ha llegado a su límite de WIP no es posible mover a ella ningún ítem más.

    • Si hay ítems terminados en la columna anterior a otra que tiene cubierto su WIP esos ítems se quedan en espera en la columna anterior. Es habitual indicarlo creando una subcolumna que hará de buffer en el que se acumularán los ítems en espera. El número de ítems en el buffer también cuenta para el límite de WIP.

  • Después de un tiempo con los ítems B y C en Develop no se puede pasar el ítem D a esa columna porque se sobrepasaría su límite de WIP.

  • En la columna Deploy se ha encontrado un problema en el ítem A. Mientras, en la columna Develop se ha terminado el ítem B. No se puede pasar a Deploy porque se rebasaría su límite de WIP de 1. Se deja en la columna Develop, pero en la subcolumna Done que hace de buffer para los ítems terminados que no pueden pasar a la siguiente columna.

  • El equipo de desarrollo no puede coger el ítem D porque sobrepasaría el límite de WIP de la columna. El problema del despliegue de A está creando un cuello de botella que obliga a que todos sean conscientes del problema.

  • Los desarrolladores que estaban con B echan una mano a los que están desplegando A. El problema de A se ha hecho visible y en el futuro los desarrolladores tendrán más cuidado en pasar a Deploy ítems mal terminados.

  • El Product Owner ha seleccionado el ítem K y se ha alcanzado el límite de WIP de la columna Selected.

  • Se termina el desarrollo de C, pero se sigue sin poder comenzar ningún otro ítem porque el problema de A sigue sin resolverse.

  • El bloqueo producido por el ítem A llega a todo el equipo. Se generan conversaciones sobre el problema y que sirven para incorporar nuevas políticas.

  • ¡Hasta el PO quiere ayudar a desplegar!

  • La nueva política ayudan a que todo vaya más fluido.
  • Se ha aumentado el límite de WIP de desarrollo a 3.

  • Es muy importante definir correctamente el alcance del tablero y la granularidad y el estado de los ítems de trabajo.
    • Si el alcance del tablero es demasiado grande, los ítems de trabajo son demasiado pequeños o sus estados son demasiado cortos en tiempo tendremos un tablero tan ocupado y que tiene que actualizarse tan frecuentemente que no será práctico.
    • Por el contrario, si el tablero tiene un alcance muy estrecho y sólo trata con ítems grandes cuyo estado cambia muy lentamente, tampoco será útil por no mostrar los elementos necesarios.

  • Es posible trabajar con varios tableros orientados a distintas audiencias: un tablero para el desarrollo y otro para el Product Owner y la empresa. El primero podría tendría como ítems de trabajo las tareas en desarrollo del equipo. El segundo funcionalidades o historias de usuario.