Por Marco Avendaño

Marco Avendaño es ingeniero de sistemas con amplia experiencia en el diseño y desarrollo de productos digitales. Él se encuentra en constante aprendizaje y puesta en práctica de los valores y principios ágiles, lo cual le ha permitido participar en procesos de transformación organizacional buscando la mejora continua de las personas, equipos de trabajo y productos. Actualmente desempeña funciones como Agile Coach del grupo Credicorp.


“La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.”

Principio del Manifiesto por el Desarrollo Ágil de Software

El reto actual que tienen las organizaciones para responder a un entorno caracterizado por ser volátil, incierto, complejo y ambiguo, es generar productos y servicios innovadores y cuyo valor sea entregado a sus clientes lo más rápido posible. En lo que respecta al desarrollo de productos software, este hecho ha dado lugar a que dentro de las organizaciones se trabaje en base a equipos de personas, los cuales están conformados por todas las especialidades necesarias para generar el producto y por supuesto se espera que sean altamente productivos. La construcción de software es compleja de manera innata y en muchas oportunidades los equipos incurren en el desperdicio de tiempo y esfuerzo.

Como desperdicio se puede entender cualquier cosa que, desde el punto de vista del cliente, no le aporta ningún valor. Por lo tanto, el principal desafío que tienen los equipos es el de reducir al máximo estos desperdicios, lo cual incrementará su productividad. ¿Pero cómo los equipos pueden eliminar los desperdicios? Para responder a esta pregunta se debe tener en cuenta un enfoque integral sobre todo el ciclo de vida de desarrollo del software, para que se tenga la capacidad de identificar las situaciones conflictivas y aplicar correcciones.

Precedentes

A mediados del siglo 1900, Taiichi Ohno hizo énfasis en la eliminación de desperdicios a través del Toyota Production System, los cuales fueron adoptados como parte principal del desarrollo de software Lean, siendo estos los que se muestran en la tabla siguiente:

Los siete desperdicios del desarrollo de software Lean

FabricaciónDesarrollo de software
Inventario en procesoTrabajo parcialmente terminado
SuperproducciónFeatures extras
Procesamiento adicionalRe-aprendizaje
TransporteTransferencia de conocimiento
MovimientoCambiar de tarea
EsperaRetrasos
DefectosDefectos

Implementing Lean Software Development from Concept to Cash (2006). Mary Poppendieck, Tom Poppendieck

Clasificación actualizada de los desperdicios del desarrollo de software

Tomando como referencia los siete desperdicios del desarrollo de software, los autores: Todd Sedano, Paul Ralph y Cécile Péraire, ofrecen una clasificación actualizada de los desperdicios relacionados al desarrollo de software:

  1. Desarrollar el producto equivocado
  2. Mala gestión del product 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

A continuación, se da a conocer el detalle de cada uno de ellos:

  • Desarrollar el producto equivocado: Se refiere al costo de crear un feature o un producto que no responde a las necesidades del usuario o de la empresa.
    • Causas: Se origina cuando se ignoran los deseos del usuario, lo que se refleja ante la ausencia de un user research, validación o pruebas. Otro aspecto que contribuye a este desperdicio es que se ignora el feedback, esto se da al atender features sin valor para el cliente, ignorar los deseos del negocio, al no involucrar a stakeholders, cuando no existe retroalimentación y cuando las prioridades están poco claras.
    • ¿Cómo reducir este desperdicio? Logrando un diseño participativo del producto, validando las features desarrolladas, llevando a cabo pruebas de usabilidad y logrando releases frecuentes.
  • Mala gestión del product backlog: Se refiere al costo de duplicar el trabajo, atender features de menor valor para el usuario o demorar las correcciones de bugs.
    • Causas: Se origina cuando se adelantan la atención de ítems que no son muy importantes, al trabajar simultáneamente en muchas features, al duplicar trabajo, cuando no existen suficientes historias listas para su atención (ready), cuando existe un desbalance entre trabajar funcionalidades y corregir bugs, al demorarse en las pruebas o la corrección de bugs críticos, así como al cambiar features frecuentemente.
    • ¿Cómo reducir este desperdicio? Logrando ordenar el product backlog de manera continua, minimizando el trabajo en progreso (work in progress), logrando suficientes historias que estén listas para su atención (ready) antes del desarrollo, corrigiendo bugs mientras se desarrollan features, recibiendo feedback de los usuarios antes de realizar cambios.
  • Retrabajo: Se refiere al costo de modificar el trabajo entregado que debería haberse hecho correctamente pero no se hizo.
    • Causas: Se origina cuando se genera deuda técnica, cuando las historias de usuario y los criterios de aceptación son ambiguos, cuando las historias de usuario no son aceptadas (no cumplen los criterios de aceptación ni la Definición de Terminado), al no identificarse la causa raíz de los defectos, así como cuando la estrategia de pruebas es deficiente.
    • ¿Cómo reducir este desperdicio? Logrando una refactorización continua, revisando los criterios de aceptación antes de comenzar a atender una historia de usuario, verificando los criterios de aceptación antes de terminar una historia de usuario, mejorando la estrategia de prueba, así como el análisis de la causa raíz de los defectos.
  • Complejidad innecesaria: Se refiere al costo de crear una solución más complicada de lo necesario, siendo una oportunidad perdida para lograr la simplificación de features, UI o código.
    • Causas: Se origina cuando se tiene, desde la perspectiva del usuario, una complejidad de los features innecesaria, también cuando se tiene, desde la perspectiva de los desarrolladores, una complejidad técnica innecesaria.
    • ¿Cómo reducir este desperdicio? Logrando una preferencia por diseños más simples para la interacción del usuario, prefiriendo diseños más simples para el código de software, analizando si realmente es conveniente adicionar complejidad a los features, e intentando un diseño iterativo e incremental.
  • Carga cognitiva extraña: Se refiere al costo de un esfuerzo mental innecesario.
    • Causas: Se origina cuando existe deuda técnica, cuando las historias de usuario son complejas o grandes, cuando existen APIs, librerías y frameworks problemáticos, cuando hay cambios de contexto innecesarios, flujos de desarrollo ineficientes, así como un código mal organizado.
    • ¿Cómo reducir este desperdicio? Logrando la refactorización del código que es difícil de entender, descomponiendo historias de usuario grandes y complejas en historias de usuario más pequeñas y simples, reemplazando librerías que son difíciles de usar, trabajando en una tarea a la vez hasta completarla, mejorando el flujo de desarrollo incluyendo mejores scripts y herramientas.
  • Trastorno psicológico: Se refiere a los costos ocasionados al angustiar al equipo.
    • Causas: Se origina al bajar la moral del equipo, cuando se activa el modo “tenemos que hacerlo rápido”, ocasionando un conflicto interpersonal o de equipo, así como originando conflicto entre equipos.
    • ¿Cómo reducirlos? Logrando la detección de la angustia, preguntando «¿Cómo van las cosas?» para ayudarles, mitigando el estrés relacionado a los plazos, reduciendo el alcance o ampliando el plazo; mitigando el estrés relacionado con los conflictos interpersonales y facilitando una mediación.
  • Pérdida de conocimiento: Se refiere al costo de volver a adquirir información que el equipo alguna vez conoció.
    • Causas: Se origina cuando existe rotación de miembros en los equipos, también cuando se evidencia la existencia de silos de conocimiento.
    • ¿Cómo reducir este desperdicio? Poniendo en práctica la programación en parejas, motivando a la polinización de conocimientos, realizando la revisión de código entre miembros del equipo, incentivando la interacción entre personas más que la generación excesiva de documentación.
  • Multitarea: Se refiere al costo ocasionado por el tiempo de inactividad, a menudo oculto por la multitarea.
    • Causas: Se origina cuando las pruebas son lentas o poco fiables, cuando existe falta de información, de personas o de equipamiento, cuando los product managers tardan demasiado en proporcionar la información necesaria, al ocasionar un cambio de contexto entre tareas.
    • ¿Cómo reducir este desperdicio? Logrando limitar el trabajo en progreso (work in progress); cuando existe un tiempo de espera prolongado, trabajando en la resolución de la causa de la espera.
  • Comunicación ineficaz: Se refiere al costo de una comunicación incompleta, incorrecta, engañosa o ausente entre todos los involucrados.
    • Causas: Se origina cuando los equipos son demasiado grandes, cuando la comunicación es asincrónica, cuando solo algunas personas dominan la conversación o no escuchan, teniendo reuniones ineficientes, cuando existe un mal entendimiento de las necesidades del usuario.
    • ¿Cómo reducir este desperdicio? Logrando una comunicación sincrónica (especialmente cara a cara), realizando turnos conversacionales y con la incorporación de un facilitador en las sesiones o reuniones.

Enfoques para la reducción de desperdicios

Se pueden considerar los siguientes tres enfoques:

  • Prevención: Creando sistemas o mecanismos que impidan los desperdicios.
  • Mejora incremental: Practicando la mejora continua, que se ejecuta en paralelo al desarrollo de features.
  • Reducción focalizada: Habilitando períodos específicos para trabajar en desperdicios.

Al momento que se desea aplicar estos enfoques y cuando se han identificado varios desperdicios, puede generarse la pregunta de ¿Cuál atender primero? Para ello se puede seguir los siguientes pasos:

  1. Enumerar los desperdicios.
  2. Clasificar los desperdicios en el cuadrante.
  3. Priorizar los desperdicios. Iniciando con los que son “fáciles de remover” y de “alto impacto” y finalizando con aquellos que son “difíciles de remover” y de “bajo impacto”.
  4. Agregar la eliminación del desperdicio en el backlog.

Cuadrante de clasificación de desperdicios

Conclusiones

  • Se debe considerar un enfoque integral del ciclo de vida de desarrollo de software para identificar los desperdicios.
  • Podemos recurrir a algunos de los siguientes enfoques para reducir los desperdicios: prevención, mejora incremental y la reducción focalizada.
  • Lograr la eliminación de los desperdicios contribuye en mejorar la productividad de los equipos de desarrollo.