Una importante lección que he aprendido es que cuando nos dejamos llevar demasiado, creamos trabajo adicional para nosotros mismos. Este trabajo adicional es una forma de meta-trabajo sin valor que yo llamo trabajo secundario . Se interpone en el camino de hacer el trabajo que realmente da valor.
¿Por qué nos permitimos estar tan ocupados? Porque creemos que si no estamos ocupados entonces debemos estar perdiendo tiempo y dinero. Los desarrolladores de software son un lote caro, por lo que deben mantenerse ocupados para obtener un buen retorno de la inversión en sus salarios, ¿verdad? Centrarse en mantener a la gente ocupada se conoce como eficiencia de los recursos . Este tipo de pensamiento está arraigado en la cultura industrial occidental.
Veamos dos ejemplos en los que los equipos de desarrollo de software tienden a generar trabajo secundario para ellos mismos.
Atrasos
¿Cuántas cosas estás rastreando en tu trabajo atrasado? Tener una lista de las próximas cosas por hacer puede ser importante; cuando terminas una cosa puedes pasar sin problemas a la siguiente. Pero si tienes demasiadas cosas en tu trabajo atrasado inevitablemente generará un nuevo tipo de trabajo que no genera valor: la gestión de la lista.
No es raro encontrar equipos en las reuniones de de preparación de atrasos en las que se prioriza la lista, se intenta recordar de qué se trataban los antiguos elementos, se hacen actualizaciones, se desglosan tareas, se estima el trabajo, etc. Lamentablemente, gran parte de este trabajo termina siendo un puro desperdicio porque nunca terminamos escribiendo el código para ofrecer esas características.
¿Cuánto trabajo secundario generará este atraso?
Deberíamos reducir este desperdicio y recuperar el tiempo para hacer el trabajo real – el trabajo que realmente añade valor. Algunos equipos tratan de mitigar el efecto de un largo retraso mediante el trabajo de las cajas de tiempo o sólo se centran en los elementos más importantes. Pero estas medidas sólo abordan los síntomas del problema en lugar de la causa real: el retraso es demasiado grande.
La solución es limitar tu inventario de atrasos.Las listas pequeñas son fáciles de administrar y no pierden mucho tiempo.Así que elige un pequeño número de artículos para guardar y elimina el resto.A medida que termines el trabajo liberarás espacio en el atraso para añadir nuevos artículos.Si surge algo más importante entonces desplazará otros trabajos y el artículo de menor prioridad será eliminado.
No te preocupes de que te olvides de los artículos de la lista. ¡Ese es el objetivo! Si algo es lo suficientemente importante, resurgirá una y otra vez hasta que lo hagas. Si no es importante, ¿por qué preocuparse?
Demasiado trabajo en progreso
Entonces, acabas de terminar de escribir un código pero tu compañero de equipo no puede hacer la revisión del código porque están ocupados con otra cosa.
La mayoría de los desarrolladores comenzarán a trabajar en la próxima tarea disponible.se siente como lo correcto, sobre todo porque no quieres que tu jefe te vea sentado sin hacer nada.pero ahora estás ocupado, lo que perjudica tu disponibilidad cuando alguien necesita que tú hagas algo por ellos o cuando tu compañero de equipo vuelve para ayudarte.
Si se deja sin control, esta mentalidad lleva a la creación de colas de trabajo entre los miembros de su equipo. A medida que la cantidad de trabajo en vuelo crece, los equipos comienzan a generar trabajo secundario para llevar un seguimiento de todo. La comunicación se hace más difícil, por lo que se añade más trabajo para el seguimiento e informe del estado. Se crean procesos para gestionar la ramificación del código, la fusión y las revisiones. Las herramientas de CI pueden ampliarse para funcionar en múltiples sucursales.
Todo este trabajo secundario agrava el problema original de estar ocupado. Además, se ralentiza por el cambio de contexto adicional. Su ritmo de entrega de valor se ralentiza.
Para evitar este problema, es necesario poner un tope a la cantidad de trabajo que puede estar en curso en un momento dado. Estos límites se denominan límites de trabajo en curso (WIP)1. Cuando un desarrollador termina una tarea y no puede comenzar una nueva, se ve obligado a esperar. Entonces está disponible cuando alguien necesita ayuda o una revisión de código. El trabajo se realiza más rápidamente ya que se centra en terminar el trabajo en lugar de comenzar un nuevo trabajo.
Los límites del WIP impiden la acumulación de trabajo secundario.
Aunque tomarse un pequeño descanso puede ser muy beneficioso, esto no significa necesariamente que los desarrolladores deban permanecer inactivos mientras esperan. Sólo significa que no deberían empezar a trabajar más en equipo. Podrían sentarse y formar pareja con otro desarrollador para que el trabajo se haga antes. O aprender algo nuevo. O podrían trabajar en alguna cosa de baja prioridad que puedan dejar de lado en un momento dado.
Inclinarse
La eficiencia en el uso de los recursos consiste en mantenerse ocupado. Cuando hagamos de esto una prioridad, siempre empezaremos a encontrar trabajo secundario. ¿Hay algo más en lo que debamos centrarnos?
Lo hay. Podemos concentrarnos en entregar valor rápidamente terminando el trabajo en vez de empezarlo. Cuando nos concentramos en esto en vez de estar ocupados, descubrimos que reducir la velocidad puede hacernos rápidos.
Centrarse en hacer el trabajo se llama eficiencia de flujo . El estudio de Lean 2 nos enseña la relación entre el flujo y la eficiencia de los recursos. Ambos son importantes, pero Lean explica cómo centrarse en el flujo nos ayuda a hacer más trabajo más rápido, ¡incluso si significa que no estamos manteniendo a la gente ocupada todo el tiempo!
Esta es una de las razones por las que las prácticas de programación en pareja y en la mafia son tan efectivas. Sabemos que escribir mucho código tan rápido como podamos no es la manera de obtener código de calidad (de hecho, así es como se hace un gran lío), por lo que deberíamos dejar de actuar como si poner las manos en el teclado indicara que estamos trabajando duro! ¿Y cuántas veces has pasado mucho tiempo codificando sólo para obtener tus mejores ideas después de salir del trabajo? El hecho de tener poco tiempo fomenta la innovación y reduce el agotamiento.
Medir la productividad del desarrollo de software es problemático en el mejor de los casos. Comparar equipos es inútil. Pero anecdóticamente, he visto de primera mano lo efectiva que puede ser la filosofía Lean. En un trabajo anterior, trabajé en un equipo que pasaba regularmente de 5 a 8 horas a la semana sólo gestionando nuestro retraso y coordinando el trabajo, ¡casi un día entero de trabajo secundario! Luego, cuando me incorporé, mi equipo aplicó estos conceptos y sólo pasó de 1 a 2 horas a la semana en las mismas cosas.
¡Así que elige estar menos ocupado! Evita o elimina el trabajo secundario.
- La mayoría de las veces, los dos términos «proceso» y «progreso» pueden utilizarse indistintamente, pero en unos pocos casos (especialmente en relación con las finanzas) puede haber diferencias importantes. ?
- Si quiere aprender más sobre Lean, le recomiendo encarecidamente el libro This is Lean (Esto es Lean) de Niklas Modig & Pär Åhlström. En lugar de tratar de mapear las prácticas Lean de otras industrias en el desarrollo de software, se centra en los principios básicos que son ampliamente aplicables. ?
Categorías: prácticasTags: lean, devops