LEAN : Siete formas de desperdicio.

Devops tiene mucho en común con LEAN. Lean es una metodología que busca la mejora continua junto con la reducción de desperdicio. El desperdicio es un lastre que tienen todas las industrias, generan costes innecesarios e incrementan los tiempos de respuesta. Por definición, si el área de desarrollo logra disminuir el desperdicio ya esta siendo mas eficiente aun cuando no exista una utilidad neta, si pierdes menos entonces ganas mas. Por ejemplo, tener una media de bugs mensual menor probablemente no aporte ingresos netos a la empresa, pero definitivamente dará mas tiempo para atender a los nuevos requerimientos o reducir la carga de las áreas de soporte, lo que se refleja en aportar mas valor al cliente. Para que puedas eliminar el desperdicio en tu área de trabajo primero debes identificar los distintos tipos de desperdicio que existen, pero primero definamos que es desperdicio.

¿Que es desperdicio?.

Desperdicio es todo aquello que no aporta valor al cliente, si la actividad, proceso, estado o lo que sea puede ser removido o pasado por alto sin que haya una afectación o se quite valor al cliente, entonces lo que tienes en frente es desperdicio. Lean define siete tipos distintos de desperdicio,  te los menciono:

Defectos.

Cualquier cosa que no funciona como se espera (bugs) o que requiere de re trabajo. En orden de importancia esta es la forma mas común y a la vez mas costosa de generar desperdicio en el desarrollo de software. Desde el punto de vista de muchos programadores dedicar tiempo en prevenir errores es mas costoso que dejar que el cliente los descubra, por lo que se consideran  a las pruebas y/o QA un desperdicio, según ellos es imposible garantizar  que una pieza de software no tendrá errores, y es cierto. Claro, el que no puedas garantizar que una aplicación no lleva bugs tampoco implica que no debas dedicar tiempo en garantizar que no agregas defectos con cada cambio que empujas a producción. Las pruebas no garantizan que existan defectos, pero si permiten garantizar que el comportamiento anterior al cambio se mantiene. Sin mecanismos que permitan detectar los defectos en etapas de construcción del software solo una cosa es segura, aparecerán defectos en producción, lo que es igual a reducción del valor aportado al cliente.

Trabajo parcialmente completado.

Es importante definir que se considera trabajo hecho por parte del equipo de desarrollo, por ejemplo: algunos programadores de la empresa consideran que el trabajo esta hecho si ya hicieron commit en el repositorio, según ellos el cambio eventualmente se ira a producción. Bueno, si, ¿y las pruebas?, ¿ya se le notifico al cliente que el cambio esta hecho pero no se ha liberado?, ¿y si hay un regreso?. Sin una definición de hecho clara y cuantificable cualquier cosa puede terminar desplegada en producción (y ser devuelta). Lo importante es aportar valor, empujar cambios solo por quemar items en el backlog es un sin sentido. Las codificación de pruebas es indispensable para garantizar que las cosas están bien hechas y por lo tanto terminadas, aquí no aplica el: en mi maquina funcionaba o el ¿que raro?.

Características extra.

Siempre esta la tentación de aportar características no requeridas por parte del desarrollador, siempre es un tema polémico. Las posiciones a favor de las características extra abogan por solucionar problemas antes de que estos se presenten, mientras que las posiciones en contra argumentan la carga extra de soporte y trabajo. Si, esta muy cool tu característica pero alguien tendrá que mantenerla y darle soporte aun  cuando nadie la use.  Cualquier característica no requerida entra en la categoría de un prototipo, osea un código candidato a ser desechado y que debe tener cierto tipo de medición, es vital saber si la característica es usada activamente, en caso de que a nadie le importe eliminarla sin piedad.

¿Y si el cliente pide características extra?, bueno, los cliente tienden a pedir características innecesarias que quieren, mas no necesitan. Ninguna característica adicional es gratis, lo que pida el cliente se construye, esto sera a costa de agregar items al backlog o quitarlos, en el caso de que el tiempo sea limitado. Lo que jamas debes hacer es agregar funcionalidad de a gratis. El tiempo gastado en re trabajo eventualmente saldrá de tu bolsillo.

Handoffs.

Un handoff es cuando un trabajador se detiene porque requiere de un insumo que aun no ha sido completado por otra persona. Por ejemplo: necesitas una copia de unos objetos Sql de la base de datos del cliente pero estos no han sido proporcionados por este desde hace días. No puedes avanzar, aunque quieras. Esta es una forma de desperdicio un poco mas compleja de tratar porque tiene que ver con personas y su estilo de trabajo. Hay que notificar inmediatamente que el trabajo se detuvo, ser claros en lo que se necesita y dejar por sentado que hay desperdicio de horas. De ser posible trabajar con los implicados para poder desatascar el trabajo.

Task switching.

Lean no es una metodología para gente multitarea. Se parte del hecho que todos los miembros del equipo dedican sus esfuerzos a la tarea mas urgente e importante. La capacidad de concentración de cada persona es limitada, para poder ejecutar una tarea del mejor modo posible esta debe ser la única actividad que se este haciendo en el momento. Obvio, si necesitas cambiar  de tarea constantemente o atiendes muchas tareas al día tu capacidad de atención va a disminuir considerablemente. El coste de arrancar de nuevo con una tarea es importante si haces esto varias veces al día.

Atrasos.

Hay factores internos que pueden generar atrasos, pero también hay factores externos  que no pueden solucionarse mediante trabajo interno. Por ejemplo: el cliente no ha respondido una serie de dudas sobre algunas historias de usuario que el equipo de desarrollo formulo algunas semanas atrás. O también: aun no se han liberado los ambientes donde se ejecutara la aplicación. Mas allá de existir elementos que no están en control del equipo se  esta generando desperdicio,  ya que el equipo debe esperar por los insumos (handoff) o debe cambiar de tareas (task switching).

Procesos no necesarios.

Los procesos están hechos para facilitar el trabajo, no para impedirlo. Todo proceso es mejorable y optimizable, tampoco podemos pasar de un escenario super burocrático a la anarquía total. Supón que todo cambio en los objetos Sql de la empresa deben ser sujetos a revisión por una autoridad, esto tiene como propósito detectar scripts peligrosos o de baja calidad, en  principio no es un proceso malo. El problema radica en que el encargado de hacer la revisión no se da abasto con las peticiones, el problema no es el proceso, es la capacidad de atención. Aqui solo hay necesidad de optimizar. Ahora supongamos que adicional a esto se requiere una firma por cada petición del jefe área, y para cada despliegue otra firma. Bueno, si ya existe una autoridad encargada de dar el visto bueno, ¿porque debería existir otro punto de control adicional?, no hace mucho sentido. En este caso este proceso de aprobación sin razón aparente genera desperdicio de tiempo.

Conclusiones.

Los recursos de las empresas son limitados, la mejor ganancia no es ganar mas, sino gastar menos. Si mantienes un porcentaje de desperdicio bajo (asumiendo que llevas métricas), tienes un punto de apoyo para mejorar el flujo de trabajo. Cuantifica los bugs y el re trabajo junto con la media de items entregados en el backlog, en el caso de que tengas que dedicar mas tiempo a reparar que a construir, entonces estas generando bastante desperdicio. Tomate el tiempo de ver que se hace mal para revertir esa tendencia.

Autor imagen: Alan Cleaver