Kanban como proceso de desarrollo de software en la práctica

Question

¿Alguien ha utilizado el kanban method para la gestión de desarrollo de software?

Estoy evaluando kanban como una técnica y sería curioso escuchar de alguien que realmente lo haya aplicado en práctica sobre su efectividad. He visto preguntas como: is-anyone-using-kanban, kanban-vs-scrum y apply-kanban-in-an-agile-team, pero no abordan mis inquietudes.

Lo que me interesa en particular es:

1. es lo que realmente ofrecen las ventajas es reclamaciones en cuanto a la identificación de los cuellos de botella de forma dinámica?
2. ¿Es fácil de ejecutar en la práctica o tiene desafíos logísticos que debe gestionar?
3. ¿Se escala bien para proyectos de equipos con muchos flujos de trabajo paralelos y muchos desarrolladores?
4. ¿Cómo se compara con el análisis de ruta crítica (como se implementó en MS Project), cómo es diferente?
5. ¿Qué otros beneficios se pueden obtener al aplicar kanban?

Gracias.

Answer 1

En el artículo Applying Kanban to PC Deployment el equipo ha de dar cuenta de los siguientes equipos:

• 160 nuevos PCs para ser desplegado
• 40 nuevas computadoras portátiles para ser desplegados
• 120 PCs y 10 computadoras portátiles para ser refrescada y redistribuido

... estamos explorando el uso de Kanban para gestionar un corto plazo funcional proyecto. Este ejemplo se centra en el uso de Kanban para crear un proceso transparente para rastrear el flujo de equipos a través de una serie de pasos complejos , sin incurrir en costos adicionales para el seguimiento de software, complejos procesos y capacitación o duplicación de esfuerzos. La uniformidad mejorada o la calidad del proceso de implementación también ayudará a mejorar las eficiencias de en los tiempos de reparación y solución de problemas, así como a garantizar un alto nivel de conformidad con el documento de licencias y software .

La página anterior también tiene enlaces a Kanban aplica ...

• de Soporte Técnico
• to PC Deployment (véase cita anterior)
• to a Development Group
• retos, conceptos adicionales, y Wrapup

Answer 2

No tengo experiencia específica con el uso de Kanban en el software, pero estoy familiarizado con la práctica desde el punto de vista de la fabricación, así que tenía curiosidad en cuanto a la implementación. Al leer su enlace, lo que más me llamó la atención es lo que parecía una suposición subyacente sobre el tamaño del mismo tamaño de las unidades de trabajo (características, historias, lo que sea). Si bien mantener las "dimensiones de la historia" es un buen objetivo, a menudo hay una mezcla de historias más grandes y pequeñas flotando, y las pequeñas restricciones numéricas en su canalización parecen artificiales. Si el objetivo es resaltar los cuellos de botella, creo que las paradas y la planificación de sprints y las retrospectivas lo harán bastante bien. Si el objetivo es facilitar la priorización, creo que poner restricciones en el número de tareas por tipos no haría eso y simplemente ordenarlos de arriba abajo.

Supongo que realmente no veo qué valor está agregando; Dicho esto, no veo el daño al intentarlo y adoptar cualquier pieza que funcione.

Answer 3

Tampoco tengo mucha experiencia en ello, pero creo que puedo ofrecer algunas ideas. 4: la principal diferencia entre las placas Kanban y otras técnicas, como CPM, es que una placa Kanban, en una implementación correcta, te obliga a imponer límites de trabajo en progreso. Esto crea un sistema de extracción, ya que los elementos nuevos son aceptados por los trabajadores solo cuando tienen capacidad. Esto difiere de un proyecto de tipo de proyecto MS donde las tareas se asignan a los trabajadores de antemano (es decir, empujadas).

Es mucho más fácil identificar un cuello de botella en un sistema de extracción, porque los elementos de trabajo estarán en cola en alguna etapa del proceso. En un sistema de inserción, el trabajo se transmite a través del sistema (ya sea que esté 'hecho o no hecho'), por lo que es difícil encontrar cuellos de botella.

Otra ventaja de un sistema de extracción es que puede comenzar a basar las líneas de tiempo de trabajo en los resultados reales (tiempo de avance y ciclo), a diferencia de la predicción. Sí, el tamaño y la granularidad de las historias sí lo afecta, pero con técnicas como los diagramas de flujo acumulativos esto se vuelve menos importante.

2: La mayoría de las implementaciones son bastante simples, y ahí radica parte de la fuerza de la técnica. Creo que si tienes problemas con la logística de la técnica, lo estás haciendo mal.Eche un vistazo a here para obtener un buen ejemplo de 'kickstart'.

Answer 4

El método Kanban está en primer plano más un catalizador para las mejoras continuas del proceso. No es una solución rápida o un conjunto fijo de pasos/prácticas. El método tiene algunos principios básicos y propiedades centrales, como se describe en David J Andersons recent blog post, que pueden guiarlo hacia mejoras continuas del proceso. a sus preguntas:

1. El método Kanban en sí mismo no identifica los cuellos de botella. Al implementar límites de trabajo en progreso para un proceso que crea estrés en su proceso, eventualmente creará un sistema de extracción y luego será más fácil identificar cuellos de botella en su proceso. Las herramientas como un tablero kanban visual y diagramas de flujo acumulativo lo ayudarán a identificar los cuellos de botella en el proceso.

2. Si aplica los principios fundamentales y las propiedades centrales y tiene la resistencia/paciencia/dedicación, no es demasiado difícil. Debe gestionar el proceso de cambio como con cada cambio organizacional, pero el Método Kanban está diseñado para realizar cambios pequeños y no amenazantes.

3. Sí, hay muchos casos documentados de esto.

4. El método Kanban no identifica un método específico para planificar y proyectar futuras entregas. David J Anderson tiene antecedentes en Theory of Constraints y usa TOC como modelo en la mayoría de los escritos que he leído. Creo que la gran diferencia es la diferencia práctica entre el uso de la planificación inicial de estilo MS Project y la planificación empírica basada en muchas implementaciones de kanban.Al trabajar con un plan de proyecto diseñado en MS Project al comienzo de un proyecto, usted sabe muy poco sobre el dominio real del problema y usted hace suposiciones. En función de estas suposiciones, configura un plan. Una ruta crítica se calcula en base a estas suposiciones. Con un sistema kanban estable y usa TOC como su modelo, planea "solo" tener su restricción/cuello de botella en la ruta crítica. Usted toma en cuenta la variabilidad histórica del trabajo que pasa la restricción y crea búferes a su alrededor con el riesgo apropiado que desea tomar. La idea es que cada hora perdida en el cuello de botella será una hora perdida para todo el sistema.

5. El principal beneficio del Método Kanban es que es un catalizador para las mejoras continuas del proceso. Comienza con lo que obtienes y hace cambios no amenazantes que se mantienen. Kanban es un método que es Made to Stick

Answer 5

1. ¿realmente ofrecen las ventajas es reclamaciones en cuanto a la identificación de los cuellos de botella de forma dinámica?

Esta ha sido mi experiencia. Al establecer los límites de su WIP para reflejar la capacidad disponible, si hay trabajo que necesita hacer uso de esa capacidad pero tiene que esperar a que esté disponible, entonces lo verá cuando la cola de trabajo retroceda antes del cuello de botella. He visto esto suceder cuando hay un equipo de QA con exceso de trabajo con un equipo de desarrollo upstream que sigue produciendo aunque no haya posibilidad de que el QA lo mire. La solución que tomamos para esto fue prestar algunos de los desarrolladores al equipo de control de calidad, que luego ayudó a aliviar el cuello de botella.

2. ¿Es fácil de ejecutar en la práctica o tiene desafíos logísticos que debe gestionar?

Esto dependerá de muchos factores que serán específicos del contexto al que lo está aplicando. Una de las grandes ventajas de Kanban es que no requiere un cambio inmediato de "todo o nada" de la forma en que está trabajando actualmente. El capítulo 'Una receta para el éxito' en el libro 'Kanban' de David Anderson ofrece una excelente manera de abordar el cambio, comenzando con 'Enfoque en calidad'

3. ¿Se escala bien para proyectar equipos con muchas transmisiones paralelas de trabajo y muchos desarrolladores?

En el proyecto donde lo usé por primera vez, terminamos con un equipo de diecisiete desarrolladores y también habíamos trasladado el equipo de control de calidad de cuatro a nuestro equipo. También tuvimos muchas dependencias externas que usamos Kanban para modelar.

4. ¿Cómo se compara con el análisis de ruta crítica (como se implementó en MS Project), cómo es diferente?

pasar como nunca han utilizado

5. ¿Qué otros beneficios se pueden obtener de la aplicación de Kanban?

Hay muchas, pero la que voy a mencionar es que le da métricas que son realmente útiles para discutir y dirigir el trabajo, tanto con el equipo y con las partes interesadas y otras personas ajenas al equipo. Específicamente, el uso de 'Throughput' y 'Cycle Time' te da una probabilística para el reparto de cuándo se realizará el trabajo.