Lean Software Development.
La metodología de desarrollo de software lean (traducción aproximada de lean: «fino o esbelto») es una traducción de los principios y las prácticas de la forma de producir lean, hacia el área del desarrollo de software.
Tiene origen en un libro del mismo nombre, escrito por Mary Poppendieck y Tom Poppendieck.
1. Eliminar los Desperdicios.
¿Qué es desperdicio?.
Desperdicio es todo lo que no añade 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 desperdicios.
- 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. - 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. 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. - 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. - 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. - 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.
El Sistema de Producción de Toyota estableció siete desperdicios, o procesos y recursos, que no añaden valor para el cliente. Estos siete desechos son:
- Transporte innecesario
- Exceso de inventario
- Movimiento innecesario de personas, equipos o maquinaria
- Espera, ya sea gente esperando o equipo en desuso
- Sobreproducción de un producto
- Sobre procesamiento o dedicar más tiempo a un producto de lo que el cliente necesita, como los diseños que requieren maquinaria de alta tecnología para características innecesarias
- Defectos, que requieren esfuerzo y costo para su corrección.
Aunque no se incluyeron originalmente en el sistema de producción de Toyota, muchos profesionales lean señalan un octavo desperdicio:
8. El desperdicio de talento e ingenio no utilizado.
2. Amplificar el Aprendizaje
El desarrollo de software es un proceso de aprendizaje continuo, a ello se le suman los retos de los equipos de desarrollo y el tamaño del producto final. El mejor enfoque para encarar una mejora en el ambiente de desarrollo de software es amplificar el aprendizaje.
3. Decidir lo Más Tarde Posible
El desarrollo de software está siempre asociado con cierto grado de incertidumbre, los mejores resultados se alcanzan con un enfoque basado en opciones por lo que se pueden retrasar las decisiones tanto como sea posible hasta que éstas se basen en hechos y no en suposiciones y pronósticos inciertos.
4. Entregar Tan Rápido Como Sea Posible
En la era de la rápida evolución tecnológica, no es el más grande quien sobrevive, sino el más rápido.
5. Potenciar al Equipo
Los directores de proyecto más experimentados simplemente han declarado la clave de éxito de los proyectos: «Buscar la buena gente y dejarles hacer su propio trabajo». Los desarrolladores deberían tener acceso a los clientes; el jefe de equipo debe proporcionar apoyo y ayuda en situaciones difíciles, así como asegurarse de que el escepticismo no arruine el espíritu de equipo.
6. Construir Integridad Intrínseca
Integridad Conceptual significa que los componentes separados del sistema funcionan bien juntos, como en un todo, logrando equilibrio entre la flexibilidad, sostenibilidad, eficiencia y capacidad de respuesta. Esto podría lograrse mediante la comprensión del dominio del problema y resolviéndolo al mismo tiempo, no secuencialmente.
7. Véase Todo el Conjunto
Los sistemas de software hoy en día no son simplemente la suma de sus partes, sino también el producto de sus interacciones.