Caso de Éxito: Scrum en un proyecto de 3 meses

Me habían pedido muchas veces que publicara cómo hicimos para que este proyecto tuviera un principio y final felices y aquí va mi retrospectiva personal.

Proyecto: Proyecto de software para industria.

Cliente: Familiarizado con las tecnologías de software, había oído hablar de Scrum, pero nunca lo había usado como marco de trabajo.

Equipo: Tres personas. Dos de ellas habían trabajado con Scrum, otra no lo conocía. Las tres personas tenían una velocidad de trabajo diferente.

Mi empresa: Nos da la libertad de gestionar el proyecto siempre que se obtengan los resultados esperados, según mi opinión, en este orden:

1. Calidad: la máxima posible, intentando no afectar las fechas planificadas
2. Fechas: lo más cercano a las planificadas, intentando no afectar los requisitos
3. Requisitos: los acordados con el cliente al principio del proyecto o los que se acuerden a lo largo del proyecto

Inicio del proyecto

Los requisitos, las fechas y el presupuesto ya estaban pactados con el Cliente, pero como hago siempre, reviso de nuevo los requisitos y vuelvo a realizar una estimación predictiva con al menos uno de los miembros del equipo que va a formar el proyecto para hacerme una idea de la presión que vamos a tener. En este caso, preveía una desviación de aproximadamente un 20%.

Decidimos – el Equipo de Desarrollo – hablar con el Cliente para volver a analizar en profundidad todos los requisitos y de paso construir el Product Backlog. Para ello, sin usar términos de Scrum, le comentamos que queríamos reunirnos con ellos para analizar todos los requisitos.

Mi idea era realizar parte de una Inception, que me permitiera dejar claro a todos las partes del proyecto qué es lo que íbamos a hacer y cómo lo haríamos.

¿Por qué no toda la Inception? Pues porque era la primera vez que iba a jugar con esta técnica y porque se supone que ya estábamos consumiendo horas del proyecto en la que no se había presupuestado tiempo para esto. De modo que seleccioné aquellas preguntas que creí me permitirían acotar mejor el proyecto:

• Definir el proyecto en una explicación corta y concisa
• Definir qué NO es este proyecto
• Comentar qué podría quitarnos el sueño durante el desarrollo de este proyecto
• Conocer a los vecinos – esa lista de implicados, sean personas o no, a los que afectará el proyecto

De estos puntos lo que más nos ayudó, sin ninguna duda, fue definir “Qué podría quitarnos el sueño”. Fue lo que más nos ayudó con diferencia. Y en orden, saber “qué no es este proyecto”, luego alguna vez recurrimos a la definición del proyecto y por último, para las Historias de Usuario y definición de la seguridad, a la lista de vecinos. El haber hecho estas preguntas fue decisivo para que el proyecto llegara a buen puerto.

Luego, en un par de jornadas duras escribimos las Historias de Usuario del Product Backlog, de modo que el cliente quedó contento porque reflejaban de forma clara qué se quería hacer, para quién y por qué, aunque no estaba reflejado el cómo. Cada vez que escribíamos una, comentábamos brevemente, junto con el equipo, sobre la dificultad de la historia de usuario y le asociábamos un valor que representaba ese esfuerzo. Habiendo explicado muy rápido cómo definíamos ese valor, por qué usábamos puntos y no horas y por qué mientras más esfuerzo más separación había entre un valor de esfuerzo y el siguiente, no hubo problemas.

Cabe decir que para escribir las Historias de Usuario leímos más de una vez la oferta formal que se hizo para la contratación del proyecto, pero salieron muchas cosas que no estaban escritas en la oferta, de modo que la satisfacción estaba asegurada para todos. Así llegamos a completar la lista inicial del producto y nos hicimos una idea de cuánto esfuerzo nos llevaría desarrollar todo lo que se quería.

Una vez conocido el esfuerzo total (recalco: inicial) – hicimos un cálculo muy sencillo:

• Explicamos al cliente que el equipo tenía una velocidad de trabajo de N puntos diarios y que esos puntos reflejaban:
  • la cantidad de trabajo que el equipo era capaz de sacar adelante cada día, es decir, la capacidad diaria de trabajo
  • que esa capacidad diaria (N puntos) es equiparable a los puntos de esfuerzo asignado a las tareas
• Luego, teniendo la fecha límite para la entrega del producto, contamos los días laborables y determinamos la capacidad de trabajo total - aproximada- hasta la fecha de entrega y vimos que no coincidían, como casi nunca coincidirán. Para desarrollar todas las historias de usuario se necesitaba más esfuerzo que capacidad tenía el equipo.

Viendo esto, le explicamos que eso sucede en la gran mayoría de los proyectos y es por eso que se entregan fuera de plazos, con poca calidad y muchos errores, y que para evitar eso, lo que nos aseguraba la calidad era la priorización de tareas por períodos de tiempo de 15 a 20 días y la entrega, demostración e instalación del producto al final de cada período.

Es en este punto donde se produce un problema de negociación importante. Es en este punto clave donde hay que explicar bien, si no cabe todo, por qué no cabe y qué consecuencias traería intentar desarrollar todo con los mismos recursos en el mismo tiempo. Es en este punto – el más importante de la negociación del tan famoso triángulo de compensación – donde se va a definir qué se mueve de los pilares del proyecto: Coste/Recursos, Tiempo/Fechas o Alcance/Funcionalidades. Nosotros conseguimos explicarnos bien y he de reconocer que teníamos un cliente que comprendía las consecuencias de una decisión incorrecta – decidimos que variarían las funcionalidades a desarrollar y que las menos importantes, que quedarían fuera del desarrollo, se realizarían en fases posteriores.

Cuando hay funcionalidades que se quedan fuera de alcance la mayoría de las veces se recomienda – en este orden:

• [Alcance] Dejar fuera aquellas funcionalidades menos importantes del proyecto, para futuras fases, después de probar, entregar y facturar lo que se ha desarrollado – Esto es sencillo si se prioriza bien al principio de cada Sprint.
• [Coste] Ampliar el equipo hasta donde lo permita el proyecto y abordar más funcionalidades. Esto requiere una ampliación del presupuesto y requiere que la empresa cuente con personas capaces de integrarse en el equipo existente. – Dos opciones difíciles de conseguir.
• [Tiempo] Como opción última y menos recomendable, mover la fecha de entrega final. Esta opción también requiere variar el presupuesto, porque a más tiempo de desarrollo, más costes para el proyecto – y este es un punto de muy difícil negociación una vez firmada la oferta.
• Hay que intentar por todos los medios no mover la fecha de entrega final, porque será el comienzo de una fecha de entrega cambiante que alargará indefinidamente el tiempo de desarrollo y los costes del proyecto.

Nosotros decidimos optar por la primera opción (dejar fuera aquellas funcionalidades menos importantes) ya que ampliar el presupuesto para ampliar el equipo no estaba en los planes. Casi siempre es la opción escogida.

Y dicho esto, ¡comenzamos con el primer Sprint!

Inicio de cada Sprint

Ya en las reuniones de inicio del proyecto le explicamos al cliente que para obtener el producto que él necesitaba, nosotros, el equipo, necesitaríamos compromiso por su parte y que era imprescindible que estuviera al principio y al final de cada Sprint para validar que el trabajo que íbamos a hacer era el que él necesitaba.

De modo que habiendo llegado a un acuerdo, antes de iniciar cada Sprint hacíamos, junto con el cliente, una selección de Historias de Usuario.

¿Cómo las seleccionábamos?

La primera vez fue un poco duro porque nuestro Product Backlog no estaba priorizado, de modo que comenzamos por priorizarlo todo. Nuestra técnica para priorizar fue la siguiente:

• Decidimos priorizar asignando valores de 1 a 100.
• Aquellas Historias de Usuario con una prioridad de más de 75 puntos quedarían fuera del alcance de nuestro desarrollo y podrían abordarse en fases posteriores. Es importante matizar esto para evitar la idea de que esas funcionalidades nunca se van a hacer.
• Comenzamos por la primera Historia y le asignamos una prioridad.
• Pasamos a la segunda Historia y le asignamos una prioridad respecto a la primera Historia priorizada con una pregunta muy sencilla – “¿esta Historia es más o menos importante que esta otra?” – y luego, sabiendo si era más o menos importante, teníamos un valor de referencia para priorizarla.
• Pasamos a la tercera historia y la priorizamos respecto a las dos Historias ya priorizadas, usando la misma pregunta.
• A partir de la cuarta Historia teníamos varias referencias para priorizar y era mucho más sencillo decidir cuándo se debía hacer esa Historia, si antes o después de otra.

• Si no teníamos claro el orden en que debíamos poner dos Historias de Usuario podíamos darles la misma prioridad o cambiar algún valor de prioridad que habíamos dado anteriormente a otra Historia.
• Al Product BackLog podían entrar nuevas Historias de Usuario en cualquier momento. Al inicio del siguiente Sprint les asignábamos un esfuerzo y las priorizábamos.

Al saber cuánta capacidad de desarrollo teníamos hasta la fecha de entrega y tener priorizadas –ordenadas- las Historias, sabíamos qué se quedaba fuera cada vez que entraba una nueva historia. Eso permitía al cliente ver, en todo momento, las consecuencias de los nuevos requisitos y priorizar mejor, porque la prioridad indicaba qué entraba y qué no entraba en cada versión del producto final.

Y una vez priorizadas, seleccionamos las Historias de Usuario del Sprint por comenzar. Para seleccionarlas, en vez de decidir primero los días que iba a tener el Sprint, seleccionábamos un grupo de ellas que ocuparan de 15 a 20 días de desarrollo – las más importantes. Los pasos que hacíamos eran:

• Seleccionar las Historias más importantes, según su prioridad, de modo que la suma del esfuerzo ocupara de 15 a 20 días de desarrollo, atendiendo a la velocidad del equipo de desarrollo.
  • Si ya el cliente había probado una versión anterior del producto:
    • Hablamos de los cambios que deseaba incluir o las incidencias que había encontrado.
    • Los cambios ya sabemos cómo los tratamos: incluimos y priorizamos antes de comenzar la selección.
    • Las incidencias son la mayoría de las veces responsabilidad nuestra y tenemos que resolverlas como primeras tareas del siguiente Sprint, suman tiempo al Sprint, tiempo que debe asumir el equipo y que no suele ser facturable.
  • Si se habían incluido Historias de Usuario – cambios – durante el desarrollo del Sprint anterior, se priorizaban antes de comenzar la selección.
• Definíamos en presencia del cliente las Tareas a realizar por cada Historia de Usuario y le asignábamos el tiempo de desarrollo a las tareas, esta vez en horas. Comprobábamos que la suma horas de las tareas se correspondía con el esfuerzo que habíamos asignado a la Historia de Usuario contra la Velocidad de trabajo. Si no se correspondía, modificábamos el esfuerzo de la Historia, para ser realistas.
  • En cada tarea poníamos, junto con el cliente, lo mejor que sabíamos, los criterios de aceptación
  • Dentro de las tareas de cada Historia, como costumbre personal, incluimos la de actualizar la Guía de Usuario y la Guía de Instalación, de modo que con cada entrega tuviésemos actualizada la documentación a entregar – por cada tarea. Esto me ha demostrado un ahorro de tiempo considerable.
• Por último, definíamos los días que ocuparía el Sprint y la fecha de la próxima reunión, donde realizaríamos la demo y entregaríamos al cliente el desarrollo realizado para que lo instalase en los servidores, junto con la documentación que le permitiría instalar y trabajar con el producto.

Me gustaría recalcar dos puntos que considero muy importantes:

• En el primer Sprint incluimos todas las tareas necesarias para montar la arquitectura inicial del proyecto. Esas tareas las incluimos delante del cliente, de modo que viera que “eso” también lleva tiempo. No hubo problemas con la asignación de tiempo para ello.
• En el primer y segundo Sprints decidimos incluir todas aquellas funcionalidades relacionadas con “aquello que nos quita el sueño” y que hablamos en la Inception. Esta decisión nos quitó muchísimas preocupaciones de encima a lo largo del proyecto, ya que todos los problemas que podían surgir se solucionaron en la primera mitad del proyecto, consiguiendo el final feliz que todos queríamos.

Reuniones de planificación, seguimiento, entrega y todas (y sólo) las que sean necesarias

Respetar el tiempo de los demás es primordial para que las reuniones sean efectivas y no se vean como innecesarias o como un retraso en el trabajo.

Para ello, es muy importante al realizar una convocatoria poner bien claro de qué se va a hablar en la reunión y poner una duración realista para que todos sepan de antemano a qué se va y cuánto tiempo se va a estar.

Por lo demás, hay mucha documentación que ayuda a mantener reuniones efectivas. De modo que no comentaré este punto.

Durante todo el proyecto intentamos, por todos los medios, mantener las reuniones que recomienda Scrum y lo conseguimos. Nos reuníamos tanto de forma presencial como en remoto.

No sólo nos juntábamos en el momento de la reunión, sino que cuando hizo falta, hicimos pair-programming aunque tenemos que mejorar en las técnicas a emplear y cualquier otra vez que lo necesitábamos, nos juntábamos para comentar cómo abordar un determinado detalle del proyecto. – Nunca nos pareció que nos juntásemos más de la cuenta, la verdad, y cuando pensábamos que nos estábamos enrollando mucho cualquiera de nosotros lo decía y decidíamos lo que fuese – o seguir o cambiar o arrancar a desarrollar de nuevo.

Es responsabilidad de todo el equipo – incluyendo al cliente, claro está – el no malgastar el tiempo. De cualquier modo, cuando tenemos las tareas ahí, frente a la cara, esperando para ser desarrolladas y un tiempo con el que nos hemos comprometido, sabemos que hay que trabajar porque es nuestra palabra el entregar en tiempo y forma lo que hemos dicho.

Y no sé qué más contaros… ah sí, una cosa, en el último Sprint decidimos “probar” a no actualizar las guías de usuario y de instalación en cada tarea, sino actualizarlas al final, como última tarea, antes de la demo con el cliente. Resultado? – Esa vez no pudimos entregarlos porque nos concentramos en terminar otras cosas más importantes.

Post-Proyecto

Una vez entregado el último paquete del producto nos cogimos un par de semanas por nuestra cuenta para probar bien el producto e ir solucionando aquello que no funcionase bien. Esto nos lo pudimos permitir por la carga de trabajo de ese momento. Por lo general ese tiempo debe estar planificado dentro del proyecto, desde el inicio, y casi nunca se hace para abaratarlo. No debería haber problemas si se desarrolla bien, pero eso es casi una quimera.

El cliente no nos reportó prácticamente ninguna incidencia y las que encontramos por nuestra cuenta las resolvimos e hicimos una última entrega.

Ya que el cliente planeaba continuar ampliando por su cuenta el producto, pero quería realizarnos consultas o solicitarnos pequeños desarrollos se le propuso una bolsa de horas en las que nos pudiera solicitar cualquier desarrollo sobre el mismo u otro producto y las consultas que necesitase y fue aceptada.

El cliente nos envió un mensaje contándonos lo cómodo que estuvo durante el tiempo de desarrollo y su satisfacción con el producto final.

Nosotros aprendimos a valorar – yo una vez más – la comodidad del trabajo con Scrum.

Hay muchos más detalles sobre el trabajo de desarrollo día a día, pero cada uno de ellos merece ser explicado con calma.

Espero que esta historia os sirva para algo y si hacéis otras cosas que nos permitan mejorar el trabajo y sentirnos más cómodos al abordar un proyecto, estaré encantado de que me lo contéis.