Si en vez de leer prefieres escuchar, dale al play.
En el mundo del desarrollo de software, el Pensamiento Lean - Lean Software Development - propone identificar y eliminar de manera sistemática los desperdicios que se generan cuando estamos creando o evolucionando un servicio. Fran Ávila, Agile Coach y Engineering Manager, ofreció un workshop en el que expuso las bases de esta filosofía y ofreció claves para implementarla.
Según expuso Ávila, hay 3 fases que marcan el camino de la metodología Lean:
La primera fase comprende de 1948 a 1975 con Taiichi Ohno, jefe de ingeniería de Toyota, quien busca transformar y optimizar los procesos de producción, logística y venta de coches. Durante 30 años desarrolla el Production System, que le permitió a la empresa incrementar exponencialmente sus ventas. Este sistema se basa en 3 pilares:
El Toyota Production System superó a los estadounidenses en el mundo de la fabricación de automóviles y abrió una serie de investigaciones sobre procedimientos. Estos estudios terminaron materializándose en el libro Lean Thinking de James P. Womack & Daniel T. Jones publicado en 1996. Se definió el concepto de Lean como una manera de producción que permite aportar valor generando menos desperdicios:
Una forma de pensar sobre las distintas actividades para generar valor y los procesos que se generan de manera inadvertida pero que hacen que ese proceso funcione cada vez peor.
Valor: creado por el productor, pero definido por el consumidor. Esto permite poner al consumidor en el centro y buscar entender cuáles son esas necesidades.
Cadena de valor: cómo se produce el valor, desde que alguien pide algo hasta que lo recibe, todo lo que pasa en el medio. Entender la cadena de valor hace que veamos donde están las ineficiencias e intentar optimizarlas.
Flujo (flow): aportar valor de manera continua, en vez de fabricar las cosas por lote buscar que el proceso sea continuo.
Tirar (pull): trabajar por demanda. Está asociado a limitar el trabajo en proceso, en vez de generar mucho y luego pasarlo a otra fase, la generación se produce porque alguien ha iniciado esa necesidad.
Perfección: eliminar los desperdicios. Intentando quitar todas la partes que no añaden nada al proceso. Tenemos que odiar a Tim Woods, es decir a estas ineficiencias que generan desperdicios: Transporte, Inventario, Movimiento, Waiting - Esperas, Over processing, Over production, Defectos, Skills - habilidades no usadas al máximo.
El movimiento Lean nace en el mundo de la producción de bienes físicos, pero luego se lo ha aplicado a distintos sectores. Ávila nos presentó a Mary y Tom Poppendieck como los autores del libro Lean Software Development, quienes cogieron el pensamiento Lean y lo aplicaron dentro de la industria del desarrollo de software. A continuación, explicó cada uno de los principios del Lean Software Development a través de ejemplos y consejos.
Hacer que las cosas funcionen. Uno de los principales desperdicios es el trabajo parcialmente terminado, porque lo único que produce valor es lo que está finalizado. Para contrarrestar esta ineficacia se puede, por ejemplo, trabajar por ramas que permitan integrar continuamente de una manera funcional. Otras actividades que generan desperdicio son la creación de funcionalidades extras y los cambios en requisitos no competitivos. Para evitarlos es importante orientarnos a objetivos y comprobar si lo que hemos creado o cambiado llega a las metas planteadas y ofrece valor al usuario final.
Asimismo, el re-aprendizaje o cuestionamiento constante y los traspasos de conocimientos generan desgaste. Se recomienda el registro o documentación de procesos y promover equipos cross funcionales que expandan el conocimiento de manera natural a través de la práctica. Los cambios de tareas, retrasos y dependencias entre equipos también generan cuellos de botellas y aumentan el tiempo de producción. Para ello, se aconseja crear equipos verticales que sean capaces de generar valor de inicio a fin.
Por último, cuando algo no funciona como se espera se produce un defecto y genera desperdicio al tener que volver a revisar el proceso y modificarlo. Para ello se pueden hacer test automáticos que te permita comprobar el funcionamiento durante la creación.
Poner la calidad en el centro de la generación de producto. Si encuentras errores de manera rutinaria, tu error está en el proceso y tienes que cambiar la forma en la que haces las cosas. Para impulsar este cambio puedes prevenir errores antes de encontrarlos por medio de Agile testing o mover el QA hacia la izquierda. También, acelerar los ciclos de feedback o tener especificaciones ejecutables, por ejemplo, por medio de pair programming y TDD, ayuda a reforzar la calidad del producto final.
Otra práctica que contribuye a mantener la calidad es escribir código legible y mantenible: clean code. Buscar siempre la simplicidad y no hacer sobre ingeniería de cosas que no vas a necesitar. Para ello es clave entender cuál es el problema que tratamos de resolver y asumir que la calidad es responsabilidad de todo el equipo: PO, QA y Devs. Las reglas y los estándares de calidad ayudan a que todo el equipo esté en la misma página y alineado a un objetivo común. Cuanto más explícitas sean estás reglas más rápido va a ser el proceso de encaminar a un nuevo integrante del equipo.
Por último, paga lo antes posible la deuda técnica, esas decisiones que no son las mejores pero que a veces necesitas tomar para resolver una eventualidad. Cuanto más tardes en pagarla más va a afectar a tu proyecto.
Aprender y pasar el conocimiento al resto. Planear es necesario, aprender es esencial. Utiliza métodos científicos que te permitan conocer si el producto que estás desarrollando realmente funciona. Puedes plantear una hipótesis, experimentar, validar su funcionamiento y hacer un spike. El feedback continuo es imprescindible y puede provenir de diferentes fuentes como de una comunidad beta, despliegues canary o A/B testing.
Crea standars, mejores prácticas y plantillas, que ayuden a hacer las cosas de forma más óptima. Pero también cuestiónalos y actualízalos según las distintas situaciones específicas. Para hacer el traspaso de conocimiento más digerible se puede cambiar el formato de documentación, por ejemplo, de escrito a multimedia como videos explicativos.
Intenta no tomar una decisión que te comprometa hasta que no sea necesario hacerlo. Elimina la idea de tener especificaciones completas al inicio porque no tienes toda la información. Cuando aplazas algo hasta el final, último momento responsable, te permites adquirir conocimientos durante ese tiempo y tomar una decisión con el mayor contexto posible. Para llegar a este punto debes considerar todas las opciones posibles e intentar tener el menor número de dependencias, por ejemplo, mediante contratos o abstracciones mínimas que te dan la posibilidad de cambiar distintas cosas.
Cuanto más rápido entregues, más información tendrás, gracias al feedback que recibes. La entrega rápida con alta calidad y a bajo coste es posible al largo plazo. La intención final es que toda la inversión que haces te permita entregar de manera más rápida y con mayor calidad.
Para medir el tiempo de tus entregas, Ávila recomendó el libro Accelerate que habla de 4 métricas vitales DORA: Deployment frequency, Lead time for changes, Mean Time to Recovery, Change Failure Rate. Con qué frecuencia haces los despliegues, cuál es el tiempo desde que quieres cambiar algo hasta que los cambias, cuál es el tiempo de recuperación si algo va mal y cómo de frecuente falla el sistema en su funcionamiento.
Otra forma de optimizar tus entregas es limitar el trabajo en proceso. Contar con gente T, personas con más de una especialización, que son capaces de hacer diferentes tareas y aportan flexibilidad al moverse por distintas fases del proceso y evitar que se generen bloqueos.
Trabajar en equipo, tener un objetivo y hacer que las personas estén comprometidas con el grupo es la mayor ventaja competitiva que puede tener una empresa. Para ello, es importante generar un entorno de confianza y seguridad, donde las equivocaciones no sean motivo de vergüenza y se promueva el feedback constructivo. También, tener autonomía es clave, porque el mejor sitio para tomar las decisiones es donde está la información. Por supuesto, hay decisiones que deben tomarse de manera centralizada ya que tienen un impacto mayor, pero las respuestas descentralizadas son útiles cuando se necesita dar una solución rápida en un área especifica.
El respeto hacia la gente también pasa por el reconocimiento del trabajo bien hecho o de una acción que promueve un comportamiento o valor que representa a la empresa. Asimismo, generar equipo con acuerdos y símbolos de identidad promueven el sentimiento de pertenencia y la satisfacción personal.
En definitiva, se busca generar cultura, comportamientos y valores que identifiquen a un grupo y a cada una de las personas que lo compone. La cultura es lo que haces cuando nadie te mira.
Combinar las oportunidades de negocio con las mejores tecnologías. Para ello, tenemos que tener una visión del flujo de valor completo, no solo el valor individual de ciertas áreas, sino como un todo. Hay que entender que el producto es completo. Software es una parte del producto pero también el servicio que se proporciona, no haces software únicamente sino que resuelves problemas de un cliente a través de software. Los problemas son globales no solo de la herramienta que se construye.
El pensamiento sistémico es vital, entender todos los componentes que hay dentro de un sistema y cómo se relacionan entre unos y otros. Eliminar los silos de pensamiento, cuanto más trabajemos de manera multidisciplinar y con distintos departamentos más valor se genera y se entiende el todo. Estas acciones deben estar orientadas a datos que nos sirva para tomar decisiones que prioricen la totalidad, como métricas, NPS, KPI's, etc.
Para concluir, Ávila resumió los tres aspectos necesarios que se deben tener en cualquier proyecto de desarrollo de software.
Observar y vigilar. Continuamente tenemos que pensar en cómo se mejora el sistema y cuestionarnos si lo que estamos haciendo es lo correcto.
Experimentar. Plantear una hipótesis, probar cómo podemos evolucionar para conseguir los mejores resultados.
Entrenarse y prepararse. Cuanto más preparados estemos y nos anticipemos a lo que va a ocurrir, más rápido podremos reaccionar.
Si te apetece puedes echar un vistazo a los slides de la presentación y hacer tus comentarios en ellas. Nos encantará leer tu feedback.
Revisa también nuestra sesión relacionada sobre desarrollo iterativo e incremental:
Si necesitas resolver problemas o enfrentas desafíos para mejorar el crecimiento de tu organización, es un buen momento para poner en marcha un plan..
Hoy vamos a sumergirnos en un tema crucial para entender cómo dar vida a proyectos exitosos: el Discovery. ¿Alguna vez te has preguntado qué implica..
En Codurance, el discovery de un producto - es decir, el proceso de entender las necesidades de los usuarios y validar tus hipótesis antes de..
Suscríbete a nuestra newsletter para que podamos hacerte llegar recomendaciones de expertos y casos prácticos inspiradores
