2009-05-29 20 views
8

¿Alguien está usando Kanban (o scrumban) para las prácticas de administración ágiles? ¿Cuál es tu experiencia con Kanban? ¿Cómo funciona en grandes entornos complejos con dependencias en proyectos de cascada?¿Alguien está usando Kanban?

Respuesta

9

Sé que la BBC lo usa bastante. Vea el blog de David Joyce para más detalles http://leanandkanban.wordpress.com/

Tiene una plataforma de deslizamiento bastante robusta para pasar.

Creo que lo que hay que recordar sobre el pensamiento Lean es que debes considerar el flujo de valores como un todo. Si bien puede optimizar al máximo el equipo de desarrollo utilizando técnicas como Kanban, es más importante incorporar tanto la corriente ascendente (gestión/análisis) como descendente (garantía de calidad/implementación/soporte) para cosechar plenamente las recompensas.

Por lo tanto, preguntar cómo encaja esto en un proceso complejo o cascada (más allá de su efecto personal), no es exactamente la pregunta correcta. Lo que es una pregunta más importante es preguntar cómo puedo comenzar a aplicar todo el flujo de valor. Sé que esto suena como el comienzo del fanatismo Lean religioso, pero es cómo te darás cuenta del verdadero valor de un proceso delgado.

Por ejemplo, considere el siguiente escenario para un proyecto típico:

  • Tiempo de análisis: 18 meses
  • Dev tiempo: 9 meses
  • QA & tiempo de liberación: 4 meses
  • adopción de los clientes y retrabajo: 12 meses

Total: 43 meses

Si aplica Lean al proceso de desarrollo mejora en un 100%, es decir, un tiempo de desarrollo de 4.5 meses, lo que arroja un nuevo total de 38.5 meses. Entonces, solo has aumentado el flujo de valor total en poco más del 10% ... ¡insignificante!

Tienes que empezar a pelear la lucha y llevar el pensamiento Lean a la alta dirección y demostrar dónde está el verdadero éxito ... que está en el rediseño de todo el proceso.

Recuerde Lean NO es un proceso de desarrollo, se puede aplicar a todos los aspectos del negocio.

Algunos libros interesantes sobre cómo llevar esta discusión más allá del equipo de desarrollo incluyen;

+0

desde entonces se ha publicado el libro Kanban por David Anderson, también – Ingvald

5

primer lugar, es importante darse cuenta de los problemas que Kanban en desarrollo de software intenta resolver:

  • Multitarea/sobrecarga de trabajo. Kanban las soluciona mediante sus sistemas Just-in-time y Queue. Hay es suficiente en la cola para mantener ocupado, pero no está sobrecargado (esto viene con práctica con estimación y velocidad eficiente monitoreo). Y JIT se asegura de que las personas no tengan que realizar múltiples tareas y , por lo tanto, pierden productividad.
  • Lanzamientos aguas abajo impredecibles. Si trabajas en una gran organización de software, la pieza que estás desarrollando podría ser solo una en una gran yuxtaposición de software. Por lo tanto, podría haber equipos descendentes que podrían esperar su característica. El sistema de cola de Kanban junto con sus cronogramas de entrega en el tiempo aseguran que haya una cierta cantidad de previsibilidad en las versiones.

En su mayoría, otras prácticas ágiles también intentan resolver problemas similares con diferentes técnicas.

grandes entornos complejos con dependencias en proyectos cascada

Esto hace que sea difícil si usted tiene una dependencia en un proyecto que no sigue ágil como entonces su cola de entrada no será predecible. Si un proyecto no ágil depende de usted, el problema podría ser menor, pero podría terminar produciendo más de lo que puede consumirse ('muda' en terminología pobre). Entonces, lo ideal sería que todos los proyectos dependientes siguieran al menos algunas prácticas ágiles, si no kanban.

Se puede encontrar un buen artículo sobre Kanban, Flow y Cadence here.

2

¿Alguien está usando Kanban (o scrumban) para las prácticas de administración ágiles?

Sí, estoy usando :-)

¿Cómo funciona en entornos complejos con grandes dependencias en proyectos cascada?

En nuestro entorno tenemos> 500 desarrolladores, por lo que es bastante grande. Mi equipo fue el primero, que utilizó Kanban, principalmente para el trabajo de mantenimiento, y ahora para el desarrollo. Nuestro trabajo diario fue muy duro, porque los otros equipos dependientes seguían técnicas clásicas de desarrollo y administración, y les gustó (todavía lo hacen) empujar el trabajo y Kanban es aproximadamente extraer.

Nuestro enfoque fue comunicarnos lo más posible para hacer que nuestro trabajo fuera transparente, pero debido a la reticencia del entorno, nos enfocamos en nuestro trabajo interno. El límite de WIP nos ayudó a mantenernos enfocados, y con el flujo de trabajo de visualización sabíamos quién está haciendo qué en este momento.

Nuestro rendimiento antes de Kanban fue del 90% (en otras palabras, cuando llegaron 10 artículos, entregamos solo 9), y después de Kanban tuvimos 100.4% y fue en aumento. Como resultado adicional, otros equipos comenzaron a venir y preguntar acerca de Kanban, porque les gustaban nuestros resultados y querían implementar su propio sistema Kanban. Por el momento, sé de 5 equipos, lo que inició Kanban en nuestra organización.

HTH,

Zsolt

Cuestiones relacionadas