2014/01/23

Kanbiando con Kanban


Hace unos días, en mi trabajo, hicimos una actividad interesante.

Se propuso a los miembros del equipo un problema de programación no muy complejo. Se eligió un lenguaje de programación y una sola computadora, cuya pantalla se reflejaba en un televisor para todos, donde cada uno trataba de avanzar lo que pudiera durante 5 minutos.

Excepto el jefe, que debía mantenerse al margen haciendo intervenciones ocasionales, nadie más que quien estaba en su turno podía hablar, contando a los demás que iba haciendo y por qué lo hacía.

Además podía buscar en Google, y modificar o borrar el código previo.

Se sucedieron varias rondas y paso un par de horas sin que lográramos escribir una solución funcional.

Entendíamos la solución a la que queríamos llegar, y probablemente todos hubieran podido escribirla trabajando solos durante quince minutos o media hora. Pero, por alguna razón, no la lográbamos alcanzar.

Cuando terminó la jornada, me retire, pero el problema continuaba en manos que quienes podían quedarse.

Me sentía frustrado, pero, conforme pasaba el tiempo me iba sintiendo además instruido. Un problema simple y solucionable se había vuelto prácticamente irresoluble debido a las condiciones de trabajo impuestas.

Estas condiciones fueron tales que prácticamente anulaban la comunicación. Eso inhabilitaba el trabajo en equipo. Al menos, él trabajo en equipo usual.

Reflexionando, me di cuenta que, al inicio, nadie asumió el reto como un trabajo en equipo. Cada uno quería, de ser posible, terminar el problema en su turno.

Luego, cuando las primeras rondas iban mostrando que no sería tan fácil, apareció gente que prefirió hacer explícita una estrategia en lugar de programar. Entonces, el trabajo de todos empezó a encauzarse y parecía que se resolvería pronto. Nos estábamos adaptando.

Es allí donde el jefe cambió de pronto las reglas. Dijo que estaba clara la solución y que el reto sería ahora tratar de escribirla una sola persona, desde cero, en 5 minutos.

Además de transformar el problema en una competencia de tipeo, de entrada, eso destruía la comunicación incipiente que había surgido espontáneamente. Fue entonces cuando me retiré.

Camino a casa iba pensando que pasaría si esa prueba se repitiera cada semana. Creo que iniciaríamos sacrificando tiempo de programación para establecer mejor primero un marco de trabajo y luego la estrategia para resolver el problema. Y luego recién empezaríamos a codear.

Me pregunte luego cuántos proyectos habrá así en la vida real. Con gente competente y sin embargo sin avances significativos. Y todo por una organización contraproducente.

Deming, el padre de la mejora continua de la calidad, decía que el 95% del resultado éxito o fracaso se debía a la organización y solo 5% a la gente.

Pero no es obvio. Mucha gente tiende a culpar a la gente y lanzarse a tomar medidas correctivas en ese sentido. Llamadas de atención, recorte de privilegios, castigos, en el peor de los casos. Capacitaciones y coaching en el mejor de los casos.

Pero, si la causa es la organización, no se solucionará nada. A menos que se empondere a la gente para que la pueda mejorar.


Un par de días después, asistimos a un seminario sobre Kanban (la metodología de visualización de flujo de trabajo inspirada en las prácticas de Toyota).

Resulta que es una herramienta muy simple y poderosa para visualizar el estado del flujo de trabajo en una organización. Y para hacer evidentes sus virtudes y defectos.

Siendo evidentes los defectos, es más fácil proponer cambios de políticas e ir gradualmente cambiando la organización.

Yo pensaba que venía utilizando Kanban, al menos en mis proyectos personales. Descubrí que lo estaba haciendo de modo incompleto. Para que Kanban haga su magia, es necesario hacer hacer explícitos los límites de trabajo en progreso (WIP, por sus siglas en inglés) y las políticas de aceptación de tareas.

Ahora estoy leyendo y aprendiendo más al respecto. Un libro que me parece sumamente útil y fácil de leer es "Scrum y Kanban: Usando lo mejor de ambos", de Henrik Knigerg y Mattias Skarin.

Estoy viendo que podría usarlo también para mejorar mi forma de estudiar... y hasta para procesar con más eficacia las montones de cosas que quiero hacer en la vida (Personal Kanban)

Una gran virtud de Kanban es que te permite iniciar como eres ahora, con lo que tienes ahora.

Viva Kanban \(^_^)/

2014/01/13

En equipo

Es muy diferente escribir código solo que en equipo.

Cuando eres solo una persona, tienes más libertad para elegir lo que te gusta o desechar lo que no te gusta. Para elegir usar patrones que solo tu conoces, para inventar tu propio framework, para usar los hackings que te gustan...

Cuando eres solo una persona, escribes código para solucionar un problema. Y punto.

Pero cuando estás en un equipo, escribes código para solucionar el problema de modo que otros puedan entender la solución y mantenerla.

Eso puede ser un poco más complicado. Porque la mayoría de tu equipo puede tener otras preferencias de formato, usar mejor otros frameworks, y cosas como los hackings (que te hacen googlear media hora para entenderlos), no son recomendados.

Pierdes la sensación de control total que puedes sentir cuando dominas tu código. En su lugar, va apareciendo el sentimiento de que todo es caos.

Y, sin embargo, del caos surge un orden, y soluciones valiosas, si las sabes ver. Es cuestión de abrir la mente para estar dispuesto a aprender... que nunca se acaba de aprender. Y que hay soluciones que no son tuyas ni mías, sino de ambos.

Cuando aparece la sinergia, donde uno más uno es más que dos, es como magia que jamás conocerías si no fuera porque trabajas en equipo. Y entonces, lo valoras.

2014/01/06

Justo a Tiempo

Just In Time (Justo a Tiempo), JIT, es una filosofía de producción.

Sus principios se basan en los que empleaba Toyota en los 1970, pero adecuados a occidente.

En el libro "Justo a Tiempo", de Edward J. Hay, mencionan que algo principal en JIT es la eliminación de desperdicio.

Los japoneses definen desperdicio como "todo lo que sea distinto de la cantidad mínima de equipo, materiales, piezas y tiempo laboral absolutamente esenciales para la producción".

A Hay le parece que determinar lo que es absolutamente esencial es subjetivo y redefine el desperdicio como "todo lo que sea distinto de los recursos mínimos absolutos de materiales, máquinas y mano de obra necesarios para agregar valor al producto".

Estoy leyendo sobre JIT y otros temas de metodologías ágiles porque estoy interesado en hallar mejores formas de desarrollar software en equipo.

En mi caso, la definición original de desperdicio, como aquello que no es el mínimo esencial para producir algo sí tiene mucho sentido.

En TDD, se va escalando sobre mínimos necesarios para producir algo. Cada escalón debe ser trivial respecto al anterior. Nada de considerar posibles mejoras por adelantado. Nada de generalizaciones antes de tiempo. Nada de de optimizaciones prematuras. Primero, lo mínimo necesario para que funcione. Las optimizaciones llegan a través de reflexión y refactorizaciones.

La definición japonesa de desperdicio la entiendo muy bien en ese contexto.

En cambio, la definición de Hay, como aquello que no agrega valor al producto, me parece contraproducente. Y realmente subjetivo, al menos desde el punto de vista de TDD.

Porque no faltarán clientes, jefes de producto o jefes de equipo que insistan en incluir por adelantado una funcionalidad X porque opinan que eso agrega valor al producto (y no están pensando en el producto actual sino el que está dos ciclos adelante, o incluso el final, o más allá...).

En cambio con la definición original uno está a salvo: ¿es absolutamente necesario para que funcione ahora? No. Entonces lo anotamos en la lista de deseos, pero la implementaremos cuando sea su momento, no antes.

Bueno, eso esta es una nota en el camino... continuaré leyendo el libro...  :-)




2014/01/02

Sobre autores

DRM (Digital Rights Management) es una clase de tecnologías usadas para controlar la copia de contenido digital después de la venta.

¿Por qué?
Las nuevas tecnologías facilitan la copia de contenido.

El copyright es un concepto legal para asegurar la exclusividad en el derecho de copiar contenido.

¿Por qué?
El contenido puede ser considerado como un producto.

El derecho de autor es un concepto legal para atribuir a un autor el copyright del contenido que produzca.

¿Por qué?
Para que el copyright pueda ser considerado como un producto.

¿Por qué?
Si algo es valioso, quien más gana es el intermediario, el encargado de la distribución.
Es una gran ventaja asegurar la exclusividad en la distribución.
Cuando alguien produce contenido, si su valor de distribución es alto, el intermediario tenderá a asegurar la exclusividad de su servicio.
El derecho de autor es un producto que el distribuidor le compra al autor para asegurar esa exclusividad.
El distribuidor defiende el derecho de autor para asegurar que ese producto siga existiendo.

El concepto de derecho de autor no ha existido siempre. Cuando aparecieron impresores que reclamaban a perpetuidad la exclusividad en la copia de los libros que habían adquirido de los autores, los gobiernos establecieron leyes con plazos menores (en el siglo XVIII). Desde entonces se ha jugado de esa manera.

¿Cuál es el problema?
El contenido, a pesar de que le han dado ese nombre, es contenedor de conocimiento. Las limitaciones comerciales para la distribución de productos, cuando son aplicadas a contenedores de conocimiento, limitan la distribución de conocimiento.

Antes, el conocimiento se difundía lentamente, principalmente de manera oral. Cuando apareció la imprenta, el conocimiento se pudo difundir principalmente por vía escrita. Eso facilitó que se empezara a considerar al contenedor de conocimiento como un producto comercial.

¿Es el conocimiento un producto comercial?
En un mundo ideal, las obras contendrían como referencia los nombres del autor o los autores que contribuyeron a su creación. Porque eso es útil para contactarlos, documentar su desarrollo, mejorar el conocimiento.

Actualmente, si la preocupación por los autores fuera sincera, se defenderían más bien derechos de atribución, para asegurar que la contribución de cada autor figure en la obra y sus derivados.

Pero lo que se defienden son cosas que permitan exclusividad comercial del contenedor, aún a pesar de que eso limite el libre desarrollo de lo que contienen, que es el conocimiento.

Lo saben los autores de libros y música, que realmente reciben bajas comisiones de parte de las distribuidoras. La mayor parte va siempre para el intermediario. Por eso, algunos autores están optando por auto publicarse o usar canales de distribución menos onerosos. Incluso, el propio autor debe pedirles permiso para citarse a si mismo.

Hubo un tiempo, reciente, en que la distribución comercial fue aliada de la distribución de conocimiento. Porque no estaba al alcance de la mayoría imprimir un libro o editar un disco. Pero la tecnología ha avanzado y ahora tenemos el poder de hacerlo. Ahora podemos contribuir a la distribución de conocimiento.

Eso significa el final de una era para los distribuidores. Tendrán que descubrir o inventarse nuevos roles. Sin embargo, lo que hacen muchos es usar sus recursos para tratar de salvar su antigua forma de vida lo más que puedan.

La opción extrema, es renunciar al copyright y usar el copyleft. Es decir, salvaguardar el derecho de atribución, pero permitir la libre distribución y modificación de la obra, con la condición que cada copia y sus derivados tenga también el mismo copyleft.

Así es como el software libre ha podido hacer tantos ciclos de desarrollo y lograr avances notables comparados con las alternativas con copyright. Así es también como Wikipedia dejó fuera a MS Encarta e incluso a la Enciclopedia Británica. Así es como el conocimiento se abre paso.

El conocimiento merece que veamos más allá de su aspecto comercial, que ha sido como el bote que ha permitido llegar a esta playa. Porque es la búsqueda del conocimiento la razón de todo lo que nos trae hasta aquí. Deberíamos honrarlo, respetarlo, cultivarlo. Dejar que sea libre y nos lleve a donde seamos capaces de ir.