Libera tus Proyectos con Lean Software Development

Actualmente, a mitad de los seminarios de Métodos Ágiles siempre hacemos los mismos cuestionamientos a la audiencia; “Levante la mano por favor, aquella persona a la cual una gráfica de Gantt le haya ayudado a sacar un proyecto adelante, aquel al cual la documentación le haya sido de ayuda vital en darle mantenimiento al software de alguien más, o tal vez, aquel líder de proyecto al cual el asignar y el controlar el avance de micro-tareas a cada miembro del equipo le haya funcionado para que la gente se comprometa más con una fecha de entrega”.

Y muy sorprendentemente para mi, hasta la fecha… nadie ha levantado la mano. Si todas éstas prácticas que en México son la quintaesencia de la Administración de Proyectos, para las cuáles invertimos miles y miles de pesos en herramientas y cursos de CMM, PMI, MoProSoft y cuántos acrónimos más, cual mantras nos esten vendiendo; no funcionan. Me pregunto entonces: ¿Por qué lo seguimos haciendo?.

Al parecer nuestras organizaciones y nosotros mismos pensamos que cuando algo no sale bien en nuestros equipos, lo que necesitamos es una capa más de “control”; un “proceso” más definido y detallado que “obligue” a los programadores, rebeldes, negligentes o apáticos, a tener “conformidad” con el proceso mágico que resolverá todos nuestros problemas. Anhelamos recetas secretas, en realidad, lo que necesitamos es tan solo un sólido conjunto de principios y sentido comun.

¿Como liberar a nuestros proyectos de balas de plata que no funcionan? Afortunados somos de tener Lean Software Development (LSD) a nuestro alcance; es libre, es gratis y simplemente funciona. Desarrollado con mucho éxito por los Poppiendick a partir de las sólidas experiencias de 3M y Toyota, LSD se basa en aplicar al desarrollo de software, los principios Lean que han hecho tan exitoso a Toyota y otras empresas. Se le considera parte de los Metodos Agiles, pero desde mi punto de vista estan por encima de ellos, LSD nos obliga a pensar, a cuestionarnos y a encontrar nuestras propias respuestas.

Los principios de LSD ameritan pasar meses y meses estudiándolos, reflexionando muy profundamente en ellos hasta que se conviertan en un acto reflejo en cada proyecto que emprendamos, pero afortunadamente no necesitamos hacer eso para obtener beneficios, tan solo tenemos que conocerles:

1. Eliminar el derroche: Es decir, evitar todo aquello que no agregue valor al proyecto. ¿Qué es aquello que no agrega valor al proyecto? Sencillo, todo lo que el cliente no pidió, pero en lo que invertimos tiempo, muchas veces facturado. Cosas como documentación sin sentido, tan solo por que lo dice el “libro”; construir el “framework”; esa “generalización del algoritmo”, por si piden cambios en el futuro; documentos de requerimientos perfectamente formateados, pero que sabemos que no es lo que construiremos al final por que siempre cambian. Eliminar todo eso es lo mejor que podemos hacer por nuestros proyectos y nuestros clientes. Aprendamos a ver estas cosas como un despilfarro.

2. Ampliar el Aprendizaje: Se trata de aceptar que nunca se sabrá exactamente lo que se tiene que construir al principio del proyecto, asi que cualquier tiempo que ocupemos tratando de hacer que el cliente nos “firme” el requerimiento rompe con el principio anterior. Ampliar el aprendizaje significa aceptar que el proceso de desarrollo es un proceso de aprendizaje, por lo tanto tenemos que repetirlo muchas veces para aprender. Solución. Muchas iteraciones cortas, tan cortas como haga sentido.

3. Retrasar los compromisos: Cada vez que aceptamos trabajar en un proyecto que tiene fecha de entrega pero no tiene requerimientos fijos es como si decidiéramos casarnos con alguien que conocimos hoy mismo. No lo hacemos en la vida real… verdad, ¿Por qué hacerlo en nuestro trabajo? Las iteraciones cortas ayudan a comprometernos con tan solo lo que podemos estimar bien.

4. Liberar Rápido: ¿Todos hacemos desarrollo por iteraciones verdad? Bueno tener iteraciones no es lo mismo que liberar rápido, liberar rápido significa que si te piden un sistema que facture, liberes “a producción” la factura lo antes posible, aunque no se haya terminado el resto del sistema. Algunas compañías como Google, Yahoo y en general todo el mundo lo ha entendio. Libera funcionalidades, no sistemas.

5. Facultar al equipo: ¿Qué es lo mejor que puede hacer un líder de proyecto? No estorbar. Tenemos que confiar en que las personas pueden ponerse de acuerdo, trabajar en equipo y en esencia auto-dirigirse. Si, cometerán errores, pero si liberan rápido, y tienen iteraciones cortas sus errores no nos costarán caro y sobre todo, se ampliará el aprendizaje. Si no pueden resolverlos por ellos mismos, entonces tal vez, debemos considerar seriamente si tenemos el equipo correcto. El trabajo en equipo ES el desarrollo de software.

6. Construir Integridad Intrínseca: En Japón, las mismas máquinas que producen las piezas para manufactura, prueban las piezas que producen, las miden y desechan las que no cumplen con los requisitos mínimos. Sin inspección, sin control de calidad separado de la producción. Sin una cultura donde el programador es el reponsable de la calidad y no un QA de otro departamento, nuestros equipos nunca podrán alcanzar madurez.

7. Pensar en el todo: “O todos coludos o todos rabones decían nuestros abuelos”. Al parecer antes se entendía mucho mejor de cómo hacer que una organización o una familia funcionara como un equipo. Abandonemos el modelo de programador estrella, lo único que producimos son Divas o Gangsters. En un equipo todos ganan y todos pierden, asi que olvidemonos de las mediciones de desempeño individuales, los que salgan bien se buscaran un trabajo donde les paguen mas y los que no salgan tan bien, haran lo mismo. Creemos equipos que compartan logros y fracasos y reduciremos la rotacion de personal.

Por que hablo con tanta seguridad, sencillo, yo mismo he pasado de creer en cosas que no funcionan y sufrir en mi trabajo, a experimentar los frutos de LSD en mi propia practica. Finalmente, busquen en internet a Mary Poppiendick y agradeceran como yo, todo el material gratuito que tiene a nuestra disposición para ayudarnos a empezar. Regalar sus libros a nuestros directores de sistemas probablemente serán los pesos mejor invertidos en mucho tiempo en nuestras carreras. Saludos y suerte!

 

Emilio Osorio García
@oemilio