Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Lean Thinking para el Desarrollo de Software

7.498 visualizaciones

Publicado el

Introducción a Lean Software Development

Publicado en: Educación

Lean Thinking para el Desarrollo de Software

  1. 1. Lean Thinking para el Desarrollo de Software Ricardo Yorky Consultor en OXIGENO LAB Twitter: @RicardoYorky
  2. 2. Objetivos • Que es Lean Software Development • Introducción al Pensamiento Lean
  3. 3. Industria del software Sistema de Información sobre Bienestar Infantil Florida • Inicio en 1990 donde se estimo que llevaría 8 años a un costo 32 millones de USD • En 2002 Florida había gastado 170 millones de USD y se estimaba terminar en 2005 a un costo de 230 millones de USD Minnesota • Inicio esencialmente el mismo sistema en 1999 y lo terminaron a inicios del 2000 a un costo de 1,1 millones de USD • Gracias a su infraestructura estandarizada, los requerimientos minimizados y un equipo de personas capaces
  4. 4. Que es Lean Software Development  Lean Software Development es la aplicación de Lean Thinking al proceso de desarrollo de software. Las organizaciones que son realmente lean tienen una fuerte ventaja competitiva, ya que responden muy rápidamente y de manera muy disciplinada a la demanda del mercado, en lugar de tratar de predecir el futuro.  Lean Software Development es la disciplina para la creación de software que se adapte fácilmente a los cambios en su dominio.
  5. 5. Orígenes El Desarrollo de Software Lean tiene sus raíces en el Sistema de Producción de Toyota (TPS) y Just-in- Time, y tiene como objetivo ayudar a las organizaciones de software a optimizar sus procesos y sus métodos de producción para entregar productos al mercado mucho más rápido y con mejor calidad. Intenta identificar y erradicar los problemas y "desventajas" de las metodologías anteriores, como el enfoque en cascada (Waterfall).
  6. 6. Orígenes Lean se enfoca principalmente en las personas y en la comunicación - si se respeta a las personas que producen el software y si se pueden comunicar de forma eficiente, es más probable que logren entregar un buen producto y satisfacer las necesidades del consumidor final.
  7. 7. Toyota Production System El Sistema de Producción Toyota (TPS), originalmente llamado "Just-in-time", es un sistema socio-técnico integral desarrollado por Toyota. Comprende su filosofía y prácticas de gestión para la fabricación de automóviles, la logística, y la relación con sus proveedores y clientes. Taiichi Ohno, Shigeo Shingo y Eiji Toyoda desarrollaron el sistema entre 1948 y 1975. Los fundadores y visionarios de Toyota se inspiraron bastante en la obra de W. Edwards Deming y en los escritos de Henry Ford.
  8. 8. Principios y Prácticas • Principios son verdades que no cambian con el tiempo o espacio. • Prácticas son la aplicación de los principios a una situación en particular. Las prácticas pueden y deberían ser diferentes al pasar de un entorno a otro, y además las prácticas cambian mientras que ocurre cada situación.
  9. 9. Como implementar los principios ? • Que debemos aprender primero ? – Aprender haciendo: Adoptar algunas practicas para que nos lleve a entender los principios detrás de cada practica. – Entender antes de hacer: Aprender y entender los principios para desarrollar practicas para cada situación especifica. • Se ha observado que los mejores resultados se obtienen combinando ambos enfoques.
  10. 10. Caso práctico • Decidimos aplicar SCRUM para el desarrollo de un nuevo proyecto de software. • Implementamos algunas prácticas de SCRUM. • Aprendimos que una metodología, no era suficiente para lograr reducción de costos. • Desarrollamos un enfoque – Integrando a todos los involucrados del proyecto – Desarrollamos una cultura tipo stop-the-line
  11. 11. Caso práctico • Iniciamos un proyecto de 15 meses en un cliente. • Luego del primer mes, el cliente priorizo entregar gran parte de la funcionalidad antes de la fecha de entrega original. • La solución fue entregada en tiempo y • En el tiempo restante se desarrollaron pendientes, sin embargo la mayor cantidad de funcionalidades entregadas fue nueva.
  12. 12. Desarrollo de Software
  13. 13. Desarrollo de Software • Software: Es la parte de un producto o servicio que se espera que cambie. Ej. El software empresarial es la parte de un proceso que soporta la complejidad del negocio. – Todo lo que conocemos sobre una buena arquitectura de software tiene que ver con desarrollar software fácil de cambiar. – Mas de la mitad de un producto de software se desarrolla recién después de su primera entrega.
  14. 14. Arquitectura de Software “Un buen diseño de software minimiza el tiempo necesario para crear, modificar y mantener el software al mismo tiempo que logra un rendimiento aceptable” – Cuando el tiempo pasa, las modificaciones al software tienden a volverse mas difíciles y mas costosas. – El costo atribuido a "mantenimiento“ oscila entre el 40 % y 90 % durante su vida útil. – El software debe ser diseñado tolerante a cambios.
  15. 15. Desarrollo de Software Desarrollo: Es el proceso de transformar ideas en productos. • Hay dos escuelas de pensamiento : – La escuela determinista del pensamiento comienza por la creación de una definición completa del producto, y luego realiza esa definición. (Waterfall) – La escuela empírica del pensamiento comienza con un concepto de alto nivel sobre el producto y luego establece circuitos bien definidos de retroalimentación que ajustan las actividades para crear una interpretación óptima sobre el concepto. (TPS)
  16. 16. Desarrollo en Casacada (Waterfall) Waterfall Model: http://commons.wikimedia.org/wiki/File%3AWaterfall_model_(1).svg Paulsmith99 at en.wikipedia [CC-BY-3.0 (www.creativecommons.org/licenses/by/3.0)], via Wikimedia Commons
  17. 17. Desarrollo con métodos agiles • El TPS basado en el enfoque empírico de inspección continua comienza con un concepto de un vehículo en lugar de una definición total del producto. • Durante el desarrollo se detalla el concepto plasmándolo en el producto final. – El concepto del Toyota Prius no incluyo originalmente un motor híbrido; se fijó el objetivo de ahorro de combustible de 5 litros por cada 100 kms
  18. 18. Desarrollo con métodos agiles • El TPS basado en el enfoque empírico de inspección continua comienza con un concepto de un vehículo en lugar de una definición total del producto. • Durante el desarrollo se detalla el concepto plasmándolo en el producto final. – El concepto del Toyota Prius no incluyo originalmente un motor híbrido; se fijó el objetivo de ahorro de combustible de 5 litros por cada 100 kms
  19. 19. SCRUM 4 semanas 24 horas Entrega mensual Lista de requisitios Prioridades SCRUM - The New New Product Development Game -HARVARD BUSINESS REVIEW - 1986
  20. 20. KANBAN
  21. 21. Desarrollo con métodos agiles • Todo proceso de desarrollo de productos que opera en un entorno cambiante debe ser un proceso empírico. – Los procesos empíricos proporcionan el enfoque más conocido de adaptación al cambio. – El software, por su propia naturaleza debe ser diseñado para adaptarse a los cambios durante el desarrollo inicial y durante su vida útil. – Por lo tanto, el proceso de desarrollo de software debe ser empírico.
  22. 22. 7 Principios de Lean Software Development
  23. 23. 1. Eliminar desperdicios
  24. 24. Eliminar desperdicios • Taiichi Ohno describió al TPS como un sistema de gestión para la absoluta eliminación de desperdicios desde que el cliente no hace un pedido hasta que pasamos a cobrarle. • En el desarrollo ágil, el objetivo es el mismo, con la diferencia que la línea de tiempo inicia desde que el cliente pide atender una necesidad hasta el momento que entregamos el software para satisfacer esta necesidad.
  25. 25. Lean Thinking 1.Especificar lo que valoran los clientes en un producto o servicio. 2.Identificar los pasos realizados para crear el producto y eliminar cada paso que no genere lo que valoran los clientes. 3.Hacer que los pasos de valor agregado ocurran en la mejor secuencia posible para que el producto fluya suavemente hacia el cliente. 4. Permitir que los clientes utilicen el producto en el momento y en el lugar que lo necesite. 5.Hacerlo de manera mas y mas efectiva.
  26. 26. Muda significa Desperdicio • Cualquier actividad humana la cual absorbe recursos y no crea valor. – Defectos que requieran rectificación. – Sobreproducción de productos y servicios que nadie necesita. – Inventario de productos apilados para procesamiento o consumo. – Procesamiento o actividades innecesarias. – Movimiento innecesario de personas. – Transporte innecesario de productos. – Clientes esperando porque no se ha entregado a tiempo. – Productos y servicios que no satisfacen las necesidades de los clientes.
  27. 27. Entender lo que valoran los clientes • Para eliminar desperdicios, primero hay que reconocerlos. • Los desperdicios son las actividades humanos que aportan valor al producto, el primer paso consiste en desarrollar un sentido muy agudo de lo que valoran los clientes. • No hay nada mejor para entender la necesidad de los clientes entregándoles pronto una parte del software y obtener así su retroalimentación. • En este rubro, el valor tiene habito de cambio debido a que los clientes pueden tener o no una idea clara de su necesidad, y además les cuesta expresarlo en términos de funcionalidades del software.
  28. 28. Tool: Visualizar los desperdicios • Las demás actividades que no son análisis y codificación realmente crear valor para los clientes ?
  29. 29. Huele a desperdicio 7 Desperdicios en Fabricación 7 Desperdicios en el Desarrollo de Software Inventario Trabajo realizado a medias o trabajo incompleto, test-and-fix churn, pruebas tardias, big-bang) integration Procesamiento extra Reaprendizaje Exceso de producción Características adicionales. Solo 20% de las características de un sistema tipico son regularmente utilizadas. Transportación Traspasos Espera Retrasos Movimiento Intercambio de tareas Defectos Defectos (Bugs)
  30. 30. Trabajo incompleto • Tiende a volverse obsoleto • Su problema principal es que no sabemos si funcionara correctamente ? • No sabemos que problema puede acarrear. • Y hasta que este en producción, no sabremos si resuelve el problema del negocio • Genera enormes riesgos financieros
  31. 31. Procesos adicionales – Reaprendizaje • El papeleo o trabajo administrativo – Consume recursos – Enlentece el tiempo de respuesta – Esconde problemas de calidad – Se pierde, se degrada y se vuelve obsoleto – Lo que a nadie le importa leer entonces no tiene valor • Si hay papeleo que agrega valor al cliente, la regla seria: – Mantenerlo corto – Expresarlo en lenguaje de alto nivel – Hacerlo offline
  32. 32. Proyectos con un enfoque tradicional  Proyectos cancelados: 31 %  Proyectos problemáticos: 53 %  Proyectos exitosos: 16 % Fuente: Standish Group Study Reported in 2000 Chaos Report.
  33. 33. Eliminar desperdicios • Brindar un liderazgo técnico y de mercado - la organización puede ser exitosa si produce productos innovadores y tecnológicamente avanzados, pero es importante entender lo que valoran nuestros clientes y conocer la tecnología que se utilizara para crear este valor. • Crear solo software de valor para los clientes - debemos ser cuidadosos con todos los procesos que sigamos. Por ejemplo, debemos asegurarnos que todos estos procesos sea útiles y estén focalizados en crear el valor necesario. • Escribir menos código - mientras más código se tenga, más pruebas se van a necesitar, por lo que se necesitará más trabajo. Si escribimos pruebas para funcionalidad que no se necesita estamos perdiendo el tiempo.
  34. 34. 2. Construir calidad empotrada
  35. 35. Construir calidad empotrada • Sincronizar - para lograr una alta calidad en el software nos debemos empezar a ocupar de él antes de empezar a escribir una sola línea de código. (Unit Testing, Code Coverage, Reducir el trabajo incompleto (Bugs), Integración continua) • Automatizar - automatizar las pruebas, la construcción, las instalaciones, y cualquier tarea que sea rutinaria. Hay que automatizar de una manera inteligente, de forma que las personas puedan mejorar el proceso y cambiar cualquier cosa que quieran sin preocuparse por si el cambio hace que algo deje de funcionar. • Refactor - eliminar la duplicación de código a CERO - cada vez que aparezca la oportunidad, realizar el refactoring del código, de las pruebas y de la documentación para minimizar la complejidad.
  36. 36. 3. Crear conocimiento
  37. 37. Crear conocimiento • Crear equipos de diseño y construcción - el líder del equipo de debe escuchar a los miembros y hacerles preguntas inteligentes. Esto animara a cada miembro del equipo a buscar respuestas que lo hará retornar lo mas pronto posible con problemas encontrados o con las soluciones en mano. • Mantener una cultura de mejora continua - crear un ambiente en donde las personas estarán mejorando constantemente en lo que trabajan – Ellos deberían saber que no son y que no deben ser perfectas – Siempre tendrán algún campo en que pueden mejorar. (Kaizen) • Enseñar métodos para resolución de problemas - el equipo de desarrollo debería comportarse como un pequeño centro de investigación, estableciendo hipótesis y realizando varios experimentos o prototipos rápidos para verificar su teoria.
  38. 38. 4. Comprometerse responsablemente
  39. 39. Comprometerse responsablemente • Calendarizar las decisiones irreversibles hasta el último momento responsable - debemos saber hacia donde queremos ir pero no conocemos el camino del todo, lo vamos descubriendo día a día - lo más importante es mantener la dirección correcta. • Romper las dependencias - los componentes deben estar lo más levemente acoplados para que puedan implementarse en cualquier orden. • Mantener opciones - desarrollar múltiples soluciones para todas las decisiones críticas y ver cuales funcionan mejor.
  40. 40. 5. Comenzar pronto y entregar rápido
  41. 41. Comenzar pronto y entregar rápido • Trabajar en bloques pequeños - reducir el tamaño del proyecto, acortar los ciclos de entrega, estabilizar el ambiente de trabajo (escucha lo que te dice la velocidad), repetir lo bueno y eliminar las prácticas que crean obstáculos. • Limitar el trabajo a la capacidad - limitar la cola de tareas al mínimo (una o dos iteraciones por delante es suficiente), no hay que tener miedo al quitar elementos de la cola - rechazar cualquier trabajo hasta que se haya vaciado un lugar en la cola. • Foco en el tiempo del ciclo y no en la utilización de recursos - agregar tareas pequeñas a la cola que no puedan atascar al proceso por un tiempo largo - reducir el tiempo del ciclo y tener pocas cosas para procesar en la cola.
  42. 42. 6. Optimizar el todo
  43. 43. Optimizar el todo • Enfocarse en el flujo completo del valor - enfocarse en ganar la carrera completa (que es el software). No hay que malgastar esfuerzo en optimizar La ineficiencias locales, sino en ver el todo y optimizar a la organización en su totalidad. • Entregar un producto completo - los equipos necesitan tener buenos líderes, y también buenos ingenieros, vendedores, especialistas de marketing, secretarias, etc. Todos juntos pueden entregar un gran producto final a los clientes.
  44. 44. 7. Respetar a las personas
  45. 45. Respetar a las personas • Capacitar a los líderes de equipo - darle a los líderes de equipo entrenamiento, guías y espacio libre para implementar el pensamiento Lean en su ambiente. • Mover la responsabilidad y la toma de decisiones al nivel más bajo posible - dejar que las personas piensen y decidan por su cuenta - ellos saben mejor que nadie cómo implementar algoritmos difíciles y aplicar los frameworks de última generación. • Fomentar orgullo por el trabajo - fomentar la pasión y la participación del equipo hacia lo que hacen y cómo lo hacen.
  46. 46. Referencias • 1990 - The Machine That Changed the World : The Story of Lean Production, by Womack, James P., Daniel T. Jones, and Daniel Roos, New York: Rawson and Associates • 2002 - “ROI, It’s Your Job!” Published Keynote Third International Conference on Extreme • Programming, Jim Johnson. • 2003 - Womack, James P. and Jones, Daniel T., Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised and Updated, HarperBusines • 2003 - Lean Software Development: An Agile Toolkit -Mary Poppendieck, Tom Poppendieck
  47. 47. Referencias • 18/06/2004 - Interview with Mary Poppendieck: An introduction to Lean Software Development - Gustaf Brandberg – CITERUS • 2008 - AgileVersusLean - Martin Fowler • 05/04/2006 - “Quality With a Name,” Jim Shore • 2006 - Implementing Lean Software Development: From Concept to Cash - Mary Poppendieck, Tom Poppendieck • 2009 - Lean-Agile Software Development: Achieving Enterprise Agility - Alan Shalloway, Guy Beaver, James R. Trott
  48. 48. Fin Ricardo Yorky Consultor en OXIGENO LAB Twitter: @RicardoYorky

×