Desde hace unos años, los marcos de trabajo ágiles están ganando terreno al software tradicional. Estos métodos priman el software funcional, el trabajo de todo el equipo con el cliente y permiten cambios en los requisitos a lo largo de todo el proceso.¿Qué marco de trabajo usas?
Lo primero de todo es saber qué marco de desarrollo ágil de software estás usando. Nosotros en intelligenia estamos implantando Kanban debido a su flexibilidad, a la existencia de un gran número de proyectos en modo mantenimiento y a la facilidad con la que se implanta.Sabemos que la mayoría de los proyectos de desarrollo usan Scrum, pero nosotros hemos querido ser diferentes y arriesgarnos con un método distinto, ¡somos así de aventureros!
Kanban es un sistema pull en el que sólo entran nuevas tareas cuando las que estaban en desarrollo se han completado. Además, estas tareas viven en un tablero en el que cada columna simboliza un estado concreto, lo que permite una visualización constante del estado del proyecto en cada momento.
Un tablero de tareas basado en la herramienta web Trello de uno de nuestros proyectos en los que el equipo técnico trabaja codo con codo con el equipo comercial.
Si no te suena Kanban, no te preocupes, hay muchas fuentes de información sobre esta metodología. Nosotros estamos siguiendo el libro Kanban: Successful evolutionary change for your technology business de David J. Anderson. Este es la mejor fuente para implantar este sistema ágil de forma completa y no quedarnos en las anécdotas de usar un tablero de tareas, sino ir más allá y buscar la mejora continua o kaizen.
Vamos a comenzar por describir los distintos procesos de evaluación.
¿Con qué profundidad está implantado el marco de trabajo?
Antes de comenzar a hacer cuentas y medir de forma cuantitativa, se recomienda evaluar la profundidad de implantación del marco de trabajo.
Hay un cuestionario desarrollado por el coach agile Christophe Achouiantz y que muestra en la entrada Depth of Kanban - A good coaching tool de su blog.
El cuestionario se basa en evaluar 7 dimensiones mediante preguntas que se responden con un sí o no. Cada dimensión se marca sobre un gráfico de tipo radar y podemos ver de forma visual cuál es la profundidad de Kanban para nuestro equipo.
Cuestionario adaptado a nuestro idioma:
Este cuestionario tienen que responderlo los miembros del equipo de cada uno de los proyectos.
Achouiantz habla de limitar el nivel según las respuestas, de manera que si, por ejemplo, en Visualización, la respuesta para la pregunta 4 es "no", no se contestan la pregunta 5 y siguientes. Esta restricción, si bien puede ser interesante, nos parecía que iba a desmotivar al equipo más de la cuenta, por lo que no la hemos aplicado. Quizás cuando volvamos a hacer la evaluación en un año seamos más exigentes.
En nuestro caso, tenemos equipos en los que hay varios desarrolladores, por lo que han tenido que contestar el cuestionario entre todos, ya que lo que se trata de ver es la profundidad del uso de Kanban por equipo de trabajo en un proyecto concreto.
Vamos a hablar sobre unos de nuestros proyectos, que llamaremos (por motivos de privacidad) proyecto A:
El proyecto A es el proyecto que mejor implantación de Kanban ha tenido, gracias en gran medida, a un cliente muy colaborativo e implicado en esta forma de trabajar.
Hay un cuestionario desarrollado por el coach agile Christophe Achouiantz y que muestra en la entrada Depth of Kanban - A good coaching tool de su blog.
El cuestionario se basa en evaluar 7 dimensiones mediante preguntas que se responden con un sí o no. Cada dimensión se marca sobre un gráfico de tipo radar y podemos ver de forma visual cuál es la profundidad de Kanban para nuestro equipo.
Cuestionario adaptado a nuestro idioma:
Este cuestionario tienen que responderlo los miembros del equipo de cada uno de los proyectos.
Achouiantz habla de limitar el nivel según las respuestas, de manera que si, por ejemplo, en Visualización, la respuesta para la pregunta 4 es "no", no se contestan la pregunta 5 y siguientes. Esta restricción, si bien puede ser interesante, nos parecía que iba a desmotivar al equipo más de la cuenta, por lo que no la hemos aplicado. Quizás cuando volvamos a hacer la evaluación en un año seamos más exigentes.
En nuestro caso, tenemos equipos en los que hay varios desarrolladores, por lo que han tenido que contestar el cuestionario entre todos, ya que lo que se trata de ver es la profundidad del uso de Kanban por equipo de trabajo en un proyecto concreto.
Vamos a hablar sobre unos de nuestros proyectos, que llamaremos (por motivos de privacidad) proyecto A:
El proyecto A es el proyecto que mejor implantación de Kanban ha tenido, gracias en gran medida, a un cliente muy colaborativo e implicado en esta forma de trabajar.
Este proyecto tiene una gran base de código y tiene muchos retos tecnológicos, lo que hace complicado mejorar los procesos de desarrollo (ver dimensión Improve). En cambio, tanto el cliente como el equipo de desarrollo tienen una gran disciplina y una gran colaboración entre ellos, lo que se ve en las dimensiones Effects, Visualize y Limit WIP.
Como acabamos de implantar Kanban, todavía no tenemos los protocolos y flujos de trabajo definidos y aun no teniendo reuniones mensuales, la retroalimentación cliente-equipo de desarrollo es constante. Todo esto se refleja en el gráfico.
Si nos encontramos con una desviación de los tiempos lead muy grande, puede que tengamos los siguientes problemas:
Primero porque saber las horas de desarrollo puro nos permite ver si tenemos un buen rendimiento, aunque tampoco tenemos que obsesionarnos. Conocemos casos de ingenieros y desarrolladores que, en menos horas, realizan más trabajo que otros, por lo que no debemos tomar esta medida como algo absoluto.
Al comienzo de la implantación del proceso puede que haya muchas tareas que quiten tiempo de desarrollo, como se ve en esta gráfica.
Lo que es evidente es que realizar un cambio es algo complejo y requiere su tiempo, por lo que más que una carrera de velocidad, implantar una mejora en los procesos de trabajo de una organización, es una carrera de resistencia.
Como acabamos de implantar Kanban, todavía no tenemos los protocolos y flujos de trabajo definidos y aun no teniendo reuniones mensuales, la retroalimentación cliente-equipo de desarrollo es constante. Todo esto se refleja en el gráfico.
Métricas de Kanban
1. Lead
El lead es el tiempo desde que el cliente solicita una funcionalidad hasta que la ve implantada en el sistema.
Si nos encontramos con una desviación de los tiempos lead muy grande, puede que tengamos los siguientes problemas:
- Tamaños de tareas muy dispares.
- Cadencia de entrega de entrega muy irregular.
- Cuellos de botella en algunos estados.
- Demasiada concurrencia de tareas (o de proyectos).
El tiempo de desarrollo nos ayudará a saber si el problema es de desarrollo o de organización.
2. Cycle
Cycle es el tiempo desde que entra una tarea al equipo de desarrollo hasta que se incluye en producción.
Nosotros no usamos sólo esta medida, sino que nos hemos definido varios flujos de trabajo para medir los tiempos de espera:
- De desarrollo.
- De implantación en el sistema en producción.
Así podemos ver qué parte del proceso es la que está causando el cuello de botella.
3. Número de retrocesos de tareas
Esta métrica no la he encontrado en la bibliografía (supongo que no he buscado extensivamente), pero creo que puede ser interesante a la hora de detectar problemas de calidad en el proceso.
Se puede medir por proyecto, por estado que origina los retrocesos o incluso por desarrollador. La idea es ver si se está desarrollando software que no cumple los requisitos que se solicitaron, bien porque sea incompleto o porque esté mal.
También, puede que el software sea correcto, pero no tenga el código no tenga la suficiente calidad y en la revisión de código efectuada por un compañero, devuelva la tarea a un estado anterior.
En general, los estados de revisión son los que más retrocesos generan, tal y como se ve en esta gráfica.
Se puede medir por proyecto, por estado que origina los retrocesos o incluso por desarrollador. La idea es ver si se está desarrollando software que no cumple los requisitos que se solicitaron, bien porque sea incompleto o porque esté mal.
También, puede que el software sea correcto, pero no tenga el código no tenga la suficiente calidad y en la revisión de código efectuada por un compañero, devuelva la tarea a un estado anterior.
En general, los estados de revisión son los que más retrocesos generan, tal y como se ve en esta gráfica.
4. Velocidades y estimaciones de los tiempos de desarrollo
Para cada tarea deberíamos tener una estimación de su tiempo de desarrollo y registrar su tiempo efectivo de desarrollo al terminarla.
Primero porque saber las horas de desarrollo puro nos permite ver si tenemos un buen rendimiento, aunque tampoco tenemos que obsesionarnos. Conocemos casos de ingenieros y desarrolladores que, en menos horas, realizan más trabajo que otros, por lo que no debemos tomar esta medida como algo absoluto.
Segundo, porque podemos examinar el tiempo medio de desarrollo por tarea (y su desviación) para ver si estamos creando tareas de distintas clases o todas de un tamaño similar.
Por último, la diferencia entre tiempos estimados y efectivos nos permite conocer cómo de bien hacemos las estimaciones. Si hay una gran diferencia, eso implica que o nos falta experiencia, o no estamos realizando la división en tareas correctamente, habiendo tareas descritas de forma ambigua o muy poco específica.
¿Hay más mediciones?
La mayoría de los equipos de desarrollo estiman con puntos de historia en Scrum, pero en Kanban no los hemos aplicado esa estimación por varios motivos:- Inexperiencia del equipo: el equipo se formó hace escasos meses.
- Falta de conocimiento de algunos proyectos: en algunos proyectos de mantenimiento no se conocía al 100% su funcionalidad.
- Dificultad de trasladar los puntos de historia a horas reales de desarrollo para cada proyecto por la idiosincrasia de cada proyecto (algunos proyectos son de mantenimiento, otros de desarrollo y algunos tienen incidencias de distintos niveles de prioridad).
- Por supuesto, se pueden crear clases de tareas, de manera que existan incidencias críticas, mejoras, tareas de mejora intangible, etc. Cada clase de tarea tendría sus propias mediciones, lo que incluso puede permitir lograr acuerdos de nivel de servicio con los clientes.
¿Con qué frecuencia hacer las mediciones?
David J. Anderson nos cuenta en varias experiencias de su manual que el proceso de mejora tardaba 15 meses. Nosotros hemos hecho las mediciones iniciales 3 meses después de comenzar el proceso de implantación. Evidentemente los resultados se pueden mejorar, porque todavía estamos en los inicios.Lo que es evidente es que realizar un cambio es algo complejo y requiere su tiempo, por lo que más que una carrera de velocidad, implantar una mejora en los procesos de trabajo de una organización, es una carrera de resistencia.
Corolario: no te obsesiones con las métricas, preocúpate por la cultura de tu equipo
Comparto la opinión de Anderson en cuanto a que antes de comenzar cualquier proceso de implantación de Kanban, hay que mejorar el proceso de desarrollo. Para ello, tendremos que ver si el equipo genera código limpio y de calidad. Una alta deuda técnica hace imposible implantar este proceso. Si no hay una mentalidad de responsabilidad y exigencia con el trabajo de uno mismo, da igual el marco de trabajo que implantes, no tendrás buenos resultados.
El equipo tiene que tener claro que tienen que estar siempre mejorando su forma de trabajar. Un desarrollador que no esté formándose y tratando de hacer las cosas cada vez mejor, se queda atrás.
Kanban puede ayudar a que los desarrolladores sean más disciplinados, el equipo tenga mayor rendimiento y los interesados sepan lo que se está haciendo en cada momento, pero sin cultura de mejora continua, o kaizen, Kanban no sirve de nada.
¿Y vosotros qué marco de trabajo ágil usáis?
Y para dicho marco, ¿cómo medís el rendimiento de vuestro equipo ágil?
El equipo tiene que tener claro que tienen que estar siempre mejorando su forma de trabajar. Un desarrollador que no esté formándose y tratando de hacer las cosas cada vez mejor, se queda atrás.
Kanban puede ayudar a que los desarrolladores sean más disciplinados, el equipo tenga mayor rendimiento y los interesados sepan lo que se está haciendo en cada momento, pero sin cultura de mejora continua, o kaizen, Kanban no sirve de nada.
¿Y vosotros qué marco de trabajo ágil usáis?
Y para dicho marco, ¿cómo medís el rendimiento de vuestro equipo ágil?
Diego! gracias por el artículo...
ResponderEliminarActualmente tengo un equipo de jóvenes desarrolladores y hemos estado incrementando de forma constante las metodologías de desarrollo ágiles usando (en un principio) SCRUM, sin embargo las características propias de la empresa en donde las dinámicas pueden llegar a ser muy improvisadas o poco planificadas nos obliga a retrasar un poco el impulso en la planificación.
En este caso, y en función a la experiencias que tienen en Intelligenia, que recomendación nos darías? Debemos cambiar nuestra metodologías de trabajo o como podríamos convivir con un entorno hostil para la planificación?
Un saludo!
Hola Julio.
EliminarLo primero antes de implantar una metodología ágil es saber si el equipo está siguiendo un buen proceso de desarrollo de software. ¿A qué me refiero con esto? Me refiero a hacer un código limpio (https://blog.goyello.com/2013/01/21/top-9-principles-clean-code/), seguir los principios SOLID (http://yashchenkon.tech/SOLID/), la ley de Demeter, desarrollar funciones con baja complejidad ciclomática y tener comentarios de calidad. Si ya tenéis eso, perfecto. Ya tenéis ganado mucho. Si no lo tenéis, hay que empezar por ahí. Sin esta base da igual el marco que elijas, no va a funcionar.
Después se puede implantar el marco de trabajo ágil que os venga bien. Mi consejo es que antes de implantar Scrum, probéis con Kanban porque es mucho más flexible y más sencillo de implantar. En nuestro caso, nuestro equipo seguía proyectos muy heterogéneos y con alto número de incidencias (supongo que a esto te refieres a "hostil a la planificación"), por lo que un enfoque Scrum era demasiado rígido.
Ten paciencia y cuando el equipo haya asumido los principios de mejora continua, sólo entonces, estará preparado para el siguiente paso.
Un saludo.
PD: si te has quedado con alguna duda, puedes escribirme un correo (diego@intelligenia.com).