MANUAL TE GP AGILES

MANUAL GESTIÓN DE PROYECTOS ÁGILES

El lector intrépido (ya conocedor de Scrum) se habrá dado cuenta de que todavía no hemos hablado de nada parecido a épicas, historias de usuario, etc. y que no hemos mencionado todavía nada de técnicas de estimación de tareas como planning poker u otras. El motivo de todo ello es que en Kanban encaramos de otra manera la planificación. En Scrum, basándonos en el conocimiento aprendido del equipo sabemos aproximadamente cuántas unidades de trabajo podemos sacar adelante en las próximas dos semanas (sprint medio) y nuestro objetivo a va a ser seleccionar un conjunto de historias de usuario que nos permitan ajustar al máximo el sprint backlog; sin embargo, en Kanban no funcionamos con divisiones temporales, no hay sprints y por lo tanto no nos vamos a centrar en intentar ajustar el volumen de trabajo a un marco temporal. Todo lo contrario, lo que estamos buscando en Kanban es ese “horno de Telepizza”, estamos buscando reducir la variabilidad y confiar en que nuestras tareas saldrán por el final del horno pasados diez minutos aproximadamente. Por tanto no queremos estimar tarjetas, queremos que las tarjetas tengan un tamaño similar que podamos acomodar en una clase de servicio. El enfoque como veis es diferente. Además no nos vamos a preocupar en exceso, nos bastará la experiencia y el sentido común para saber si una tarea es adecuada o no. Os propongo las siguientes claves para dimensionar una tarjeta para hacer que sea pequeña.  Los límites del WIP no se llevan bien con tareas grandes (de semanas o meses). Si tengo un límite de 2 y estoy trabajando en 2 tareas de un mes de duración me he convertido en un cuello de botella automáticamente.  Evitemos las tareas con sub-tareas. Nos quitan visibilidad y crean bloqueos parciales difíciles de gestionar ya que nos permiten avanzar a medias con una tarea.  Es más fácil ajustar la variabilidad de las tarjetas si procuramos que sean siempre pequeñas.

Para aprender a dimensionar, hay que entender qué significa pequeña en nuestro contexto, que no es un concepto genérico.

Queremos que las tareas fluyan por un tablero con pulso, que las veamos avanzar y entregar valor de manera constante. Esto nos permite ser ágiles, tomar decisiones y detectar problemas de manera rápida. Os recomiendo que intentéis en la medida de lo posible que las tarjetas sean de un tamaño tal que vuestro equipo pueda sacarlas adelante en pocos días o una semana como máximo. Si una tarea veis que va a ser más larga preguntaros siempre si es divisible en unidades menores de valor. Esto es clave, no sirve de nada dividir en unidades que no generen un valor para nuestros stakeholders ya que esta es la clave del sistema, entregar valor de manera constante. Si una tarea no se puede dividir porque no generaríamos valor con las divisiones de manera independiente, entonces no es divisible.

212

European Open Business School