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.

Siempre he odiado involucrarme en la capa de vista de una aplicación por las deficiencias de sus lenguajes y la falta de opciones. HTML, JSP, JavaScript, CSS son las monturas de los jinetes del apocalipsis. Desde mi más tierna edad profesional me preguntaba…

Por qué no utilizar Java para la capa de vista?

Bendita solución.

GWT nació en 2006 de la necesidad de Google en proporcionar a sus usuarios interfaces ricas, claras, ligeras, intuitivas y sobre todo dinámicas. Dado que ninguna herramienta externa o lenguaje cubría sus necesidades, decidieron desarrollar su propia solución, que posteriormente convirtieron en código abierto, generando JavaScript a partir de código Java y solucionando problemas comunes como la internacionalización, la comunicación asíncrona, el histórico de navegación y la compatibilidad entre navegadores.

Y lo consiguieron, los resultados desde el punto de vista de usuario son muy buenos y el desarrollador se abstrae completamente de AJAX y JavaScript.

Monstruo avernal.

Sin embargo GWT no se imponía en el mercado, no se convertía en estándar, el número de proyectos y profesionales GWT no despegaba e incluso recientemente ha empezado a decaer.

¿Por qué? Yo no entendía la razón… hasta que he tenido que involucrarme profesionalmente. Quizás las lagunas que le encuentro a estas versiones de GWT sean debidas a mi desconocimiento de la propia tecnología y a mi escasa experiencia de un par de meses, lo que en el mejor de los casos sitúa a GWT como una tecnología con una curva de aprendizaje poco suave debida a su buena pero escasa documentación oficial, su gran número de rígidas convenciones (no documentadas) y sobre todo al enfoque erróneo en sus orígenes de aspirar a gestionar el proyecto en lugar de ser una simple herramienta más que se utiliza únicamente en la vista y en el controlador para las llamadas asíncronas.

Colaboración, intercambio y estandarizar: se debió crear una fundación sin ánimo de lucro y dotarla de fondos o colaborar con las existentes, para encontrar una solución común para resolver un problema común ajeno a sus negocios. Sin embargo Google buscó una ventaja competitiva sobre su competencia haciendo algo que no pertenece a su core de negocio, pan para hoy…

Las versiones v01.xx son muy “noventeras” : rígidas (pensadas para las necesidades de Google), implementa supuestamente el patrón MVP (a mí me parece una arquitectura de dos capas cliente-servidor), mini-manuales, sota caballo y rey, tu proyecto pasa a ser un proyecto GWT, el desarrollo será rápido pero cogido con chinchetas (si funciona no toques, por qué tocas?), el mantenimiento será infernal y las migraciones eternas. Salvando las distancias, recuerdan a Alfresco.

Las versiones v02.xx han mejorado enormemente : existe un plugin de Google para Eclipse, un plugin para Maven con el que colaboran Codehaus, Sonatype y Google, se creó GIN (Gwt Injection) para inyectar dependencias, es más flexibilidad, existe más documentación.

Sin embargo aún debe avanzar hacia una hipotética versión v03.xx más simple, más documentada, con menos convenciones para reconvertirlas en configuraciones, una simple herramienta del proyecto en lugar de ser el centro del proyecto, lo que facilitaría su integración para gestionar la Vista con otras herramientas MVC como Struts, Spring MVC o las que aparezcan en un futuro.

Ángel o demonio?

Depende de cómo lo utilices.

Si te estás planteando utilizar GWT para tu nuevo desarrollo, o migrar tu actual proyecto a GWT, no creo que sea una mala idea, pero antes de hacer nada profundiza, aprende, practica con una pequeña kata y sé consciente del riesgo que estás introduciendo en tu proyecto y de que la curva de aprendizaje será mayor de lo esperado.

Mientras escribo estas líneas mi boca aún está enviando señales a mi cerebro indicando la sensación de total deleite que resuena en estéreo a lo largo de toda mi cavidad bucal. Supongo que será debido a la ensalada que he degustado hace unos escasos minutos, nada especial, sólo lechuga, cebolla, zanahoria, manaza y queso condimentado con vinagre de módena y aceite bueno de Jaén.

Anoche mismo me tomé una ensalada igual, y no me produjo la misma sensación. Será casualidad, pero la diferencia acaso radique en que la lechuga era de mi huerto, al igual que la zanahoria, procedentes de la primera recolección de mi huerto, el 28/11/2011.

Voy a regodearme un poco más en esta sensación cacofónica de placer bucal, vuelvo dentro de unos minutos.

Ya estoy. Sigo igual, pero voy a seguir escribiendo.

Aún no había helado en este magnífico otoño. Las temperaturas han sido suaves pero se mantuvieron constantemente por encima de los 10 grados incluso por las noches hasta finales de noviembre. La siguiente quincena la temperatura se mantenía entre los 5 y los 10 grados por la noche, y la última entre los 0 y los 5 grados. A medio día los días de sol la temperatura casi llegaba a la treintena de grados, pero según progresaba el otoño iban disminuyendo tanto el pico de temperatura como la duración de esta banda.

Ha habido varios días sueltos totalmente nublados y una racha de una semana con niebla a finales de Noviembre, un par de días hasta las 14:00h, pero en general las horas de sol han sido abundantes para la época.

Además el agua ha sido generosa y constante los dos primeros meses, sólo una gran lluvia pero el suelo se ha mantenido siempre húmedo. El último mes ha sido más bien seco.

La primera helada de la temporada ha llegado el 29/11/2011, dejando una vista de Salamanca preciosa con los campos bellamente blancos para presentar una Salamanca apenas perceptible al otro lado del río por la niebla y nubes bajas en la que destacaba la poderosa silueta de la Catedral mientras un tenue Sol luchaba por levantarse. Fría vista, pero cálida sensación de belleza de una manaña de Noviembre digna de inmortalizar. Únicamente ha habido otras dos más durante los dos últimos días del Otoño.

Han prosperado aproximadamente un 60% de lo esperado por lo sembrado, lo que atribuyo a novatada, hormigas, aves, gatos… Nada preocupante, en especial si siembro en semillero.

Las plantas han crecido sustancialmente menos de lo esperado, lo que atribuyo por un lado a la mala calidad del suelo, a que han crecido demasiado juntas, a la orientación norte pero sobre todo al verse entre dos edificios que disminuye significativamente las horas de sol. La razón por la que el huerto está situado ahí es para buscar la protección que ofrecen los edificios, menos viento, menos sol abrasador en verano y más fácil de cubrir con un plástico, pero habrá que replantearlo. Respecto a la proximidad entre semillas, habrá que hacer una segunda plantación con un bancal profundo.

Y de la calidad de lo cosechado, como comento al principio, no me puedo quejar en absoluto.

El Momento de la Verdad es un libro (que puedes previsualizar en la sección de libros de Google, aquí) escrito en 1987 por Jan Carlzon. Relata el cambio de paradigma que aplicó en 3 compañías mientras él estuvo al frente como presidente de las mismas dentro de un mercado estancado e hipercompetitivo en costes como el aeronáutico de los años 80.

Aunque es un libro sobre calidad y atención al cliente, sus lecciones se pueden extraer y extrapolar a cualquier ámbito.

3 compañías, 3 problemas diferentes, 3 enfoques diferentes.

Estudiar las necesidades en cada caso. No hay soluciones universales, no hay balas de plata, no hay buenas o malas decisiones, sino las decisiones adecuadas a cada necesidad.

Los empleados son un activo fundamental de la compañía. Por tanto tener a los empleados motivados y mantenerlos así resulta vital para que marquen la diferencia.

Para conseguir motivarlos Carlzon recomienda comunicar internamente el nuevo paradigma (visión) de la organización y delegar responsabilidades para que cada empleado opere ajustándose al nuevo paradigma

“Queríamos que todo el mundo en la compañía entendiera el objetivo”.

En este caso el paradigma es satisfacer al cliente, así que la plantilla tenía autoridad para decir “sí” para satisfacer las necesidades del cliente, pero debía pedir permiso para decir que “no”. ¿Funcionaría este enfoque en España?

Para mantener a los empleados motivados resulta vital el desempeño de los responsables.

Para mantener a los empleados comprometidos con la visión de la organización resulta vital el desempeño de los líderes.

El principal objetivo es consguir clientes satisfechos, comunicando efectivamente al mercado la nueva visión y cumpliendo sus expectativas.

Objetivo claro

Todas las acciones de Carlzon se guiaban bajo un único objetivo: que su compañía consiguiese marcar la diferencia con respecto a su compentencia.

You practically need to mentally turn the organization upside down to become a customer-driven service company. When I was at SAS, we said: “We used to fly airplanes – now we fly people.” [1]

Tienes que cambiar la mentalidad de la organización prácticamente de arriba a abajo para convertirte en una compañía de servicios orientada al cliente. Cuando yo estaba en SAS decíamos que “nosotros solíamos hacer volar aeroplanos; ahora hacemos volar a personas”.

1 nuevo enfoque : Momentos de la Verdad

El cambio de paradigma fue considerar a sus clientes satisfechos como los verdaderos y más importantes activos de su compañía, y por tanto cada contacto entre un cliente y cualquier parte de la compañía era un Momento de la Verdad. Estos momentos son los que determinan si una organización tendrá éxito o fracasará.

Anytime a customer comes into contact with any aspect of your business – whether with staff at the front line or however remote – is an opportunity to form an impression. [1]

Cualquier ocasión en que un cliente entra en contacto con cualquier aspecto de tu negocio [...] es una oportunidad para formar una impresión.

De ahí la importancia de los empleados, especialmente los que tienen trato directo con el cliente. Esta “primera línea” de contacto con el cliente disponía de libertad de acción y decisión sobre los burocráticos procedimientos para conseguir satisfacer al cliente en los escasos 15 segundos de media que duran estos momentos. Sí se producían errores, pero :

Los errores pueden ser corregidos generalmente más adelante; el tiempo que se pierde no tomando una decisión nunca puede recuperarse.

(y yo que creía que la agilidad la “descubrieron” ayer dos “gurús” del software, españoles)

Jefe / Responsable / Líder

Es un concepto que tengo claro antes de mi primera lectura de este libro, hará casi una década. Un jefe no tiene que tomar todas las decisiones o producir o saber hacer el trabajo de sus subordinados mejor que sus subordinados.

Un responsable tiene que crear la atmósfera para que el equipo funcione mejor.

Un líder comunica su visión y guía a su equipo.

Algo que ya hacía Sócrates hacía miles de años.

Referencias

[1] Extraído de esta entrevista a Jan Carlzon.

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.