Una guía del programador para descifrar el código 'Dos veces el trabajo, la mitad del tiempo'

La gestión teórica está llena de abuelos. He leído obras de Deming, Goldratt, Ohno y Drucker. He oído hablar de Ackoff y Juran. Disfruté la actitud humana y cuidadosa en cada libro que he leído. Nunca lo fue: "Explotar a las personas hasta el agotamiento". Peter Drucker, en su "Management Rev Ed", incluso nos guió a nosotros, los gerentes del siglo XXI, en lo que debemos hacer:

La contribución más importante, y verdaderamente única, de la administración en el siglo XX fue el aumento de cincuenta veces en la productividad del trabajador manual en la manufactura. La contribución más importante que debe hacer la gestión en el siglo XXI es, de manera similar, aumentar la productividad del trabajo del conocimiento y del trabajador del conocimiento.

Veinte años después del siglo XXI, ¿qué tan cerca estamos de cumplir este ambicioso objetivo en el mundo del desarrollo de software? Veo que estamos lejos de eso. Exploremos dónde estamos, qué problemas tenemos y qué podemos hacer al respecto.

Explorando el enfoque generalizado de la eficiencia del desarrollo de software

"El arte de hacer el doble de trabajo en la mitad del tiempo" es el subtítulo del libro " Scrum " de Jeff Sutherland, coautor de este marco. Me gusta este subtítulo, ya que refleja claramente cuánto más eficientes podemos llegar a ser en nuestros esfuerzos de programación. Sin embargo, no todo está despejado. El primer problema que encontramos aquí es que es difícil entender qué es la eficiencia en nuestro trabajo. El siguiente problema complejo es entender si nos volvemos más eficientes con el tiempo.

Pero, ¿por qué queremos eficiencia al final? Bueno, se trata de hacer lo mismo con menos esfuerzo, y en muchas esferas de nuestra vida es genial tener los mismos o mejores resultados más rápido oa un precio más bajo.

Volvamos a nuestra pregunta. Los practicantes de Scrum proponen puntos de historia como una medida de una tarea. Hay una definición del sitio web scrum.org :

Un Story Point es una unidad de medida relativa, decidida y utilizada por equipos Scrum individuales, para proporcionar estimaciones relativas de esfuerzo para completar los requisitos.

Un punto de historia es una magnitud de complejidad relacionada con la tarea de referencia. Usted y yo tenemos una idea de cuánto esfuerzo nos tomó implementar esa tarea no muy difícil. Si te digo que el nuevo trabajo costará tres puntos de historia, te digo que será tres veces más difícil que el anterior. Es mi suposición, y quién sabe lo difícil que sería.

Centrémonos de nuevo en la eficiencia. Si entregamos tareas estimadas en 25 puntos de historia en este sprint, ¿estamos mejor que en el sprint anterior cuando solo teníamos 15? ¿O tal vez fuimos más cuidadosos y dimos estimaciones más altas para el mismo esfuerzo? Pero, ¿cómo podemos siquiera comparar? No hacemos trabajo repetitivo en ingeniería de software a escala de fábrica. Diseñamos e implementamos fábricas de información que brindan servicios. ¿Hay lugar para las charlas de eficiencia en nuestra industria?

Hay un lugar para estas charlas. Al menos, podemos ralentizar las cosas intencionalmente. Por ejemplo, podemos procrastinar o saltar de una tarea a otra. Si podemos hacer algo menos eficiente, hay esperanza de lo contrario. Sin embargo, no veo los puntos de la historia como un instrumento de medición útil aquí. Pueden ser abusados sin esfuerzo, intencionalmente o no. Tenemos que buscar algo mejor.

Definición del objeto de medición

Antes de definir la forma de aumentar la velocidad de nuestro esfuerzo de programación, necesitamos determinar cuál es ese esfuerzo que queremos medir. No veo nada que podamos usar en toda la industria, pero el lado positivo es que no necesitamos tanta amplitud para mejorar la eficiencia. La necesidad es algo que describa un paso de trabajo significativo en el desarrollo de su producto de programación. Podemos usar épicas, tareas, funciones o cualquier otra cosa que represente el ajuste positivo del sistema en desarrollo.

En mi lugar actual, usamos tres niveles diferentes:

 User-valuable feature: ⎿ Its slice for the engineering team's convenience: ⎿ The specific task inside a slice (eg, back-end task).

Necesitamos que el ajuste tenga las siguientes características:

1. Tiene la hora de inicio y la hora de finalización;
2. Ocurre regularmente.

Así que lo que definimos aquí es "este gran trabajo". Llamémosle la acción en la parte consecuente del artículo. No todas las acciones son iguales. He demostrado tres tipos en el ejemplo anterior.

Necesitamos que la acción ocurra regularmente.

Este requisito proviene del hecho de que no puede ser eficiente en última instancia desde el principio, pero puede volverse más eficiente con el tiempo. No es el inconveniente del enfoque descrito. Scrum funciona de esta manera, el sistema de producción de Toyota funciona de esta manera y la ciencia funciona de esta manera. Requerimos repetibilidad para descubrir el estado actual y mejorarlo consistentemente.

Puede hacer cualquier cosa nueva con una eficiencia optimizada en última instancia solo por casualidad. Y cuanto más compleja sea la acción, menos posible será. La preparación previa puede ayudar. Sin embargo, la capacidad de preparación anticipada significa que la acción o sus subacciones ocurrieron en el pasado y hay conocimiento sobre ellas. No hay nada que preparar para algo completamente nuevo. Por otro lado, difícilmente nos encontramos con una novedad completa en nuestra vida. Una fracción de la experiencia previa siempre es relevante para las situaciones nunca experimentadas.

En suma, tenemos una acción de tipo como esencia a medir.

¿Cómo medir una acción de un tipo?

A primera vista, el apartado anterior no añade nada. Hacemos algunas acciones de un tipo. ¿Cómo es mejor que las tareas medidas con puntos de la historia, tallas de camisetas o animales? Un nombre no es una sola ganancia. La acción de un tipo tiene dos marcas de tiempo, y podemos medir su duración restando el comienzo de la finalización. La duración es una excelente ganancia aquí, ya que es nuestra clave para el lenguaje de la realidad cotidiana.

• ¿Cuánto tiempo tomó completar una epopeya?
• Nos tomó 39 días de principio a fin.

Maravilloso.

¿Hay algo más que ganamos?

El segundo requisito de nuestra acción, la ocurrencia regular, nos da tanto que cuesta creerlo. En primer lugar, obtenemos un flujo de acciones de un tipo. Aquí hay una definición de flujo del libro "Actionable Agile Metrics for Predictability " de Daniel Vacanti:

En pocas palabras, el flujo es el movimiento y la entrega de valor al cliente a través de un proceso.

Nuestro requisito de dos marcas de tiempo, el comienzo y la finalización de una acción, nos brinda un buen conjunto de nuevas métricas. Aquí están del mismo libro:

Trabajo en progreso (la cantidad de elementos en los que estamos trabajando en un momento dado), Tiempo de ciclo (cuánto tiempo lleva cada uno de esos elementos para completar nuestro proceso) y Rendimiento (cuántos de esos elementos se completan por unidad de tiempo ).

Puedo intrigarte si crees que es todo lo que tenemos aquí. Estamos al principio. Otro tesoro que nos regala el fluir es la huella que va dejando con el paso del tiempo. Este rastro nos permite entender mejor el sistema. Podemos capturarlo usando varios diagramas. Uno de ellos es el diagrama de dispersión del tiempo de ciclo.

Su deleite proviene del hecho de que captura "cómo hacemos las cosas aquí". No requiere nada de su proceso, ninguna metodología particular. ¿Desea capturar el flujo de cepillado de dientes utilizando el diagrama de dispersión de tiempo de ciclo? Hazlo. ¿Quieres lo mismo para las casas construidas en tu zona? Absolutamente bien. ¿Desea realizar un seguimiento del ciclo de vida del desarrollo, incluidos los experimentos A/B realizados después de desarrollar nuevas funciones? Por favor, comience y haga.

En la imagen, también puede ver las líneas de percentiles firmadas con 50 %, 70 %, 85 % y 95 % a la derecha. ¿Qué quieren decir? En el lado izquierdo, hay días. Puede leer el 85% y 16 días de la siguiente manera:

Para el 85 % de los artículos que ingresaron a nuestro sistema en el período que se revisa, tardaron 16 días o menos en salir.

Es la segunda vez que uso la palabra "sistema" en esta sección. ¿Qué significa? Vamos a definirlo de la siguiente manera para esta historia:

El sistema es algo que hace acciones de un tipo.

Una acción de este tipo en el ejemplo anterior del sistema de construcción de casas es construir una casa. Hacer un kilómetro de carretera no cuenta como una acción aquí. Es otro tipo de acción y otro sistema. Sin embargo, no hay una división concreta, pero queremos que nuestras casas sean parecidas, así como el cepillado de dientes y el desarrollo de software con pruebas A/B. Para algo lo suficientemente diferente, podemos idear otro sistema.

Una ganancia más importante

Es hora de discutir un efecto más que nos ayudaría a garantizar la precisión de nuestros esfuerzos de mejora. Imagina que tienes un equipo y necesitas crear un nuevo software. Tomas las historias de usuario como una medida de progreso, como una acción. Después de completar su primera historia, es hora de hacer la retrospectiva para ver dónde podríamos estar mejor la próxima vez.

¿Hay algo en esta lógica que nos lleve a una trampa? Echemos un vistazo más de cerca.

Durante la implementación de la primera historia de usuario, el principal obstáculo fue acordar las bibliotecas necesarias e instalar el software requerido. Tomó algún tiempo, y fue un verdadero dolor. Durante la retrospectiva, el equipo discutió lo doloroso que fue y cómo podemos ser mejores la próxima vez. La falta bastante obvia es que la próxima vez, difícilmente, necesitará ponerse de acuerdo sobre las bibliotecas e instalar el software. Las bibliotecas suelen permanecer durante mucho tiempo. La instalación del software sería parte de la incorporación de nuevos miembros, pero no molestará al equipo ya establecido en su segunda historia de usuario. Es lo suficientemente diferente y ahora puede convertirse en parte del sistema de incorporación.

Echemos un vistazo a la siguiente sabiduría de programación de Donald Knuth ( o Tony Hoare ):

La optimización prematura es la fuente de todos los males.

Supongo que conoces este, que te dice que no pienses en el rendimiento en las primeras etapas del desarrollo de software. Es posible que haya visto esta sabiduría en la siguiente forma:

Haz que funcione, hazlo bien, hazlo rápido.

El ejemplo sobre la instalación de bibliotecas muestra que el adagio es relevante para el código y también para el equipo de codificación. ¡Qué misterio nos encontramos aquí! No es un misterio sino el atributo de un sistema. Hay al menos dos razones por las que debemos evitar saltar directamente a las mejoras después del primer intento.

Razón estadística para no saltar de inmediato a la mejora

Toda acción completa de un tipo tiene su duración. La duración consta de dos partes: una motivada por causas comunes y otra motivada por causas especiales.

Vamos a referirnos al ejemplo del cepillado de dientes una vez más. Por lo general, cubrir el cepillo de dientes con pasta de dientes lleva unos segundos. En casos especiales, debe sacar la pasta de dientes del armario, abrirla y usarla. Aquí toda la acción dura varios minutos. Si, por alguna razón, necesitamos pensar en la eficiencia de la subacción del recubrimiento del cepillo de dientes en el cepillado de dientes, hacerlo después de la inicial sería engañoso. La acción inicial contiene una parte extra y se diferencia de la típica acción que queremos acelerar.

La naturaleza de ser especial conduce a la apariencia inconsistente de las razones de duración especial. Lo que se muestra siempre es el núcleo de nuestra acción, el objetivo fructífero de nuestras mejoras.

Teoría de las Restricciones Razón para no saltar de inmediato a la mejora

¿Qué nos dice la teoría de las restricciones? Nos dice que el todo que produce algo será tan productivo como su parte menos productiva. Imagina que tenemos una empresa que construye casas diminutas de un piso. Nuestras capacidades anuales son las siguientes:

• 6 sótanos,
• 24 conjuntos de paredes,
• 52 techos.

¿Cuántas casas podemos construir al año? Puede responder seis, pero sugiero decir no más de seis. Nuestro proceso de construcción es consecuente: sótano → paredes → techo. Terminar la última casa, la sexta, puede atrasarse al final del año.

Si aumentamos la cantidad de paredes que levantamos o los techos que construimos, ¿cambiará esto la capacidad de toda nuestra empresa? ¿Produciremos más que el mencionado "no más de seis"? No, el sótano todavía nos limita.

Los números de capacidad de arriba provienen de la experiencia de esta empresa superficial. No tenemos esta experiencia después de implementar la primera historia de usuario. Todavía tenemos que determinar la restricción de nuestro sistema de creación de historias de usuario, ya que no sabemos cuánto dura cada subacción. Considere que tenemos garantía de calidad como parte de nuestro proceso de desarrollo de historias de usuario. La prueba de una historia de usuario dura cuatro horas. El desarrollo de una historia de usuario dura cinco días hábiles en general. Digamos que hay 250 días hábiles en un año. ¿Espera tener 50 historias de usuario completas al final o 730? Al igual que con las casas y sótanos, como máximo 50 por año. Necesitamos recopilar estadísticas para comprender la forma de nuestra acción y su parte menos productiva.

¿Cuántas acciones completas son suficientes para comenzar las mejoras?

Para estar completamente seguro, sugiero tener el número ∞ de acciones completas en este punto. Después de tener este número exacto, puedes estar 100 % seguro de qué mejorar primero.🥁

Para aquellos que están fuera del mundo de las matemáticas puras, consideremos los siguientes pensamientos. Aquí hay una referencia del libro "Métricas ágiles accionables para la previsibilidad " que hace referencia al libro " Cómo medir cualquier cosa ":

Por ejemplo, Douglas Hubbard (cuyo libro "Cómo medir cualquier cosa" figura en la Bibliografía) aconseja a sus clientes sobre su " Regla de los cinco ": Regla de los cinco: hay un 93,75 % de posibilidades de que la mediana de una población se encuentre entre el valores más pequeños y más grandes en cualquier muestra aleatoria de cinco de esa población.

No vea esto como un tabú para cambiar algo en las primeras cinco acciones. Considere también otros aspectos: seguridad de la salud, cohesión del equipo y más.

¿Dónde comenzar la mejora?

Si tomamos la acción elemental, por ejemplo, encender el televisor presionando un botón, podemos pensar en ello como un todo. Para reducir la cantidad de movimientos y el tiempo total, cómprese un clicker y manténgalo en un lugar cerca de su sofá. En este ejemplo, la primera acción podría tardar unos 20 segundos y la segunda... un segundo. ¡Mis felicitaciones! Ha reducido el 95% del tiempo requerido anteriormente y aún recibe el mismo valor. ¡Qué fantástica eliminación de residuos!

No todas las acciones son tan sencillas. El desarrollo de historias de usuario ya mencionado es complejo. Es un desafío manejar la mejora allí de un solo salto. Necesitamos dividir las cosas en subacciones, como en el ejemplo de construcción de casas. Podemos empezar con el siguiente ciclo de vida:

1. Análisis,
2. Desarrollo,
3. Pruebas,
4. Hecho.

¿Donde empezar?

En Lean manufacturing, el proceso de creación, o acción, como se denomina en este artículo, consta de subacciones de tres tipos:

• actividades de valor agregado;
• Actividades necesarias sin valor agregado;
• Desperdiciar.

Formular la historia del usuario, diseñar una solución y codificarla son actividades de valor agregado. El uso de la bifurcación de git durante el desarrollo podría considerarse una actividad necesaria sin valor agregado. No añade nada a este cambio pero organiza todo el proceso. El desperdicio impide la acumulación de valor por un tiempo sin una buena razón. Esperar a que la base de datos no funcione es un desperdicio.

En Lean manufacturing, los desperdicios (o muda ) son conocidos y definidos por el creador del Sistema de Producción de Toyota, Taiichi Ohno. Al menos están definidos para la empresa Toyota, el fabricante de automóviles. Otras industrias tienen sus variantes. Aquí está el nuestro, creado por Mary y Tom Poppendiecks en el libro " Lean Software Development ":

1. Trabajo parcialmente hecho,
2. Procesos adicionales,
3. Características adicionales,
4. Cambiar de tarea,
5. Esperando,
6. Movimiento,
7. defectos

¿O estos? Del libro " Implementing Lean Software Development " de los mismos autores:

1. Trabajo parcialmente hecho,
2. Características adicionales,
3. reaprender,
4. Entregas innecesarias,
5. Cambiar de tarea,
6. retrasos,
7. defectos

¡Al menos los ingenieros de software pueden moverse ahora!😅

¿Cómo es posible que estos pilares hayan cambiado tanto en tan solo varios años en nuestra industria? Veo la respuesta en la imposibilidad de tener una lista suficiente de desechos para todos los tiempos por venir. Incluso a Toyota, en algún momento, se le ocurrió el octavo desperdicio.

Es genial que la lista de nuestra industria haya cambiado tan radicalmente. Este cambio nos abre la mente a reconsiderar nuestros pensamientos sobre lo que es desperdiciar continuamente. Aquí hay una visión más de lo que puede ser una parte inútil del desarrollo de software:

Uno de los mayores malentendidos en el mundo del software es el valor del código. Pero el código es una responsabilidad, como diremos repetidamente en este libro. Cuanto más código escribimos, más complejidad y riesgo generamos para nosotros mismos.

Es una cita de " The Value Flywheel Effect " de David Anderson con Mark McCann y Michael O'Reilly. ¡Uf, qué paseo!

Entonces, ¿cómo empezamos? Mirando la subacción menos productiva. ¿Qué buscamos? Subacciones que no agregan valor.

Reconsideración del flujo de trabajo de desarrollo de historias de usuario

Déjame recordarte el flujo de trabajo que teníamos:

1. Análisis,
2. Desarrollo,
3. Pruebas,
4. Hecho.

Por lo general, estas son las partes realizadas por diferentes personas, y siempre hay algo de tiempo para esperar el traspaso. Documentémoslo:

1. Análisis activo,
2. análisis hecho,
3. desarrollo activo,
4. Desarrollo hecho,
5. Pruebas,
6. Hecho.

Yo no ideé estos pasos. Los tomé de la demostración del producto ActionableAgile Analytics . ¿Podemos confiar en ellos? Diré que sí, ya que he visto diferentes ejemplos de datos reales, y este se parece mucho. Investiguemos las estadísticas de las siguientes etapas. Demuestra los promedios.

El tiempo de ciclo del sistema es de 9,37 días. Esta afirmación significa que una tarea llega a la etapa Análisis activo , se mueve a través de todas las siguientes y deja Prueba por Terminado y, en promedio, esta ruta demora 9,37 días. Las etapas con "Activo" en su nombre parecen aportar utilidad al resultado, así como Pruebas . Las etapas que terminan en "Terminado" son colas, esperas y nada útil. Si los marcamos de acuerdo con el diagrama de Eficiencia de flujo, veremos que, en promedio, solo el 40% del tiempo dedicado a una sola historia de usuario es valioso.

En este diagrama, también incluimos el tiempo bloqueado rastreado y las tareas extrañas, que pasaron todo su tiempo en las etapas "Listo". Si los excluimos, la eficiencia de flujo para este ejemplo de demostración sería de alrededor del 50 %.

Abordar la pérdida de tiempo descubierta

Como tenemos muy poca información sobre el conjunto de datos de demostración, no habrá recomendaciones específicas como: "Dale mejores computadoras al Equipo E". Sin embargo, habría suficientes pensamientos para inspirar el suyo propio en su caso. La parte menos productiva de nuestro proceso es la etapa de Análisis Realizado . Ni siquiera podemos llamarlo así, ya que describe la espera. Sin embargo, toma casi el 29% de cada tarea. ¿Cuál podría ser la razón aquí?

La fase de desarrollo activo no parece lenta y requiere menos tiempo para completarse que la parte de análisis activo. Mirando el WIP promedio, destacaremos el problema: el departamento de análisis puede manejar más historias de usuarios simultáneamente.

Equilibrar esto, por ejemplo, incorporando más desarrolladores al equipo, podría ser una posible solución. Sin embargo, no se apresure aquí. La razón puede ser muy diferente. La etapa Análisis realizado puede contener el trabajo encubierto. Puede ser que los desarrolladores no estén satisfechos con la calidad de los requisitos, pero no puedan resolver este problema de manera sistemática y dediquen tiempo durante esta etapa a mejorarlos. Para descubrir las condiciones de contorno, proponer el manejo de la interfaz de usuario de las solicitudes asincrónicas y más.

Antes de proponer la solución aplica el análisis de causa raíz: usa cinco porqués , espina de pescado u otra cosa.

Verificación del éxito del cambio aplicado

Digamos que abordamos el problema de la sección anterior. ¿Cómo podemos estar seguros de que el cambio propuesto funcionó? Necesitamos acumular datos una vez más. ¿Recuerdas la Regla de los Cinco de arriba? Podemos usarlo aquí también. Nuestro sistema ya está ajustado. Medimos de nuevo.

En mi trabajo utilizo dos herramientas para medir los resultados del experimento:

1. diagrama de flujo acumulativo,
2. La línea de tendencia en el diagrama de dispersión de tiempo de ciclo.

¿Ve el área cian del análisis realizado ? Espere que al menos se vuelva más delgado a medida que pasa el tiempo y que desaparezca como máximo.

Mire la línea discontinua verde que aparece en este diagrama ya familiar. Muestra la tendencia del tiempo de ciclo del 85 % durante los últimos N días. Uso 30 en lugar de N, ya que es lo suficientemente estable para demostrar los cambios. Si la solución descubierta maneja la causa raíz lo suficientemente profunda, espere que esta línea se deslice ≈30% hasta 11 días.

Si no hay cambios significativos en los datos, es hora de buscar otras soluciones.

Los siguientes pasos

El siguiente punto obvio de mejora es la etapa de desarrollo terminado . Imaginemos que también lo hemos superado. Hemos reducido el 50% del tiempo requerido inicialmente para completar la historia del usuario. Sin embargo, el título de la historia promete cuadriplicar la productividad. En este caso, podemos empezar a pensar en la etapa de Análisis Activo . Luego intente paralelizar el Testing one con él y Development Active .

Sin embargo, no estoy seguro de que sea necesario aquí. Imagine usar un software que obtiene nuevas funciones cada dos días. Puede que el mercado no esté preparado para ello. El mercado se convierte en una limitación para nuestro sistema. Este descubrimiento no significa que siempre estemos tan limitados con nuestras mejoras. Por lo general, tenemos varios sistemas de desarrollo que crean valor y nuestras funciones tardan más de nueve días. En mi experiencia, la vista de pájaro sobre los artículos que duran seis meses descubrió solo el 30% del tiempo de valor agregado. La imagen más detallada de las tareas dentro del 30 % nuevamente demostró el 30 % exacto del tiempo de valor agregado. Resultó que durante los 180 días completos, solo hubo 16 días de actividad de valor agregado. Es visible un potencial de mejora de 11 veces.

El enfoque en resumen

Preguntas válidas

Siento que el enfoque descrito tiene un alto potencial para hacer la gestión de contribuciones del siglo XX que nos ha pasado. Cuando le hablo a alguien sobre el método, generalmente me enfrento a varias preguntas:

1. ¿No destruirá esto la alegría de programar?

2. El desarrollo de software es tan impredecible y tan creativo. ¡¿Cómo podemos hablar de trabajar en su eficiencia?!

   
   

La propuesta no destruirá la alegría de la programación. Es posible que haya notado que trabajamos para eliminar los agujeros en el proceso en los que no sucedía nada. Ser capaz de tomar la tarea recién creada es tan alegre como tomarla dos días después. Otra alegría proviene de ver su código como el sistema en proceso de cambio y su equipo como el mismo. Tienes una nueva tierra de herramientas de programación y enfoques abiertos.

¿Por qué necesitaría anteriormente herramientas de programación de mafiosos en línea? ¿Para ser más rápido? Pero, ¿qué era más rápido entonces? ¿Por qué necesitaría la etapa de diseño de software explícito? ¡Ajá! Nuestro equipo de desarrollo está lleno de errores, razón por la cual las historias de usuarios esperan hasta el 30 % de su ciclo de vida para que los desarrolladores corrijan los errores. ¿Por qué no los prevenimos?

Lo que mata la alegría de programar es la necesidad regular de cortarse la carne para completar las tareas. Ser empoderado con mejores métodos, herramientas y conocimientos no mata la alegría.

Sí, la creación de desarrollo de software es impredecible y no rutinaria. Sin embargo, ¿es infinitamente impredecible? ¿Sería suficiente un año para completar cualquiera de las tareas que te miran desde tu cartera de pedidos? ¿Qué tal diez años? ¿Es la naturaleza de su variación tan esquiva que no podemos hacer nada al respecto? La existencia del diagrama de dispersión de tiempo de ciclo nos muestra que existe un límite para la variación del desarrollo de software. Puede señalar que algunas tareas requieren una solución constante de texto rápida, mientras que otras requieren varios días de investigación. Estaría de acuerdo con esto, pero también le preguntaría: "¿La existencia de estas tareas es el resultado de la naturaleza inevitable del software, o es el resultado de la arquitectura de software que utiliza? ¿No es la gran bola de barro en los procesos la razón de tal lío?"

¿No es la necesidad de un flujo de desarrollo más fluido finalmente una razón infalible para abordar sus deudas técnicas, arquitectónicas y de proceso?

Sí, incluso en la arquitectura más favorable al cambio, aparecerían preguntas difíciles que requieren más tiempo del que nos gustaría que necesitaran. Y ya tenemos el lugar en el diagrama de dispersión de tiempo de ciclo por encima de la línea del percentil 95 para manejarlos. Pero son excepciones, y no queremos que todo se convierta en excepciones.

Nosotros, los gerentes, no debemos apagar el fuego, sino trabajar en el diseño de nuestros sistemas y su variación.

Evitar los pasos obvios y equivocados

No soy la primera persona que busca la eficiencia en nuestra industria. Algunos de los buscadores piensan que ya están familiarizados con el tema. Su enfoque es instalar el software de seguimiento en las computadoras de sus empleadores y castigar a aquellos que realizan algunos tratados como si no funcionaran. Este método muestra el completo desconocimiento de las fuentes de eficiencia del desarrollo de software. La idea de un gran éxito resultante de una gran tensión no solo es pobre. es mortal Limita nuestra mirada a nuestros sistemas en una sola dimensión: trabajando lo suficiente o no lo suficiente. Su experiencia personal proporciona suficientes ejemplos de personas quemadas. La historia nos muestra que los países cayeron en esta trampa con muchas bajas que los acompañaron. No, trabajar duro no es el camino hacia la mejora continua. ¿Pero, qué es esto?

Descubriendo el lugar para comenzar

Hace más de un siglo, Frederick Taylor inició su trabajo sobre lo que ahora conocemos como administración científica. Miró a sus colegas y buscó los métodos más eficientes para que hicieran su trabajo:

Taylor decidió descubrir, por métodos científicos, cuánto tiempo les tomaría a los hombres realizar cada trabajo dado; y fue en el otoño de 1882 cuando comenzó a poner en funcionamiento las primeras características de la gestión científica.

No conozco la estructura del negocio en el que trabajaba Taylor en ese entonces. Podría darse el caso de que su paso de producción estuviera entre otros, lo que también podría significar que Taylor quedó atrapado en la trampa de la suboptimización local. Se trata de aumentar la cantidad de techos que nuestra empresa imaginaria de construcción de viviendas puede manejar. La influencia del descubrimiento de Taylor no disminuye, incluso si este fuera el caso. Ahora conocemos el peligro de esta trampa y podemos actuar de manera más inteligente.

¿Recuerdas mi ejemplo con artículos que duran seis meses o 180 días? Si elimino con éxito la pérdida de tiempo en los artículos internos donde trabajan los ingenieros, ahorraré 38 días y me quedarán 142 días para un artículo grande. Si hago lo mismo con el exterior donde trabaja todo el equipo, ahorraré 126 días y tendré 54 días para el mismo artículo grande. Torturar a los desarrolladores con horas extras y camas en la oficina no tiene sentido si quieres ganar a lo grande. Mire el proceso de generación de valor desde el punto de vista del pájaro y solo profundice una vez que esté fuera del margen de mejora en este nivel.