mapa con brujulaLa cosa más valiosa que puede gastar un hombre es el tiempo - Theophrastus (372 AC - 287 AC)

Lean es el nombre del método que usa Toyota para producir y desarrollar automóviles. Como desarrolladores de software no hacemos ninguna de esas dos cosas, así que ¿por qué nos debería interesar? La razón es simple: los principios básicos del método de Toyota son principios que en la realidad aplican en cualquier lugar. No son panaceas: los principios son universales, aunque puedan variar las prácticas específicas.

En esta primera parte de la guía vamos a ver los siente principios principios y las bases del pensamiento Lean.

Principios y prácticas

Los principios son verdades fundamentales que no cambian en el tiempo y el espacio, mientras que lsas prácticas son la aplicación de los principios para una situación particular. Las practicas pueden y deben cambiar cuando nos movemos de un ambiente al siguiente, y también cambian a medida que evoluciona la situación (Poppendieck y Poppendieck 2006).

Los principios que guian a Lean pueden aplicarse al software. Esto brinda una guía para aquellos que intentan desarrollar software de manera más efectiva. En esta serie de artículos, en vez de describir a Lean por si sólo, vamos a describir a Lean en términos de las prácticas Ágiles que sugiere. Hay mucho poder en este conocimiento: cuando un coach Ágil se encuentra en una situación donde no se puede seguir una práctica Ágil estándar, los principios Lean lo van a guiar hacia un mejor camino. Los principios de Lean también nos muestran cosas diferentes para mirar además de las prácticas Ágiles. Al volver algunas cosas explícitas se logra que los coach Ágiles tengan más variedad a su alcance para mejorar los métodos.

Los siete principios

Los siete principios del Desarrollo de Software Lean son:

  • Respetar a las personas
  • Eliminar el despercidio
  • Posponer el compromiso
  • Crear conocimiento
  • Entregar rápidamente
  • Construir la calidad desde adentro
  • Optimizar el total

Los elementos fundacionales previos

Antes, vamos a ver algunos principios fundamentales sobre los que se basa Lean, y que es bueno tener en claro desde el principio. Los más importantes son:

  • La mayoría de los errores son de naturaleza sistémica y por lo tanto se debe mejorar el sistema de desarrollo.
  • Se debe respetar a las personas para poder mejorar el sistema.
  • Se van a tomar mejores decisiones si se atiende la secuencia de tiempo del desarrollo, en vez de intentar maximizar la utilización de los recursos.

Estos elementos son fundacionales en el sentido de que todo el resto de las reflexiones aparecen luego. Los dos primeros puntos son las bases del trabajo de Edwards Deming. Deming es el hombre al cual los Japoneses les suelen atribuir la forma en la que producen bienes de alta calidad. El último punto, muchas veces descripto como "Justo-A-Tiempo" (Just-In-Time) fue agregado por Toyota y constituye un componente esencial de Lean.

Buscar la fuente de los errores en el sistema

Cuando algo sale mal, nuestra tendencia normal es buscar a quien culpar. Cuando un avión se estrella inmediatamente nos preguntamos - ¿fueron terroristas? (culparlos a ellos), ¿fue un error del piloto? (culparlo a él), ¿fue un error de la aerolínea? (culparlos a ellos), ¿fue un error del constructor? (culparlos a ellos), ¿fue un error de un componente del avión? (culpar a su constructor). No nos cuestionamos este enfoque; sabemos que alguien tiene que tener la culpa del accidente. Pero quizas es la situación en la cual se encontraba algunas de las personas que estamos culpando la que ocasionó el problema.

Veamos un ejemplo típico del desarrollo de software. Supongamos que se te asigna como responsable de escribir una característica para un sistema existente. Te dan la documentación de un analista del equipo que describe la funcionalidad que se tiene que escribir. Nunca se te da la oportunidad de hablar con alguien que realmente vaya a utilizar el software, sino que simplemente tenés que confiar en el documento. Escribis el código, se prueba, se le muestra la nueva característica al cliente, quien responde: "¡esto no es lo que pedí!".

¿A quién culparias? ¿Al cliente por no ser claro? ¿Al analista por escribir algo pobremente? ¿A vos mismo, por no poder seguir la especificación? ¿Al tester por no probarlo adecuadamente? Si reflexionamos un poquito vamos a descubrir que no hay ninguna persona a la quien culpar; en cambio, el problema tiene que ver con la forma en la que las personas están trabajando juntas. En otras palabras, el "sistema" actual hace que cada persona trabaje de manera separada en roles específicos. No existen mecanismos de feedback, y se propagan los errores. Un "sistema" Ágil haría que las personas trabajen como equipo. El cliente, analista, desarrollador y testear hablarian entre ellos y decidirían juntos sobre las necesidades del cliente y la mejor forma de satisfacerla. Este sistema es mejor. Aunque todavía es posible que surjan errores, la mayoría se elimina porque la comunicación es mejor.

Mejorar la comunicación es uno de los objetivos principales de Ágil; desafortunadamente, las prácticas Ágiles tienden a enfatizar la comunicación a un nivel local: entre el equipo, y entre el equipo y el cliente. Ágil ofrece un soporte pobre para mejorar la comunicación entre los equipos, arriba y abajo del flujo de valor, o a través de la compania. Las prácticas Lean ayudan con la comunicación en estos contextos más grandes, haciendo énfasis en la mejora continua del proceso, la optmización del total, y la entrega rápida. en Lean, las demoras de la comunicación causan demoras y desperdicios, en la forma de errores, y por lo tanto deben ser eliminados.

En los artículos siguientes de esta serie vamos a describir a Lean en términos de prácticas Ágiles, viendo como las diferentes prácticas apuntan a alguno de estos principios.

La guía completa

  1. Parte 1: los principios Lean (este artículo)
  2. Parte 2: Lean y Ágil
  3. Parte 3: Justo A Tiempo y conclusión
Traducido de An Agile developer's guide to Lean software development, de Shalloway, Beaver y Trott.

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw