La razón principal del 20% de tiempo es mantener la utilización de la capacidad al 80% en lugar de al 100%.
Puede pensar en una organización de desarrollo de software como un sistema que convierte las solicitudes de características en características desarrolladas. Puede modelar su comportamiento utilizando la teoría de colas .
TEORÍA
Si las solicitudes llegan más rápido de lo que el sistema puede atenderlas, se ponen en cola. Cuando las llegadas son más lentas, el tamaño de la cola disminuye. Debido a que los procesos de llegada y servicio son aleatorios, el tamaño de la cola cambia aleatoriamente con el tiempo.
Los matemáticamente inclinados pueden preguntar sobre esta "aleatoriedad": debe haber alguna distribución de probabilidad, entonces, ¿cuál será el tamaño de la cola en promedio? La matemática (teoría de colas) tiene una respuesta a eso: si los procesos de llegada y de servicio son Markov, entonces N = rho ^ 2 / (1-rho).
(Donde rho es el coeficiente de utilización igual a la relación de servicio y tasas de llegada. Si los procesos no son de Markov, la matemática es más complicada, pero no cambia las conclusiones).
Si traza esta función, puede ver que la longitud promedio de la cola permanece baja mientras la utilización es de hasta 0.8 , luego aumenta bruscamente y llega al infinito. Puede comprender esto intuitivamente pensando en la CPU de su computadora: cuando su utilización se acerca al 100%, la computadora deja de responder.
PRÁCTICA
La economía del desarrollo de software es tal que las compañías de software incurren en grandes costos cuando sus colas están en estados de alta cola. Esto incluye oportunidades de mercado perdidas, productos obsoletos, proyectos atrasados y desperdicio causado por las características del edificio en previsión de la demanda.
El 20% del tiempo es, por lo tanto, la respuesta científica al problema de optimizar los resultados económicos: evite estados de alta cola evitando los índices de utilización que los causan. Es esencialmente la holgura lo que mantiene al sistema receptivo.
Varias conclusiones prácticas siguen inmediatamente:
- si está considerando un 20% de tiempo y está haciendo una contabilidad de costos (el tiempo de los desarrolladores cuesta X, pero / y la empresa puede / no puede permitírselo), lo está haciendo mal.
- si está asignando un 20% a un viernes cada semana, lo está haciendo mal
- si está configurando un sistema de envío / revisión / aprobación de propuestas de proyectos del 20%, lo está haciendo mal
- si estás completando hojas de tiempo, lo estás haciendo mal
- Si utiliza la innovación como motivador durante un 20% de tiempo, lo está haciendo mal. Si bien los nuevos productos han salido del 20% de los proyectos, no eran el punto. Si su empresa no puede innovar durante sus horas centrales, ¡eso es un problema!
- El 20% del tiempo no se trata de creatividad. No digas que liberarás tu creatividad con un 20% de tiempo, pregunta por qué no eres lo suficientemente creativo durante tus horas centrales.
RESPUESTAS A PREGUNTAS EN LOS COMENTARIOS
Dan , entendiste bien y describiste con precisión el error cometido por muchos. No puede elegir su porcentaje de utilización, porque es una variable de salida. Es una relación de características de dos procesos, por lo que es lo que es porque los procesos son como son. Una organización tiene influencia sobre ambos procesos; la capacidad y la demanda de correspondencia es uno de los problemas difíciles que aborda el cuerpo de conocimiento de desarrollo de software lean. La utilización es uno de los indicadores de qué tan bien se resolvió este problema en una organización. La holgura emerge a medida que avanza su iniciativa Lean y elimina el desperdicio del flujo de valor. Pero si ordena un 20% de tiempo, terminará en la misma trampa de utilización con menos capacidad disponible.
Kim , todavía es parcialmente una cuestión de cultura. La referencia cultural más cercana que se me ocurre es el nivel sinérgico del llamado modelo Marshall de cambio organizacional. Emerge al final de las transformaciones lean exitosas o está presente en organizaciones construidas Lean desde el principio. ( Aquí hay un enlace al documento técnico de Bob Marshall (PDF)) .
Referencias
La lógica anterior está bien respaldada en la literatura de ingeniería de software. Mary y Tom Poppendieck lo insinuaron en su libro 2006 Implementing Lean Software Development . Donald Reinertsen en su libro de 2009 Principios del flujo de desarrollo de productos (Capítulo 3) brinda un tratamiento exhaustivo de este tema, con fórmulas y gráficos.