resumen lean software development

Resumen Lean Software Development  


El libro Lean Software Development de Mary y Tom Poppendieck es una lectura obligatoria para todos aquellos que quieran entender muchos de los principios, patrones y prácticas agile. Hace casi 15 años que se escribió pero todavía hoy todo lo que hay escrito en el libro es 100% vigente y aplicable en las organizaciones actuales.

Lean Software Development

El libro está estructurado en 7 capítulos (+1 extra) donde en cada uno te explica un principio y te da herramientas para desarrollar este principio. En este post encontrarás un resumen nada detallado de cada uno. Si quieres ampliar información encontrarás información más que de sobra en Internet o incluso en este blog, ya que tanto los principios como las herramientas han sido ampliamente desarrolladas por otros autores.

Los 7 principios de Lean Software Development

1) Ver y eliminar el waste-desperdicio

  • Evitar definir requerimientos a detalle muy temprano cuando se sabe que se van a solicitar muchos cambios.
  • Apurar el desarrollo aun sabiendo que el software no se va a probar inmediatamente.
  • Incorpora la calidad temprano
    • Eliminar la mala de costumbre de no probar bien lo desarrollado y dejarle el trabajo a QA que ya “nos informará si algo salió mal”.
    • Automatizar pruebas y solucionar defectos apenas estos se detecten y no dejarlos para después.
    • Eliminar la causa raíz de los incidentes asegurando que estos nunca más vuelvan a ocurrir.
  • Herramientas:

2) Ampliar el aprendizaje

  • Pretender tener un diseño definido a detalle asumiendo que éste no va a cambiar no es realista. Sobre todo para un sistema complejo y con mucha incertidumbre.
  • Se sustituyen los requisitos por presentar las pantallas a los usuarios.
  • Herramientas:
    • Tool 3: Feedback.
    • Tool 4: Iteraciones.
    • Tool 5: Sincronización (builds cada día del producto y tests automatizados, comunica restricciones y deja la solución emerger).
    • Tool 6: Set-Based Development (converger con restricciones en lugar de decisiones tempranas), ver ToC aplicada al SoftDev o CCPM.

lean software development

3) Decidir lo más tarde posible

  • Dejar las decisiones para el final introduciendo opciones en el desarrollo, aunque cueste más desarrollar las opciones (la reducción del riesgo lo compensa).
  • Situación donde he visto que mi idea era mejor que otras pero debido a que ésta no estaba contemplada en el plan inicial no fue considerada. En este caso todos los requerimientos se definieron muy temprano y no se consideró que a medida que se progresa se gana más conocimiento y las ideas evolucionan en el proyecto.
  • Herramientas:
    • Tool 7: Options Thinking (retrasa decisiones importantes si hay incertidumbre), ya vimos algo de esto en los resúmenes del 1º día de las CAS.
    • Tool 8: El último momento responsable.
    • Tool 9: Tomando decisiones, 2 aproximaciones depende del contexto, depth-first para decisiones claras o un experto vs breadth first para retrasar decisiones.

4) Reaccionar/Liberar tan rápido como sea posible

  • Liberar lo más rápido posible y con una buena velocidad, esto mejora el aprendizaje.
  • Transparencia en el proceso.
  • Herramientas:
    • Tool 10: Sistemas Pull y planificaciones solo alto nivel con Information Radiators, ver también Kanban.
    • Tool 11: Teoría de colas, mirar tiempo de ciclo en lugar de trabajo hecho, y hacer releases pequeñas para disminuir tamaño de cola.
    • Tool 12: Cost of Delay, hay que dar al equipo un modelo económico (Trade-off triangle) para que tome sus propias decisiones acorde a lo que la compañía persigue. Mejor si los 3 ejes tienen las mismas unidades de medida. Así se reducirán los tiempos de ciclo y se respetarán las fechas.

5) Potenciar el equipo

  • Las organizaciones de software no pueden funcionar a pleno rendimiento, hay que dejar un tiempo para invertir en formación, reestructuración, y organizar recursos para crecer.
  • Herramientas:
    • Tool 13: Autodeterminación, el manager se convierte en empowerer y facilitador del trabajo, introducir feedback loops, implementa basado en principios y no en procesos.
    • Tool 14: Motivacion, comunica el propósito de los proyectos, el objetivo debe ser conseguible. Comunica a los developers con los clientes directamente. Recibirás un mayor compromiso con el trabajo de las iteraciones.
    • Tool 15: El liderazgo dentro del equipo emerge, no se elige desde arriba sino que es algo que se debe ganar.
    • Tool 16: Experiencia, promueve las comunidades de expertos y los estándares.

lean software team

6) Crear la integridad

  • Integridad conceptual significa que los componentes separados del sistema funcionan bien juntos, como en un todo, logrando equilibrio entre la flexibilidad, mantenibilidad, eficiencia y capacidad de respuesta.
  • Flujo de información entre lo que debe construir y la construcción debe ser al mismo tiempo, no secuencialmente. No es válida la documentación, mejor la comunicación cara a cara.
  • Pruebas de aceptación para probar el todo.
  • Herramientas:
    • Tool 17: Integridad percibida, foco en el valor para el cliente, utilizar modelos en lenguaje de negocio como contrato entre equipo y clientes.
    • Tool 18: Integridad conceptual, la solución debe funcionar como un todo. La comunicación debe ser efectiva sobre todo en la fase de diseño. Mejor si el diseño no se basa en un documento de requerimientos sino hacer sesiones continuas de diseño. Si algo ya funciona y lo puedes reaprovechar hazlo.
    • Tool 19: Refactoring, la arquitectura debe mantenerse sana durante la evolución. Simplicidad, claridad, mantenibilidad.
    • Tool 20: Testing, deben probar que hace lo que debe, automatizar al máximo e integrar en la construcción diaria.

7) Véase todo el conjunto

  • Piensa en grande, actúa en pequeño, equivócate rápido; aprende con rapidez.
  • Hay que ver el conjunto, no solo el producto o el proceso, y siempre aplicando sentido común.
  • Herramientas:
    • Tool 21: Medidas, para mejorar y decidir hay que medir. Medidas de información, no de rendimiento individual. Por ejemplo asignar los defectos a features, no al desarrollador.
    • Tool 22: Contratos, se busca la colaboración, ser flexible con el alcance. El cliente debe entender que si el riesgo surge deberá incrementar el coste, no puede ser coste y fecha fija.

Hasta aquí el resumen del libro. Si te ha gustado y estás pensando en comprarlo, puedes hacerlo desde el siguiente enlace de afiliados. A ti no te cuesta nada y a mí me ayudarás a mantener este blog.

También te puede interesar...

Agile BCN Open Space primavera de 2017 (II) Este pasado sábado se celebró el Barcelona el Open Space de la comunidad Agile BCN. Cerca de 70 personas nos reunimos en las oficinas de Netmind IT co...
Resumen Clean Code Este verano he releído uno de los libros de referencia de todo buen programador. Se trata de "Clean Code", de Robert C. Martin (o más conocido como Un...
Agile BCN Open Space primavera de 2017 (I) Este pasado sábado se celebró el Barcelona el Open Space de la comunidad Agile BCN. Cerca de 70 personas nos reunimos en las oficinas de Netmind IT co...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *