El desarrollo de software ajustado es una traducción de los principios y prácticas de fabricación ajustada al dominio 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 , valores y principios sólidos, 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 del 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 correspondientes. prácticas ágiles. La participación de los Poppendieck en la comunidad de desarrollo de software ágil , incluidas charlas en varias conferencias Agile [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 cercanos en concepto a los principios de fabricación Lean: [4]
La filosofía Lean considera desperdicio ( muda ) todo lo que no agrega valor al cliente . Dichos desechos pueden incluir: [5]
Para eliminar el desperdicio es necesario poder reconocerlo. Si se pudiera evitar alguna actividad o se pudiera lograr el resultado sin ella, es un desperdicio. La codificación parcialmente realizada y finalmente abandonada durante el proceso de desarrollo es un desperdicio. Las funciones adicionales, como el papeleo y las funciones que los clientes no suelen utilizar, son un desperdicio. Cambiar de persona entre tareas es un desperdicio (debido al tiempo invertido, y a menudo perdido, por las personas involucradas en el cambio de contexto). Esperar otras actividades, equipos, procesos es un desperdicio. Volver a aprender los requisitos para completar el trabajo es un desperdicio. Los defectos y la baja calidad son desperdicios. Los gastos generales de gestión que no producen valor real son un desperdicio.
Se utiliza una técnica de mapeo del flujo de valor para identificar el desperdicio. El segundo paso es señalar las fuentes de desperdicio y eliminarlas. La eliminación de residuos debe realizarse de forma iterativa hasta que se liquiden 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 en el que los desarrolladores escriben el código y lo que han aprendido. El valor del software se mide en términos de idoneidad para su uso y no en conformidad con los requisitos.
En lugar de agregar más documentación o planificación detallada, se podrían probar diferentes ideas escribiendo código y construyendo. El proceso de recopilación de requisitos de los usuarios podría simplificarse presentando pantallas a los usuarios finales y obteniendo sus comentarios. La acumulación de defectos debe evitarse 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 junto con pruebas de refactorización y integración . Aumentar la retroalimentación a través de breves sesiones de retroalimentación con los clientes ayuda a determinar la fase actual de desarrollo y ajustar los esfuerzos para futuras mejoras. Durante esas breves sesiones, 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: 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 con base en hechos y no en suposiciones y predicciones inciertas. Cuanto más complejo sea un sistema, más capacidad de cambio debe incorporarse en él, lo que permitirá retrasar compromisos importantes y cruciales. El enfoque iterativo promueve este principio: la capacidad de adaptarse a los cambios y corregir errores, que podrían resultar muy costosos si se descubren después del lanzamiento del sistema.
Un enfoque de desarrollo de software ágil puede acelerar la creación de opciones para los clientes, retrasando así ciertas decisiones cruciales hasta que los clientes se hayan dado cuenta mejor de sus necesidades. Esto también permite una adaptación posterior a los cambios y la prevención de costosas decisiones tempranas vinculadas a la tecnología. Esto no significa que no deba involucrarse ninguna planificación; por el contrario, las actividades de planificación deben concentrarse en las diferentes opciones y adaptarse a la situación actual, así como aclarar situaciones confusas estableciendo patrones para una acción rápida. Evaluar diferentes opciones es eficaz tan pronto como se comprende que no son gratuitas, pero proporcionan la flexibilidad necesaria para tomar decisiones tardías.
En la era de la rápida evolución tecnológica, no es el más grande el que sobrevive, sino el más rápido. Cuanto antes se entregue el producto final sin defectos importantes, antes se podrán recibir comentarios e incorporarlos a la siguiente iteración . Cuanto más cortas sean las iteraciones, mejor será el aprendizaje y la comunicación dentro del equipo. Con rapidez, las decisiones pueden retrasarse. La velocidad asegura el cumplimiento de las necesidades actuales del cliente y no las que requería ayer. Esto les da la oportunidad de retrasar la decisión sobre lo que realmente necesitan hasta que adquieran mejores conocimientos. Los clientes valoran la entrega rápida de un producto de calidad .
La ideología de 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 permitiendo 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 implementar cada tarjeta. De este modo, la organización del trabajo cambia a un sistema autónomo : cada mañana, durante una reunión de pie , cada miembro del equipo revisa lo que se hizo ayer, lo que se debe hacer hoy y mañana, y solicita las aportaciones necesarias de sus colegas o el 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 genera desperdicio . Sin embargo, la implementación eficiente ha demostrado que es una buena práctica realizar entregas rápidas 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 dicen a los trabajadores cómo hacer su propio trabajo. En una técnica de entrenamiento , los roles se cambian: a los gerentes se les enseña cómo escuchar a los desarrolladores , para que puedan explicar mejor qué acciones podrían tomarse, así como también brindar sugerencias para mejorar. El enfoque lean sigue el principio ágil [6] "construir proyectos en torno a personas motivadas [...] y confiar en ellos para hacer el trabajo", [7] fomentando el progreso, detectando errores y eliminando impedimentos, pero no la microgestión .
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 organizacional, las personas necesitan algo más que solo la lista de tareas y la seguridad de que no serán perturbadas durante su finalización. de las tareas. Las personas necesitan motivación y un propósito superior por el cual 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. Esta es la llamada integridad percibida: cómo se anuncia, se entrega, se implementa, se accede a ella, qué tan intuitivo es su uso, su precio y qué tan 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 podría 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 una gran porción, 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 después de un largo desarrollo de forma aislada.
Una de las formas saludables de lograr una arquitectura integral es la refactorización . A medida que se agregan más funciones al código base original, más difícil resulta agregar más mejoras. La refactorización consiste en mantener la simplicidad, la claridad y la cantidad mínima de funciones en el código. Las repeticiones en el código son signos de diseños de código incorrectos 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 de desarrolladores y clientes, que tengan el mismo control de versiones, sincronización y semántica que el estado actual del sistema. Al final, se debe verificar la integridad con pruebas exhaustivas, garantizando así que el sistema haga lo que el cliente espera. Las pruebas automatizadas también se consideran parte del proceso productivo, por lo que si no aportan valor deben considerarse desperdicio. Las pruebas automatizadas no deberían ser un objetivo, sino más bien un medio para lograr 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 al 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 estén involucradas en su desarrollo y más piezas sean desarrolladas por diferentes equipos, mayor será la importancia de tener relaciones bien definidas entre 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 ganancias a corto plazo, que no permite relaciones beneficiosas para todos .
Todos los miembros de un proyecto deben comprender bien el pensamiento Lean 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 principios Lean a lo largo de todo el proceso de desarrollo de software. Sólo cuando todos los principios lean se implementan 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 .
Las prácticas de desarrollo de software ágil, o lo que los Poppendieck llaman "herramientas", se reformulan ligeramente a partir de los equivalentes originales en el desarrollo de software ágil . Ejemplos de tales prácticas incluyen:
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 eficiente se considera un método de desarrollo de software ágil. [9]