7 desperdicios en el desarrollo de software Lean [y cómo prevenirlos]

En la década de 1930, el sistema de producción de Toyota nos dio los principios de producción ajustada . Ahora, la industria de TI, software y desarrollo web también ha adoptado estos principios para mejorar sus procesos de producción. En realidad, los conceptos y principios de Lean se utilizan en más formas que solo en la fabricación. Sin embargo, en TI y software, todavía hay quienes apuntan hacia el desarrollo Agile cuando mencionan Lean y el desarrollo de software en el mismo contexto. Si bien es cierto que los principios Agile y Lean comparten filosofías similares, existen diferencias clave que los distinguen. Profundizando en Lean, discutiré de qué habla Lean además de sus puntos clave.

Una breve mirada al desarrollo de software ágil y esbelto

La principal preocupación del desarrollo ágil es aumentar la adaptabilidad. El Manifiesto Ágil habla en detalle sobre interacciones individuales, pequeños lanzamientos incrementales y colaboraciones con clientes. Destaca la rápida respuesta a cambios y requerimientos. De esta manera, los equipos de desarrollo de software pueden adaptarse rápidamente a las actualizaciones y comenzar a impulsar esos cambios de manera constante y frecuente. A modo de ejemplo, los siguientes son los valores Agile según el manifiesto:

1. Individuos e interacciones sobre procesos y herramientas.
2. Software de trabajo sobre documentación completa.
3. Colaboración con el cliente sobre la negociación del contrato.
4. Responder al cambio que seguir un plan.

El desarrollo Lean , por otro lado, destaca acciones que no aportan mejoras al producto final o al proceso en su conjunto. Habla de los Residuos en el Desarrollo de Software presentes en siete formas. Estos son los siguientes:

1. Inventario
2. Superproducción
3. Procesamiento adicional
4. Transportación
5. Esperando
6. Movimiento
7. Defectos

Todos los créditos a Mary y Tom Poppendieck y su libro, Lean Software Development: An Agile Toolkit . El mundo del desarrollo de software y el diseño web ahora conoce la importancia de analizar la eficiencia de cada proceso.

¿Por qué cambiar al desarrollo de software Lean?

Echemos un vistazo a la investigación del Departamento de Administración de Empresas de la Universidad de Turiba . Informan que alrededor del 73% de las empresas bajo estudio vieron una mejora en la calidad del producto al adoptar un sistema lean. Un ejemplo es Timberline Software en Oregón, que también informó una mejora en la calidad en 2002 después de adoptar un modelo esbelto.

Quizás BBC Worldwide pueda barrer todos los argumentos. Bajo sus diversas mejoras, experimentaron un 47 % menos de variación y vieron un aumento del 37 % en la entrega de software . Sorprendentemente, su mejora en la velocidad de entrega del software no afectó la calidad de su producto . En resumen, su número medio de errores disminuyó y el número de defectos se redujo en un 24 % .

Al final de su estudio, la universidad afirma las experiencias de BBC Worldwide y otras empresas que se volcaron hacia lean. Llegaron a la conclusión de no haber experimentado ningún impacto negativo importante. Por el contrario, vieron un aumento en la productividad del equipo durante sus sprints lean probados. En resumen, la universidad reporta resultados positivos al aplicar métodos lean al desarrollo de software .

Entonces, ¿cuáles son estos errores y desperdicios que las empresas deben reducir?

Los desperdicios en el desarrollo de software Lean

1) Desperdicio de inventario

En el desarrollo de software lean, el trabajo completado parcialmente es desperdicio de inventario. En esencia, también se ajusta a la definición: un bloque de código que está incompleto pero que está esperando para completarse simplemente ocupa espacio de inventario de código. Los principios Lean definen que los desarrolladores no deben dejar el trabajo incompleto. Sin embargo, no se trata solo de códigos parciales. Los desperdicios de inventario en el desarrollo de software también incluyen:

• Documentación no codificada
• Códigos no sincronizados
• Códigos no probados
• Códigos no implementados
• Códigos no documentados

Solución:

La fuerte adherencia a los principios Lean y la metodología Kanban limitará el proceso de trabajo para mantener el proyecto manejable. Una gran cantidad de tareas incompletas significa fallas en la gestión del proyecto, lo que puede generar problemas en la asignación de tareas. Lean sugiere que los desarrolladores de software asignen tareas manejables y se aseguren de que se completen antes de entregar más.

2) Sobreproducción

¿Alguna vez te has encontrado con una función en una aplicación móvil que te pareció completamente inútil? ¿Qué pasa si la misma característica es inútil para la mayoría de los usuarios de la aplicación? Extra Features es el próximo desperdicio en términos de desarrollo de software lean y el Galaxy S4 de Samsung ofrece un excelente ejemplo. Galaxy S4 introdujo la función Air Gesture , que aunque parecía prometedora en papel, mostraba una realidad diferente. Teniendo en cuenta que la función ya no está disponible en los nuevos dispositivos Samsung, apunta a una cosa: las masas no la necesitaban .

Cuando se trata de software y desarrollo web, el cliente y sus usuarios son claves para descubrir las características necesarias de un software. Las características adicionales de bajo valor que los usuarios no usan o incluso usan con poca frecuencia son simplemente un desperdicio en el desarrollo de software lean. A veces, esta es la causa de que las empresas de software se apresuren a agregar funciones como muestra de fuerza. En realidad, las nuevas funciones no se usan, agregan complejidad y aumentan los costos de mantenimiento de las aplicaciones. En última instancia, la característica adicional no agrega valor.

Solución:

El Principio de Pareto o la Regla 80/20 establece que el 80% de los usuarios probablemente usará el 20% de las funciones. Por lo tanto, los desarrolladores deben apuntar al desarrollo iterativo. El objetivo principal debe ser construir un MVP y luego continuar agregando más funciones según las necesidades de los clientes o usuarios. Además, el equipo de desarrollo de software debe estar listo para comprometerse con los cambios en las funciones que también pueden surgir durante la fase de desarrollo. En breve:

“En lugar de preocuparse por cómo desarrollar cosas más rápido, es mucho mejor aprender a dejar de desarrollar cosas que no son importantes y concentrarse en las cosas que tendrán un impacto real”. – La mentalidad Lean: haga las preguntas correctas

3) Procesamiento adicional

El procesamiento adicional, un desperdicio en la fabricación ajustada, se convierte en reaprendizaje en términos de desarrollo de software ajustado. El reaprendizaje es el aprendizaje repetido de cualquier cosa a través de múltiples canales. Documentación detallada que nadie lee o actividades de planificación extra son algunos de sus ejemplos. El tiempo, el esfuerzo y los recursos utilizados para crear documentación que podría entregarse verbalmente oa través de otras formas de comunicación (verbal, correo electrónico, etc.) son esfuerzos desperdiciados. Incluso un simple paso de estampado de goma cuando no hay requisitos para ello es un desperdicio.

Solución:

El desarrollo de software Lean enfatiza la construcción de una sólida colaboración en equipo y una red de comunicación saludable entre los equipos. Los equipos de software deben participar en plataformas de aprendizaje compartidas, donde también pueden compartir nueva información relevante con otros equipos. Esto apunta a romper los silos de conocimiento .

Según Stack Overflow , los silos de conocimiento son parte de la “evolución natural del crecimiento del proyecto” . Los equipos deben pasar información a otros departamentos si va más allá de su alcance, incluida la información que es simplemente un pensamiento. Desafortunadamente, esto ocurre con poca frecuencia, y los nuevos miembros del equipo a menudo tienen que apoyarse en esa información aislada para continuar construyendo. Eventualmente, a medida que el equipo crece y se agregan más departamentos a un proyecto, la necesidad de dispersar la información evoluciona aún más. La documentación escrita es la única forma de permitir que los equipos crezcan.

4) Transporte

Mientras que el transporte en la manufactura esbelta se refiere a las actividades de movimiento de un producto, en el desarrollo de software esbelto, lo llamamos Handoffs. En términos prácticos, Handoffs o movimiento es el tiempo perdido en mover datos de una ubicación a otra. Cada vez que los desarrolladores de software transfieren proyectos de un equipo a otro, existe la necesidad de generar trabajo adicional para transferir conocimientos y brindar capacitación. Esto se da bajo la suposición de que la transferencia de conocimiento ocurre con un 100% de éxito, ¡y eso no es posible!

Según Tom y Mary Poppendieck, las empresas pierden alrededor del 50 % del conocimiento en cada traspaso. Esto significa que después de 5 transferencias , el conocimiento sobrante es solo el 3% de la cantidad total que inicialmente comenzó a fluir.

Solución:

Si bien la transferencia de conocimiento en sí misma es crucial para cualquier proyecto, podemos reducir sus efectos negativos. Establecer políticas para romper los silos de conocimiento mediante la integración de equipos dispares para que trabajen juntos y agregar equipos multifuncionales puede resultar efectivo.

Además, se debe dar preferencia a los canales de comunicación como la documentación, los correos electrónicos, las llamadas de voz y las conversaciones en persona. Los bucles de retroalimentación deben ser rápidos y las iteraciones deben ser menos para mejorar aún más los resultados.

5) Esperando

Cualquier proceso que detenga la actividad del proyecto es un desperdicio, y el software Lean lo llama Work Delay . Este desperdicio puede variar desde retrasos en la aprobación hasta dependencias. Tan pronto como se requiere que alguien apruebe una determinada tarea, trabajo o trabajo, se genera un desperdicio. Este es un cuello de botella en toda la gestión del proyecto que restringe el avance de los equipos hasta que obtienen la aprobación. En algunos casos, esto puede incluso resultar en reelaboración y reajustes, especialmente si se requiere la aprobación de los clientes. En resumen, el retraso en el trabajo, o el aspecto de espera del desarrollo Lean, es el intervalo de tiempo en el que uno o más miembros del equipo esperan ociosamente la entrada de otra parte/equipo/individuo para continuar.

La siguiente figura muestra cómo las semanas de espera pueden extender un proyecto a varias semanas. Tenga en cuenta que la causa de la espera no está definida.

Solución:

El sector de desarrollo de software puede eliminar los retrasos en el trabajo o esperar al reducir las transferencias (discutido anteriormente) . Los equipos deben adoptar un enfoque de comunicación más instantáneo para las aprobaciones: prefieran la comunicación en persona o la mensajería instantánea en lugar de correos electrónicos o avisos de recordatorio. Cree equipos independientes que sean independientes de la aprobación o validación de otros. Esto puede tomar tiempo para la implementación completa, pero facilita el trabajo. También existe la necesidad de distribuir los poderes de toma de decisiones entre los miembros en el desarrollo de software lean.

6) Movimiento

El movimiento se convierte en cambio de contexto en el diseño de software esbelto y, para explicar esto, puede referirse a él como un hermano de Handoff. En el cambio de contexto, el trabajo de un programador puede requerir que tome varios proyectos, lo que a menudo los obliga a saltar de un proyecto a otro según los requisitos.

La realidad es que se requiere un cambio en un estado mental completo para sacar a la luz el mapeo de proyectos complejos y el trabajo de programación del pasado antes de que un programador promedio pueda comenzar su próxima tarea en curso. Jeff Atwood, cofundador de Stack Overflow , explica el impacto del cambio de contexto de la siguiente manera:

“Incluso agregar un solo proyecto a su carga de trabajo es profundamente debilitante según el cálculo de Weinberg. Pierdes el 20% de tu tiempo. En el momento en que agrega un tercer proyecto a la mezcla, casi la mitad de su tiempo se desperdicia en el cambio de tareas”. –Jeff Atwood

También he incluido su representación gráfica a continuación:

En consecuencia, el cambio de tareas tampoco es algo que deba ignorarse. Si no se controla, también puede tener graves repercusiones para los miembros del equipo. Tómalo de un estudio de la BBC que registró que "Aquellos que se distraían con el correo electrónico entrante y las llamadas telefónicas vieron una caída de 10 puntos en su coeficiente intelectual, más del doble de lo que se encontró en los estudios sobre el impacto de fumar marihuana".

Solución:

De manera similar a cómo un equipo de desarrollo puede manejar el desperdicio de trabajo parcial realizado, pueden reducir el cambio de contexto al limitar la cantidad de trabajo en progreso. Nuevamente, la metodología Kanban del proceso Agile es la clave para limitar el flujo de trabajo aquí. El trabajo no planificado también puede introducir un cambio de contexto y puede reducirse mediante revisiones posteriores al incidente. Las personas y los equipos deben priorizar las tareas y otros equipos también deben sincronizarse con las prioridades de los demás para reducir las "sorpresas" .

7) Defectos

Finalmente, los defectos , como en la manufactura esbelta, son simplemente lo que son: un desperdicio. De manera similar a los principios de manufactura esbelta, el desarrollo de software esbelto relaciona los códigos defectuosos o los errores con el desperdicio. Esto se debe a que los defectos generan trabajo adicional en forma de reelaboración. Agregan más tiempo para completar el proyecto y obligan a los programadores a cambiar de contexto. A continuación se muestra una ecuación simple para ver su impacto:

Cantidad de Residuos Por Defecto = (Impacto del Defecto) x (Tiempo Transcurrido Hasta Su Detección)

En general, los gastos en reparar un defecto en forma de tiempo, dinero y mano de obra pueden ser significativos en ausencia de controles de calidad adecuados. Además, los defectos detectados en una etapa temprana de desarrollo son más fáciles de corregir en comparación con los detectados durante la fase de operación, o incluso más tarde.

Solución:

Mitigar la programación defectuosa, los códigos y los errores es de lo que se trata la parte "Construir calidad en" del desarrollo de software lean. Garantiza una programación de calidad y reduce el retrabajo. Promueve la práctica de la estrategia de revisión propia y por pares y asegura el registro de defectos. La documentación sólida es clave, pero, de nuevo, la documentación no debería resultar en otro desperdicio (¡ya discutido anteriormente!) .

Conclusión: ¡el desarrollo de software Lean es una batalla digna de participar!

Para resumir todo, la tabla anterior puede explicar los defectos del desarrollo de software lean. Los principios de Lean no son solo para la industria de fabricación y productos. Como muestra la investigación anterior, es un método beneficioso para comenzar a trabajar en un proyecto de software. La idea de eliminar el desperdicio para aumentar la eficiencia y la calidad es igualmente importante en la industria del desarrollo de software. Puede requerir una presión adicional para implementarlo en todos los niveles, pero sus resultados a largo plazo valen la pena asumir cualquier desafío.