• Save
Lean Thinking para el Desarrollo de Software
Upcoming SlideShare
Loading in...5
×
 

Lean Thinking para el Desarrollo de Software

on

  • 2,129 views

Introducción a Lean Software Development

Introducción a Lean Software Development

Statistics

Views

Total Views
2,129
Views on SlideShare
1,497
Embed Views
632

Actions

Likes
2
Downloads
0
Comments
1

7 Embeds 632

http://leanparaguay.com 291
http://comunidad.iebschool.com 210
http://www.leanparaguay.com 98
http://www.paraguayagil.com 26
http://www.linkedin.com 4
http://www.holistica.co 2
http://www.google.com.pe 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Introducción a Pensamiento Lean y la manera en que este se aplica al desarrollo de software
  • El término sistema socio-técnico fue originalmente usado para designar la interacción obrero – máquina en ambientes de trabajo industrial. Actualmente se ha extendido su alcance para abarcar las complejas interacciones entre las tecnologías y las personas, así como sus consecuencias psicológicas y culturales.Originalmente llamado "Just-in-time", se basa en el enfoque creado por el fundador de Toyota, Sakichi Toyoda, su hijo Kiichiro Toyoda, y el ingeniero Taiichi Ohno. Los fundadores de Toyota se inspiraron mucho en la obra de W. Edwards Deming y los escritos de Henry Ford. Cuando estos hombres llegaron a Estados Unidos para observar la línea de montaje y la producción masiva que había hecho rico Ford, no se mostraron impresionados. Mientras compraban en un supermercado observaron la simple idea de un dispenser automático de bebidas, y cuando el cliente quiere tomar una bebida, toma uno, y se reemplaza al instante. Los principios fundamentales de la TPS se incorporan en The Toyota Way.
  • Muchas empresas implementan practicas de las metodologías agiles, pero si no aprenden a reconocer y a eliminar desperdicios en su cadena de valor y tampoco generan respeto por sus trabajadores y partners, los resultados serán mediocres.
  • Las practicas de Lean Manufacturing y la gestión de la cadena de suministro no se traducen fácilmente al desarrollo de software, ya que tanto el software como la actividad de desarrollo son individualmente muy diferentes a las operaciones y la logística. Vamos a echar un vistazo a cada una de estas palabras, el software y desarrollo y analizar dónde radica su singularidad.
  • Casi todo lo que sabemos sobre una buena arquitectura de software tiene que ver con la creación de software fácil de cambiar.Por ejemplo, en el artículo "QualityWith a Name," Jim Shore define una arquitectura de software alta calidad como: "Un buen diseño de software minimiza el tiempo necesario para crear, modificar y mantener el software al mismo tiempo que lograr un rendimientoaceptable en ejecución”.Cuando el tiempo pasa, las modificaciones al software tienden a volverse mas difíciles y costosos.El porcentaje de coste del ciclo de vida del software atribuido a "mantenimiento" oscila entre el 40 y 90 por ciento.La mayoría de los sistemas exitosos y duraderos han sido modificado en su ciclo de vida.El software debe ser diseñado y construido con tolerancia a cambios en la mente.
  • El Sistema de Desarrollo de Producto de Toyota se encuentra de lleno basado en la escuela empírica. Comienzan con un concepto de un vehículo en lugar de una definición. Incrementalmente construyen este concepto en un producto durante el proceso de desarrollo.Por ejemplo, el concepto de ToyotaPrius no incluyo originalmente un motor híbrido; se fijó el objetivo de ahorro de combustible de 5 litros por cada 100 kms, 20 kilómetros por litro o 47,5 millas por galón.El concepto de producto Prius también requería una cabina espaciosa para los pasajeros, pero no se definieron las dimensiones del vehículo en el concepto original. Recién durante el desarrollo, el equipo se basa en el motor híbrido, que acababa de salir del laboratorio de investigación, como la mejor forma de lograr el objetivo agresivo de economía de combustible.Creemos que todo proceso de desarrollo trata con un entorno cambiante debe ser un proceso empírico, ya los procesos empíricos proporcionan el enfoquemás conocidode adaptación al cambio. Como hemos señalado anteriormente, 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 desarrollo de software debe ser proceso empírico.
  • El TPS se encuentra de lleno basado en la escuela empírica. Comienzan con un concepto de un vehículo en lugar de una definición. Incrementalmente construyen este concepto en un producto durante el proceso de desarrollo.Por ejemplo, el concepto de ToyotaPrius no incluyo originalmente un motor híbrido; se fijó el objetivo de ahorro de combustible de 5 litros por cada 100 kms, 20 kilómetros por litro o 47,5 millas por galón.El concepto de producto Prius también requería una cabina espaciosa para los pasajeros, pero no se definieron las dimensiones del vehículo en el concepto original. Recién durante el desarrollo, el equipo se basa en el motor híbrido, que acababa de salir del laboratorio de investigación, como la mejor forma de lograr el objetivo agresivo de economía de combustible.Creemos que todo proceso de desarrollo trata con un entorno cambiante debe ser un proceso empírico, ya los procesos empíricos proporcionan el enfoquemás conocidode adaptación al cambio. Como hemos señalado anteriormente, 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 desarrollo de software debe ser proceso empírico.
  • El TPS se encuentra de lleno basado en la escuela empírica. Comienzan con un concepto de un vehículo en lugar de una definición. Incrementalmente construyen este concepto en un producto durante el proceso de desarrollo.Por ejemplo, el concepto de ToyotaPrius no incluyo originalmente un motor híbrido; se fijó el objetivo de ahorro de combustible de 5 litros por cada 100 kms, 20 kilómetros por litro o 47,5 millas por galón.El concepto de producto Prius también requería una cabina espaciosa para los pasajeros, pero no se definieron las dimensiones del vehículo en el concepto original. Recién durante el desarrollo, el equipo se basa en el motor híbrido, que acababa de salir del laboratorio de investigación, como la mejor forma de lograr el objetivo agresivo de economía de combustible.Creemos que todo proceso de desarrollo trata con un entorno cambiante debe ser un proceso empírico, ya los procesos empíricos proporcionan el enfoquemás conocidode adaptación al cambio. Como hemos señalado anteriormente, 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 desarrollo de software debe ser proceso empírico.
  • Creemos que todo proceso de desarrollo trata con un entorno cambiante debe ser un proceso empírico, ya los procesos empíricos proporcionan el enfoquemás conocidode adaptación al cambio. Como hemos señalado anteriormente, 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 desarrollo de software debe ser proceso empírico.
  • La idea central consiste en maximizar el valor del cliente y reducir al mínimo los desperdicios.Simplemente, lean significa crear más valor para los clientes con menos recursos.Una organización ágil entiende el valor de los clientes y centra sus procesos clave para aumentar continuamente este valor. Lean Thinkingtieneunalargahistoria de habergeneradomejorasdramaticas en campos tan diversoscomo la fabricacion, salud y la construccion.

Lean Thinking para el Desarrollo de Software Lean Thinking para el Desarrollo de Software Presentation Transcript

  • Lean Thinking para elDesarrollo de Software Ricardo Yorky Consultor en ( holistica ) Twitter: @RicardoYorky
  • Objetivos• Que es Lean Software Development• Introducción al Pensamiento Lean
  • Industria del softwareSistema de Información sobre Bienestar InfantilFlorida Minnesota• Inicio en 1990 donde se • Inicio esencialmente el estimo que llevaría 8 años a mismo sistema en 1999 y lo un costo 32 millones de USD terminaron a inicios del 2000 a un costo de 1,1• En 2002 Florida había millones de USD gastado 170 millones de USD y se estimaba terminar en • Gracias a su infraestructura 2005 a un costo de 230 estandarizada, los millones de USD requerimientos minimizados y un equipo de personas capaces
  • 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.
  • Orígenes El Desarrollo de Software Lean tiene sus raíces enel 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 paraentregar productos al mercado mucho más rápido ycon mejor calidad. Intenta identificar y erradicar los problemas y "desventajas" de las metodologíasanteriores, como el enfoque en cascada (Waterfall).
  • Orígenes Lean se enfoca principalmente en las personas y en la comunicación - si serespeta 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.
  • Toyota Production SystemEl Sistema de Producción Toyota (TPS), originalmentellamado "Just-in-time", es un sistema socio-técnico integraldesarrollado por Toyota.Comprende su filosofía y prácticas de gestión para lafabricación de automóviles, la logística, y la relación con susproveedores y clientes.Taiichi Ohno, Shigeo Shingo y Eiji Toyoda desarrollaron elsistema entre 1948 y 1975.Los fundadores y visionarios de Toyota se inspiraronbastante en la obra de W. Edwards Deming y en los escritosde Henry Ford.
  • 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.
  • 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.
  • 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
  • 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.
  • Desarrollo de Software
  • 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.
  • Arquitectura de Software “Un buen diseño de software minimiza el tiempo necesario para crear, modificar y mantener elsoftware 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.
  • Desarrollo de SoftwareDesarrollo: Es el proceso de transformar ideas enproductos.• 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)
  • Desarrollo en Casacada (Waterfall)Waterfall Model: http://commons.wikimedia.org/wiki/File%3AWaterfall_model_(1).svgPaulsmith99 at en.wikipedia [CC-BY-3.0 (www.creativecommons.org/licenses/by/3.0)], via Wikimedia Commons
  • 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
  • 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
  • SCRUM 24 horas Lista de 4 semanas requisitios Entrega mensual Prioridades SCRUM - The New New Product Development Game -HARVARD BUSINESS REVIEW - 1986
  • KANBAN
  • 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.
  • 7 Principios de Lean Software Development
  • 1. Eliminar desperdicios
  • 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.
  • Lean Thinking1.Especificar lo que valoran los 4. Permitir que los clientes utilicen clientes en un producto o el producto en el momento y en servicio. el lugar que lo necesite.2.Identificar los pasos realizados 5.Hacerlo de manera mas y mas para crear el producto y eliminar efectiva. 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.
  • 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.
  • 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.
  • Tool: Visualizar los desperdicios• Las demás actividades que no son análisis y codificación realmente crear valor para los clientes ?
  • Huele a desperdicio7 Desperdicios en Fabricación 7 Desperdicios en el Desarrollo de SoftwareInventario Trabajo realizado a medias o trabajo incompleto, test-and-fix churn, pruebas tardias, big-bang) integrationProcesamiento extra ReaprendizajeExceso de producción Características adicionales. Solo 20% de las características de un sistema tipico son regularmente utilizadas.Transportación TraspasosEspera RetrasosMovimiento Intercambio de tareasDefectos Defectos (Bugs)
  • Trabajo incompleto• Tiende a volverse obsoleto• Su problema principal es que no sabemos si funcionara correctamente ?• No sabemos que problemar puede acarrear.• Y hasta que este en produccion, no sabremos si resuelve el problema del negocio• Genera enormes riesgos financieros
  • 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
  • Proyectos con un enfoque tradicional Proyectos cancelados: 31 % Proyectos problemáticos: 53 % Proyectos exitosos: 16 % Fuente: Standish Group Study Reported in 2000 Chaos Report.
  • 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.
  • 2. Construir calidad empotrada
  • 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.
  • 3. Crear conocimiento
  • 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.
  • 4. Comprometerseresponsablemente
  • 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.
  • 5. Comenzar pronto y entregar rápido
  • 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.
  • 6. Optimizar el todo
  • 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.
  • 7. Respetar a las personas
  • 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.
  • 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
  • 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
  • FinRicardo YorkyConsultor en ( holistica )Twitter: @RicardoYorky