Dec 20

KanbanFlow

 Hace unos días descubrí una herramienta online que me ha encantado, KanbanFlow.

Te registras gratuitamente y tienes la posibilidad de crear tableros Kanban. Lo que me ha gustado es la sencillez de uso, pero con bastantes posibilidades de configuración. Puedes crear varios tableros, indicar qué columnas tiene cada tablero, crear etiquetas de colores y simplemente arrastrarlas de una columna a otra, en fin, todo lo que se espera de un tablero. Puedes añadir subtareas, que no serían más que una lista de "checks" dentro de una etiqueta. Lleva además un cronómetro de pomodoro con el que podemos guardar tiempos de trabajo en las tareas.

La versión gratuita en principio permite crear cualquier número de tableros y compartirlos con cualquier número de usuarios. La versión de pago principalmente permite asignar roles a los usuarios, exportar a ficheros pdf, csv, etc, llevar histórico de las tareas y tiempos, …

Otro detalle es que la gente que está trabajando en esto parece estar pendiente del asunto. Puse una pequeña petición en su página de ayuda y soporte y aunque me la negaron, tardaron en contestar una o dos horas.

Sep 09

Kanban explicado en comic

 A través de javahispano, (original de One day in Kanban land ), encuentro un post de astracanada en el que cuentan un dia de Kanban en una tira de comic. Leyendo el comic que copio a continuación, se entiende bastante bien la filosofía de Kanban. De todas formas, después de la imagen pongo las mil palabras que valen menos.

comic-camban-1

kanban comic

En Kanban la idea es centrarse en tareas concretas, bajo demanda y no abordar demasiadas cosas a la vez. En la primera columna del tablero están todas las tareas a hacer. El responsable del proyecto pasa las que considera más importantes a la columna "selected" con una restricción: nunca puede tener en esa columna más de dos tareas (el 2 que aparece debajo de selected).

Los desarrolladores, en su columna "Develop", pueden tener un máximo de dos tareas. La columna se subdivide en dos: las que están haciendo en ese momento "Ongoing" y las que ya han acabado "Done". No puede nter más de 2 tareas en la columna "Develop".

Los de pruebas "Deploy", sólo pueden tener una tarea. Una vez probada, se pasa a la columna "Live", que es definitivamente acabada.

Cuando cualquiera se queda sin trabajo porque los límites de las columnas le impiden coger alguna o añadir más, deben intentar ayudar a los del tapón. Es el ejemplo, hacia la mitad del comic, en que un grupo de desarrolladores no pueden coger una nueva tarea puesto que hay un taón en la parte de pruebas. Su misión es ir a ayudar en las pruebas. Incluso el jefe, cuando ve el atasco, intenta ayudar como puede (llevando más café).

La verdad es que es una metodología bastante interesante para fases finales de proyecto, donde básicamente lo que hay son bugs, modficaciones y pequeños añadidos.

Jul 22

¿Dos es más del doble? ¿Quién se atreve a probarlo?

Pongámonos en situación. Supongamos un grupo de dos desarrolladores que tienen que hacer dos tareas. Las tareas no tienen nada que ver la una con la otra, incluso son de proyectos distintos. Lo único que tienen en común es que tienen que estar para ayer, es decir, el tiempo para que estén acabadas es demasiado corto y es muy probable que se llegue por los pelos o no se llegue.

Ante esta situación tenemos dos soluciones:

  1. Solución tradicional, estándar, típica y la más habitual. Cada desarrollador se pone con una tarea y hasta donde lleguen. Esto da tranquilidad aparente, puesto que ambas tareas están haciéndose y se acabarán o no dependiendo de si los desarrolladores se acordaron de traerse el gorro de dormir a la empresa.
  2. Solución ágil, moderna y a la moda. Los dos desarrolladores se ponen juntos a hacer una de las tareas. Cuando la acaban, se ponen con la otra. Desde luego, parece muy arriesgado y a algún jefe se le pueden poner los pelos de punta – ¡¡ Pero !! ..  ¿cómo?¿no estais haciendo nada de la tarea B? –

Supuestamente la solución ágil es la correcta, pero eso sólo es cierto si dos desarrolladores trabajando juntos avanzan el doble de rápido que uno solo. Pero no queda ahí la cosa. Si la solución ágil es la correcta, es porque es mejor que la solución tradicional. Eso quiere decir que dos desarrolladores juntos deberían trabajar más del doble de rápido que si trabaja uno solo.

¿Y es esto cierto? ¿dos desarrolladores juntos trabajan más del doble de rápido que uno solo?. Si tú eres uno de los desarrolladores y es a tí al que van a caer los capones si las tareas no están acabadas a tiempo, ¿te atreverías a desarrollar una en conjunto con tu compañero y abandonar temporalmente la segunda? Y si tú eres el jefe de esos dos desarrolladores y es a tí al que caen los capones ¿les animarías a trabajar juntos en una tarea dejando abandonada temporalmente la otra? ¿Y a mitad del tiempo límite darías el tipo cuando tengas que decir -La tarea B no está porque ni siquiera la hemos empezado-?

Decisión difícil que requiere valor.

Apr 11

Metodologías ágiles: ¿Estamos perdiendo el horizonte?

 

Buscando y leyendo sobre metodologías ágiles en internet, no recuerdo dónde, pero me he encontrado en varias ocasiones con cosas como "Para hacer Scrum y ser ágiles hay que seguir los principios de scrum a rajatabla. Las reuniones diarias deben ser diarias y si no, no le sacaremos todo el partido a Scrum". O cosas como "En programación extrema hay que seguir estrictamente todas sus reglas. No podemos, por ejemplo, hacer programación extrema y no hacer la programación en parejas".

Este tipo de afirmaciones me lleva a pensar si no estaremos perdiendo el horizonte de las metodologías ágiles. Uno de los principios del manifiesto ágil es "Individuos e interacción frente a procesos y herramientas". En el momento que ponemos unas reglas para una metodología ágil y decimos "hay que seguirlas a rajatabla", estamos contradiciendo el espíritu de las metodologías ágiles.

Es cierto que Scrum o Programación extrema han demostrado su valía en muchas ocasiones. También es cierto que las reglas de dichas metodologías han salido como fruto de la experiencia y han demostrado ser útiles. Por ello, alguien que lleva aplicando metodologías ágiles unos pocos años y en unos pocos proyectos no es posiblemente la persona más indicada para decidir si esas reglas son buenas o no. Pero tampoco es correcto decir "hay que seguirlas a rajatabla, siempre y en todo momento".

Lo ideal, si empezamos con metodologías ágiles o las estamos usando, pero no somos gurús del tema, es que cojamos aquella metodología que creamos que se ajusta mejor a nuestros entorno y la sigamos a rajatabla. Siempre es mejor seguir reglas que sabemos han funcionado en muchas ocasiones que rechazar algunas de ellas o reinventarlas sin una buena base previa de experiencia. Más adelante, podremos aplicar en profundidad la verdadera filosofía de las metodologías ágiles, cuando tengamos experiencia en la metodología, veamos qué cosas se pueden mejorar y podamos comprobar  que efectivamente mejoran, podremos empezar a aplicar cambios. Pero debemos ser realistas, el realizar cambios y que realmente mejoren la metodología, sólo lo conseguirán unos pocos con mucha experiencia e ideas claras: los verdaderos gurús del tema.

Aug 10

Manifiesto ágil: Personas sobre procedimientos

Uno de los valores del manifiesto ágil es valorar "Individuos e interacciones sobre procesos y herramientas". Este es posiblemente el más importante de todos ellos y quizás, el que menos en cuenta se tiene cuando se intenta implantar una metodología ágil. No por la parte de "interacciones", ya que cosas como programación en parejas, los daily scrum meeting, y demás tipos de interacciones sí se tienen muy en cuenta, sino por la parte de "individuos".

Según mi experiencia, precisamente la parte de "individuos" es la más importante de todas y sin ella, todo lo demás se va al garete.

Con la parte de individuos se quiere decir gente preparada y adecuadamente motivada, es decir, gente que sabe hacer bien su trabajo y que tiene ganas de hacerlo. Y eso es lo realmente importante. Si la gente no es técnicamente adecuada o no tiene ganas de hacer las cosas, da igual que hagan o no reuniones diarias, que trabajen en parejas, que se les den herramientas o que interaccionen con el cliente: el trabajo no sale bien.

Y eso es algo que estoy viendo continuamente en el trabajo. Según qué personas caigan en qué proyectos, estos pueden ir bien o mal, incluso aplicando la misma metodología con las mismas herramientas.

Así, hay proyectos que cuando llegan a los programadores están totalmente sin definir, no se sabe muy bien qué es lo que hay que hacer en ese proyecto, qué es lo que quiere el cliente y ni siquiera se sabe cuales son los requisitos. Mientras, otros proyectos llegan a los programadores bastante bien definidos, con una idea clara de lo que hay que hacer (aunque luego cambie) y llega con algo de documentación en condiciones, al menos, para las partes con más incertidumbre. Casualmente, las personas responsables de proyecto suelen coincidir en los casos que llega o no llega el proyecto definido. Si el responsable es "Fulanito", su proyecto llega bien definido. Si es "Menganito", no se sabe qué hay que hacer en ese proyecto.

Luego, entre los programadores, siempre hay módulos que llegan en plazo más o menos bien y sin demasiados problemas, incluso aunque esa parte no esté bien definida. Otros módulos, llegan mal y con muchos problemas, aunque estén bien definidas. Casualmente, las partes que llegan bien suelen estar hechas siempre por las mismas personas y las que dan muchos problemas, por otras. Un programador bueno técnicamente, con iniciativa y bien motivado, cuando le llega un algo para hacer mal definido, empieza a dar la paliza al responsable del proyecto para enterarse qué tiene que hacer, hace sus propias propuestas si no lo consigue, hace su código bien hecho y fácilmente modificable y finalmente entrega algo que funciona y que sirve para lo que quiere el jefe, incluso aunque el jefe no sabía qué quería. Un mal programador, sin iniciativa y sin motivación, cuando le llega una cosa sin definir, no hace nada salvo protestar y se entretiene con internet o con otra cosa. Al final, cuando la cosa corre prisa, hace lo que le puede deprisa y corriendo, lo hace mal porque técnicamente tampoco es bueno y el proyecto tiene problemas y se retrasa.

Obviamente, no debería llegar a los programadores cosas sin definir, pero aquí puedes ver que aunque el procedimiento y las herramientas sean las mismas, si se junta un mal jefe de proyecto con malos programadores, el proyecto va de culo, mientras que si se junta un buen jefe de proyecto con buenos programadores, ese proyecto suele ir de cine.

Cuando fallan las personas en una de las dos partes, la otra puede "arreglar" la situación. Ante un jefe de proyecto incompetente, los buenos programadores acaban prácticamente definiendo y llevando ellos el proyecto. Ante unos programadores incompetentes, un buen jefe de proyecto lleva mucha supervisión, define mucho las cosas, prueba mucho y sabe sacar lo máximo posible de los programadores que le han tocado.

Y todo esto es real, es lo que voy viendo en varios años de trabajar en proyectos con bastante gente, tanto de currito como llevando programadores.