¿Qué es Lean?
Lean es el nombre de un método de producción y desarrollo creado y aplicado por Toyota. Los principios que subyacen a los métodos de Toyota son principios que funcionan en todas partes porque son universales y se basan verdades que no cambian con el tiempo o el espacio. Las prácticas, es decir, la manera de aplicar estos principios en una determinada situación pueden y deben variar con el tiempo y según la situación evoluciona.
Lean nos dice que hay que centrarse en mejorar el sistema que usamos para producir centrándose en la optimización de procesos.
Un objetivo fundamental de Lean es crear un flujo rápido y flexible, es decir, es útil pensar en el proceso de desarrollo como un oleoducto y todo lo que ralentiza el flujo son residuos, deshechos. En desarrollo de software los residuos son los retrasos a los que estamos ya habituados, los errores que todos cometemos, los malentendidos, y las esperas y los retrasos por falta de recursos. Todo esto se traduce en el incremento del gasto pero al eliminar los obstáculos, estos residuos, mejoramos nuestro proceso.
El sistema en su conjunto es el origen de los errores. Lean nos dice que la mayoría de los errores son de naturaleza sistémica y por lo tanto el sistema debe ser mejorado. También nos dice que hay que respetar a los trabajadores con el fin de mejorar el sistema. y que hay que hacer las cosas justo en el momento que tengan que hacer, ni antes ni después. A esto se le llama llama comunmente "Just-In-Time" o "JIT" y Lean sugiere centrarse en reducir el tiempo de lanzamiento al mercado mediante la eliminación de las demoras en el proceso de desarrollo, utilizando métodos JIT.
Mejorar la comunicación es un objetivo fundamental de todas las metodologías ágiles, desafortunadamente las prácticas ágiles tienden a enfatizar la comunicación a nivel local, en el equipo, entre los equipos relacionados, y con el cliente. Agile ofrece pocas soluciones para mejorar la comunicación entre equipos no tan íntimamente relacionados y prácticamente ninguna para la comunicación de arriba a abajo o alto y ancho de toda la empresa.
Lean promueve la comunicación centrándose en la creación de valor de extremo a extremo, proporcionando un contexto común para todos los involucrados en el sistema de producción a lo alto y ancho de toda la organización. Esto obliga a los diferentes niveles de la organización a comunicarse con más frecuencia y con énfasis en la mejora continua de procesos, la optimización del conjunto y la entrega temprana y con frecuencia. El pensamiento Lean ayuda a eliminar los retrasos que causan los residuos.
Los principios Lean se pueden aplicar en muchos ámbitos. Todos los componentes de una empresa involucrados en el flujo de producir o añadir valor al producto o servicio que se ha creado, mejorado o mantenido se pueden beneficiar de estos principios. En el ámbito del desarrollo de software, Lean se puede convertir en una guía para aquellos que quieren desarrollar un software más eficiente y de alta calidad.
Lean proporciona una guía para los equipos de desarrollo ágiles. De hecho la metodología Scrum puede ser vista como una manifestación de los principios Lean. Entendimiento Lean puede ayudar en la implementación de Scrum pero también se puede aplicar en toda la empresa, ayudando así a aplicar Scrum en toda la empresa.
1.- Respetar a las personas
En desarrollo de software, respetar a la gente incluye la noción de que el equipo que hace el trabajo es el responsable del proceso que sigue. El proceso se convierte así en la aplicación de sus ideas de cómo desarrollar buen software. Cuando hay cambios el proceso cambia. Por lo tanto, el proceso es la base por la que el equipo que construye software lo hace de la mejor manera que saben, dentro de las limitaciones que se dan. Respetar al equipo es respetar su proceso.
2.- Eliminar residuos
La eliminación de residuos, desperdicios, basura o en inglés "waste" es la pauta principal para el practicante de Lean. Residuos es código más complejo de lo que debería. Residuos se producen cuando se crean defectos. Residuos es esfuerzo necesario para crear un producto sin valor añadido. Donde quiera que haya residuos, el practicante de Lean analizará el sistema para ver cómo eliminarlos ya que es probable que un error en el sistema vuelva a repetirse tarde o temprano.
3.- Aplazar el compromiso
Aplazar el compromiso significa tomar decisiones en el momento adecuado, en el ultimo momento en que se pueda responder. No se deben tomar decisiones demasiado pronto, cuando no se tiene toda la información que necesita, ni demasiado tarde, cuando puede suponer un gasto extra. Aplazar el compromiso es una manera proactiva de planificar el proceso y así no trabajar en cierta funcionalidad hasta que no se necesite. Esto evita tener que tomar decisiones ahora que podrían cambiar más adelante cuando tengamos más información. Este principio se puede utilizar para guiar el proceso de toma de requisitos, el análisis y el diseño e implementación.
Al establecer los requisitos debemos preguntarnos dónde debo gastar nuestro tiempo. ¿Tengo que concretar todos los requisitos con el cliente? Es evidente que no. Algunos requisitos son más importantes que otros. Los requisitos más importantes para la empresa suelen ser los que representan mayor valor para el cliente. Es un error demasiado común. Las metodologías ágiles profundizan en los requisitos que los clientes consideran más importantes, esta es una de las justificaciones básicas para el desarrollo iterativo e incremental, pero sólo centrarse en las características importantes para el cliente no debería ser suficiente para decidir en qué trabajar en cada momento, Debemos prestar atención a los riesgos de la arquitectura y tener en cuenta qué requisitos pueden causar problemas si se ignoran. Éstos son los que deben ser desarrollados primero y no otros.
Durante las fases de diseño e implementación los desarrolladores tienden a tomar decisiones cuando tienen que resolver un problema pero les alta información o no lo tienen claro. Un enfoque suele ser hacerlo lo más sencillo posible, sin prever necesidades futuras. El otro enfoque es anticiparse a lo que pueda suceder. Ambos enfoques tienen diferentes retos, para el primero el resultado en el código es que es difícil de cambiar porque no ha tenido en cuenta la variabilidad del código mientras lo escribía. Para el segundo el código es más complejo de lo necesario porque, como los desarrolladores tienen un tiempo difícil predecir, se anticipan a las creando clases, abstracciones o métodos que en realidad no son necesarios, pero que agregan complejidad.
Un enfoque alternativo a estos dos es el llamado "diseño emergente", Diseño Emergente en desarrollo de software consiste en:
• Utilizar los bien conocidos patrones de diseño para crear arquitecturas de aplicación resistentes y flexibles.
• Limitar la aplicación de patrones de diseño a aquellas características que estén completamente definidas
• Escribir test de aceptación y tests unitarios antes de escribir el código, ambos mejoran el proceso y crean una malla de protección frente a previsibles cambios.
Utilizar patrones de diseño hace el código fácil de cambiar y nos limitamos a implementar sólo lo que realmente se necesita en cada momento además de hacer el código menos complejo. Las pruebas automatizadas mejoran el diseño y lo hacen seguro frente a posibles cambios de requisitos. Estas características del diseño emergente permiten aplazar el compromiso de una implementación en particular hasta que se entienda lo que realmente se necesita hacer.
4.- Crear conocimiento
El software tiene un valor inherente escaso, su valor viene de que permite y optimiza la entrega de productos y servicios. Por lo tanto, es más útil pensar en el desarrollo de software como parte del proceso productivo, es decir, del conjunto de actividades encaminadas a crear productos que satisfagan las necesidades de los clientes mientras se avanza en los objetivos estratégicos de la empresa.
En las empresas de software, el software se desarrolla para ayudar en el trabajo y las necesidades de los clientes que lo utilizan. El software es un medio para un fin y el fin es satisfacer un cliente, ya sea directamente con un producto o indirectamente al ofrecerle un servicio a través o mediante nuestro software. Cuando se ve de esta manera, es claro que el papel del software en las organizaciones de TI es apoyar a productos y servicios de la empresa y debe considerarse como parte de desarrollo de productos.
1º Descubrir lo que el cliente necesita
2º Encontrar la manera de fabricarlo
3º Fabricar
En desarrollo de software, parece pasamos más tiempo hablando del tercer paso, sin embargo, los dos primeros pasos en realidad nos llevan la mayor parte del tiempo. Muchos al leer esto pensarán que no es así y yo les preguntaría cuanto tiempo tardarían en desarrollar un pequeño programa en el que estaban, supuestamente, trabajando y del que, supuestamente, acaban de perder todo el código fuente. La mayoría de los desarrolladores me dirían que gastarían entre un 20 y un 50 por ciento del tiempo que tardaron la primera vez porque en lo que verdaderamente gasta más tiempo un desarrollador es en "descubrir lo que el cliente necesita " y, sobretodo, en "encontrar la manera fabricarlo".
Crear conocimiento significa comprender el proceso que se utiliza para desarrollar software para satisfacer cierta necesidad del cliente. Mediante la comprensión de sus métodos, puede mejorar más fácilmente. Crear conocimiento significa documentar mínimamente y compartir diseños puntuales y también diseños globales y arquitectura.
También se crea conocimiento con una buena batería de tests unitarios con una nomenclatura concreta ya que una funcionalidad, un requerimiento del cliente debería traducirse en n tests unitarios que cubran al máximo el código implementado, el nombre de esos n tests debería ser suficiente para que cualquier compañero entienda cómo y por qué funciona y existe ese código.
5.- Entregar rápido y con frecuencia
Otra razón para hacer el desarrollo iterativo es entregar al cliente de manera rápida y continuada permitiendo una pronta inmersión en el mercado, una mayor credibilidad, una fuerte lealtad, etcétera. Aunque esto además supone una mayor rapidez a la hora de conseguir ingresos también supone un gasto previsible por la necesidad calculada de futuros desarrollos en sucesivas iteraciones.
Este principio, la "entrega rápida", debe entenderse también como una eliminación de retrasos. Las demoras representan residuos, son gastos innecesarios y se busca eliminarlos entregando más rápido y con más frecuencia. Los beneficios de la entrega rápida son claros pero también es esencial hacerlo de una manera sostenible.
6.- Producir con calidad
La calidad ha de estar estructurada, o lo que es lo mismo, el sistema debe basarse en la calidad a todos los niveles. A fin de mantener la velocidad de desarrollo los equipos deben desarrollar la calidad tanto en su proceso como en su código. La implantación de calidad en el proceso permite a un equipo mejorar mediante la eliminación de los residuos que él mismo crea. Una manera de conseguir calidad es definir, si es posible entre tester, desarrollador y cliente, pruebas de aceptación antes de escribir el código , esto implica una necesaria conversación en torno a los requisitos y ayuda a los desarrolladores a entender la funcionalidad que necesitan desarrollar.
También se puede conseguir calidad en el código mediante el uso de métodos descritos anteriormente para eliminar residuos. Muchos desarrolladores gastan gran parte de su tiempo investigando como resolver y resolviendo errores o bugs, sin pruebas automatizadas, los errores y los bugs son más frecuentes por culpa de un código de peor calidad además de que el código que es difícil de entender y eso contribuye a la pérdida de tiempo.
7.- Optimizar el conjunto
Hay que concentrarse en todo el proceso en su conjunto, desde el principio (concepto) hasta el final (consumo). Frecuentemente se busca, con toda lógica, optimizar cada paso, cada flujo de trabajo de cada departamento, el problema con la optimización de cada paso es que crea grandes "inventarios" entre los pasos y toda esa cantidad de información a menudo no es tarea fácil de digerir.
En el mundo del software, estos "inventarios" los representan tareas parcialmente realizadas. Entender el flujo como una sola pieza, como un todo, es decir, centrado en la construcción de un elemento en su totalidad, es un proceso mucho más eficiente que aquel que se concentra en la construcción de cada una de sus partes con mayor rapidez pues los "inventarios" ocultan errores en el proceso, o en la consecución de cada una de las partes o en el ensamblado. Pueden ocultar malentendidos con el cliente, diseños ineficientes, bugs, errores de integración, etcétera. Cuanto mayor sea el inventario o más partes haya más probable es que haya errores no detectados. Residuos. Gastos.
¿Por qué no muchas "equipos ágiles"obtienen los resultados esperados?
¿Por su falta de experiencia?
¿Por falta de atención durante el aprendizaje?
¿Se olvida la gestión del cambio?
¿No están siguiendo el libro?
¿Es porque no han contratado a un tutor o un profesor con experiencia?
¿Tal vez se olvidaron de las buenas prácticas y los patrones de diseño?
¿Es porque no se ha dominado la complejidad o el pensamiento sistémico?
¿Será que no se centran en la mejora continua?
Es posible que se deba a uno o varios de estos motivos pero muchos casos que he visto están relacionados con el diseño de la organización, con burocracia interna y con falta de comunicación interdepartamental.
Los equipos ágiles se centran en la entrega de valor a intervalos regulares. Cada dos o tres semanas trabajan en una lista de oportunidades de negocio expresadas en las historias de usuario o tareas y juntos trabajan a toda velocidad para analizar, desarrollar, probar y liberar todo el conjunto. Su enfoque es fuerte y simple y sus resultados suelen ser bastante bueno sin embargo dependen de personas fuera del equipo. Los gerentes, administrativos, ingenieros de sistemas, comerciales, etcétera, todos ellos individuos que forman parte de diferentes departamentos o entidades organizativas que aún perteneciendo a la misma empresa tienen otro enfoque y otra visión. Algunos se centran en mantener los sistemas actuales, otros en la gestión contable, otros en la captación de clientes, otros en minimizar el cambio, etcétera.
Si bien la principal preocupación del equipo de desarrollo es la liberación de elementos de valor a intervalos regulares ésto es sólo una preocupación menor para los demás integrantes del resto de departamentos y, aunque ésto no es ninguna sorpresa para nadie en realidad, tiene un grave impacto en la tasa de éxito de entrega del equipo de desarrollo.
- Las historias de usuario no se acaban dentro de la iteración, porque el product owner no ha tenido tiempo para validarlas.
- La siguiente versión software no sobrevivirá mucho tiempo porque el servicio de soporte técnico no tuvo tiempo para formarse y está creciendo el descontento entre los usuarios.
- Operaciones ha decidido aplazar la implantación de un nuevo desarrollo interno ya que se acaban de dar cuenta de que tenían un grave problema de almacenamiento.
¿Cómo podemos aprovechar los beneficios producidos por un cambio que abarca todo el proceso si el resto de la organización hace todo lo contrario? Las empresas deberían empezar a plantearse el coaching ágil a todos los niveles. Se ha visto que la formación en metodologías ágiles ha dado muy buenos resultados en equipos de desarrollo pero va siendo hora de ir formando en éste tipo de metodologías y formas de pensar a todos los niveles de la empresa.
Yo ya me considero evangelista de éstas metodologías, me encanta hablar de eficiencia y he conseguido que varias personas de distintos departamentos, amigos míos y trabajando en otras empresas, se quedaran encantados con éste enfoque organizativo. Si crees que sería interesante impartir un curso de formación enfocado a la eficiencia en tu empresa, no sólo en departamentos de desarrollo, tan sólo tienes que ponerte en contacto conmigo y lo adapto a tus necesidades.
