¿Cuánto tiene realmente que ver Lean Software Development con el concepto original de lean manufacturing?

Históricamente, la mayor parte del enfoque de Lean Software Development se ha centrado en los principios de producción. Sin embargo, ahora hay una nueva escuela de pensamiento que sugiere que esos principios son algo limitados en lo que respecta al desarrollo de software.

La mayor parte del desarrollo de software consiste en producir algo nuevo; algo que nunca se ha producido antes. Debido a esto, la mayoría de los proyectos de software tienen variación y variabilidad naturales. Tratar de aplicar los principios de Lean Production para crear una entrega predecible y confiable en realidad puede sofocar esa variación y variabilidad, reduciendo la innovación.

La nueva escuela de pensamiento trata el software no como una línea de producción Lean , sino como un desarrollo de productos Lean , en el sentido de que es más como diseñar autos nuevos que construir el mismo auto una y otra vez.

El método Kanban de David Anderson, que menciona @Pawel, deriva más de la nueva escuela de pensamiento que de la antigua. Él da las siguientes pautas :

• El valor triunfa sobre el flujo
• El flujo triunfa sobre la eliminación de residuos
• Luego elimina los residuos.

Por ejemplo, si puede poner en producción algo que es extremadamente valioso para el negocio, hágalo antes que cualquier otra cosa, incluso si eso significa que otras piezas de trabajo se quedan por más tiempo. Después de eso, haga lo necesario para mantener el flujo de trabajo a través del sistema. Esto puede significar tener colas o búferes como "listo para desarrollo" o "listo para prueba", aunque se considerarían inventario y, por lo tanto, desperdicio. Después de eso, eliminar los residuos.

Si está buscando trabajo en el espacio de desarrollo de productos Lean cuyos principios se puedan trasladar al desarrollo de software Lean, le recomiendo Managing the Design Factory de Don Reinertsen y Freedom from Command and Control de John Seddon . Otros trabajos relacionados con el pensamiento Lean, como Fifth Discipline de Peter Senge , también pueden ser útiles.

Para el desarrollo de software Lean real, recomiendo Kanban de David Anderson y Management 3.0 de Jurgen Appelo .

Dan North también pasó algún tiempo analizando cómo aplicar la Teoría de las Restricciones a este tipo de variabilidad, y se le ocurrió la idea de que la ignorancia es la restricción, es decir, la velocidad a la que puede aprender información relevante representa la máquina restringida en tu tubería. Él llama al acto de apuntar a esa ignorancia Descubrimiento Deliberado , y en mi experiencia es una filosofía muy efectiva. También es la columna vertebral de BDD y Feature Injection.

Para responder tu pregunta:

El Sistema de producción de Toyota se desarrolló aplicando los principios del Pensamiento Lean al contexto de Toyota y, en ese sentido, Kanban es muy similar: aplica los principios del Pensamiento Lean al contexto de un equipo en particular. No aplica la fuerza bruta de TPS a ese equipo, ni tampoco la mayoría de los conjuntos exitosos de desarrollo de software Lean. (Como nota, escuché que la mayoría de las líneas de producción que han intentado replicar TPS han tenido un éxito limitado).

Solo hay un lugar donde realmente podemos lograr la Producción Lean de Software de la misma manera que una línea de producción, y es en la integración y el despliegue continuos, donde realmente estamos construyendo lo mismo una y otra vez. El desarrollo de software generalmente no funciona de esa manera.

Los principios generales del desarrollo de software Lean (LSD) están alineados con los valores sobre los que se basa el sistema de producción de Toyota (TPS). En ambos casos se busca:

• limitar los residuos
• hacer que el flujo sea lo más suave posible
• hacer que todos sean responsables de la calidad y la mejora de la calidad

La principal diferencia es una cuestión de trabajo en ambas industrias: en la fabricación nos ocupamos de cosas tangibles, como piezas, mientras que en la industria del software nos ocupamos de bytes intangibles.

Sin embargo, si piensa en cómo se definió el desecho en TPS, por ejemplo, inventario, probablemente fue tan poco intuitivo para algunos como lo es con la definición de desecho en software, por ejemplo, código que no se usa en este momento.

Las reglas específicas de LSD y TPS se aplican, por supuesto, a la industria específica. En la fabricación, normalmente construimos muchas cosas iguales, por ejemplo, cientos de miles de automóviles, mientras que en el desarrollo de software, cada característica es diferente. El proceso en sí, naturalmente, también es diferente. Sin embargo, también significa que es imposible comparar la productividad o la eficacia entre una industria y otra, por lo que no creo que haya realmente una respuesta para una de sus preguntas.

Su última pregunta también es vaga, ya que ¿qué significa exactamente "lograr una producción de software verdaderamente ajustada"? Lean tiene que ver con el viaje, no con el destino. Si lo mira desde esa perspectiva, la respuesta es definitivamente positiva, ya que podemos aplicar los principios generales de Lean en el desarrollo de software. Por cierto, podemos hacerlo no solo con LSD sino también con Kanban, por poner el ejemplo más obvio.

Obviamente, incluso los principios fundamentales de los dos escenarios no son los mismos. Sin embargo, alguien sintió que los paralelos eran útiles. Y tal vez lo eran.

Discutiría totalmente con los comentarios anteriores. La gestión ajustada significa gestionar con recursos escasos, y así es como debe tratarse.

Por lo tanto, el desarrollo de software Lean debe centrarse en:

1. Logrando más en un tiempo limitado, utilizando herramientas y métodos. Equipos, ágiles, etc.

2. Pasar más tiempo haciendo código nuevo, aplicando algunos principios de TDD que disminuyen los errores.

3. Gastar cada recurso de la manera más efectiva. Es decir, el desarrollador principal dedica más tiempo a hacer módulos básicos que enseñar a los jóvenes o hacer las pruebas. También significa que si los desarrolladores bien pagados hacen mucho trabajo de rutina que pueden hacer los desarrolladores de nivel inferior, delegar.

3.1. Además, si tiene muchos problemas de administración que su desarrollador más caro tiene, está equivocado. Gasta cada $ con el mayor resultado posible.