 | Este artículo necesita citas adicionales para su verificación . ( julio de 2014 ) ( Aprenda cómo y cuándo eliminar este mensaje de plantilla ) |
| Desarrollo de software |
|---|
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 de Toyota , [1] está surgiendo con el apoyo de una subcultura pro-lean dentro de la comunidad ágil . Lean ofrece un sólido marco conceptual, valores y principios, así como buenas prácticas, derivadas de la experiencia, que apoyan a las organizaciones ágiles.
Origen [ editar ]
El término 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 compara las herramientas 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 Agile [3], ha dado como resultado que dichos conceptos sean más aceptados dentro de la comunidad ágil.
Principios lean [ editar ]
El desarrollo esbelto se puede resumir en siete principios, muy cercanos en concepto a los principios de manufactura esbelta: [4]
- Eliminar residuos
- Amplifica el aprendizaje
- Decide lo más tarde posible
- Entregue lo más rápido posible
- Empoderar al equipo
- Desarrollar integridad en
- Optimizar el conjunto
Elimina el desperdicio [ editar ]
La filosofía Lean considera todo lo que no aporta valor al cliente como un desperdicio ( muda ). Dichos desechos pueden incluir: [5]
- Trabajo parcialmente realizado
- Características adicionales
- Reaprendizaje
- Cambiar de tarea
- Esperando
- Transferencias
- Defectos
- Actividades de gestión
Para eliminar el desperdicio, uno debe poder reconocerlo. Si alguna actividad puede pasarse por alto o el resultado puede lograrse sin ella, es un desperdicio. La codificación parcialmente hecha eventualmente abandonada durante el proceso de desarrollo es un desperdicio. Las funciones adicionales como el papeleo y las funciones que los clientes no utilizan con frecuencia son un desperdicio. Cambiar personas entre tareas es un desperdicio. Esperar otras actividades, equipos, procesos es un desperdicio. 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.
Se utiliza una técnica de mapeo de la cadena de valor para identificar el desperdicio. El segundo paso es señalar las fuentes de residuos y eliminarlas. La eliminación de desechos debe tener lugar de forma iterativa hasta que se liquiden incluso los procesos y procedimientos aparentemente esenciales.
Amplificar el aprendizaje [ editar ]
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 la aptitud para el uso y no de 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 usuario podría simplificarse presentando pantallas a los usuarios finales y obteniendo sus aportes. La acumulación de defectos debe 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 junto con la refactorización y las pruebas de 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, ambos representantes de clientesy el equipo de desarrollo aprende más sobre el problema del dominio y descubre posibles soluciones para un mayor desarrollo. Así, 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 ]
Decidir lo más tarde posible [ editar ]
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 se puedan tomar en base a hechos y no a suposiciones y predicciones inciertas. Cuanto más complejo es un sistema, más capacidad de cambio debe incorporarse, lo que permite retrasar compromisos importantes y cruciales. El enfoque iterativo promueve este principio: la capacidad de adaptarse a los cambios y corregir errores, que pueden ser muy costosos si se descubren después del lanzamiento del sistema.
- Con 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. Como una solución se considera irrazonable, se corta. Al final de un período, se comparan los diseños supervivientes y se elige uno, quizás con algunas modificaciones basadas en el aprendizaje de los demás, un gran ejemplo de aplazamiento del compromiso hasta el último momento posible. Las decisiones de software también podrían beneficiarse de esta práctica para minimizar el riesgo provocado por un gran diseño inicial. Además, habría múltiples implementaciones que funcionan correctamente, pero son diferentes (en cuanto a implementación, internamente). Estos podrían usarse para implementar sistemas tolerantes a fallas que verifiquen que todas las entradas y salidas sean correctas,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 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 anteriores vinculadas a la tecnología. Esto no significa que no se deba involucrar ninguna planificación, al contrario, las actividades de planificación deben concentrarse en las diferentes opciones y adaptarse a la situación actual, así como aclarar situaciones confusas mediante el establecimiento de patrones de acción rápida. La evaluación de diferentes opciones es efectiva tan pronto como se da cuenta de que no son gratuitas, pero brindan la flexibilidad necesaria para la toma de decisiones tardía.
Entregue lo más rápido posible [ editar ]
En la era de la rápida evolución de la tecnología, 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á recibir la retroalimentación e incorporarla 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 se pueden retrasar. La velocidad asegura la satisfacción de las necesidades actuales del cliente y no lo que requirió ayer. Esto les da la oportunidad de retrasar la decisión sobre lo que realmente necesitan hasta que obtengan un mejor conocimiento. 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 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 tarjetas pequeñas o historias : los desarrolladores estiman el tiempo necesario para la implementación de cada tarjeta. Por lo tanto, la organización del trabajo cambia a un sistema de autoajuste , 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 los colegas o del cliente. Esto requiere transparencia del proceso, lo que también es beneficioso para la comunicación del equipo.
El mito subyacente a este principio es que la prisa genera desperdicio . Sin embargo, la implementación ajustada ha proporcionado que es una buena práctica entregar rápido para ver y analizar el resultado lo antes posible.
Empoderar al equipo [ editar ]
Ha existido una creencia tradicional en la mayoría de las empresas 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 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 brindar sugerencias para mejoras. El enfoque lean sigue el principio ágil [6] "construye proyectos alrededor de individuos motivados [...] y confía en ellos para hacer el trabajo", [7] alentando el progreso, detectando errores y eliminando impedimentos, pero no 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 la lista de tareas y la seguridad de que no serán molestadas durante la finalización. de las tareas. Las personas necesitan motivación y un propósito superior para trabajar con 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 equipodebe 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.
Desarrollar integridad en [ editar ]
El cliente debe tener una experiencia general del sistema. Esta es la llamada integridad percibida: cómo se anuncia, entrega, implementa, accede, 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 equilibrio entre flexibilidad, facilidad de mantenimiento, eficiencia y capacidad de respuesta. Esto se puede lograr entendiendo el dominio del problema y resolviéndolo al mismo tiempo, no secuencialmente. La información necesaria se recibe en pequeños lotes, no en un gran trozo, preferiblemente mediante comunicación cara a cara y no con documentación escrita. El flujo de información debe ser constante en ambas direcciones, desde el cliente hasta 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 a la base del código original, más difícil se vuelve agregar más mejoras. La refactorización consiste en mantener la simplicidad, la claridad y la cantidad mínima de características en el código. Las repeticiones en el código son signos de diseños de código incorrectos y deben evitarse. El proceso de construcción completo y automatizado debe ir acompañado de un conjunto completo y automatizado de pruebas para desarrolladores y clientes, con 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 lograr un fin,específicamente la reducción de defectos.
Optimizar el todo [ editar ]
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 es el sistema, más organizaciones están involucradas en su desarrollo y más partes son desarrolladas por diferentes equipos, mayor es la importancia de tener relaciones bien definidas entre diferentes proveedores, para producir un sistema con componentes que interactúan 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 las ganancias a corto plazo, que no permite relaciones de beneficio mutuo.
Todos los miembros de un proyecto deben comprender bien el pensamiento Lean antes de implementarlo en una situación concreta de la vida real. "Piense en grande, actúe en pequeña escala, fracase rápido; aprenda 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. Solo 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 .
Prácticas de software ajustado [ editar ]
Las prácticas de desarrollo de software esbelto, o lo que los Poppendiecks llaman "herramientas", se reformulan ligeramente a partir de los equivalentes originales en el desarrollo de software ágil . Ejemplos de tales prácticas incluyen:
- Ver desperdicio
- Mapeo de flujo de valor
- Desarrollo basado en conjuntos
- Sistemas de tracción
- Teoría de colas
- Motivación
- Mediciones
- Desarrollo impulsado por 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 esbelto se considera un método de desarrollo de software ágil. [9]
Ver también [ editar ]
- Programación extrema
- DevOps
- Kanban
- Tablero Kanban
- Integración ajustada
- Servicios lean
- Scrum (desarrollo)
Referencias [ editar ]
- ^ Yasuhiro Monden (1998), Toyota Production System, An Integrated Approach to Just-In-Time , Tercera edición, Norcross, GA: Engineering & Management Press, ISBN 0-412-83930-X .
- ^ Mary Poppendieck; Tom Poppendieck (2003). Desarrollo de software ajustado: un conjunto de herramientas ágil . Addison-Wesley Professional. ISBN 978-0-321-15078-3.
- ^ Mary Poppendieck: "El papel del liderazgo en el desarrollo de software" https://www.youtube.com/watch?v=ypEMdjslEOI
- ^ Mary Poppendieck; Tom Poppendieck (2003). Desarrollo de software ajustado: un conjunto de herramientas ágil . Addison-Wesley Professional. págs. 13-15. ISBN 978-0-321-15078-3.
- ^ Mary Poppendieck; Tom Poppendieck (2003). Desarrollo de software ajustado: un conjunto de herramientas ágil . Addison-Wesley Professional. págs. 19-22. ISBN 978-0-321-15078-3.
- ^ "12 principios detrás del manifiesto ágil - Alianza ágil" . agilealliance.org . 4 de noviembre de 2015.
- ^ Marcar líneas; Scott W. Ambler (2012). Entrega ágil disciplinada: Guía del profesional para la entrega ágil de software en la empresa . IBM Press. págs. 54–. ISBN 978-0-13-281013-5.
- ^ Mary Poppendieck; Tom Poppendieck (2003). Desarrollo de software ajustado: un conjunto de herramientas ágil . Addison-Wesley Professional. págs. 182–. ISBN 978-0-321-15078-3.
- ^ "¿Qué es el desarrollo de software ágil?" . agilealliance.org . 29 de junio de 2015.
Lectura adicional [ editar ]
- Ladas, Corey (enero de 2008). Scrumban: Ensayos sobre sistemas Kanban para el desarrollo de software ajustado . Prensa Modus Cooperandi. ISBN 0-578-00214-0.
- Ries, Eric (septiembre de 2011). El Lean Startup : cómo los emprendedores de hoy utilizan la innovación continua para crear negocios radicalmente exitosos . Crown Business. ISBN 978-0307887894.
