En la década de 1930, el sistema de producción de Toyota nos dio   . 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. los principios de producción ajustada  Una breve mirada al desarrollo de software ágil y esbelto  La principal preocupación del   es aumentar la adaptabilidad. El   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: desarrollo ágil Manifiesto Ágil  Individuos e interacciones sobre procesos y herramientas.  Software de trabajo sobre documentación completa.  Colaboración con el cliente sobre la negociación del contrato.  Responder al cambio que seguir un plan.  El   , 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: desarrollo Lean  Inventario  Superproducción  Procesamiento adicional  Transportación  Esperando  Movimiento  Defectos  Todos los créditos a   y su libro,   . El mundo del desarrollo de software y el diseño web ahora conoce la importancia de analizar la eficiencia de cada proceso. Mary y Tom Poppendieck Lean Software Development: An Agile Toolkit  ¿Por qué cambiar al desarrollo de software Lean?  Echemos un vistazo a la   del Departamento de Administración de Empresas de la   . Informan que alrededor   bajo estudio vieron una mejora en la calidad del producto al adoptar un sistema lean. Un ejemplo es   en Oregón, que   en 2002 después de adoptar un modelo esbelto. investigación Universidad de Turiba del 73% de las empresas Timberline Software también informó una mejora en la calidad  Quizás   pueda barrer todos los argumentos. Bajo sus diversas mejoras, experimentaron un   y vieron un   . Sorprendentemente, su mejora en la   . En resumen, su número medio de errores disminuyó y el número de   . BBC Worldwide 47 % menos de variación aumento del 37 % en la entrega de software velocidad de entrega del software no afectó la calidad de su producto 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,   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: el trabajo completado parcialmente  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?   es el próximo desperdicio en términos de desarrollo de software lean y   ofrece un excelente ejemplo. Galaxy S4 introdujo la función   , 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:   . Extra Features el Galaxy S4 de Samsung Air Gesture 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   o la   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: Principio de Pareto Regla 80/20  “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   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. reaprendizaje   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   ,   son parte de la   . 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. Stack Overflow los silos de conocimiento “evolución natural del crecimiento del proyecto”   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,   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! Handoffs  Según Tom y Mary Poppendieck, las empresas   del conocimiento en cada traspaso. Esto significa que   , el   de la cantidad total que inicialmente comenzó a fluir.  pierden alrededor del 50 % después de 5 transferencias conocimiento sobrante es solo el 3%   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   . 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. Work Delay  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   . 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. (discutido anteriormente)   6) Movimiento  El movimiento se convierte en   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. cambio de contexto  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.   ,   el impacto del cambio de contexto de la siguiente manera: Jeff Atwood, cofundador de Stack Overflow explica  “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   que registró que    estudio de la BBC "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   , 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: defectos   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   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   . "Construir calidad en" (¡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. 

Flow

Samsung

Got A Topic To Write? I Can Help!

Read My Stories

Este audio es producido en el idioma original de la historia!

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

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Telegram: el puente de Crypto Island hacia el continente

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

El modelo Bitcoin UTXO, impulsando un ecosistema único

Telegram: el puente de Crypto Island hacia el continente

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

El modelo Bitcoin UTXO, impulsando un ecosistema único

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps