De Scrum a Lean – aprendiendo un poco

Aunque el objetivo principal de Scrum es la organización y la gestión de proyecto, Lean se centra más en los procesos con el fin de producir más rápidamente productos de calidad. Este modelo de gestión (Lean) puede ser útil para empezar a adoptar principios ágiles, o puede ser a lo que evolucione tu equipo cuando Scrum no es suficiente.

Esta es la historia de Parkos Csaba publicada aquí: http://net.tutsplus.com/articles/editorials/from-scrum-to-lean/, me pareció interesante traducirla y compartirla .

Un poco de historia

Lean es un conjunto de principios definidos por la industria de fabricación de automóviles de Japón en la década de 1980. El ingeniero de calidad de Toyota, John Krafcik, acuñó el término, mientras que la observaba los procesos y herramientas utilizadas para “eliminar el desperdicio” en la producción de automóviles en masa. Aunque no fue hasta 2003 cuando Mary y Tom Poppendieck introdujeron el término Lean como  un proceso de desarrollo software en su libro, Lean Software Development: An Agile Toolkit.

Considerando Scrum como un conjunto de reglas y roles, Lean es un conjunto de principios y conceptos con algunas herramientas. Ambos son considerados como técnicas ágiles, y comparten la misma ideología de entrega rápida mientras reducen defectos y errores. Siempre me gusta enfatizar la adaptación ágil, pero no podemos olvidar  que Scrum se presenta como un conjunto de reglas obligatorias. De hecho algunos fanáticos de Scrum ponen el grito en el cielo si estar reglas no se siguen al pie de la letra.

“Lean, por otro lado, es más abierto; sus seguidores presentan el proceso como una serie de recomendaciones altamente adaptables.”

Se anima al equipo o empresa para tomar decisiones, y se adaptan esas decisiones a las “sorpresas” que surgen en el día a día del equipo y de la compañía.

Este es el comienzo de mi historia: Como mi equipo ya estaba muy experimentado utilizando Scrum, nos parecía que algunos aspectos de esta metodología nos estaba deteniendo. Nos convertimos en un equipo disciplinado y homogéneo, de tal manera que las reuniones diarias no eran del todo eficientes. Como equipo hemos aprendido a que debemos resolver los problemas rápidamente y nos sentimos en la necesidad de evitar estos procedimientos que nos estaban deteniendo…

Los dos grandes conceptos de Lean

Lean expone dos conceptos importantes, pero el “core” de la idea detrás de Lean es: “Eliminarlos residuos y mejorar e work flow (flujo de trabajo).

Eliminando los residuos

Cualquier cosa que se interponga en el camino de la producción es residuo. Esto incluye tiempo perdido, material sobrante, y fuerza de trabajo sin usar. Es importante destacar que los defectos en el producto final son residuos, debido a que se pierde tiempo solucionándolos, se malgasta dinero para reemplazarlos y se gastan recursos en encontrar otras soluciones.

“SI ALGO VA A ROMPERSE, LO HARÁ UN VIERNES”

El concepto residuo se traduce bastante bien al mundo del desarrollo software. Los residuos pueden describirse como retrasos en las entregas, errores, y los programadores no tienen nada de qué ver (no  confundir esto con “los programadores deben programar ocho horas al día, sin pausa y sin youtube)

Mejorar el flujo

El concepto Lean de Toyota se concentra en el flujo de producción. En una planta de producción, el flujo es una cadena de procedimientos que transforman las materias primas en productos finales. Estos procedimientos pueden ser muy diferentes unos de otros y tener diferentes tiempos, pero cada uno puede ser mejorado para hacerlos más eficientes. Es una lucha constante para mejorar los cuellos de botella del proceso

“En un flujo ideal cada etapa tiene la misma cantidad de tiempo y esfuerzo para producir la misma cantidad de productos”

Esto no significa que cada proceso tenga que gastar la misma cantidad de dinero, pero cada proceso debe completarse con la misma “cantidad de facilidad”.

Irónicamente, Scrum fue la herramienta que nos llevó a darnos cuenta de los residuos en nuestro proyecto. Si bien nos adaptamos a “Scrum puro” en algunas áreas de nuestra producción, empezamos a identificar errores/ retrasos que se podían evitar fácilmente mediante la adopción de un enfoque diferente.

Cuando nos dimos cuenta de esto no conocíamos apenas Lean. Habíamos leído algunos artículos sobre el tema, pero lo ignoramos porque estábamos concentrados en nuestro proceso Scrum. Scrum era nuestra mejor arma, estábamos muy contentos con Scrum, pero teníamos que abrir nuestras mentes.

Los principios Lean

Para el desarrollo de software podemos adaptar los principios Lean en estos 7:

1 – Eliminar residuos

En el desarrollo de software, se pueden encontrar y eliminar residuos mediante el reconocimiento de cosas que pueden ser mejoradas. Siendo pragmáticos, nada que no sea un valor directo para el cliente es un residuo. Aquí tenemos algunos ejemplos: un residuo es un error, un comentario en el código, una funcionalidad no pedida, equipos que tienen que esperar a otros equipos, realizar una llamada personal… Todo lo que produce esperas a usted o a su equipo es un residuo, y deberán tomarse las medidas adecuadas para eliminarlo.

Recuerdo que uno de nuestros problemas era la necesidad de reaccionar más rápido que dos Sprints, os pongo un ejemplo. Si seguimos Scrum al pie de la letra, vemos que se prohíbe cambiar las historias asignadas al Sprint actual. Por tanto si un cliente encuentra un bug que necesita solución debe esperar al siguiente Sprint, o por ejemplo cuando un cliente necesita rápidamente una nueva funcionalidad que se completa en dos días no podemos incluirla en el Scrum actual. Scrum no es lo suficientemente frecuente en estos casos.

2 – Ampliar el aprendizaje

Partimos de la premisa de que usted tiene desperdicio, y que naturalmente quiere menos desperdicio en el futuro.   Pero ¿Por qué hay residuos? Puede que un miembro del equipo no sepa bien cómo abordar un problema en particular. Es normal, nadie lo sabe todo.

“Dar valor  al aprendizaje”

Identificar las áreas donde se necesita mejorar. Cuanto más sepa el equipo más fácil es reducir los residuos.

Por ejemplo, el aprendizaje de Test Driven Development (TDD) puede reducir el número de errores en el código. Si tiene problema con la integración de módulos provenientes de equipos diferentes, es posible que desee aprender lo que significa Integración Continua y poner en práctica una solución adecuada.

También podemos aprender del feedback del usuario, lo que le permite aprender de como los usuarios utilizan su producto. Por ejemplo, si escondemos una característica muy utilizada detrás de 5 clics. Esto es una señal de desperdicio. Inicialmente podemos culpar a los desarrolladores o a los diseñadores de UX, pero los usuarios tienden a utilizar el software “a su manera” (la manera del usuario y o del UX). Aprender de los usuarios ayuda a eliminar este tipo de residuos. También ayuda a eliminar requisitos erróneos o incompletos.

Por ejemplo, en algún momento, mi equipo identificó que algunos módulos se podrían haber escrito mejor si hubiéramos conocido más del dominio del problema desde el principio. Como no podíamos volver atrás, decidimos invertir tiempo en conocer todo el dominio del problema y realizar una función más compleja con ese conocimiento.

3 – Decidir lo más tarde posible

Todas las decisiones tienen un coste. Puede que este no sea inmediato y material, pero tienen un coste. Aplazar las decisiones ayuda a prepararse para enfrentarse bien preparados a los problemas. Probablemente el ejemplo más común es demorar el diseño de la basa de datos.

“Las decisiones no tienen por qué ser de carácter técnico; tener una buena comunicación con los clientes ayuda a tomar decisiones que afectan a enfocar las características de los productos.”

Pero los usuarios no siempre saben lo que quieren. Al aplazar las decisiones hasta que los usuarios realmente necesitan esa funcionalidad, tendremos más información sobre el problema y se podrá una funcionalidad necesaria  adecuada a dicho problema.

Hace 14 años, mi equipo tomo la decisión de utilizar como base de datos de datos MySQL. Se tomó esta decisión a comienzo del proyecto,  que ahora tenemos que cargar.

Elegir la metodología ágil que funcione mejor para su equipo.

Mirando el lado bueno, hemos aprendido de los errores pasados. Tomamos decisiones de programación, arquitectura y proyecto lo más tarde posible De hecho, hemos aprendido una gran lección antes de adoptar Lean. Escribir código abierto y desacoplado, crear un diseño que sea persistente y una configuración agnóstica. Es algo muy difícil de hacer pero ayuda en el futuro.

4 – Entregar lo más rápido posible

Vivimos en un mundo de constante cambio. Los ordenadores quedan obsoletos cada dos años. La ley de Moore sigue siendo válida.

La velocidad de entrega lo es todo en este mundo

Es muy importante dar valor a los clientes tan pronto como sea posible. La historia ha demostrado que un producto incompleto con una cantidad aceptable de errores es mejor que nada. Además, es importante ver el comportamiento de los usuarios ante el producto. Sus comentarios tienen un valor incalculable.

Nuestra empresa tuvo un sueño.: Entregar después de cada Sprint. Naturalmente, esto es impracticable en la mayoría de los casos. Nuestros usuarios no querían que el producto se actualizase cada semana o cada mes. Nosotros aprendimos que el término “rápido” debíamos aplicarlo a lo que el usuario percibe. En los productos de nuestra industria rápido quiere decir que haya actualizaciones cada pocos meses y corrección de errores críticos en días. Esta es la manera en la que nuestros usuarios perciben rápido. Para otras industrias habrá otras definiciones de rápido.

5 – Autorizar al equipo

Los programadores solían estar encerrados en cubículos, en silencio, desempeñando las tareas para su empresa. Esta era la imagen predominante de un programador a finales de los 90, pero hoy sin duda no es el caso.

“La historia demuestra que el enfoque en cascada no es adecuado para el software”

Era tan malo que solo el 5% de todos los proyectos software eran entregados a tiempo. Millones de dólares gastados en proyectos fracasados.

Lean identificó que los programadores desmotivados eran los causantes de este desperdicio. Pero, ¿Por qué esa falta de motivación? Buenos, es que nadie escuchaba a los programadores, ni a los equipos de desarrollo. La compañía establecía tareas y los empleados solo eran un recurso que producía código fuente.

Lean anima a los directivos a escuchar a los programadores, anima a los programadores a enseñar el proceso de producción software. También anima a los programadores a interactuar con cliente y usuarios. Esto no significa que los desarrolladores tengan que hacerlo todo, pero les da poder para influir sobre la evolución de los producto.  Hay una frase que refleja ese factor motivacional “¿Sabes esa funcionalidad que les gusta a los usuarios?Fue idea mía ;)” Por ello la motivación es un factor importante.

Pero creo que esto no solo funciona en los equipos grandes, nuestro equipo está formado por un puñado de desarrolladores, por lo que siempre ha estado cerca de los usuarios. Esta relación nos ha permitido influir en el producto.

6- Integridad de la build

Integridad es sinónimo de solidez cuando hablamos de productos software, y es como los clientes ven el producto en su conjunto. La integridad puede ser por ejemplo la uniformidad en la interfaz de usuario, la fiabilidad, la seguridad, la sensación de seguridad que tiene el usuario del producto. La integridad es la imagen completa que tienen los usuarios creada acerca de tu producto.

Cualquier cosa que se interponga en el camino de la producción es desperdicio

La integridad puede observarse como el look and feel de la UX en torno a las distintas pantallas. Pero también puede practicarse la integridad a nivel de código fuente. Que el código siga unas “normas de estilo”, el uso de patrones de diseño, el nombrado de variables,… Integridad significa que tenemos que refactorizar el código frecuentemente. Esta integridad es continua e interminable, debemos esforzarnos, pero nunca alcanzarla.

Mantener la integridad de nuestro código es una tarea difícil. Nos dimos cuenta que la búsqueda de código duplicado es una tarea más que difícil de hacer, y por duplicación no me refiero a un par de líneas duplicadas en el mismo método o clase.

Encontrar duplicidad en el código es una tarea difícil y requiere un amplio conocimiento del código fuente.

He formado parte del mismo proyecto más de un año, y todavía me sorprendo cuando encuentro código duplicado. Pero  hay algo bueno, hemos llegado a un punto en el que realmente vemos estas cosas y tomamos medidas al respecto. Desde que comenzamos activamente a eliminar duplicados la calidad de nuestro código ha aumentado. Estamos un paso más cerca de lograr la integridad.

7 – Ver el conjunto

Al crear aplicaciones, se tiene confiar siempre en componentes de terceros con el fin de desarrollar nuestro producto,  así como nuestro producto tiene que comunicarse con otros. Su aplicación tiene que integrarse con el diseño del dispositivo o del sistema operativo de su PC ¿No es más fácil usar una aplicación que se integre con el sistema de notificaciones de su teléfono?

Los usuarios no siempre saben lo que quieren

Es cierto, ver el todo no es tan fácil. Tenemos que separarnos de los pequeños detalles y ver el producto desde lejos. Uno de los momentos memorables en el desarrollo de nuestro producto es cuando nos dimos cuenta de que teníamos que confiar en lo que producen otros programadores de otros proyectos.

En un momento dado, ese componente que usábamos cambió. En ese momento teníamos dos opciones o aplicar un parche o culpar a los programadores que escribieron ese componente. Elegimos coger el toro por los cuernos y arreglamos el problema en el componente.