Recientemente me han pedido que inspeccione el sistema Kanban que sigue nuestra empresa y tengo algunas dificultades para solucionarlo. Estoy trabajando en una empresa nueva y en el departamento de software hay 5 desarrolladores y 1 probador. Usamos JIRA para nuestro tablero Kanban. Las tareas aparecen inicialmente en la cartera de pedidos y cuando se aprueba la tarea y se asigna un desarrollador, se mueve a desarrollo. Cuando el desarrollador comienza a trabajar en la tarea, se mueve a en progreso y luego se envía a la fase de revisión/prueba/implementación. Si falla la prueba o la revisión, se vuelve a mover al desarrollo; de lo contrario, se completa y se mueve al estado de terminado.
Tenemos una cartera de pedidos realmente grande, está llena de tareas que casi se olvidan y no parece mejorar. Por ejemplo, la tarea más antigua ha estado allí durante 3 años.
La mayoría de las veces nos encontramos en demandas urgentes de los clientes o errores importantes. Los desarrolladores se quejan de que no hay tiempo suficiente para eliminar parte del trabajo pendiente, ya que se preocupan principalmente por las tareas urgentes. También hay algunos trabajos estancados que son tareas que nuestro equipo no sabe cómo manejar y estas tareas están en todas partes: trabajo atrasado, desarrollo e incluso en revisión. Las tareas se atascan en la fase de revisión porque algunas de ellas tardan mucho en simularse o probarse, por lo que los desarrolladores no están dispuestos a pasar por la fase de prueba porque prefieren trabajar en tareas urgentes.
No hay un límite en WIP porque dicen que están constantemente interrumpidos por tareas no planificadas o urgentes y que no tendría sentido limitar WIP. Por lo tanto, no puedo limitar la cantidad de tareas en las que trabajan los desarrolladores.
No creo que el equipo de desarrolladores sea pequeño, solo creo que les falta un sistema y les gusta resolver las cosas a su manera. El trabajo que he hecho hasta ahora consiste en filtrar los requisitos del cliente para que el trabajo pendiente no tenga tareas redundantes, pero las tareas antiguas todavía están ahí.
¿Qué puedo ofrecer al equipo para que puedan hacer frente tanto a las tareas urgentes como a las estancadas?
Primero: Está claro que su equipo de pruebas es demasiado pequeño . Una proporción de 5:1 simplemente va a (1) causar un gran retraso y (2) provocar errores. Tu propio proyecto es prueba de ello.
Incluso si pudiera demostrar que su proporción de 5:1 es suficiente, necesita al menos un probador más. Un equipo de 1 probador no es una buena idea porque no tienes a nadie probando el probador. Como usted mismo escribió, ¡tiene una lista constante de errores importantes ! QED.
Segundo: Su equipo está perdiendo mucho tiempo haciendo malabarismos con la lista. Y algo de esta lista simplemente nunca se va a hacer . ¡No puedes ver el bosque por los árboles!
Mi sugerencia es tomarse una tarde libre y jugar a matar la lista .
Dedique la primera media hora a establecer las reglas (que debe preparar de antemano, pero desea una participación del 80 % para conservar la cordura).
Algunas reglas con las que puede comenzar:
El objetivo de esto es hacer que la lista sea lo suficientemente pequeña para que todos puedan ver lo que van a hacer en el futuro previsible. Dejarán de perder el tiempo revisando cosas que nunca podrán hacer.
Último: no cree que el equipo de desarrolladores sea demasiado pequeño . Pero si vuelves a leer tu publicación, es difícil de creer. No veo cómo incluso el sistema más ingenioso del mundo podría reducir un retraso de más de 3 años, que se alimenta constantemente, sin agregar mano de obra.
Hay un par de problemas aquí.
El primer problema es el gran retraso. Esto es relativamente fácil de resolver: revise los elementos en el backlog y resuelva cualquier cosa que ya no sea necesaria. La resolución puede ser cualquier cosa, desde eliminar los elementos hasta marcarlos como "no funciona" u "obsoleto". La eliminación de duplicados también se puede hacer en este momento. Esta cartera de pedidos más pequeña debería ser más fácil de priorizar y, en general, administrar en el futuro. Le advierto que elimine los problemas conocidos del trabajo pendiente: es factible que los clientes o clientes potenciales soliciten tener acceso a problemas conocidos o a un subconjunto relevante de problemas conocidos.
El segundo problema es la falta de límites WIP. Recomendaría instanciar estos. Sin embargo, dado que también está trabajando en problemas críticos, tiene una fila "acelerada" en el tablero Kanban. También recomendaría comenzar a recopilar métricas sobre el rendimiento y el tiempo del ciclo para que pueda comenzar a predecir el trabajo futuro o cuándo posiblemente pueda comenzar y terminar el trabajo en función de dónde se encuentre en la cartera de pedidos. Creo que una de las cosas que revelarán estas métricas es que necesita personas adicionales o un cambio en el proceso que le permita mover el trabajo desde el momento en que está listo para la prueba hasta que se hace más rápido.
El tercer problema parece estar relacionado con la cantidad de problemas críticos. Tener una gran cantidad de problemas críticos que no pueden esperar o necesitan ser acelerados podría indicar una mala calidad. También podría indicar una mala gestión del producto y la priorización de estos problemas. Volviendo a tener métricas, si tiene datos sobre cuánto tiempo llevará realizar el trabajo dada una ubicación en la cartera de pedidos, puede trabajar con las partes interesadas para determinar si el trabajo realmente debe acelerarse o si puede priorizarse adecuadamente y seguir sus límites WIP. En general, reducir la cantidad de trabajos de reparación de defectos que se agregan a la cartera de pedidos también sería beneficioso para el equipo y el proyecto.
Tenemos una cartera de pedidos realmente grande, está llena de tareas que casi se olvidan y no parece mejorar. Por ejemplo, la tarea más antigua ha estado allí durante 3 años.
Un enfoque que he usado en el pasado es el siguiente:
Encuentro que este enfoque tiende a enfocar las mentes. Lo que sucede a menudo es que las personas que solicitan el trabajo aceptan archivar las tareas o solicitan más recursos para su equipo para que las tareas se realicen antes.
No hay un límite en WIP porque dicen que están constantemente interrumpidos por tareas no planificadas o urgentes y que no tendría sentido limitar WIP.
¡Esta es una situación en la que WIP funciona muy bien!
Cuando aparece una tarea urgente o no planificada, el equipo busca si causará que se exceda el límite WIP. Si lo hace, entonces se debe retirar algo más de esa cola.
Por ejemplo, aparece una corrección de error urgente. El equipo ya tiene 5 elementos en la columna 'desarrollo', que es el límite WIP. Miran hacia abajo en la lista y eliminan un elemento, volviéndolo a colocar en la columna de espera para comenzar.
A continuación, el equipo informa a la persona que solicitó el artículo que acaba de ser devuelto a la columna de espera para comenzar. Les dicen que su trabajo se retrasará debido a una tarea de mayor prioridad.
Los beneficios de este enfoque son:
Finalmente, puede resultarle útil tratar de cuantificar el impacto de las tareas urgentes y no planificadas.
Por ejemplo, podría enviar un correo electrónico de estado quincenal que diga cosas como:
Debido a las correcciones urgentes a la base de datos que llegaron la semana pasada, tuvimos que detener el trabajo en varias tareas. El equipo tardó casi un día en cambiar a las nuevas tareas y ese tiempo se perdió efectivamente. Estimaríamos que el impacto en el equipo fue una reducción en la eficiencia del 10-20% en el transcurso de la quincena.
Nuevamente, esto ayudará a enfocar las mentes.
El hecho de que su nota (tarea) más antigua sea de tres años no es necesariamente un problema, simplemente porque no importa qué tan grande sea el equipo que tenga, ellos junto con sus clientes siempre podrán generar más ideas sobre cosas nuevas para desarrollar/cambiar/refactorizar. /fix/etc de lo que la capacidad de su equipo podrá administrar. Si los miembros del equipo entienden esto, tendrán menos problemas con una acumulación cada vez mayor. Sin embargo, es posible que desee dedicar uno o dos días al año a limpiarlo; simplemente revisando los artículos más antiguos y deshaciéndose de los que ya no crearían valor.
En mi opinión, los beneficios de usar límites WIP están muy bien descritos https://leankit.com/learn/kanban/benefits-of-wip-limits/ .
Sin embargo, su pregunta era sobre cómo administrar las tareas urgentes y estancadas. Permítame tratar de elaborar un poco sobre cómo lo administramos en nuestro desarrollo, que está funcionando bastante bien.
En primer lugar, creo que podría considerar cambiar el contenido de sus notas. Usted mencionó que tiene notas que contienen tareas. En nuestro modelo de desarrollo, estamos tratando de asegurarnos de que cada nota describa un entregable que agregará valor al producto. Para completar ese entregable (nota), es posible que se deban realizar muchas tareas diferentes (análisis de requisitos, opciones arquitectónicas, diseño, implementación, documentación, verificación, validación, etc.). Al trabajar con límites WIP, hemos visto que se vuelve más efectivo si usa entregables en lugar de tareas. Tenemos dos límites WIP diferentes. Uno para las notas en todo el tablero (sin incluir las notas en el backlog o las columnas terminadas), lo llamamos Límite WIP de Kanboard (KWL). El otro es el límite WIP para las fases individuales en el Kanboard, lo llamamos Límite WIP de fase (PWL).
Un ejemplo: si su Kanboard tiene las fases Requisitos y diseño (RAD), Desarrollo y prueba de componentes (DCT), Prueba de características (FTE) y Prueba de integración (ITE), mientras que el tamaño de su equipo es 4. KWL sería 3 (tamaño del equipo - 1) y PWL <= 3. PWL comienza desde uno en la columna más a la derecha y aumenta en uno hasta un máximo de 3 en este caso.
Tratamos de mantener el esfuerzo estimado para una nota en la cartera de pedidos al máximo de lo que se puede completar en 2 semanas hombre. Dado que la cantidad de notas en curso está limitada por el límite WIP, esto significa que más de una persona trabajará en al menos una de las notas; fomentando el trabajo en equipo. Con los PWL disminuyendo en general, también respalda la idea central con Kanban para respaldar el flujo (preparar las cosas para el lanzamiento) en lugar de mantener muchas cosas en progreso (o estancadas) al mismo tiempo. Si una nota está atascada en la columna ITE, ninguna otra nota puede moverse allí. Esto enfatiza aún más que es más importante que el equipo termine en conjunto las tareas restantes para terminar esa nota en lugar de comenzar algo nuevo. Con los entregables estimados son de un máximo de 2 semanas hombre, creemos que se desglosan lo suficientemente bien como para respaldar que todas las personas del equipo puedan comprender qué se debe hacer para obtener la nota en la columna "listo para publicar". Cuando los entregables en la cartera de pedidos son más grandes que eso, se tiende a dedicar demasiado tiempo a hacer cosas que no son necesarias o se pierden cosas simplemente porque no está lo suficientemente claro qué entregar.
Digamos que hay un elemento estancado en la columna ITE y solo 3 de las cuatro personas del equipo pueden contribuir a trabajar en él, entonces la cuarta persona debería trabajar en la nota más alta en la columna FTE (prioridad más alta en el en la parte superior de cada columna, al igual que en el backlog). Tal vez esa cuarta persona no pueda contribuir (fácilmente) a la nota FTE o la nota DCT o la nota RAD para el caso. En ese caso se ha producido holgura (holgura en el sentido de lo que se describe en el enlace anterior).
Las notas estancadas deben ser administradas por el equipo o los gerentes de equipo como cualquier otra nota. Si algo impide que el equipo continúe trabajando en ello, entonces un gerente/gerente de producto/gerente de proyecto/maestro de scrum/maestro ágil (o lo que sea que tenga en su lugar) necesita ayudar a resolver el obstáculo. Si esto es algo que no involucra a los miembros del equipo, entonces la nota debe volver a colocarse en el backlog (porque nadie en el equipo está trabajando activamente en ello).
Las tareas urgentes, como usted dice, pueden muy bien ser tareas (no necesariamente entregables). Podría ser "investigar este informe de error" o "medir esto" o "resumir esto para un cliente", "debe resolverse un error que impide que el equipo funcione", etc. Para estos, hemos introducido una ambulancia (solo una ) en nuestro Kanboard. Una ambulancia acompaña una nota tan urgente mientras se mueve sobre el tablero y la ambulancia es el único artículo que puede romper el límite WIP. Cuando la ambulancia está en el tablero, tiene prioridad sobre las demás notas y la mayor cantidad posible del equipo debe contribuir a remediar la nota urgente lo más rápido posible.
Si utiliza esta configuración y se encuentra en una situación en la que la ambulancia está siempre (o con mucha frecuencia) presente en el Kanboard, es posible que deba considerar la creación de un único equipo específico para administrar solo las notas de la ambulancia.