Los principios del "Lean software development"

Hace poco me suscribí al blog de Sandy Kemsley el cual me interesa porque escribe buenos artículos relacionados al tema BPM entre otras cosas.

Estos últimos días ha estado participando de la "Gartner BPM Summit in Orlando" y me ha llamado la atención el término "Lean IT" y no pude con mi curiosidad y me fui a la Wikipedia a ver de que trata este tema. El artículo en inglés lo pueden encontrar acá, a continuación va un resumen/traducción de lo que entendí del tema.

Básicamente trasladaron los principios y prácticas de lo que se conoce como lean manufacturing al dominio del desarrollo de software.

Se puede resumir en siete principios:

• Eliminar la basura: es decir, eliminar funcionalidades y código que no es necesario, requerimientos que no son claros, burocracia, la comunicación interna que detectemos como lenta.
• Amplificar el aprendizaje: cuanto antes podamos presentar un prototipo de lo que estamos desarrollando a nuestros clientes más rápido podremos enseñarle con algo concreto cual será el resultado final que obtendrá con el sistema y más rápido podremos ajustar el mismo en base al feedback que nos den. O sea, cuanto mas cortos sean los ciclos de desarrollo, mas feedback podremos obtener y mejor posicionados estaremos para hacer ajustes para la siguiente iteración.
• Decidir lo más tarde posible: esta ligado al tema de que si estamos en un proceso iterativo de desarrollo hay ciertas decisiones que podemos tomarlas cuando realmente tengamos algo tangible para discutir con los usuarios, es decir, acá esta la pantalla y esta es la funcionalidad este bien o mal en ese momento podemos tomar mejores decisiones y no basarnos en supuestos o asumir cosas que muchas veces es lo que hacemos como desarrolladores de software.
• Entrega lo más rápido posible: la velocidad en la entrega nos asegura que estamos dando lo que el cliente necesita hoy y nos posiciona muy bien para la próxima iteración del sistema. Esto no quiere decir que le demos un producto defectuoso sino que debemos concentrarnos en resolverle el problema que el cliente realmente quiere y no distraernos en otros aspectos menos importantes.
• Empower the team: (no encontré una traducción que me gustara a esta frase y creo que se entiende el concepto) el rol del gerente ha cambiado, la idea es que no le tenga que decir a los desarrolladores lo que tienen que hacer sino que cada integrante del equipo sea capaz de determinar cuales son los caminos a seguir. El gerente tiene que ser un líder que sepa escuchar a su equipo, que guíe el barco y ofrezca ayuda en las situaciones complicadas.
• Construir integralmente: el cliente necesita ver el sistema en todo su conjunto, como es entregado, desarrollado, accedido, que tan fácil es de usar y como le resuelve los problemas. Debe haber comunicación de ida y vuelta en cada instancia y asegurarnos que la suma de las partes, es decir cada componente del sistema cuando son integrados funcionan correctamente y no por eso perdemos flexibilidad y eficiencia en el proceso de construirlo.
• Ver el todo: “Think big, act small, fail fast; learn rapidly” es importante que todos los involucrados entiendan estos principios, en definitiva se trata de un trabajo en equipo que implica personas de distintos perfiles y lo que debemos lograr es encontrar la manera de que todos se relacionen de la mejor forma para llevar adelante un proyecto.

Sin duda que estos conceptos están relacionados con lo que se conoce como Agile development software, repasando estos principios me doy cuenta de que es lo que intentamos hacer en el día a día cuando usamos GeneXus para desarrollar nuestros productos y donde el desarrollo incremental que nos permite GeneXus se adapta muy bien a estos principios.