h1

Desarrollo de software sin desperdicios: Lean Software

03/27/2008

Wizbook [Icon By Buuf]  Libros: Software Engineering

El tipo de desperdicio más peligroso es aquél que no sabemos reconocer.

Shigeo Shingo, coautor del Sistema de Producción Toyota

Terminé de leer el libro Implementing Lean Software Development From Concept to Cash de Mary y Tom Poppendieck. En dicha lectura se describe el origen del término Lean Software Development, desde sus orígenes como parte del Toyota Production System, una filosofía de trabajo parecida a la Calidad Total y el Just-In-Time con el objetivo de disminuir los costos y aumentar los ingresos al reducir el desperdicio de tiempo y horas/hombre durante el proceso de manufactura.

Luego, siguiendo con la historia, comentan cómo apareció el término Lean Manufacturing, que es básicamente una adaptación del sistema de producción original a la idiosincrasia Estadounidense. Finalmente el Lean Software Development parte de éste como una fórmula para desarrollar software de forma rápida y eficiente. Por ello el libro y los capítulos que lo conforman dan muchas ideas que podemos englobar en un sólo concepto: desarrollo ágil de software.

Así entonces, en el libro nos describen los 7 principios de este tipo de desarrollo. Elaboro un poco en cada principio:

  1. Eliminar el desperdicio. Es decir, debemos apoyarnos en técnicas que nos ayuden a prevenir "trabajo parcialmente terminado", o lo que es lo mismo: documentación no implementada y código no sincronizado, sin probar, documentar o deployar.
  2. Construir calidad desde el principio. Esto significa, en palabras de Shingeo Shingo:
    …Si realmente buscas calidad, no inspecciones el problema después de que éste ha ocurrido: controla las condiciones para no permitir que ocurra dicho defecto en primer lugar. Si esto no es posible, se inspecciona el producto a lo largo de cada pequeño paso [de su desarrollo] para que los defectos sean localizados inmediatamente después de que ocurran. Cuando un defecto es encontrado, se detiene la línea [de producción], se encuentra su causa y se corrige inmediatamente.

  3. Crear conocimiento. O Mejor dicho: evitar el modelo de "Cascada" a como dé lugar. Esto implica que el diseño detallado debe elaborarse mientras vamos construyendo los entregables de nuestro producto. Aquí conviene seguir los siguientes tips para lograrlo:
    1. Un early release (demo, maqueta, prueba de concepto o versión funcional) tan pronto como sea posible para obtener retroalimentación por parte de los stakeholders.
    2. Daily builds y retroalimentación rápida por parte de las pruebas de integración.
    3. Un equipo o líder técnico con la experiencia e instintos necesarios para tomar buenas decisiones.
    4. Una arquitectura modular que soporte agregar nueva funcionalidad.

  4. Diferir el compromiso. O como bien se expresa en Software Estimation: Demystifying the Black Art: para estimar debemos saber distinguir entre una estimación y un compromiso. Por lo tanto: Estimación ≠ Compromiso
  5. Entregar rápidamente. Básicamente existen dos requisitos:
    1. Equipos con gente capaz de resolver problemas y cuyas decisiones sean apoyadas por management.
    2. Una metodología, herramientas y cultura de desarrollo ágil (es decir: XP o SCRUM, Eclipse o Netbeans y el uso de frameworks que nos ahorren la carga de desarrollo como Spring y Hibernate).

  6. Respetar a la gente. Aunque en el libro Productive Projects and Teams de Tom DeMarco vienen muchos ejemplos para no destruir la capacidad nata con la que cuentan los equipos de trabajo, me parece muy bueno el ejemplo que proporcionan en este libro (que a su vez fue tomado de una anécdota publicada en el blog de Joel Spolsky, ex-empleado de Microsoft) para darnos cuenta de la diferencia que puede hacer el mantra help me help you:
    Cuando Joel Spolski entró a trabajar en Microsoft, se dio a la tarea de desarrollar la estrategia del lenguaje de macros de Excel – que más tarde evolucionaría en Visual Basic for Applications. Pasó un tiempo aprendiendo lo que necesitarían los usuarios y se puso a desarrollar una especificación. Para su sorpresa, un grupo de arquitecturas aplicativas se dio cuenta lo que estaba haciendo y le solicitaron una junta de revisión. Joel pensó que le podrían dar algunos buenos consejos con respecto a su especificación, pero encontró que este grupito sabía incluso menos que él acerca de dichas macros – aún cuando contaban con cuatro PhDs y su jefe era amigo personal de Bill Gates – es decir, este individuo era el empleado número 6 de Microsoft.

    Aunque la idea que traían de las macros era muy vaga, el grupo pensó que era su trabajo determinar cómo debían implementarse. Tanto los jefes de Joel como su equipo de programadores lo respaldaban al 100% y le dejaron en claro que la decisión era suya. Sin embargo, el grupo de arquitecturas aplicativas no estaba contento con esto, y su jefe solicitó una junta de alto perfil para quejarse de cómo Joel estaba batiendo la estrategia de macros.

    Si Microsoft fuese una compañía ordinaria, podemos imaginarnos como hubiese desembocado este escenario: El grupo se sale con la suya y Joel ya sea se la come o se sale de Microsoft. Sin embargo, eso no es lo que pasó:

    Un día después de la junta, Pete Higgins (director general de Office – si, ese Office) platicó con Joel en la cafetería y se dio la siguiente conversación:

     Higgins: Y… ¿Cómo te va con el grupo de arquitecturas aplicativas? He escuchado que has tenido algunos problemas con ellos.

     Joel: Ah… Nada que no pueda manejar.

     Higgins: No se diga más: ya entiendo.

    Al siguiente día, Joel escuchó vía radiopasillo que el grupo había sido disuelto. Él estaba impresionado. Como él mismo comenta: "En Microsoft, si eres el programador trabajando en la estrategia de macros de Excel, e incluso si has estado en la compañía menos de seis meses, no importa: TU eres el Dios de la estrategia de macros de Excel, y nadie, incluso el empleado número 6, tiene permitido interponerse en tu camino. Punto."

  7. Optimizar el conjunto. Aquí la frase clave es: Metodología de desarrollo de software.

Después de describir de forma general estos principios, se detallan un poco cada uno de ellos, terminando con un roadmap de Lean Software y algo de bibliografía.

La Crítica

Aunque el libro es relativamente reciente (editado en Septiembre de 2006), los conceptos que se manejan no son nuevos; siendo honestos hasta pareciera una tesis de licenciatura: todo lo que describen proviene de terceros o blogs y sitios web disponibles públicamente. Adicionalmente, aunque me parecen buenos los tips que se manejan y algunas de las anécdotas que presentan me parecen de lo más chuscas, la mayoría de ellos vienen más bien del mundo de la ingeniería industrial y no del desarrollo de software y sus metodologías. De hecho, creo que este libro puedo englobarlo en el artículo Metodología de Desarrollo de Software que publiqué en este mismo blog. Si el objetivo es aprender algo más formal y no sólo tips, recomiendo las siguientes ligas que podemos llamar La Fuente:

• Manifesto for Agile Software Development.
• Extreme Programming: A gentle introduction.
• Sunsetting Version 1.1 of the CMMI Product Suite.

Todas ellas con las ideas de gente como Kent Beck (autor del Extreme Programming), Martin Fowler (creador de Spring y los términos Inyección de Dependencia y Refactoring) y el equipo de investigación y desarrollo del Software Engineering Institute.

Sin embargo si consideramos al libro como un Agile Software Development for Dummies me parece bastante bueno; sobre todo para gente no relacionada al desarrollo de software como, por ejemplo, ingenieros industriales que acaban de sacar su certificación como PMP y se tengan que lanzar al ruedo para ejecutar el delivery de algún proyecto de software.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: