Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles:
- Eliminate waste
- Amplify learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- Optimize the whole
Eliminate wasteEdit
Lean philosophy regards everything not adding value to the customer as waste (muda). Such waste may include:
- Partially done work
- Extra features
- Relearning
- Task switching
- Waiting
- Handoffs
- Defects
- Management activities
In order to eliminate waste, one should be able to recognize it. If some activity could be bypassed or the result could be achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Las funciones adicionales, como el papeleo y las funciones que no suelen utilizar los clientes, son un despilfarro. El cambio de personas entre tareas es un desperdicio. Esperar a que se realicen otras actividades, equipos o procesos es un despilfarro. El reaprendizaje necesario para completar el trabajo es un desperdicio. Los defectos y la baja calidad son un desperdicio. Los gastos generales de gestión que no producen valor real son un desperdicio.
Para identificar el desperdicio se utiliza una técnica de mapeo del flujo de valor. El segundo paso es señalar las fuentes de desperdicio y eliminarlas. La eliminación de los residuos debe realizarse de forma iterativa hasta que se liquiden incluso los procesos y procedimientos aparentemente esenciales.
Amplificar el aprendizajeEditar
El desarrollo de software es un proceso de aprendizaje continuo basado en iteraciones al escribir el código. El diseño de software es un proceso de resolución de problemas en el que participan los desarrolladores que escriben el código y lo que han aprendido. El valor del software se mide en la aptitud para el uso y no en la 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 código y construyendo. El proceso de recopilación de requisitos del usuario podría simplificarse presentando pantallas a los usuarios finales y obteniendo sus aportaciones. La acumulación de defectos debería evitarse ejecutando pruebas tan pronto como se escriba 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. El aumento de la retroalimentación a través de breves sesiones de retroalimentación con los clientes ayuda a determinar la fase actual de desarrollo y a ajustar los esfuerzos para futuras mejoras. Durante esas breves sesiones, tanto los representantes de los clientes como el equipo de desarrollo aprenden más sobre el problema del dominio y descubren posibles soluciones para el desarrollo posterior. De este modo, los clientes comprenden mejor sus necesidades, basándose en el resultado existente de los esfuerzos de desarrollo, y los desarrolladores aprenden a satisfacer mejor esas necesidades. Otra idea en el proceso de comunicación y aprendizaje con un cliente es el desarrollo basado en conjuntos – éste se concentra en comunicar las restricciones de la futura solución y no las posibles soluciones, promoviendo así el nacimiento de la solución a través del diálogo con el cliente.
Decidir lo más tarde posibleEditar
Como el desarrollo de software siempre está asociado a cierta incertidumbre, se deberían conseguir mejores resultados con un enfoque basado en conjuntos u opciones, retrasando las decisiones lo más posible hasta que se puedan tomar basándose en hechos y no en suposiciones y predicciones inciertas. Cuanto más complejo sea un sistema, más capacidad de cambio debe incorporarse, lo que permite retrasar compromisos importantes y cruciales. El enfoque iterativo fomenta este principio: la capacidad de adaptarse a los cambios y corregir los 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 coche, por ejemplo, tres equipos pueden diseñar soluciones para el mismo problema. Cada equipo aprende sobre el espacio del problema y diseña una solución potencial. Cuando se considera que una solución no es razonable, se corta. Al final de un periodo, se comparan los diseños supervivientes y se elige uno, quizá con algunas modificaciones basadas en el aprendizaje de los demás: un gran ejemplo de aplazamiento del compromiso hasta el último momento. Las decisiones en materia 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 múltiples implementaciones que funcionan correctamente, pero que son diferentes (en cuanto a la implementación, internamente). Éstas podrían utilizarse para implementar sistemas tolerantes a fallos que comprueben la corrección de todas las entradas y salidas, a través de las múltiples implementaciones, simultáneamente.
Un enfoque ágil de desarrollo de software puede adelantar la construcción de opciones para los clientes, retrasando así ciertas decisiones cruciales hasta que los clientes hayan comprendido mejor sus necesidades. Esto también permite la adaptación posterior a los cambios y la prevención de costosas decisiones anteriores limitadas por la tecnología. Esto no significa que no haya que planificar, sino que, 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 la aclaración de situaciones confusas mediante el establecimiento de patrones de actuación rápida. La evaluación de las diferentes opciones es efectiva en cuanto se comprende que no son gratuitas, sino que proporcionan la flexibilidad necesaria para la toma de decisiones tardías.
Entregar lo más rápido posibleEditar
En la era de la rápida evolución de la tecnología, no sobrevive el más grande, sino el más rápido. Cuanto antes se entregue el producto final sin grandes defectos, antes se podrá recibir el feedback, e incorporarlo a la siguiente iteración. Cuanto más cortas sean las iteraciones, mejor será el aprendizaje y la comunicación dentro del equipo. Con la velocidad, las decisiones pueden retrasarse. 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 la producción justo a tiempo podría aplicarse 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 se convierte en un sistema de autoaprendizaje: cada mañana, durante una reunión, cada miembro del equipo revisa lo que se ha hecho ayer, lo que se va a hacer hoy y mañana, y solicita cualquier aportación necesaria a sus colegas o al cliente. Esto requiere transparencia en el proceso, lo que también es beneficioso para la comunicación del equipo.
El mito que subyace a este principio es que la prisa hace el despilfarro. Sin embargo, la implementación de Lean ha proporcionado que es una buena práctica entregar rápido para ver y analizar el resultado lo antes posible.
Empoderar al equipoEditar
Ha habido una creencia tradicional en la mayoría de las empresas sobre la toma de decisiones en la organización – los gerentes dicen a los trabajadores cómo hacer su propio trabajo. En una técnica de trabajo lean, los papeles se invierten: se enseña a los directivos a escuchar a los desarrolladores, para que puedan explicar mejor qué acciones se podrían llevar a cabo, así como aportar sugerencias de mejora. El enfoque lean sigue el principio ágil de «construir proyectos en torno a individuos motivados y confiar en ellos para hacer el trabajo», fomentando el progreso, detectando errores y eliminando impedimentos, pero sin microgestionar.
Otra creencia errónea ha sido la consideración de 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 organizativo, las personas necesitan algo más que la lista de tareas y la seguridad de que no serán molestadas durante la realización de las mismas. 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 proporcionar apoyo y ayuda en situaciones difíciles, así como garantizar que el escepticismo no arruine el espíritu del equipo. Respetar a las personas y reconocer su trabajo es una forma de potenciar al equipo.
Construir la integridad enEdit
El cliente necesita tener una experiencia global del sistema. Esta es la llamada integridad percibida: cómo se anuncia, se entrega, se despliega, se accede a él, lo intuitivo que es su uso, su precio y lo bien que resuelve los problemas.
Integridad conceptual significa que los componentes separados del sistema funcionan bien juntos como un todo con equilibrio entre flexibilidad, mantenibilidad, eficiencia y capacidad de respuesta. Esto puede lograrse comprendiendo el dominio del problema y resolviéndolo al mismo tiempo, no de forma secuencial. La información necesaria se recibe en pequeños lotes -no en un solo y vasto trozo-, preferiblemente mediante la comunicación cara a cara y no con 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 después de un largo desarrollo aislado.
Una de las formas saludables hacia la 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 nuevas mejoras. La refactorización consiste en 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 un mal diseño del mismo y deben evitarse. El proceso de construcción completo y automatizado debe ir acompañado de un conjunto completo y automatizado de pruebas para el desarrollador y el cliente, con el mismo versionado, sincronización y semántica que el estado actual del sistema. Al final, la integridad debe verificarse con pruebas exhaustivas, garantizando así que el sistema hace lo que el cliente espera que haga. Las pruebas automatizadas también se consideran parte del proceso de producción y, por lo tanto, si no añaden valor, deben considerarse un desperdicio. Las pruebas automatizadas no deben ser un objetivo, sino un medio para conseguir un fin, concretamente la reducción de defectos.
Optimizar el TodoEditar
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 – descomponiendo las grandes tareas en otras más pequeñas, y estandarizando las diferentes etapas del desarrollo, se deberían encontrar y eliminar las causas raíz de los defectos. Cuanto más grande sea el sistema, más organizaciones participen en su desarrollo y más partes sean desarrolladas por 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 sólida es mucho más beneficiosa que la optimización de los beneficios a corto plazo, que no permite relaciones en las que todos salgan ganando.
El pensamiento esbelto tiene que ser bien entendido por todos los miembros de un proyecto, antes de aplicarlo en una situación concreta de la vida real. «Piensa en grande, actúa en pequeño, falla rápido; aprende rápidamente»: estos lemas resumen la importancia de entender el campo y la conveniencia de implementar los principios lean a lo largo de todo el proceso de desarrollo de software. Sólo cuando se implementan todos los principios lean juntos, combinados con un fuerte «sentido común» con respecto al entorno de trabajo, existe una base para el éxito en el desarrollo de software.