archivo

Archivo de la etiqueta: Scrum

Si se orienta el desarrollo a sprints (hay que tener en cuenta que el enfoque iterativo incremental es en sí un concepto más amplio) es, entre otros motivos, para conseguir un ritmo sostenible en el desarrollo.

Por eso cada sprint requiere tener preparada de antemano la materia prima, es decir, todos los inputs que necesita para poder ser completado, de lo contrario se tendrá que invertir tiempo en él para obtener esa materia prima, con el riesgo de producirse bloqueos por falta de esas entradas, lo que lo hará menos productivo y menos predecible en cuanto al cumplimiento de los compromisos.

Nos quejamos muchas veces y con razón de la falta de medios económicos para llevar a cabo el proyecto (acorde a las expectativas puestas en él y los plazos) y también de la falta de colaboración del área usuaria. Sobre esto último pocas veces nos paramos a pensar en los motivos que hacen que los usuarios no colaboren.

Uno de ellos puede ser precisamente la falta de medios para proporcionarnos la información y entregables que, una vez interpretados, conforman la materia prima de cada sprint. Es decir, muchas veces el product owner quiere pero no puede.

Se sobreentiende que quien contrata el trabajo ha tenido en cuenta esa carga de trabajo adicional (que en función del tipo de proyecto puede ser muy grande para las personas implicadas), sin embargo no es lo normal, ya que se piensa que con apoyos puntuales es suficiente, creyendo que el equipo de proyecto puede con todo y no, no puede, y si me apuráis, no debe, porque la carga de especificación del sistema debe recaer en el área usuaria.

Las consecuencias de esto es que determinadas tareas del sprint no estarán lo suficientemente definidas y eso hace mucho daño a esta dinámica de trabajo, tanto que nos deberíamos plantear, probablemente, objetivos menos ambiciosos.

Os indico a continuación algunas alternativas y aunque soy de la opinión de intentar reconducir la situación, no siempre va a ser posible:

– Adecuar la capacidad del equipo de proyecto a la carga del área usuaria. De nada vale tener una maquinaria capaz de producir x productos al día si solo entra material para producir x/4 productos.

– Plantear un enfoque iterativo incremental con fases de definición (con el nivel de detalle suficiente para el proyecto y la iteración) entre sprints. En este caso es más impredecible la duración de la fase de análisis pero más predecible la construcción.

– No plantear sprints propiamente dichos y aplicar estrategias de gestión del flujo de trabajo y del WIP (Work in progress), como por ejemplo, definiendo límites en el número de elementos terminados y no pasados a producción o dejando ese aspecto abierto y limitando el número de tareas en fase de análisis.

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.

Aplicando prácticas de Scrum y si me apuráis, por puro sentido común, tenemos que tener como objetivo que el resultado de cada sprint sea una versión entregable y por tanto, que se pueda pasar a producción.

Es muy importante desarrollar con intención para reducir el número de iteraciones (o dicho de otra forma para ganar en cantidad de trabajo efectivo por unidad de tiempo o lo que es lo mismo para ganar en productividad), para ello debemos minimizar (siendo el objetivo máximo eliminar), el número de componentes (funcionalidades) defectuosas que llegan al final del sprint (y por extensión a producción).

Para ello cada historia de usuario debe estar completamente terminada. ¿Qué es eso? Desde luego no es programar las tareas en que se descompone la historia y hacer cuatro pruebas, sino de tener la certeza de que efectivamente funciona, lo que implica una buena batería de testing y la verificación de que efectivamente cumple con las expectativas del usuario.

Una primera aproximación a esto último son las medidas para verificar la misma que aparecen en la historia de usuario, en las cuales tenemos que minimizar las ambigüedades para poder dar por bueno o rechazar la misma, ya que no debería haber medias tintas.

Estas medidas pueden estar implícitas en la propia descripción de la historia o separadas en un apartado diferente de la misma.

Otra cosa es que después, el product owner o por extensión los usuarios, se den cuenta de que la especificación realizada no satisface sus expectativas, en este caso el problema está en la especificación y para solucionarlo se requerirá evolucionar (modificar) esa funcionalidad en uno de los siguientes sprints.

Si aplicamos las prácticas de Scrum de pila de sprint y que la misma no se debe modificar una vez definida e iniciados los trabajos nos encontramos ante una situación problemática si aparece una urgencia que es necesario tratarla a corto plazo.

Antes de nada lo que hay que hacer es analizar lo crítica que es la urgencia o lo que es lo mismo, ¿puede esperar a que terminemos el sprint y se pueda tratar en el siguiente?. Esto es importante porque no todo lo que parece urgente lo es realmente como para tener que romper una dinámica de trabajo.

Si efectivamente no puede esperar, tenemos que adaptarnos a esa circunstancia, ya que sería mucho más perjudicial no hacerlo. No sería ágil aferrarnos a la metodología.

¿Qué hacemos?

Hay diferentes alternativas y a priori ninguna tiene que ser necesariamente la mejor, ya que sería necesario conocer las circunstancias concretas del proyecto.

– Se anula el sprint y se inicia uno nuevo con esa tarea y las del anterior sprint que se consideren convenientes (como mínimo las que ya estén terminadas).

– Se intercambian tareas ya definidas en el sprint por la nueva tarea, teniendo en cuenta que el esfuerzo restante en las mismas debería ser mayor o igual que el de la misma tarea.

– Lo mismo pero considerando la nueva tarea fuera del sprint, es decir, se resta capacidad de la línea de trabajo para asignársela a la nueva tarea para pasar el cambio a producción cuanto antes.

– Similar al caso anterior pero realizada por una persona de fuera del equipo (esto solo funcionaría con tareas que no requirieran un conocimiento profundo de la arquitectura, tecnología o el negocio).

– Se incluye la nueva tarea y se alarga la fecha de finalización del sprint.

Y seguro que se os ocurren otras tantas. Y os digo lo de siempre, lo importante es el producto no la metodología.

Otra estrategia puede consistir en prever que este tipo de circunstancias se pueden producir en el proyecto, para ello os recomiendo leer los siguientes artículos:

Incidencias e iteraciones I.
Incidencias e iteraciones II.

Confundir agilidad con Scrum y Scrum con agilidad es algo muy frecuente. Scrum es solo un marco de trabajo, un contexto que favorece un enfoque ágil, pero lo que realmente marca la diferencia en cuanto a la agilidad son las personas.

Por eso es fundamental incidir sobre las bases de lo que es la agilidad, recogidas en el Manifiesto Ágil, entenderlas es esencial, sentirlas más todavía.

Si dejamos que sea Scrum quién se encargue de la agilidad, estamos dejando todo en manos de su implementación y al final, no se hace otra cosa que seguir una metodología, después el día a día y las actuaciones que se realicen en el proyecto pueden derivar en un enfoque que no tiene nada que ver con la agilidad.

Si extendemos la agilidad más allá de lo que es el desarrollo de software y la extendemos al funcionamiento de un departamento TIC, la implantación de la misma puede empezar por un punto concreto, por ejemplo los proyectos, pero si realmente se quiere un funcionamiento ágil del mismo, no te puedes basar exclusivamente en ese punto concreto: “Utilizamos Scrum y ya somos ágiles”, sino que la agilidad debe implantarse como filosofía y como método en todas las áreas del departamento y para ello es fundamental que las personas entiendan, comprendan y compartan esta forma de trabajar.

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…

¿Qué es Scrum?, ¿un proceso o un marco de trabajo?, una cosa es lo que piense y otra lo que se hace realmente.

La agilidad es colaboración entre personas y capacidad de adaptación al contexto y al cambio, esto implica que en esencia y de partida no te debes “casar” con ninguna estrategia, metodología o práctica de desarrollo ya que debes seleccionar aquella que mejor se adapte a las condiciones y contexto del proyecto y cambiarla parcial o totalmente si hiciera falta por la propia evolución del proyecto (por la propia necesidad de adaptación al cambio).

Querer aplicar Scrum sí o sí no es ágil en esencia. Aplicarlo en contextos donde sí sea una estrategia favorable pero limitarte por la ortodoxia de las prácticas tampoco es ser ágil. Lo que es ágil es tener la mente abierta a elegir las prácticas que más pueden convenir al proyecto, adaptar aquellas otras que lo requieran y descartar las que no procedan.

La ortodoxia por encima de todo convertirá a Scrum en un proceso y precisamente no es eso lo que queremos. Por eso siempre insisto a las personas que se están iniciando en el agilismo en que no se limiten exclusivamente a leer o asistir a conferencias y cursos (que por otra parte serán interesantísimos y serán atajos para comprender conceptos y comportamientos que llevan tiempo y experiencia aprender y sobre todo asimilar) sino que experimenten desde las bases del Manifiesto Ágil.

Es cierto que Scrum es la suma de sus prácticas debidamente ejecutadas en un proyecto. Por eso cuando trato de hablar sobre qué estrategias, prácticas o metodologías suelo aplicar en mis proyectos trato de indicar que, entre otras, utilizo algunas prácticas de Scrum.

Soy de la opinión de que cada organización y cada proyecto presenta sus peculiaridades y que cuanto más nos adaptemos a ellas más probabilidad existe de que el proyecto salga adelante. Por ese motivo no hay que cerrarse entre las cuatro paredes de una metodología, la agilidad implica ser flexible y esto supone que siempre hay que poner por encima la actitud ágil que cualquier estrategia que quieras aplicar.

No se trata de reinventar la rueda sino de aplicar en base a lo que conoces de la organización, del proyecto, de tu propio equipo, del cliente y en base a tu conocimiento y tu experiencia los ingredientes que consideras necesarios, ¿qué después habrá que seguir puliendo? pues lo más probable es que sea así ya que los proyectos no son lineales y lo que funciona hoy no tiene por que ser lo más adecuado mañana.