Lycka Bonita

En mi opinión, su punto más conflictivo de Kanban es su respuesta ante atascos en la cadena de producción. Kanban propone un límite en el trabajo (WIP, Work In Progress) que puede ser asignado a cada etapa de la cadena de producción. El WIP actúa como un cuello de botella artificial detectando tempranamente atascos en ambos lados de la etapa atascada: los trabajos se acumulan en su entrada, la alimentación de tareas a las etapas posteriores se detiene.

Kanban sugiere corregir esta ineficiente situación parando la producción de la cadena y que cada operario deja de trabajar en su puesto para ayudar a desatascar el problema. Una vez solucionado el problema se vuelve a la normalidad.

Kanban, en la práctica: nuestro problema

Hasta ahora no había tenido la oportunidad de enfrentarme a una situación similar en la vida real, además una situación similar al descrito en la imagen que acompaña esta entrada: no podemos desplegar una versión.

Nuestras circunstancias :

• Somos un equipo distribuido de 5 personas en 2 centros de trabajo a varios cientos de km de distancia.
• Se trata de un proyecto que nos ha sido entregado recientemente para que llevemos su mantenimiento correctivo y evolutivo.
• El proyecto está basado en versiones antiguas de tecnologías en cuya integración no tenemos conocimiento ni experiencia suficiente. Además presenta importantes puntos de mejora en más de un área.
• Una de las primeras cosas que hemos hecho al recibir el control del proyecto ha sido eliminar todo el código de pruebas… qué locura no? nuestras razones teníamos
• Partimos de un punto en el que el proyecto arranca, funciona y ha sido validado por los usuarios en un ambiente de preproducción.
• Nuestro primer objetivo, simplificar. Llevamos una reducción del 75% en el tamaño del WAR, en el tiempo de compilación y arranque, también una importante simplificación de la estructura del proyecto… pero no arranca correctamente.

En estas circunstancias, los desarrollos no pueden ser validados hasta conseguir arrancar el proyecto y comprobar si funcionan. Qué debemos hacer?

• Debemos parar todos los desarrollos y poner a todas las personas a reparar la línea base hasta conseguir desplegar esta versión?
• O debemos seguir cada uno con lo nuestro? Una persona o un equipo arreglando la línea base y el resto continuando con los desarrollos, que se validarán cuando la línea base se arregle?

Kanban, en la práctica: qué hicimos?

La primera semana después de romper la línea base seguimos al pie de la letra la recomendación de Kanban. Paramos la cadena de producción y nos pusimos todos a intentar que el proyecto arrancase nuevamente. 5 pollos sin cabeza, cero resultados, cero avance.

A la semana optamos por la segunda solución. Nos dividimos el trabajo.

Un centro se dedicaba a aprender e investigar sobre las versiones más modernas de las tecnologías y su integración, para después preparar la formación al otro centro y acometer la migración del proyecto a las nuevas versiones (arreglando la línea base en el camino).

El otro centro se dedicaba a sustituir partes de la arquitectura. Es decir queda fuera de la cadena de producción de código, pasando a trabajar en otra cadenas de montaje independiente (arquitectura). Cuando arreglemos el problema volverán a nuestra cadena para desarrollar pruebas desde cero.

Fallo de Kanban? Fallo en nuestra aplicación de Kanban? Nuestra respuesta es un atajo?

Creo que no, no y no. Creo que es un fallo en la gestión del proyecto, nunca debimos ir tan lejos sin conocimientos más avanzados en las tecnologías involucradas. Si hubiésemos abordado en primer lugar la (auto)formación no nos hubiésemos encontrado en esta situación que nos ha hecho perder al menos una semana de trabajo de 4 personas. Con la segunda solución retrasamos la salida de esta incómoda situación, pero al menos no desperdiciamos trabajo.

Decía Wiston Churchill que la democracia es el peor sistema de gobierno a excepción de todos los inventados hasta la fecha.

Algo así pasaba con las metodologías tradicionales en cascada hace unos años, algo así pasa ahora con las metodologías ágiles aceptadas en la actualidad, y algo así pasará con las nuevas metodologías que nos sorprenderán este año.

Y con cada cambio de metodología, nos toca aprender. En España suele ser “aprender”, pero por lo que Dilbert nos cuenta pasa es algo universal:

Vamos a probar algo llamado Programación Ágil.

Significa que no vamos a planificar más, y no más documentación. Simplmente empezad a escribir código y a quejaros.

Me alegra que eso tenga un nombre.

Eso ha sido vuestra formación.

No tengo ninguna duda que las metodologías ágiles sí representan una sustancial mejora respecto a sus predecesoras, no en vano estos últimos años han desaparecido de la primera línea los últimos dinosaurios del software (Sun, IBM, ASF) y ha aparecido un gran nuevo actor (Oracle). Está siendo sin duda una década de cambios, todo fluye y nada permanece que diría Heráclito.

Hoy no me imagino enfrentarme a ningún proyecto sin un enfoque ágil y en la importancia de la integración continua sino como objetivo sí como guía, pero en mi modesta opinión le añado una vuelta de tuerca antes de comenzar a enfrentarse a un problema: el poder de las katas, para iniciarse / dominar en las tecnologías y arquitecturas a emplear.

Pero guardaros de los jefes-pelos-punta (o clientes / comerciales / compañeros) que se leen un libro y repiten como en una misa los nuevos nombres molones sin entender lo que dicen, guardaros de esos falsos mesías e ídolos.

Y recordad la lección de Wally, en realidad no es nada nuevo, sólo distinto perro con el mismo collar: únicamente se ha cambiado el énfasis, pero el que hacía buen software ayer es casi seguro que lo seguirá haciendo hoy y mañana.

TDD (Test Driven Development, o Desarrollo Guiado por Pruebas) es un proceso de desarrollo de software (aunque no veo ningún impedimento para extrapolarlo a cualquier otro proceso de desarrollo). Aunque aporta ventajas medibles y no es muy novedoso, en España ha tenido poco impacto y poca penetración.

Proceso de Desarrollo En Cascada

En realidad no supone un gran cambio respecto al proceso tradicional en cascada, pero el énfasis que pone en dos aspectos claves cambia la forma de ver el ciclo de desarrollo, al igual que una tilde o una coma pueden cambiar completamente el significado de un texto.

Una vez que el equipo de desarrollo y el cliente comprueban todo el valor que aportan a un producto, se preguntarán cómo han podido vivir antes. Pero para llegar a este estado se debe contar con el apoyo claro de la dirección del equipo de desarrollo.

Primero las pruebas [1]

TDD - Core

Tradicionalmente primero se desarrolla y luego se prueba. Este proceso propone intercambiar el orden las cajitas de desarrollo y pruebas para que las pruebas guíen el desarrollo (incluso hay quien dice que deben guiar el diseño) :

• Primero especificar y desarrollar pruebas que debe superar el producto.
• Después se desarrolla. Este paso no se da por finalizado hasta que se superan todos los test. Esta es la razón por la que se dice que las pruebas guían el desarrollo.
• Finalmente se refactoriza (cambiar la estructura interna de un sistema sin afectar a sus funcionalidades) tanto las pruebas como el código para mejorar el diseño interno. Al igual que el paso anterior, esta tarea no se da por completada hasta que se superen todos los test.

Se consigue mejorar la comunicación entre equipos, aumentar la comprensión de lo que realmente se debe desarrollar y al automatizar las pruebas se reduce muy significativamente el tiempo dedicado a pruebas manuales (tanto por el equipo de desarrollo como por el cliente al validar los entregables) a la vez que se aumenta la confianza en el producto.

Entregas frecuentes [2]

Waterfall vs Iterative Waterfall

Por otro lado aconseja la repetición de ciclos de desarrollo muy cortos. En cada iteración (o entrega) se parte de un estado estable y confiable (el código supera todas las pruebas automáticas) y finalizamos en otro estado estable y confiable.

También aporta grades beneficios a nivel global del proyecto. Si debemos especificar menos requisitos y partimos de un prototipo podremos ser más específicos y rigurosos, y las entregas continuas facilitan el control del desarrollo (garantizando que la comprensión del producto es la correcta y mejorando el diseño interno) y en la fase de explotación aumentan el valor del producto reduciendo el tiempo de entrega.

Ajustando los parámetros : cobertura

El precio a pagar por la utilización de este proceso es que desarrollar pruebas significa que hay más código que mantener, más tiempo de desarrollo inicial, más código que probar (las pruebas no tienen por qué estar libre de errores, desarrollamos pruebas para las pruebas? Y también pruebas para las pruebas de las pruebas?…). También es posible encontrar pruebas que no cubran efectivamente el código y/o no han evolucionado mientras el código que cubren sí.

Por tanto se puede recuperar con creces la inversión en el tiempo desarrollo de las pruebas o lastrar el proyecto.  Así, la cobertura de los test, es decir el código que se cubre efectivamente con un test, resulta una decisión crucial para optimizar el proceso y maximizar el ROI de aplicar este proceso.

Sobre la cobertura de los test hay opiniones para todos los gustos, incluso propuestas tan disparatadas como perseguir el 100% de cobertura o valorar la calidad de tu código en función del % de código que está cubierto por test. La opción mayoritaria, que es la que yo recomiendo, es cubrir con test hasta que nuestra confianza en el sistema sea aceptable. Cómo?

• Recomiendo definir un criterio de validación para cada funcionalidad, automatizar estas pruebas de aceptación así como las posibles APIs (puntos de entrada de terceros a nuestro sistema).
• Recomiendo utilizar los datos que se utilizaron para definir los requisitos como Datos de Entrada para alimentar las pruebas. Para ello se pueden utilizar Hojas de Cálculo y/o Bases de Datos. Las Hojas de Cálculo son fácilmente entendibles y mantenibles por los propios usuarios, se pueden adjuntar como anexos al contrato del proyecto y pueden ser leídos por un programa informático.
• Prefiero probar el negocio que los servicios o la persistencia ya que el negocio no puede funcionar si no funciona correctamente el resto.

No más, no menos. Más significa más código a mantener y evolucionar (y posibilidades de error) sin que nos aporte valor, simplemente tardaremos un poco más de tiempo en encontrar exactamente el fallo en un test que no se pasa. Menos significa que nuestro sistema no es confiable.

Para profundizar…

De mi cosecha añadiría también un tercer cambio de paradigma o énfasis. El artefacto entregable es un sistema software (como tradicionalmente lo hemos visto) pero también es un producto (como realmente lo ve un usuario): es importante que el desarrollador lo entienda también como un producto para maximizar el valor del sistema para el cliente y poder reutilizar los máximos componentes posibles.

Los seguidores de TDD recomiendan desarrollar siguiendo los principios KISS (“Keep It Simple, Stupid”, lo simple es bello, efectivo y eficaz) y YAGNI (“You Ain’t Gonna Need It”, no lo vas a necesitar). Yo recomiendo utilizar KISS para todo en esta vida, y YAGNI con mucho cuidado, ya que en ocasiones no seguirlo resulta útil para detectar fallos en el diseño: estás seguro de que no lo vas a necesitar?

[1] Imagen vista en nilclass.

[2] Imagen vista en Agile101. Para ampliar información, consultar The Difference Between Waterfall, Iterative Waterfall, Scrum and Lean Software Development (In Pictures!).

Un hombre de negocios se fue de vacaciones a un pueblecito costero. Dando un paseo por el muelle vio atracar a una pequeña barca con un único pescador que traía varios atunes. El hombre de negocios felicitó al pescador por la calidad de su pescado.

-          Cuánto has tardado en cogerlos?  – le preguntó al pescador el hombre de negocios.

-          Sólo un ratito – contestó el pescador.

-          Por qué no se queda más tiempo y pesca más?

-          Tengo suficiente para mantener a mi familia y dar algunos a amigos.

-          Pero… qué hace con el resto del tiempo?

-          Me levanto tarde, pesco un poco, juego con mis hijos, me echo la siesta con mi mujer y voy al pueblo todas las noches dando un paseo, donde bebo vino y toco la guitarra con mis amigos. Tengo una vida plena y ocupada, señor.

-          Señor, soy licenciado en administración de empresas y puedo ayudarle. Debería pasar más tiempo pescando y con las ganancias comprar una barca más grande. En poco tiempo podría comprarse varias barcas al ser mayor la redada. Con el tiempo tendría una flota de barcos de pesca. En lugar de vender lo que faena a un intermediario lo vendería directamente al consumidor, hasta abrir su propia enlatadora.

>  Tendría que marcharse de esta pequeña aldea costera de pescadores claro, para mudarse a la capital para preparar su salto como multinacional rodeado de un equipo directivo en condiciones.

-          Pero señor, cuánto tiempo me llevará todo eso?

-          15 ó 20 años. Como mucho 25.

-          Pero luego qué, señor?

-          Eso es lo mejor. Cuando llegue el momento anunciaría su salida a bolsa y vendería sus acciones al público haciéndose muy rico. Ganaría millones.

-          Millones, señor? Y luego qué?

-          Luego se jubilaría y se mudaría a un pequeño pueblecito pesquero donde se levantaría tarde, pescaría un poco, jugaría con sus hijos, se echaría la siesta con su mujer e iría al pueblo todas las noches dando un paseo, para beber vino y tocar la guitarra con sus amigos…

Tim Ferriss en su libro La Semana Laboral de 4 horas nos propone este sencillo método:

• 2 minutos. Utiliza una guía visual (acompañar la lectura con el dedo o un boli) evita regresiones.
• 3 minutos. Comenzar cada línea enfocando la tercera palabra por la izquierda y terminarla enfocando la tercera por la derecha. De esta manera se utiliza la visión periférica que se desperdiciaría en los márgenes.
• 2 minutos. Enfocar sólo dos veces por línea, una en cada palabra ancla.
• 3 minutos. Practicar leyendo demasiado deprisa como para comprender pero con buen técnica para después pasar a una velocidad cómoda y comprendiendo el contenido. Es como pasar de 130km/h a luego 80, parece que va a cámara lenta.

Probadlo si queréis y contadme vuestras experiencias… Yo sabéis que soy más pausado y me gusta saborear las lecturas, como por ejemplo prueban las dos veces que me he leído el libro.