¿Tiene interés representar en un burndown el esfuerzo real?

En un burndown se suele representar una recta que representa la proyección lineal del tiempo restante para completar el sprint con respecto a la duración del mismo y otra línea que representa diariamente el restante real.

Si la línea del restante real se encuentra por encima o por debajo de la proyección lineal se puede decir que vamos peor o mejor de lo esperado respectivamente.

Por tanto, si tenemos ese dato, ¿tiene interés representar una línea con el esfuerzo real?. Desde mi punto de vista, dependerá si de alguna forma queremos representar el esfuerzo que supone conseguir avances en el sprint, ya que se pueden invertir horas en una historia de usuario y que el tiempo restante no disminuya en la misma proporción y también puede pasar que la dedicación real de algunos de los desarrolladores en el sprint sea superior a la jornada laboral que esté fijada.

De esta forma podemos tener un sprint que puede ir bien con respecto a lo esperado pero que sin embargo esté suponiendo un esfuerzo significativo para el equipo y esto puede tener consecuencias en los próximos sprints, ya que el overtime termina afectando al rendimiento de las personas, por lo que puede ser necesario tomar decisiones como, por ejemplo, modular la velocidad del equipo a estas circunstancias, analizar los motivos que han dado lugar a que las estimaciones realizadas no hayan sido acertadas o a que el trabajo no se haya realizado con la fluidez deseada.

Es cierto que estas conclusiones se pueden sacar al final, no obstante, si se hace un análisis a diario es posible tomar determinadas decisiones dentro del sprint que puedan solucionar alguno de los problemas que provocan esta situación.

Tareas, pruebas, tiempo restante

Una tarea (que puede ser una subdivisión de una historia de usuario o una historia de usuario propiamente dicha) puede considerarse terminada bien cuando el desarrollador o desarrolladores la hayan finalizado y probado o bien cuando esa tarea de testing la haga un tercero, en ambos casos, nos puede surgir la siguiente pregunta: si las pruebas han sido correctas, ¿debemos considerar que el tiempo restante es 0?.

¿Qué puede pasar? Que cuando integremos con terceras historias aún en construcción o incluso todavía no iniciadas nos demos cuenta que existen errores en la que hemos dado por terminada y, por tanto, que el tiempo restante ya no sea cero, de manera que nuestras previsiones o expectativas si tomamos como referencia, por ejemplo, un burndown, se vean afectadas, sobre todo, si el defecto encontrado es importante.

La alternativa a no considerar el tiempo restante es 0, es dejar un cierto margen de tiempo restante en función de las probabilidades de error en la integración del componente, de su complejidad, criticidad, etc…, pero en cualquier caso, estaríamos especulando y, pese a que pueda considerarse una postura conservadora, no refleja con fidelidad el estado del sprint.

Por tanto, soy de la opinión de que cuando una tarea se considere terminada (eso sí, con una batería de pruebas ejecutada correctamente y que sea adecuada a su naturaleza) se considere que el tiempo restante sea 0, con independencia de que posteriormente sea necesario realizar reajustes en el mismo como consecuencia de problemas que se vayan detectando.

La huida de actividades que no aporten valor al producto

Nuestro objetivo y el del cliente debe ser tratar de conseguir el mayor valor posible para el producto, lo cual requiere que se haga un uso racional de la inversión ya que de esta forma tendremos la posibilidad de obtener un mayor rendimiento de las iteraciones.

Para eso es muy importante desarrollar con intención, lo que requiere una alta implicación de todos los stakeholders del proyecto, sobre todo del responsable funcional, de las personas que colaboran con él y del equipo de desarrollo.

Sin embargo, la falta de intención no es el único factor que puede hacer que no se extraiga el mayor aprovechamiento posible de la inversión, hay otro muy importante que son las actividades de proceso o metodología, ya sea incluidas por el propio equipo de desarrollo o por la organización, que generan entregables que no aportan un valor real al producto y al proyecto.

Este mal es muy común en organizaciones que entienden que la singularidad de los proyectos es algo secundario y que todos deben tener un cuerpo de procesos común. Esto es lo mismo que pretender que una misma talla de ropa sirva para todos los componentes de una familia.

Parto de la base de que la organización necesita armonizar determinadas actividades de los proyectos, requiere recibir unos inputs necesarios para su gestión y para mantener un cuerpo de conocimiento. Soy de la opinión de que la base deben ser unos mínimos, comunes a todos los proyectos, con la mentalidad abierta a crear excepciones si fuera necesario (teniendo en cuenta que la excepción no se debe convertir en la norma) y que a partir de ahí, sea el proyecto quien mande, alcanzándose acuerdos para ampliar esa base de procesos si todas las partes entienden que aporta valor.

El problema lo tenemos cuando no se parte de mínimos y cuando se intenta encorsetar el desarrollo con actividades, sean pocas o muchas, que no solo restan flexibilidad al proyecto sino que originan costes en tareas y entregables cuyos coste de realización (y mantenimiento) son superiores al valor que proporcionan al producto y a la organización.

Evita el despilfarro

Tu reputación, tus alianzas, la búsqueda de la oportunidad y tu adaptación a los precios de mercado resultan fundamentales para ser competitivo en un ecosistema tan difícil como es el de los servicios de desarrollo de software o el de sus productos.

Una vez conseguido el contrato, si el mismo se encuentra dentro de unos parámetros razonables de alcance y precio, existirá probabilidad de conseguir beneficios si hay un buen entendimiento con el cliente, en el que se repartan responsabilidades y se conozcan las reglas del juego y si se es productivo (existen, todos los sabemos, infinidad de circunstancias que pueden complicar un proyecto, lo que he hecho es señalar un contexto que, de entrada, puede ser favorable).

Ser competitivo y poder sobrevivir de manera adecuada incluso en períodos de escasez requiere la adopción de una serie de medidas, una de ellas es evitar el despilfarro, entendiéndose éste como todo gasto totalmente innecesario y con bajas expectativas de retorno, siendo su gravedad proporcional al importe y a su posible carácter estructural.

Dentro del ámbito de un proyecto, el despilfarro (generalmente provocado por el cliente, pero en muchos casos alentado por el proveedor) se centrará en el desarrollo de funcionalidades innecesarias, en añadir complejidad adicional, en reinventar la rueda, en la pérdida de un ritmo de desarrollo y en la falta de intención. También lo podremos encontrar en procesos que no se adaptan a la naturaleza del producto a desarrollar y que provoca la generación de entregables sin utilidad real para el proyecto.

A más alto nivel, una organización despilfarra cuando contrata proyectos de desarrollo o productos que no necesita o para procesos que, por su inestabilidad, sería aconsejable esperar tiempos mejores. También se tira el dinero cuando se contratan servicios con un nivel de calidad o servicio superior al que se necesita, esto es equivalente a comprar mucha más comida de la que necesita y a llenar semanalmente el cubo de basura con todo lo que se ha echado a perder o llenar un almacén con más materia prima de la que se necesita incurriendo en los siguientes costes: gasto de almacenamiento y gasto por la materia prima adicional (que se puede deteriorar por el paso del tiempo).

Ese despilfarro se termina convirtiendo en estructural en el momento en que esos sistemas o productos se convierten con más o menos éxito en herramientas de trabajo, lo que obliga a seguir invirtiendo en ellos.

Este crecimiento sin orden y sin medida, basado en la suposición de que cada vez se va a tener más presupuesto, termina por colapsar en el momento en que se interrumpe ese flujo de dinero, que provocará que el mantenimiento y soporte para muchas de esas aplicaciones o productos sea precario o inexistente.

En períodos de abundancia parece que todo vale y nada importa, pero cuando las cosas no van bien, te acuerdas de cada céntimo de euro que has tirado o que tienes comprometido en proyectos, productos o servicios prescindibles. No se trata de mirar por el dinero exclusivamente cuando todo va mal, ya que lo mismo es demasiado tarde, sino de saber qué se está haciendo cuando se tiene éxito.

Desarrollo de software. Sé flexible ante otros enfoques, estrategias u opciones

Miyamoto Musashi fue un famoso guerrero samurai de la primera mitad del siglo XVII y autor del tratado de artes marciales llamado «El libro de los cinco anillos».

Entre sus numerosas citas se encuentra la siguiente: «No guardes apego a ningún tipo de arma o a ninguna escuela de lucha».

Esa reflexión resulta muy apropiada para mostrarnos que independientemente de que pensemos que unos determinados tipos de enfoque, estrategias o prácticas son más óptimas en términos generales, es posible que nos encontremos con proyectos o situaciones dentro de los mismos donde sea más recomendable elegir otras opciones.

A lo único que debemos tener apego es a a nuestro deseo de sacar el proyecto adelante para cumplir con las expectativas del usuario (cliente) y las nuestras, todo lo demás son instrumentos para conseguir ese fin, por ese motivo, aunque cueste, es necesario tener abierta la mente a otras posibilidades, incluso a aquellas en las que no creemos.

No hacerlo es ponernos limites y restricciones artificiales, y ya son muchas las resistencias con las que nos encontramos como para que seamos nosotros mismos lo que nos echemos más piedras a la mochila.

Desarrollo de software. Funcionalidad crítica, sprint, no llegamos

Nos encontramos con la siguiente situación: tenemos un sprint en el que es necesario modificar una funcionalidad crítica del sistema (motivada, por ejemplo, por un cambio normativo) y se tiene que hacer de una vez (no podemos dividirla en historias más simples) ya que si no se ejecuta de esa manera no va a funcionar cuando la pasemos a producción.

En ese sprint, además, hay otras historias de usuario que se están desarrollando y en un equipo en paralelo tenemos a personas solucionando incidencias, cuya entrega se iba a sincronizar con el sprint. En un determinado momento, nos damos cuenta de que no vamos a tener la funcionalidad lista para la fecha de finalización del sprint, ¿qué hacemos?.

Hay diferentes posibilidades. La solución a aplicar podría ser diferentes en cada proyecto:

– Lo más tentador es retrasar la fecha de finalización del sprint. A mi personalmente no me gusta y creo que solo se debería hacer en el caso de que no hubiera otra salida. ¿Por qué? Creamos un precedente y más pronto que tarde nos volveremos a encontrar con una nueva situación, en este caso con menos criticidad, en la que se termine aplicando la misma solución y se entra de esta manera en un bucle nada beneficioso.

– Reducir el alcance del sprint, centrando los esfuerzos en la funcionalidad crítica. Podría funcionar si se detecta pronto la desviación y si el fallo en la estimación del esfuerzo de construcción de la funcionalidad crítica no es muy sensible. Si se aplica esta estrategia habrá historias de usuario comprometidas que no se podrán completar.

– Incrementar la capacidad del equipo. Esto solo va a funcionar si las personas que se incluyen en el equipo conocen la tecnología, las dinámicas de trabajo o si las tareas a realizar no requieren ese nivel de especialización. Podría valer con incrementar la dedicación de personas que no estén a tiempo completo en el proyecto o pasar personas del equipo de resolución de incidencias al equipo del sprint. Esta estrategia podría combinarse con la anterior.

– Completar la funcionalidad crítica en el siguiente sprint, es decir, el sprint termina con las historias de usuario que se hayan podido completar y en el nuevo sprint se sigue trabajando con ella.

La decisión a adoptar debe contar con el consenso del responsable funcional porque afecta a los plazos en que determinadas funcionalidades se incorporan, modifican o corrigen en el sistema, también es importante mantener la calma con el objeto de aplicar la solución más adecuada. En la retrospectiva es fundamental que se analice en qué se ha fallado y se tomen las medidas oportunas para reducir la probabilidad de que este problema se vuelva a producir en un futuro.

Mary Poppendieck. Desarrollo con intención

Mary Poppendieck realiza la siguiente reflexión: «No tome decisiones irreversibles demasiado pronto, retrasa las decisiones de diseño todo lo que sea posible, de manera que cuando las tengas que tomar, lo hagas con la mejor información disponible para hacerlas correctamente».

Tiene razón, pero lo que pide es difícil. Requiere que el Product Owner tenga una visión sólida del producto, conozca bien el negocio y tenga el apoyo por parte del equipo de desarrollo sobre qué funcionalidades una vez construidas son más costosas de modificar.

Poppendieck, lo que recomienda es que se desarrolle con intención, sabiendo lo que se hace, para de esta forma reducir el número de iteraciones. Aún así, la especulación a veces es inevitable porque el responsable funcional no tendrá claro siempre si la solución que propone es la mejor o qué reacción va a tener el conjunto de usuarios ante las mismas.

El objetivo es conseguir cada vez un mayor valor para el producto con una inversión ajustada a ese incremento. A veces tendremos más éxito que otras, porque equivocar nos equivocaremos ya que el desarrollo del producto es evolutivo y en él nos daremos cuenta no solo de nuevas funcionalidades que son necesarias, sino de algunas ya implementadas que son mejorables.

Por ello, siguiendo las recomendaciones de Poppendieck, el desarrollo debería comenzar por lo más prioritario y dentro de ello por lo que se tenga más claro en ese momento, si se tienen dudas sobre una funcionalidad y se prevé un coste de modificación alto (por sí misma o por su impacto sobre terceros desarrollos), mejor esperar, si se puede, un poco más.

Estimación, cuidado con las condiciones ideales

Un error muy frecuente que nos encontramos con las estimaciones lo tenemos en pensar que se van a dar condiciones ideales: no se van a sufrir interrupciones inesperadas, no vamos a sufrir contratiempos técnicos y la capacidad calculada para cada persona no va a sufrir cambios (en el momento en que una persona por el motivo que sea no puede ir a trabajar un día, rompe ya los esquemas).

Si a eso le sumamos lo difícil que resulta acertar, estamos sometiendo cada sprint a una presión que los desarrolladores no van a poder aguantar porque la realidad será que para cumplir los compromisos se tendrá que incrementar la capacidad de todos y eso se traduce en overtime. El otro camino es dejar historias de usuario comprometidas para más adelante (sacarlas de la pila de sprint). Ambas soluciones son malas. La primera porque no es sostenible, ya que incluso los equipos más motivados no pueden aguantar un ritmo por encima de sus capacidades físicas durante un tiempo prolongado y la segunda porque perdemos predecibilidad y fiabilidad.

Ten en cuenta en que fase del proyecto te encuentras, no tienes el mismo conocimiento al principio que tras la sexta o séptima iteración y ten en cuenta que no se puede asegurar capacidades del 100% de nadie. Se puede estar asignado al proyecto un 100% pero prever una capacidad para el sprint inferior a esa, si después resulta que no han existido contratiempos y puede estar al 100% pues mejor, ya que así aprovechará para ayudar a otros compañeros, para ayudar a resolver contingencias que hayan podido ocurrir en la iteración, para refactorizar, etc…).

El equipo recibe muchas presiones (y quién esté libre de pecado que tire la primera piedra) para que asuma el mayor número de historias de usuario posible. Se tiene que aprender a decir que no y a respetar las condiciones para que un conjunto de personas puedan cumplir sus compromisos sin tener que reventarse.

Gestión de riesgos en los enfoques ágiles

Sea cual sea el enfoque, estrategia o metodología que apliques en un proyecto, van a aparecer riesgos o problemas que pueden afectar en mayor o menor medida al proyecto y al cumplimiento de los compromisos y expectativas y que no deberíamos ignorar, en unos casos porque su materialización puede poner todo patas arriba y en otros porque una vez materializados suponen una resistencia importante en el propio proceso de desarrollo.

La gestión de riesgos en los enfoques ágiles está implícita en la propia dinámica de trabajo y en las prácticas que se vienen a aplicar. Esto no quiere decir que sea menos importante o que se le dedique menor atención, solo que ya se entiende, de base, que es necesario trabajar en ello.

Es importante tener en cuenta que se presta principal atención a los impedimentos o resistencias que son contingencias u obstáculos que bloquean o afectan a la velocidad real del equipo, lo cual no quiere decir que se ignoren riesgos a más alto nivel.

En un enfoque ágil de desarrollo se debe tratar que los problemas, resistencias y errores salgan a la luz lo antes posible porque se entiende que cuanto más cerca de su origen se aplique de manera efectiva cada solución, menos daño provocará al proyecto al ser menor su impacto en el producto y en las personas (si no se hace por eliminar o paliar determinadas resistencias, afectará al ánimo y moral de las mismas, agudizando el efecto que sobre la productividad provocan esos impedimentos) y, por tanto, menor el esfuerzo que se necesitaría para volver de nuevo a una situación de equilibrio.

Un ejemplo de ello lo tenemos en las reuniones diarias o Daily Scrum en las que cada participante, además de indicar lo que hizo la jornada anterior y lo que pretende realizar en esta, comenta qué impedimientos, obstáculos, resistencias o problemas se están encontrando en la realización de sus tareas. Se habla de ello para poner estas contingencias encima de la mesa con el objeto de que se le proporcione una solución que lo mismo puede ser inmediata o requiere de tareas (o incluso sprints específicos) para abordarlas.

No olvidemos que la comunicación entre las personas ni empieza ni termina con el Daily Scrum, por lo que aplicando los principios de transparencia que deben regir en un proyecto ágil, en cualquier momento se puede y se debe levantar la mano para comunicar un riesgo o un problema que puede afectar al desarrollo.

En cualquier caso, tenemos otro punto de sincronización en las retrospectivas, en las que se analiza en qué aspectos se puede mejorar y cómo y qué resultado están dando las medidas aplicadas hasta ahora para tratar otros puntos de mejora detectados en sprints anteriores. Este es otro punto donde se puede y se deben discutir sobre todo aquello que afecte a lo que sería un normal desarrollo del proyecto.

Estas resistencias, se pueden inventariar en una pila de impedimentos o Impediment Backlog con el objetivo de hacerlas visibles y poder hacer un seguimiento de las mismas.