Desarrollo de software lean

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Lean software development" – news · newspapers · books · scholar · JSTOR (July 2014) (Learn how and when to remove this message)

El desarrollo de software lean es una traducción de los principios y prácticas de manufactura esbelta al ámbito del desarrollo de software . Adaptado del Sistema de Producción Toyota ^[1] , está surgiendo con el apoyo de una subcultura pro-lean dentro de la comunidad ágil . Lean ofrece un marco conceptual sólido , valores y principios, así como buenas prácticas, derivadas de la experiencia, que respaldan a las organizaciones ágiles.

La expresión "desarrollo de software lean" se originó en un libro con el mismo nombre, escrito por Mary Poppendieck y Tom Poppendieck en 2003. ^[2] El libro reafirma los principios lean tradicionales , así como un conjunto de 22 herramientas y las compara con las prácticas ágiles correspondientes. La participación de los Poppendieck en la comunidad de desarrollo de software ágil , incluidas las charlas en varias conferencias ágiles ^[3], ha dado como resultado que dichos conceptos sean más ampliamente aceptados dentro de la comunidad ágil.

El desarrollo Lean se puede resumir en siete principios, muy similares en concepto a los principios de la fabricación Lean: ^[4]

1. Eliminar desperdicios
2. Amplificar el aprendizaje
3. Decidir lo más tarde posible
4. Entregar lo más rápido posible
5. Empoderar al equipo
6. Desarrollar la integridad en
7. Optimizar el conjunto

La filosofía Lean considera como desperdicio ( muda ) todo aquello que no aporte valor al cliente . Entre estos desperdicios se encuentran: ^[5]

1. Trabajo parcialmente realizado
2. Características adicionales
3. Reaprendizaje
4. Cambio de tareas
5. Espera
6. Transferencias
7. Defectos
8. Actividades de gestión

Para eliminar el desperdicio, uno debe ser capaz de reconocerlo. Si alguna actividad se puede obviar o el resultado se puede lograr sin ella, es un desperdicio. La codificación parcialmente hecha que finalmente se abandona durante el proceso de desarrollo es un desperdicio. Las características adicionales, como el papeleo y las características que los clientes no suelen usar, son un desperdicio. Cambiar a las personas de una tarea a otra es un desperdicio (debido al tiempo que las personas involucradas en cambiar de contexto emplean, y a menudo pierden). Esperar a otras actividades, equipos o procesos es un desperdicio. Volver a aprender los requisitos para completar el trabajo es un desperdicio. Los defectos y la menor calidad son un desperdicio. Los gastos generales de gestión que no producen un valor real son un desperdicio.

Para identificar los desperdicios se utiliza una técnica de mapeo de la cadena de valor . El segundo paso consiste en señalar las fuentes de desperdicios y eliminarlas. La eliminación de los desperdicios debe realizarse de forma iterativa hasta que se eliminen incluso los procesos y procedimientos aparentemente esenciales.

El desarrollo de software es un proceso de aprendizaje continuo basado en iteraciones al escribir código. El diseño de software es un proceso de resolución de problemas que involucra a los desarrolladores que escriben el código y lo que han aprendido. El valor del software se mide en función de su aptitud para el uso y no de su conformidad con los requisitos.

En lugar de añadir más documentación o una planificación detallada, se podrían probar diferentes ideas escribiendo el código y desarrollándolo. El proceso de recopilación de requisitos de los usuarios se podría simplificar presentando pantallas a los usuarios finales y obteniendo sus comentarios. Se debería evitar la acumulación de defectos ejecutando pruebas tan pronto como se escribe el código.

El proceso de aprendizaje se acelera mediante el uso de ciclos de iteración cortos, cada uno de ellos acompañado de refactorización y pruebas de integración . Aumentar la retroalimentación mediante sesiones breves de retroalimentación con los clientes ayuda a determinar la fase actual del desarrollo y a ajustar los esfuerzos para futuras mejoras. Durante esas sesiones breves, tanto los representantes del cliente como el equipo de desarrollo aprenden más sobre el problema del dominio y descubren posibles soluciones para un mayor desarrollo. De este modo, los clientes comprenden mejor sus necesidades, basándose en el resultado existente de los esfuerzos de desarrollo, y los desarrolladores aprenden cómo satisfacer mejor esas necesidades. Otra idea en el proceso de comunicación y aprendizaje con un cliente es el desarrollo basado en conjuntos, que se concentra en comunicar las limitaciones de la solución futura y no las posibles soluciones, promoviendo así el nacimiento de la solución a través del diálogo con el cliente. ^{[ jerga ]}

Como el desarrollo de software siempre está asociado con cierta incertidumbre, se deben lograr mejores resultados con un enfoque basado en conjuntos o en opciones , retrasando las decisiones tanto como sea posible hasta que puedan tomarse en base a hechos y no a suposiciones y predicciones inciertas. Cuanto más complejo sea un sistema, más capacidad de cambio debe tener, permitiendo así retrasar compromisos importantes y cruciales. El enfoque iterativo promueve este principio: la capacidad de adaptarse a los cambios y corregir errores, que podrían ser muy costosos si se descubren después del lanzamiento del sistema.

Con el desarrollo basado en conjuntos: si se necesita un nuevo sistema de frenos para un automóvil, por ejemplo, tres equipos pueden diseñar soluciones para el mismo problema. Cada equipo aprende sobre el espacio del problema y diseña una posible solución. Si una solución se considera poco razonable, se descarta. Al final de un período, se comparan los diseños supervivientes y se elige uno, tal vez con algunas modificaciones basadas en el aprendizaje de los demás: un gran ejemplo de postergar el compromiso hasta el último momento posible. Las decisiones de software también podrían beneficiarse de esta práctica para minimizar el riesgo que conlleva un gran diseño inicial. Además, habría entonces múltiples implementaciones que funcionan correctamente, pero son diferentes (en cuanto a la implementación, internamente). Estas podrían usarse para implementar sistemas tolerantes a fallas que verifiquen todas las entradas y salidas para comprobar su corrección, en las múltiples implementaciones, simultáneamente.

Un enfoque de desarrollo de software ágil puede adelantar la creación de opciones para los clientes, retrasando así ciertas decisiones cruciales hasta que los clientes hayan comprendido mejor sus necesidades. Esto también permite una adaptación posterior a los cambios y la prevención de costosas decisiones tempranas limitadas por la tecnología. Esto no significa que no se deba realizar una planificación; por el contrario, las actividades de planificación deben concentrarse en las diferentes opciones y en la adaptación a la situación actual, así como en aclarar situaciones confusas estableciendo patrones para una acción rápida. La evaluación de diferentes opciones es efectiva tan pronto como se comprende que no son gratuitas, pero proporciona la flexibilidad necesaria para la toma de decisiones tardía.

En la era de la rápida evolución tecnológica, no sobrevive el más grande, sino el más rápido. Cuanto antes se entregue el producto final sin defectos importantes, antes se podrá recibir la retroalimentación y se podrá incorporar a la siguiente iteración . Cuanto más cortas sean las iteraciones, mejor será el aprendizaje y la comunicación dentro del equipo. Con velocidad, las decisiones se pueden retrasar. La velocidad asegura la satisfacción de las necesidades actuales del cliente y no de lo que requería ayer. Esto les da la oportunidad de retrasar la toma de decisiones sobre lo que realmente necesitan hasta que adquieran un mejor conocimiento. Los clientes valoran la entrega rápida de un producto de calidad .

La ideología de producción justo a tiempo se podría aplicar al desarrollo de software , reconociendo sus requisitos y entorno específicos. Esto se logra presentando el resultado necesario y dejando que el equipo se organice y divida las tareas para lograr el resultado necesario para una iteración específica . Al principio, el cliente proporciona la información necesaria. Esto podría presentarse simplemente en pequeñas tarjetas o historias : los desarrolladores estiman el tiempo necesario para la implementación de cada tarjeta. De este modo, la organización del trabajo cambia a un sistema de autoejecución : cada mañana, durante una reunión de pie , cada miembro del equipo revisa lo que se ha hecho ayer, lo que se debe hacer hoy y mañana, y solicita cualquier información necesaria a los colegas o al cliente. Esto requiere transparencia del proceso, lo que también es beneficioso para la comunicación del equipo.

El mito que subyace a este principio es que la prisa es sinónimo de desperdicio . Sin embargo, la implementación lean ha demostrado que es una buena práctica entregar rápidamente para poder ver y analizar el resultado lo antes posible.

En la mayoría de las empresas, ha existido una creencia tradicional sobre la toma de decisiones en la organización: los gerentes les dicen a los trabajadores cómo hacer su propio trabajo. En una técnica de trabajo en equipo , los roles se intercambian: a los gerentes se les enseña a escuchar a los desarrolladores , para que puedan explicar mejor qué acciones se pueden tomar, así como brindar sugerencias para mejoras. El enfoque lean sigue el principio ágil ^[6] "construir proyectos en torno a individuos motivados [...] y confiar en ellos para hacer el trabajo", ^[7] alentando el progreso, detectando errores y eliminando impedimentos, pero sin microgestionar .

Otra creencia errónea ha sido la de considerar a las personas como recursos . Las personas pueden ser recursos desde el punto de vista de una hoja de datos estadísticos, pero en el desarrollo de software , así como en cualquier negocio organizacional, las personas necesitan algo más que una lista de tareas y la seguridad de que no serán molestadas durante la realización de las tareas. Las personas necesitan motivación y un propósito superior por el que trabajar: un propósito dentro de la realidad alcanzable, con la seguridad de que el equipo puede elegir sus propios compromisos. Los desarrolladores deben tener acceso al cliente; el líder del equipo debe brindar apoyo y ayuda en situaciones difíciles, así como asegurarse de que el escepticismo no arruine el espíritu del equipo. Respetar a las personas y reconocer su trabajo es una forma de empoderar al equipo.

El cliente necesita tener una experiencia global del sistema, es decir, la denominada integridad percibida: cómo se publicita, se entrega, se implementa, se accede al mismo, cuán intuitivo es su uso, cuál es su precio y cuán bien resuelve los problemas.

La integridad conceptual significa que los componentes separados del sistema funcionan bien juntos como un todo con un equilibrio entre flexibilidad, mantenibilidad, eficiencia y capacidad de respuesta. Esto se puede lograr entendiendo el dominio del problema y resolviéndolo al mismo tiempo, no de manera secuencial. La información necesaria se recibe en pequeñas porciones, no en un gran fragmento, preferiblemente mediante comunicación cara a cara y no mediante documentación escrita. El flujo de información debe ser constante en ambas direcciones, del cliente a los desarrolladores y viceversa, evitando así la gran cantidad de información estresante que se genera después de un largo desarrollo en forma aislada.

Una de las formas saludables de lograr una arquitectura integral es la refactorización . A medida que se añaden más características a la base de código original, más difícil resulta añadir más mejoras. La refactorización trata de mantener la simplicidad, la claridad y el número mínimo de características en el código. Las repeticiones en el código son signos de malos diseños de código y deben evitarse (es decir, aplicando la regla DRY ). El proceso de construcción completo y automatizado debe ir acompañado de un conjunto completo y automatizado de pruebas para desarrolladores y clientes, que tengan el mismo control de versiones, sincronización y semántica que el estado actual del sistema. Al final, la integridad debe verificarse con pruebas exhaustivas, asegurando así que el sistema hace lo que el cliente espera. Las pruebas automatizadas también se consideran parte del proceso de producción y, por lo tanto, si no agregan valor, deben considerarse un desperdicio. Las pruebas automatizadas no deben ser un objetivo, sino un medio para un fin, específicamente la reducción de defectos.

Los sistemas de software modernos no son simplemente la suma de sus partes, sino también el producto de sus interacciones. Los defectos en el software tienden a acumularse durante el proceso de desarrollo: al descomponer las tareas grandes en tareas más pequeñas y estandarizar las diferentes etapas de desarrollo, se deben encontrar y eliminar las causas fundamentales de los defectos. Cuanto más grande sea el sistema, más organizaciones participen en su desarrollo y más partes desarrollen diferentes equipos, mayor será la importancia de tener relaciones bien definidas entre los diferentes proveedores, para producir un sistema con componentes que interactúen sin problemas. Durante un período de desarrollo más largo, una red de subcontratistas más fuerte es mucho más beneficiosa que la optimización de los beneficios a corto plazo, que no permite relaciones beneficiosas para todos .

El concepto Lean debe ser bien comprendido por todos los miembros de un proyecto antes de implementarlo en una situación concreta de la vida real. “Piensa en grande, actúa en pequeño, falla rápido; aprende rápidamente” ^[8] : estos lemas resumen la importancia de comprender el campo y la idoneidad de implementar los principios Lean a lo largo de todo el proceso de desarrollo de software. Solo cuando se implementan todos los principios Lean en conjunto, combinados con un fuerte “sentido común” con respecto al entorno de trabajo, existe una base para el éxito en el desarrollo de software .

Las prácticas de desarrollo de software lean, o lo que los Poppendieck llaman "herramientas", son una versión ligeramente reformulada de los equivalentes originales en el desarrollo de software ágil . Algunos ejemplos de dichas prácticas incluyen:

• Viendo el desperdicio
• Mapeo del flujo de valor
• Desarrollo basado en conjuntos
• Sistemas de tracción
• Teoría de colas
• Motivación
• Medidas
• Desarrollo basado en pruebas

Dado que el desarrollo de software ágil es un término general para un conjunto de métodos y prácticas basados ​​en los valores y principios expresados ​​en el Manifiesto Ágil, el desarrollo de software lean se considera un método de desarrollo de software ágil. ^[9]

• Programación extrema
• DevOps
• Kanban
• Tablero Kanban
• Integración lean
• Servicios Lean
• Scrum (desarrollo)

• Ladas, Corey (enero de 2008). Scrumban: ensayos sobre sistemas Kanban para el desarrollo de software lean. Modus Cooperandi Press. ISBN 978-0-578-00214-9.
• Ries, Eric (septiembre de 2011). El método Lean Startup : cómo los emprendedores de hoy utilizan la innovación continua para crear empresas radicalmente exitosas . Crown Business. ISBN 978-0307887894.