Se entiende por “desperdicio” a cualquier actividad que consuma recursos pero que no agrega ningún valor, según la percepción del cliente. El desarrollo de software Lean está inspirado en Lean Manufacturing y Toyota Production Systems, donde se encuentran definidos los 7 desperdicios de la fabricación, y es a partir de ellos que se adopto los 7 desperdicios del desarrollo de software, con los cuales se tiene el propósito de descubrirlos y eliminarlos para reducir costos y hacer que los productos sean más efectivos. En la presente charla se dará a conocer las características de estos desperdicios, así como, indicar algunas recomendaciones para reducirlos.
11. Taiichi Ohno
A mediados de 1900 hizo énfasis en
la eliminación de desperdicios a
través Toyota Production System
En el corazón del desarrollo de
software lean se encuentra el mismo
principio: eliminar el desperdicio
#agiles2020
12. #agiles2020
Fabricación Desarrollo de software
Inventario en proceso Trabajo parcialmente terminado
Superproducción Features extras
Procesamiento adicional Reaprendizaje
Transporte Transferencia de conocimiento
Movimiento Cambiar de tarea
Esperando Retrasos
Defectos Defectos
Implementing Lean Software Development From Concept to Cash (2006)
Mary Poppendieck, Tom Poppendieck
Los siete desperdicios
13. Removing Software
Development Waste
to Improve Productivity
Todd Sedano, Pivotal, USA
Paul Ralph, Dalhousie University, Canada
Cécile Péraire, Carnegie Mellon University Silicon Valley, USA
#agiles2020
Rethinking Productivity in Software Engineering (2019)
Edited by Caitlin Sadowski, Thomas Zimmermann
15. 1. Desarrollar el producto equivocado
2. Mala gestión del Backlog
3. Retrabajo
4. Complejidad innecesaria
5. Carga cognitiva extraña
6. Trastorno psicológico
7. Pérdida de conocimiento
8. Esperando / multitarea
9. Comunicación ineficaz
#agiles2020
16. Desarrollar el producto equivocado
El costo de crear un feature o un producto que no responde a las
necesidades del usuario o de la empresa
1
17. Causas
❖ Ignorar los deseos del usuario
- Falta de user research,
validación o pruebas
- Ignorar el feedback
- Atender features sin valor
❖ Ignorar los deseos del negocio
- No involucrar a stakeholders
- Poca retroalimentación
- Prioridades poco claras
¿Cómo reducirlos?
❖ Diseño participativo
❖ Validación de features
❖ Pruebas de usabilidad
❖ Releases frecuentes
18. Mala gestión del Backlog
El costo de duplicar el trabajo, atender features de menor valor para el
usuario o demorar las correcciones de bugs
2
X
19. Causas
❖ Adelantar la atención de ítems
❖ Trabajar simultáneamente en
muchas features
❖ Duplicar trabajo
❖ No existen suficientes historias
en Ready
❖ Desbalance entre trabajar
funcionalidades y corregir bugs
❖ Demora en las pruebas o la
corrección de bugs críticos
❖ Cambiar features
frecuentemente
¿Cómo reducirlos?
❖ Ordenar el Backlog de manera
continua
❖ Minimizar el WIP (terminar antes
que empezar)
❖ Lograr suficientes historias en
Ready antes del desarrollo
❖ Corregir bugs mientras se
desarrollan features
❖ Recibir feedback de los usuarios
antes de realizar cambios
20. Retrabajo
El costo de modificar el trabajo entregado que debería haberse hecho
correctamente pero no se hizo
3
21. Causas
❖ Deuda técnica
❖ Historia y criterios de
aceptación ambiguos
❖ Historias no aceptadas (criterios
y DoD)
❖ No se identifica la causa raíz de
los defectos
❖ Estrategia de prueba deficiente
¿Cómo reducirlos?
❖ Refactorización continua
❖ Revisar los criterios de
aceptación antes de comenzar
una historia
❖ Verificar los criterios de
aceptación antes de terminar
una historia
❖ Mejorar la estrategia de prueba
❖ Mejorar el análisis de la causa
raíz de los defectos
22. Complejidad innecesaria
El costo de crear una solución más complicada de lo necesario; una
oportunidad perdida para simplificar features, UI o código
4
23. Causas
❖ Complejidad innecesaria de los
features, desde la perspectiva
del usuario
❖ Complejidad innecesaria
técnica, desde la perspectiva del
equipo
¿Cómo reducirlos?
❖ Preferir diseños más simples
para la interacción del usuario
❖ Preferir diseños más simples
para el código de software
❖ Analizar si realmente es
conveniente adicionar
complejidad a los features
❖ Intentar el diseño iterativo e
incremental
25. Causas
❖ Deuda técnica
❖ Historias complejas o grandes
❖ APIs, librerías y frameworks
problemáticos
❖ Cambios de contexto
innecesarios
❖ Flujo de desarrollo ineficiente
❖ Código mal organizado
¿Cómo reducirlos?
❖ Refactorizar código que sea
difícil de entender
❖ Descomponer historias grandes
y complejas en historias más
pequeñas y simples
❖ Reemplazar bibliotecas que son
difíciles de usar
❖ Trabajar en una tarea a la vez
hasta completarla
❖ Mejorar el flujo de desarrollo
incluyendo mejores scripts y
herramientas
27. Causas
❖ Baja moral del equipo
❖ Modo “tenemos que hacerlo
rápido”
❖ Conflicto interpersonal o de
equipo
❖ Conflicto entre equipos
¿Cómo reducirlos?
❖ Detectar la angustia. "¿Cómo van
las cosas?"
❖ Mitigar el estrés relacionado a
los plazos, reduciendo el alcance
o ampliando el plazo
❖ Mitigar el estrés relacionado con
los conflictos interpersonales,
facilitando una mediación
29. Causas
❖ Rotación de equipos
❖ Silos de conocimiento
¿Cómo reducirlos?
❖ Programación de pares
❖ Polinización de conocimientos
❖ Revisión de código entre
miembros del equipo
❖ Incentivar la interacción más
que documentación
31. Causas
❖ Pruebas lentas o poco fiables
❖ Falta de información, de
personas o de equipamiento
❖ Los Product Managers tardan
demasiado en proporcionar la
información necesaria
❖ Cambio de contexto entre tareas
¿Cómo reducirlos?
❖ Limitar el WIP
❖ Cuando la espera es
prolongada, trabajar en la causa
de la espera
33. Causas
❖ Equipos demasiado grandes
❖ Comunicación asincrónica
❖ Solo algunas personas
dominando la conversación o no
escuchan
❖ Reuniones ineficientes
❖ Mal entendimiento de las
necesidades del usuario
¿Cómo reducirlos?
❖ La comunicación sincrónica
(especialmente cara a cara)
❖ Turnos conversacionales
❖ Incorporar un facilitador
35. #agiles2020
Mejora incremental
Práctica de mejora continua, que se ejecuta en paralelo al desarrollo
de features
Prevención
Creación de sistemas que impidan el desperdicio
Reducción focalizada
Habilitación de períodos específicos para trabajar en desperdicios
38. Conclusiones
❖ Considerar un enfoque integral para identificar los desperdicios
❖ Recurrir a la prevención, mejora incremental y la reducción focalizada
❖ Eliminar los desperdicios contribuye en mejorar la productividad
#agiles2020
39. “Si no agrega valor
es un desperdicio”
Henry Ford
#agiles2020