domingo, 20 de julio de 2008

Los siete Principios de Lean (o los siete Mitos de la Ingeniería de Software)

Lean Software Development es una filosofía para el desarrollo de software que surgió en la década de 1990, cuyos principios abrevan de las experiencias del TPDS (Toyota Product Development System), una filosofía que le sirvió a Toyota para desarrollar nuevos productos y que fue adaptada por Mary y Tom Poppendieck, que a su vez es una derivación de la metodología original de Toyota usada para manufactura y operaciones llamada TPS (Toyota Production System). A su vez, todas las filosofías de Toyota derivan del gurú y padre de la calidad William Eduards Deming. Hoy en día, Lean Software Development está teniendo nuevamente vigencia gracias a la comunidad de Software Ágil, que ha tomado bastante de estos principios.

El fin de este post es enunciar los siete principios fundamentales de Lean Software Development y, con ellos, siete grandes mitos de la Ingeniería de Software que la filosofía Lean y la comunidad de metodologías ágiles intentan derribar. El material que presentaré a continuación fue extraído de una clase de Administración y Control de Proyectos Informáticos II dictada por Juan Gabardini en junio de 2008 en la FIUBA.

Principio 1: Eliminar el Desperdicio

Lean habla constantemente de desperdicio, llamándolo de una forma muy particular: "muda". Lean reconoce siete tipos de muda:
  • Actividades humanas que absorben recursos pero no crean valor
  • Errores que requieren rectificación
  • Ítems de producción que nadie quiere y que se acumulan en el inventario
  • Pasos de procesamiento que nadie necesita
  • Movimiento de empleados y bienes de un lugar a otro sin propósito
  • Capacidad ociosa (gente que espera ociosa a que otra actividad anterior a la suya que no entregó a tiempo finalice)
  • Bienes y servicios que no responden a la necesidad del usuario
En software se considera como desperdicio a cualquier artefacto que no genere valor al cliente, que no genere beneficio al cliente. El stock es desperdicio; los requerimientos, el diseño y las listas de bugs también lo son. Lean va más lejos y afirma que cualquier lista de administración (de bugs, de TO-DO, de requerimientos) es desperdicio. Esta afirmación es fuerte, pero es cierta teóricamente hablando, ya que cualquiera de estas listas insume tiempo de administración y de priorización y repetidas repriorizaciones que en definitiva no aportan valor al cliente. Son waste.

MITO: La especificación temprana reduce el desperdicio.

Este mito es derribado usando como pretexto que el negocio puede cambiar durante el desarrollo del producto. Todo lo que se definió en forma temprana puede cambiar al mes o a la semana siguiente. La mitad de los requerimientos pueden dejar de ser prioritarios, dejar de aportar valor al cliente. Por eso los sprints de Scrum suelen ser de dos semanas a un mes, y no más largos.

En Lean, la funcionalidad no usada es considerada como la mayor fuente de desperdicio porque produce costo en toda la cadena de desarrollo y no genera valor. Hay una frase muy famosa en nuestro ámbito que dice: "el 80% de los usuarios usa el 20% de la funcionalidad". La funcionalidad no usada no sólo insume costos en el desarrollo del feature en sí, también es muda porque hace más grande el código, por ende se hace más complejo, más propenso a errores y todo esto implica mayor arquitectura, mantenimiento, refactoring, etc.

Principio 2: Construir con Calidad

¿Es bueno testear y encontrar defectos en un producto? Por supuesto es mejor que el equipo de desarrollo encuentre los defectos a que los encuentre el cliente. Pero la verdad es que mucho mejor sería que no los haya. ¿Por qué no construir bien desde la primera vez?

Siguiendo con la filosofía del TPS, Lean propone que cuando se encuentren defectos, hay que parar la línea de producción para corregir la causa raíz y que este defecto no vuelva a ocurrir. Se debe atacar los bugs en cuanto se detecten. Recuerden que una lista de bugs enorme insume mucho tiempo de priorización y administración; es desperdicio.

MITO: El trabajo del tester es encontrar defectos.

Un tester debe incorporar la calidad en el desarrollo lo antes posible. El tester debe ayudar a que cuando se produzca un problema se encuentren las causas raíces y se arreglen. Lean tiene una visión proactiva de la calidad. Medir la calidad al final es la peor forma de corregir problemas (por supuesto es mejor que no medirla). Calidad no es Testing. Testing es una forma de medir la Calidad.

¿Cómo se lleva esto a la práctica? El tester debe ayudar a que el programador haga buenas pruebas unitarias y debe armar las pruebas de aceptación correctamente, y en lo posible automatizar toda prueba para saber, de forma rápida y efectiva, que el producto cumple con los requerimientos del usuario en todo momento. El rol del tester pasaría a ser QA, pero no QA de Quality Assurance, QA de Quality Assistant. La forma que QA tiene ahora de asegurar la calidad no es testeando y reportando bugs, sino ayudando en todo el proceso de desarrollo. Ayudando también al Product Owner a expresar sus requerimientos de forma testeable, al diseñador para que haga una arquitectura y diseño testeables, etc.

Principio 3: Crear Conocimiento

Lean ve al desarrollo de un producto como una oportunidad única de aprendizaje y mejora. Una empresa que aprende, que crea conocimiento y que lo difunde entre todos sus equipos de trabajo, es una empresa evolutiva, abierta a la mejora continua y al crecimiento.

MITO: Las predicciones crean predictibilidad.

Esto significa que si yo estimo de una manera correcta y analizo el problema, entonces voy a tener una estimación que me va a ayudar a cumplir con las fechas propuestas. Mis predicciones de cómo va a ser el futuro aumentan la probabilidad de que ocurra lo que yo predije.

Dicho así parece obvio que no podemos modificar el futuro simplemente con decirlo. Hay que aceptar que el mundo es variable, que siempre hay cambios que no voy a poder incluir en mis predicciones. Crear conocimiento está más orientado a mejorar mi forma de trabajo que a predecir manteniendo mi forma de trabajo actual.

Cuando uno estima en un entorno ágil, nunca lo hace a largo plazo. Por eso los sprints de Scrum son tan cortos, porque cuanto más cercano es el futuro que intento predecir, menos probabilidad existe de equivocación. Es como si apuntara con una escopeta; si estoy demasiado lejos del blanco, cualquier mínima variación hacia donde apunto producirá un desvío brutal en la variación de la trayectoria.

Principio 4: Postergar el Compromiso

Este principio dice que hay que tomar las decisiones lo más tarde posible (ni más tarde, ni menos). Es el mismo concepto de ALAP en Critical Chain. De esta forma uno genera decisiones más comprometidas y siempre trata de buscar soluciones que sean reversibles. Tomar las decisiones lo más tarde posible implica más conocimiento del negocio, mayor certidumbre y por ende menor retrabajo.

MITO: Planificación es compromiso

La planificación implica contar con una serie de datos muy detallados en etapas muy tempranas del proyecto. El cono de incertidumbre en esto es implacable. Todas las partes involucradas tienen que entender que la planificación es un rango de probabilidades. Se puede achicar los rangos con iteraciones más chicas, pero definitivamente la predicción del futuro no significa compromiso, sino no seríamos informáticos sino futurólogos.

Como en el mundo laboral existen compromisos que hay que tomar, la comunidad ágil propone distintas formas de contrato a las convencionales. Por ejemplo, puede haber una cláusula que diga que si una entrega no agrega valor al cliente se cancela. Esto es bueno ya que a la hora de hacer el contrato ni una parte ni otra sabe a ciencia cierta qué puede dar valor dentro de unos meses. Otra forma de contrato ágil podría ser que si para el cliente el producto, en un momento dado, tiene suficiente calidad y funcionalidad para ser pasado a producción en forma definitiva y se decide cancelar el proyecto, cliente y proveedor se reparten la mitad del beneficio que queda.

Principio 5: Entregas Rápidas

Las entregas rápidas implican alta calidad, por ende bajos costos. Si las pruebas están automatizadas, los costos de setup van a ser menores, por ende se logrará reducir el costo de cada liberación, entregar más rápido y reducir el retrabajo. También es un concepto heredado de Toyota. En Toyota se trabaja JIT, sin stock. La demanda rige despóticamente sobre toda la línea de producción. Nada se construye de más. Cuando hay una orden de pedido, se construye sólo esa orden de la forma más rápida y efectiva posible y se entrega cuanto antes. Así fue como los japoneses de Toyota lograron hacer tambalear la posición de líder de mercado que hasta entonces tenían los americanos con Ford y sus entregas lentas y poco personalizadas.

MITO: El apuro causa desperdicio.

"Ágil es rápido, no apurado". El apuro sí causa desperdicio, la rapidez no. Si se trabaja rápido, menos y de forma efectiva, y rigurosamente día a día se hace refactoring y se mejora las condiciones de trabajo, las cosas se pueden hacer bien la primera vez.

Principio 6: Respetar a las Personas

Lean pone especial foco en el respeto a las personas. Las personas no son robots, ni engranajes, ni operarios bobos (tipo Chaplin en "Tiempos Modernos") que siguen las especificaciones escritas por un consultor al pie de la letra sin pensar. Se tiene absoluta confianza en el equipo de trabajo. Cuando hay un problema, no se culpa a la persona, sino al sistema que permitió a la persona cometer el error.

Para lograr entregas rápidas, mejora continua y confiar plenamente en las personas, se necesita equipos con buen skill, con alta experiencia técnica, que es uno de los requerimientos más criticados en los entornos ágiles. No puedo pedirle a un programador junior que recién está aprendiendo Java, que codifique rápido, bien y encima que se enfoque en las meta-tareas de generar conocimiento para la empresa, refactoring y mejora continua.

También es muy importante contar con líderes emprendedores, proactivos y verdaderos coach.

MITO: Existe la mejor manera de hacerlo.

Este mito asume que un consultor, por ejemplo, sabe más que las mismas personas que hacen su trabajo, y que debe entrenarlos para que sigan el estándar que él mismo definió. Viene de la vieja escuela que dice: "Ustedes tienen que hacer las cosas así", donde un jefe que estima y asigna tareas a las personas, genera compromiso obligado a sus empleados para que cumplan sus predicciones. "Yo, consultor especializado, te voy a decir a vos cómo es la mejor forma de hacer tu trabajo". Esto, en cualquier entorno ágil o de mejora continua, no existe.

Principio 7: Optimizar el Todo

Optimizar el conjunto. No caer en optimizaciones locales. Por ejemplo, no se puede optimizar el sector de ventas sin optimizar el sector de producción, o de entregas, porque de nada sirve vender para ayer algo que todavía no está hecho ni se puede hacer de una forma rápida. Otro ejemplo podría ser el de un equipo de Testing saturado. La solución más local sería incorporar más testers al equipo, pero esto podría no solucionar el problema, ya que la causa raíz podría provenir de otro equipo, de que desarrollo le está entregando funcionalidad demasiado tarde o Testing no cuenta con las herramientas necesarias para hacer su trabajo.

MITO: Optimizar por descomposición.

Este mito dice que siempre que divida venceré. Un criterio que los programadores conocemos muy bien. Pero esto no siempre es cierto para el mundo de las empresas. Por ejemplo, yo puedo dividir hasta el límite el sector de Compras y contratar al proveedor más óptimo para cada materia prima. Es muy probable que esto no funcione correctamente, ya que no es bueno tener tantos proveedores. Con cada tercerización se necesita una interface clara y trabajada, se necesita confianza, trato. El tiempo y los riesgos de contar con un proveedor, por más bueno que sea, se multiplica por la cantidad de proveedores que tenga. En Critical Chain cada vez que se depende de algún módulo de tercero, se agrega un buffer de tiempo, porque esta interdependencia entre empresas se considera un riesgo alto.