Lean Software Development: Libera tus proyectos

En los seminarios sobre métodos ágiles que realizo, típicamente pregunto lo siguiente a la audiencia: “Levante la mano por favor, aquella persona a la cual un diagrama de Gantt le haya sido la diferencia para sacar adelante un proyecto, o que para darle mantenimiento al software de alguien más haya utilizado documentación separada al mismo código, o tal vez aquel líder de proyecto que le haya funcionado asignar y controlar el avance de microtareas por cada miembro del equipo, para que así se comprometan más con una fecha de entrega.

Sorprendentemente (o no tanto), hasta la fecha nadie ha levantado la mano. Si todas estas prácticas que son la quinta esencia de la administración de proyectos, y para las cuáles invertimos miles de pesos en herramientas y cursos no funcionan, entonces ¿por qué lo seguimos haciendo?

Al parecer, pensamos que cuando algo no sale bien 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, pero en realidad lo que necesitamos es tan solo un conjunto sólido de principios y sentido común.

¿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, gratis y simplemente funciona. LSD fue desarrollado por Mary y Tom Poppendieck a partir de experiencias en 3M y Toyota, y se basa en aplicar al desarrollo de software los principios de “lean” que han hecho tan exitosas a estas empresas. Se le considera parte de los métodos ágiles, pero desde mi punto de vista está por encima de ellos, ya que LSD nos obliga a pensar, cuestionarnos y encontrar nuestras propias respuestas.
LSD se basa en los siguientes 7 principios:

1. Eliminar el despilfarro. Es decir, evitar todo lo 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. En esta categoría entra funcionalidad adicional a la que pidió el usuario, o especificación de requerimientos demasiado detallada en etapas tempranas del ciclo de vida. Aprendamos a ver éstas cosas como un despilfarro.
2. Ampliar el aprendizaje. Debemos aceptar que nunca se sabrá exactamente lo que se tiene que construir al principio del proyecto. Así 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 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. Si no lo hacemos en la vida real, entonces ¿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 funcionalidad para facturar lo antes posible, aunque no se haya terminado el resto del sistema. Empresas como Google o Yahoo entienden esto y lo aplican en sus desarrollos. 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 autodirigirse. Si, cometerán errores. Pero si liberan rápido y tienen iteraciones cortas, entonces sus errores no nos costarán caro, y sobre todo se ampliará el aprendizaje. Si no pueden resolverlos por ellos mismos, entonces debemos evaluar 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. No hay una inspección o control de calidad separada de la producción. Nuestros equipos nunca podrán alcanzar madurez, en un esquema donde el responsable de la calidad sea otro grupo separado del de desarrollo.
7. Pensar en el todo. “O todos coludos, o todos rabones” decían nuestros abuelos. Al parecer, antes se entendía mucho 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 y gangsters. En un equipo todos ganan y todos pierden, así que olvidémonos de las mediciones de desempeño individuales. Lo único que esto provoca es que los que salgan bien se busquen un trabajo donde les paguen más, y los que no salgan tan bien, harán lo mismo. Creemos equipos que compartan logros y fracasos y reduciremos la rotación 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 práctica. Finalmente, les recomiendo que busquen en Internet a Mary Poppiendick y agradecerán 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.