jueves, 21 de febrero de 2013

¿Restricciones en el demanda TI, de costes, de presupuesto? Tal vez te interese el pensamiento Lean

Lean Software Development es la adaptación al mundo del software del Sistema de Producción de Toyota (TPS) principal culpable de que Toyota pasara a ser el mayor fabricante mundial de automóviles e igualmente el motivo por el que todos asociamos a la marca con la Calidad.

Si ya has leído otras fuentes sobre Lean aquí no vas a encontrar nada nuevo, espero que este sea el primero de una serie de post desde nuestra experiencia y pretende dar una breve introducción de sus principios.

Lean Software Develompent no es una metodología, ni método, ni proceso de desarrollo sino que se trata de una serie de principios que debes adaptar a tu propio proceso con el objetivo final de mejorarlo. Por otro lado existen diferentes escuelas de pensamiento sobre Lean que se centran en aspectos distintos, para unos, por ejemplo, lo importante es la reducción del desperdicio (waste) mientras que otros se centran más en el flujo de trabajo. En este post nos centraremos en resumir los principios descritos por Mary y Tom Poppendeick.

PRIMER PRINCIPIO: Eliminar el desperdicio

Definición de desperdicio desde la perspectiva Lean: Todo lo que no aporta valor al usuario. Esto implica tener muy claro qué es valor... monográfico para un futuro post...

En fabricación uno de los mayores desperdicios es el inventario puesto que se debe almacenar, asegurar, mover, se desfasa… en este caso (y sin que sirva de precedente) la propiedad de intangibilidad del software juega a nuestro favor, pero me temo que existe un equivalente: el trabajo parcialmente hecho.

Kanban, por ejemplo, en su fase inicial aconseja la generación de estos almacenes (buffers) como mal menor para mejorar la cadencia del flujo de trabajo, pero una vez conseguido esto, potencia descubrir los cuellos de botella, solucionarlos y minimizar su uso. De hecho, el objetivo final es eliminarlos por completo al igual que hicieron en Toyota apoyándose en el Just In Time (JIT).

Otro de los grandes desperdicios de nuestra industria es la funcionalidad extra que no requería el usuario y finalmente no se utiliza. Sobre esto ya dejé una referencia sobre un grupo de trabajo recientemente creado en Cómo construir el producto que "realmente" esperan.

SEGUNDO PRINCIPIO: Desarrollar con Calidad

Este principio aconseja construir con calidad y descubrir los errores en ciclos tempranos: test unitarios, test de integración, test de sistemas… automatizados.

Evitar mantener vivos los errores apuntados en el sistema de seguimiento de tareas. Obviamente es importante identificar y realizar el seguimiento de los errores, pero en el enfoque Lean un error detiene la cadena de producción para solucionarlo. Un error apuntado en el sistema de seguimiento de tareas es trabajo parcialmente hecho... lo que va en contra del primer principio.

TERCER PRINCIPIO: Crear conocimiento
El proceso de desarrollo del software se acerca al desarrollo de productos (segunda derivada del TPS) y ambos tienen en común que son procesos basados en el conocimiento. Lean aconseja amplificar este conocimiento desde dos dimensiones:
  • Es importante aprender sobre el producto en sí. En esto nos ayuda el desarrollo iterativo potenciando una alta realimentación. 
  • Igualmente importante es aprender sobre el propio proceso. Lean asigna la responsabilidad de la mejora del proceso al equipo de trabajo (quien mejor conoce la forma de trabajar es quien hace el trabajo), justificando la dedicación de parte del tiempo productivo en la mejora del proceso. 

CUARTO PRINCIPIO: Aplazar las decisiones


Posponer las decisiones irreversibles hasta el último momento responsable, esto es, justo antes de que la decisión sea demasiado tarde.

También muy relacionado con el desarrollo de producto lo que facilita su aplicación al software. Si Toyota lo aplica al diseño de coches… en el software no debería ser más complejo. No implica no tomar decisiones, sino identificar aquellas que son irreversibles o costosamente reversibles y tomar la decisión la más tarde posible.

Por otra parte se potencia diseñar los sistemas lo suficientemente flexibles. Pero ojo, no todos las partes de nuestros sistemas necesitan el mismo grado de flexibilidad… no olvidemos que la flexibilidad no es gratis por lo que se debe aplicar este principio con sentido común y en muchos casos basándonos en la experiencia.

QUINTO PRINCIPIO: Entregar con rapidez

Los requisitos cambian, por lo que necesitamos desarrollar el software tan rápido como nos sea posible para que los usuarios/clientes no tengan tiempo a cambiarlos.

Bien, de acuerdo… aún así los requisitos cambian… pero si entregamos el producto lo antes posible y obtenemos una rápida realimentación (tercer principio) estaremos en una mejor situación para que los cambios se corrijan sobre el diseño actual en lugar de sobre el código escrito dentro de unos meses: eliminamos desperdicio (primer principio).

SEXTO PRINCIPIO: Respetar a las personas

En el aspecto de personal TPS se centra en los siguientes aspectos:
  • Liderazgo emprendedor. Una organización que respeta a sus personas desarrolla buenos líderes y se asegura de que los equipos tienen el tipo de liderazgo que fomenta el compromiso motivando a su gente en crear productos de calidad. 
  • Personal técnico experto. Una organización Lean debe desarrollar y nutrir experiencia técnica en el área/tecnología en que trabaja. Se me vienen a la cabeza diferentes empresas por lo bien o mal que aplican este principio con su personal...
  • Responsabilidad en la planificación y el control. En lugar de decirle a la gente qué tiene que hacer y cómo ha de hacerlo se promueve la auto-organización que permita la consecución de unos razonables objetivos. Potenciar la flexibilidad necesaria para que la gente solucione por sí mismos los problemas…lo fácil es decirlo, verdad? A nosotros nos ha llevado 6 meses de esfuerzo apoyados en el uso de Kanban que personalmente creo que es un facilitador estupendo para este y otros principios Lean.
SÉPTIMO PRINCIPIO: Optimizar el conjunto

Cuando se piensa en la optimización desde una perspectiva Lean se piensa en la optimización del conjunto de la cadena de valor, traspasando la fronteras internas por las que dicha cadena atraviesa.

Probablemente este principio, junto con el anterior, sean los de más difícil aplicación sin el apoyo de la alta dirección. Hay que tener en cuenta que Lean sobrepasa los límites de un equipo de desarrollo por lo que determinados principios serán de difícil aplicación sin el adecuado compromiso de la jerarquía superior...

Y hasta aquí una primera explicación muy, muy resumida de los siete principios de Lean Software Development. No existe una guía de aplicación de los principios, pero en las referencias citadas abajo encontrarás una serie de prácticas y consejos que puedes utilizar para incorporarlos a tu propio proceso.

Reflexión

Personalmente creo que en momentos como el actual te puede llegar a interesar el pensamiento Lean porque, probablemente, tu organización, departamento IT o empresa esté sufriendo las restricciones de la severa crisis que atravesamos y todo lo anteriormente expuesto fue diseñado en una situación igualmente de enormes restricciones. Ten en cuenta que TPS se crea en Japón, en plana posguerra y en una empresa que no disponía de los recursos de las grandes compañías automovilísticas del momento (americanas).

Por otra parte, la demanda japonesa era significativamente menor a la que disfrutaban los colosos americanos, por lo que, la única forma de sobrevivir en esa situación era reinventar las reglas del juego y la forma de hacer las cosas. Aunque a Toyota le fue bien con la aplicación de estos principios no fue hasta la crisis del 74, debido a una importante contracción de la demanda mundial, que otras empresas (principalmente japonesas) empezaran a replicar el modelo, de nuevo bajo fuertes restricciones.

De ahí el título del post ¿Restricciones en la demanda TI, de costes, de presupuesto? Tal vez te interese el pensamiento Lean. En mi caso este ha sido el motivo principal que me ha llevado a optimizar y mejorar la forma que tenemos de hacer las cosas, años atrás no existían estas restricciones sino que la situación era la contraria, recordemos que la demanda era tan grande que nuestro problema era encontrar profesionales en el mercado que nos permitieran seguir produciendo... Con la situación a la inversa (mantener la producción aun perdiendo personal) he acabado profundizando y guiando a mi equipo de desarrollo a través de Lean y Kanban (de nuestras experiencias con Kanban escribiré en breve).

Referencias

Mary y Tom Poppendieck, Lean Software Development - An Agile Toolkit, Addison Wesely, 2003.
Mary y Tom Poppendieck, Implementing Lean Software Development, Addison Wesely, 2006.



No hay comentarios:

Publicar un comentario