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 está siendo más eficiente aun cuando no exista una utilidad neta, si pierdes menos entonces ganas más. Por ejemplo, tener una media de bugs mensual menor probablemente no aporte ingresos netos a la empresa, pero definitivamente dará más tiempo para atender a los nuevos requerimientos o reducir la carga de las áreas de soporte, lo que se refleja en aportar más 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.
¿Qué 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 más común y a la vez más costosa de generar desperdicio en el desarrollo de software. Desde el punto de vista de muchos programadores, dedicar tiempo en prevenir errores es más costoso que dejar que el cliente los descubra. Por lo que se consideran a las pruebas 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 está hecho si ya hicieron commit en el repositorio, según ellos el cambio eventualmente sé ira a producción. Bueno, si, ¿y las pruebas?, ¿ya se le notifico al cliente que el cambio está 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 relevante es aportar valor, empujar cambios únicamente 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 él: en mi máquina funcionaba o él ¿qué raro?.
Características extra.
Siempre está 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, o sea un código candidato a ser desechado y que debe tener cierto tipo de medición, es vital saber si la característica es empleada 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, más no necesitan. Ninguna característica adicional es gratis, lo que pida el cliente se construye, esto será a costa de agregar items al backlog o quitarlos, en el caso de que el tiempo sea limitado. Lo que jamás 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 aún 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 más 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 más 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 esté 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 relevante 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: aún no se han liberado los ambientes donde se ejecutara la aplicación. Más allá de existir elementos que no están en control del equipo, se está 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 comprobación no se da abasto con las peticiones, el problema no es el proceso, es la capacidad de atención. Aquí 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, ¿por qué 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 más, 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 más tiempo a reparar que a construir, entonces estás generando bastante desperdicio. Tomate el tiempo de ver que se hace mal para revertir esa tendencia.
Autor imagen: Alan Cleaver
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20
2 comments On LEAN : Siete formas de desperdicio.
Pingback: Kanban: Items rezagados o que se mueven lento. – Happy Devops ()
Pingback: Opinión del libro: It doesn't have to be crazy at work. – Happy Devops ()
Comments are closed.