archivo

Archivo de la etiqueta: Kanban

Conseguir una mejora del Cycle time cuya repercusión en los resultados sea mayor que la inversión económica realizada y sin pérdida de calidad en el resultado final debe ser un objetivo de todo sistema de estas características (sea Kanban o cualquier otro que utilice estrategias similares).

De hecho la aplicación de Kanban pretende de entrada detectar qué aspectos están afectando al Cycle time y posteriormente detectar de la manera más temprana posible esos cuellos de botella (pretende, por tanto, detectar resistencias y atacarlas con el objetivo de reducir su impacto).

No podemos olvidar que lo más importante siguen siendo las personas, su interacción, sus conocimientos y su capacidad, factores que influyen notablemente en el Cycle time, además de otros aspectos, como los medios disponibles y la tecnología.

Tal y como decía en el primer párrafo, la mejora del Cycle time no debe hacerse a expensas de la calidad del software o al menos debe sopesarse qué supone una cosa y qué supone otra. De nada vale entregar antes pero que el producto resultante sea peor, se llega antes, pero después se tendrá que invertir esfuerzo en dar una solución a los defectos o a reenfocar aspectos funcionales o no que se podían haber hecho mejor si se le hubiera dedicado una mayor atención.

La definición del flujo de trabajo es algo que está abierto y es lógico que así sea porque cada equipo de trabajo y cada proyecto tiene sus peculiaridades.

Es frecuente encontrarnos con tableros que no tienen una fase para el testing y suele ser provocado porque se entiende que de manera implícita se encuentra en la fase de realización, construcción, desarrollo o como se quiera llamar.

Conociéndonos como nos conocemos los desarrolladores y nuestras prácticas habituales de no probar de manera adecuada los componentes que construimos es una buena idea incluir una fase de testing de manera explícita. Es cierto que no te asegura nada (hacer testing requiere de disciplina y buenas prácticas) pero el simple hecho de considerarse una actividad y visualizarse es algo que tiene mucha fuerza.

Por ese motivo, aunque creas que la inclusión de esa fase no aporta nada, prueba a hacerlo y tras un tiempo, trata de sacar conclusiones de manera objetiva a través del número de defectos que se hayan conseguido solventar antes de alcanzar producción en comparación con los valores que estuvieras obteniendo hasta ahora, a partir de ahí ya tendrás todos los datos necesarios para continuar con estas prácticas de manera general, en proyectos o sprints concretos o tomar la decisión de, como hasta ahora, no incluirla.

Veamos una posible implementación Scrum-dominante. Dentro del flujo de trabajo que se defina en un tablero Scrum, supongamos que se definen un conjunto de fases tan simple como: Sin iniciar, en construcción, testing y finalizada, y para una o más de ellas se establece un límite de tareas abiertas de manera que si se alcanza el límite ninguna tarea más puede entrar en esa fase, lo que hace que los esfuerzos se deban enfocar en eliminar ese cuello de botella: deben salir tareas para que puedan entrar otras. De esa manera se pretende detectar problemas lo más próximo posible a su origen para tratar de resolverlos lo antes posible (filosofía lean).

Veamos ahora una posible implementación Kanban-dominante. En este caso, el sprint está abierto, pueden ir entrando nuevas tareas siempre y cuando no se sobrepase el WIP definido.

Llegado un punto (se puede denominar punto de ajuste) tendremos que ir cerrando la iteración, lo que obligará a centrarnos en aquellas tareas en ejecución que se consideren más prioritarias, lo que implicará que determinadas tareas ya iniciadas pasen a ser trabajadas en futuros sprints. Ese punto de ajuste deberá realizarse con suficiente antelación porque de lo contrario puede haber un mayor número de tareas que queden abiertas y/o que dentro de las que ya se ha comenzado a trabajar haya algunas prioritarias que queden sin ser atendidas.

Hemos visto dos posibles implementaciones, en función de que se pretenda que predomine Scrum o Kanban. También existen otras en las que pueden convivir ambas estrategias, una de ellas puede consistir en que el sprint se realice según las prácticas de Scrum y por otro lado, tener reservada cierta capacidad del equipo de trabajo para resolver incidencias u otro tipo de peticiones que tengan que ser atendidas con urgencia sin alterar los compromisos adquiridos en la iteración (pila de sprint).

Esta capacidad se regiría por prioridades y limitando el WIP.

Esta última implementación me parece muy interesante y es bastante efectiva. Puedes empezar a practicarla sin definir WIP (aunque ya no estaríamos aplicando Kanban) y más adelante empezar a ajustar límites en determinadas tareas del flujo.

Scrumban es el resultado de combinar prácticas de Scrum con Kanban. Sería más ortodoxo decir que es la combinación de Scrum (puro) con Kanban pero la realidad es que no son muchos casos en los que organizaciones o equipos aplican Scrum al pie de la letra y no es porque no exista voluntad de hacerlo, sino porque la realidad de muchos proyectos lo impide.

Es cierto que la Scrum Guide dice que si solo se implementan partes concretas de Scrum no se puede considerar Scrum, y lo respeto, por ese motivo prefiero hablar generalmente de prácticas de Scrum en lugar de utilizar de manera rotunda la palabra Scrum.

No obstante, en este artículo cuando la utilice, me gustaría que lo entendieráis como su conjunto de prácticas (roles, eventos, etc…), independientemente de que las utilice todas o no o haya alguna sobre la cual se aplique un enfoque diferente, ya que resulta más interesante entrar a analizar cómo se puede combinar con Kanban.

Realmente y como os he insistido en muchas ocasiones, no podemos considerar una herramienta, una metodología o una estrategia por muy interesante y práctica que ésta sea como para que todo nuestro trabajo gire alrededor de ella. Le damos el valor que se merece pero nunca por encima de las necesidades de un proyecto, sin hiciéramos lo contrario no estaríamos siendo ágiles.

Hay muchas implementaciones posibles de Scrumban porque se trata, como dice, Henrik Kniberg de obtener lo mejor de ambas. Os recomiendo la lectura de su libro: “Kanban y Scrum, obteniendo lo mejor de ambos”.

Simplificando, podríamos decir que se trataría de añadir el concepto de gestión visual del flujo de trabajo (si bien esta práctica se aplica prácticamente de serie en muchos equipos que utilizan Scrum) y el WIP (Work in Progress) a Scrum, con el objeto de detectar cuellos de botella dentro de cada sprint. Sin embargo, depende mucho de la implementación que se vaya a realizar, ya que si un equipo está habituado a trabajar con Kanban, podría decirse que Scrumban se trataría de añadir el concepto de sprint a Kanban.

También existen estrategias que combinan en flujos de trabajo diferentes ambos enfoques.

En el siguiente artículo veremos algunos ejemplos de implementaciones de Scrumban.

Mientras el producto no esté en producción y, por tanto, no empiecen a llegar incidencias con diferente grado de prioridad y en cualquier momento, puede resultar relativamente sencillo mantener un determinado nivel de predecibilidad en los sprints, de manera que salvo errores importantes en las estimaciones se ejecutarán la mayor parte de las historias de usuario o incluso todas ellas.

Sin embargo, en el momento en que empiezan a llegar incidencias, la cosa cambia. Si no tienes capacidad de “reserva” para afrontarlas tocará tomar determinadas decisiones y para ello nos podemos hacer una serie de preguntas:

– ¿Dejo las incidencias para el siguiente sprint?.

Dependerá de la urgencia de las mismas y de lo que queda para que finalice el sprint, habrá veces en que se pueda aplazar al siguiente sprint, otras en las que incluso se dejará para más adelante y otras donde la criticidad haga que tengas que ponerte con ellas nada más conocer de su existencia.

– ¿Anulo el sprint e inicio uno nuevo en el que ya tenga en cuenta estas incidencias que han llegado?.

En este caso dependerá del número de incidencias y de su complejidad (además, como es lógico de su criticidad). Si vamos a tener que dedicar gran parte de la capacidad a trabajar en ellas, mantener el sprint definido deja de tener sentido. ¿Es la solución definir un nuevo sprint? Sí, pero en situaciones de inestabilidad, tal vez lo mejor sea que tengamos más peso de Kanban que de Scrum.

– ¿Cambio alcance del sprint de manera que sustituyo la realización de determinadas historias de usuario a cambio de las incidencias?.

Puede ser bastante práctico pero dependerá de las incidencias que lleguen porque si terminan desvirtuando el sprint, tal vez lo mejor sea cambiar de enfoque.

– ¿Introduzco las incidencias como parte del alcance del sprint, retrasando la finalización del mismo?.

La respuesta es similar a la anterior y dependerá también del contexto y situación del proyecto, de las incidencias y de lo que pueda aportar a la productividad de los equipos y a la efectividad de los trabajos mantener inamovibles la fecha de finalización de lo sprints.

Lo que quiero que saquéis como conclusión es que no es posible formular una solución que valga para todo. Tenéis que analizar qué os conviene más y siempre con una mentalidad abierta, más allá de la ortodoxia de la aplicación de una determinada estrategia o metodología.

No obstante, puede ser interesante, aún no siendo tampoco una solución universal, dejar siempre capacidad libre del equipo para atender a estas incidencias, de manera que no sea necesario mover el alcance del sprint salvo situaciones de saturación. Esa capacidad variaría en función de la estabilidad del producto y de las implantaciones (y de su importancia) que se estén realizando en ese momento.

¿Y si no se usa esa capacidad? Esa capacidad sobrante se puede utilizar para muchas cosas, desde tareas propias de infraestructura, programación por pares, realizar actividades opcionales sobre determinadas historias de usuario, etc…

Si no se acota la cantidad de trabajo que se puede asumir a la capacidad real existente, quiere decir que el ritmo del proceso de desarrollo no lo marca la cantidad de trabajo que podemos sacar sino la cantidad de trabajo que entra y eso a corto, medio y largo plazo resulta perjudicial porque resulta muy complicado volver a encontrar el equilibrio.

¿Qué pasa cuando se satura un servidor o un PC? Que el rendimiento de los procesos abiertos cae en picado, pues exactamente lo mismo pasa cuando saturamos la línea de trabajo.

Por ese motivo insisto que un departamento TIC no debe decir a todo que sí, sino que debe ajustar su servicio a lo que realmente puede admitir y lo que no entre ahí tendrá que esperar. El problema es que como los departamentos TIC no pintan nada, aunque digan que no, habrá alguien más arriba que dirá que sí y empiece a saturar con ese tipo de decisiones a la capacidad de trabajo existente.

El problema no es solo ese, sino que además los departamentos TIC, como consecuencia de la crisis económica, cuentan con menos presupuesto, por lo que con cada recorte se desborda la capacidad, ya que con menos personal se deben seguir prestando los servicios básicos a la organización que además, crecen con el tiempo, al existir un mayor número de sistemas en la organización y ser cada vez más críticos en sus procesos internos y de negocio. Si a esto le sumas esa carga adicional de trabajo, por mucha voluntad que se ponga, la calidad del servicio caerá en picado.

El ritmo lo debe marcar lo que sale, porque las tareas que conseguimos terminar son las que determinan nuestra capacidad real y las que permiten dejar un hueco para que se pueda trabajar sobre otra.

En los proyectos de desarrollo de software pasa lo mismo, si trabajamos sobre demasiadas tareas de forma simultánea el esfuerzo y tiempo necesario para la realización de las mismas será mayor (incluso mucho mayor) que si las mismas estuvieran ajustadas a la capacidad del equipo, además, se corre el riesgo de que muchas de ellas queden abiertas indefinidamente si su prioridad no es muy alta, ya que seguirán entrando nuevas tareas y la presión y la carga de trabajo tiende a hacer que se centre el esfuerzo en ir cerrando todas las tareas que se puedan, que generalmente serán aquellas más simples y/o con mayor prioridad.

Una de las grandes aportaciones de la orientación a sprint (se siga Scrum o no) o de la aplicación de Kanban la tenemos en que se trata de limitar la cantidad de trabajo absorbible a la capacidad real de trabajo que puede admitir el equipo (limitación del WIP: Work in progress).

Realizar una correcta gestión de las expectativas es fundamental en todo proyecto de desarrollo de software. Hay que ser muy constante en este aspecto porque aunque se piense que las expectativas están bajo control, las mismas van a variar con el tiempo, ya sea por la propia evolución del proyecto o por presiones que se reciban desde el exterior.

Los responsables funcionales te van a apretar porque tienden a exigirte un mayor alcance y en un menor tiempo de lo pactado. Tienen que comprender (y tener una cierta experiencia) cómo funciona un proyecto con prácticas de Scrum para que sean más moderados en sus peticiones de modificación del sprint, sin embargo, cuando ellos mismos están recibiendo presiones, les resulta complicado no traspasarte, aunque sea, parte de ellas.

Precisamente por este motivo se agiliza en muchos casos las prácticas de Scrum con Kanban, pero esto simplemente trata de definir determinadas reglas del juego, la complejidad realmente se encuentra en mantener un equilibrio entre lo que el usuario desea y lo que realmente se puede hacer (o lo que realmente se considera práctico realizar), porque está claro que el usuario manda, pero también debe ser consciente, y para eso estamos nosotros, de la complejidad que tiene la realización de una determinada solución.

Es importante poner las cartas sobre la mesa y a partir de ahí que decida. No vale con ser simplemente ejecutores de historias de usuario, también tenemos que proporcionar ese valor a los product owners porque se trata de aprovechar de la mejor manera posible la inversión, de manera que consigamos ganar el mayor valor posible con el menor esfuerzo y de no complicar de manera innecesaria el producto.