archivo

Archivos Mensuales: marzo 2014

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.

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.

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.

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.

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.

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 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.