Spikes en Scrum

Spikes en Scrum

En este post hablaremos de los spikes Scrum. Se trata de usa de esas palabrejas que se escuchan en el mundillo agile y que no siempre se tiene muy claro de qué va.

Básicamente, podemos decir que un spike representa el esfuerzo dedicado por parte del Equipo de Desarrollo Scrum a algo que no es desarrollar código. Esta es la definición corta.

Te propongo profundizar en este tema y darle un buen repaso a este concepto no demasiado extendido. Ni siquiera en muchas organizaciones que, en principio, trabajan de forma ágil.

Vamos a ello.

El Equipo de Desarrollo debe dedicar tiempo a investigar

Imaginemos que queremos desarrollar un producto de comercio electrónico. Supón que durante el Sprint debes abordar una historia de usuario en la que se pide que el usuario pueda realizar el pago de un artículo que estaba en su carrito de la compra.

Pues bien, ¿tienes claro cómo se desarrolla todo ese proceso de compra por Internet? Tal vez desarrollar esta historia no lleve demasiado tiempo… siempre y cuando sepas cómo se hace.

Quizá te lleves una buena parte del Sprint investigando cómo demonios integrar tu aplicación con una pasarela de pago. Seguro que, una vez conozcas los secretos de los pagos por Internet, te resulte sencillo. Pero hasta que llegue ese momento no tendrás más remedio que dedicar esfuerzo a investigar.

O imagínate que decides instalar un sistema de testing automático. Tal vez no sea coser y cantar y haya que dedicar un tiempo no ya a instalar el entorno, sino a investigar las distintas cuestiones técnicas que puedan surgirte o evaluar las posibles opciones que te ofrece el mercado.

Como puedes observar, en ambos casos deberás dedicar un tiempo importante del Sprint a una tarea que no se traduce en generar un incremento. Se trata, pura y simplemente de trabajo de investigación.

¿Cómo se aborda esta clase de tareas en Scrum?

Qué son los spikes Scrum

Los spikes Scrum son esfuerzo del Equipo de Desarrollo Scrum dedicado a investigación de cuestiones técnicas o funcionales para poder abordar una historia de usuario o una historia técnica.

Es más, el hecho de realizar esta investigación te permitirá estimar el esfuerzo que te costará desarrollar esa historia con mayor grado de finura. El spike, en este caso, marca la diferencia entre estimar una historia a ciegas y estimarla sabiendo a qué te enfrentas.

En definitiva, un spike es una historia de investigación y por tanto no se traduce en software construido.

Este término se utilizó por primera vez en Extreme Programming (XP). Dejo aquí la definición traducida que nos brinda la web http://www.extremeprogramming.org:

Crea spikes para encontrar respuestas a problemas técnicos o de diseño difíciles. Un spike es un programa muy simple para explorar posibles soluciones. Construye el spike para abordar solo el problema bajo examen e ignore todas las demás preocupaciones. La mayoría de los spikes no son lo suficientemente buenos como para mantenerlos, así que espera tirarlos. El objetivo es reducir el riesgo de un problema técnico o aumentar la fiabilidad de la estimación de una historia de usuario.

Cuando una dificultad técnica amenaza con retrasar el desarrollo del sistema, ponga a un par de desarrolladores en el problema durante una semana o dos y reduzca el riesgo potencial.

Podemos extender el término spike a otras cuestiones que lleven tiempo de Sprint al Equipo de Desarrollo sin que ello se traduzca en codificación de la solución, como por ejemplo el tiempo de formación del DevTeam.

No incluyas aquí el tiempo dedicado a los eventos Scrum, ya que se da por sabido que son parte del framework

Por lo demás, acota el tiempo del spike al del Sprint, como harías con cualquier ítem del Backlog, y estímalo. Lo incluirás dentro del Sprint durante el Sprint Planning, tal y como lo harías con cualquier otro ítem.

¿Para qué sirven los spikes en Scrum?

Evidentemente, investigar es algo que tendrá que realizar el Equipo de Desarrollo Scrum tarde o temprano.

Normalmente cada producto tiene sus peculiaridades y a no ser que estemos desarrollando un producto muy semejante a otros previos y que podamos aprovechas el 100% del conocimiento anterior, terminarás teniendo que dedicar tiempo a documentarte en cuanto a nuevas tecnologías, o requisitos de arquitectura, o peculiaridades del negocio que marcarán la diferencia a la hora de desarrollar el producto.

En resumen: los spikes sirven para aumentar el conocimiento técnico y funcional del equipo.

Si uno o varios miembros del Equipo de Desarrollo reciben una formación relacionada con sus competencias de cara al producto, ese esfuerzo/tiempo dedicado se computaría con un spike.

Además, ese tiempo que dediques a investigar una funcionalidad te servirá de cara a estimar la historia o historias de usuario relacionadas.

Antes de investigar una funcionalidad puede parecerte que construirla supone un esfuerzo tremebundo, lo que haría que la historia de usuario se concibiese como muy compleja. O viceversa, si no investigas puedes llegar a subestimar el esfuerzo que tendrás que dedicar a desarrollar esa historia de usuario.

Realizar un trabajo de investigación te dejará más claro a qué te enfrentas y podrás estimar el esfuerzo que te supondrá con cierto criterio.

Representación de los spikes en el Backlog

Un spike se representará como cualquier otro ítem del Backlog, así que contará con los atributos que ya podemos ver, por ejemplo, en las historias de usuario.

Es decir, un spike tendrá un identificador, un nombre, una descripción, una estimación de esfuerzo, etc.

Los spikes se pueden reflejar en el Backlog mediante tres formas normalmente: como historias técnicas, como un issue type o tipo de ítem específico o como subtareas de la historia (de usuario o técnica) de la que hemos estado investigando.

Como historia técnica

Si estás usando un Backlog virtual, por ejemplo Jira, y no tienes creado un issue type específico para los spikes, puedes utilizar por ejemplo Operation task (que es el que suele usarse para las historias técnicas), especificando en la descripción corta que se trata un spike.

Aquí lo importante es que quede claro y bien reflejado a qué ha estado dedicando esfuerzo el DevTeam y que no se trata de una historia de usuario o de un bug. De cualquier otro modo, si sólo contabilizas las historias de usuario, podrías encontrarte que de un Sprint a otro el rendimiento del DevTeam ha caído de forma inexplicable, y eso es algo que no te gustará elevar a tus jefes sin tener buenos argumentos…

Como un issue type específico

Puedes crear en tu Backlog virtual, si tu herramienta te lo permite, un tipo de ítem que sea spike, de la misma forma que ya tendrás uno que sea tipo bug, otro user story, etc.

Esto representará sin lugar a dudas ese esfuerzo de investigación y te facilitará generar estadísticas de forma automática. Por ejemplo, podrás saber qué porcentaje del esfuerzo de tus Sprints se dedica a investigar.

Si estás utilizando un Backlog físico ahí lo tienes fácil: puedes crear ítems de tipo spike y en general lo que te dé la gana… Ventajas de escribir en un posit lo que te apetezca 😉 

Como una subtarea de una Historia (de usuario o técnica)

Si el spike sobre una historia lo voy a realizar en el mismo Sprint en el que desarrollaré dicha historia, no tiene mucho sentido que utilices un ítem específico para ese esfuerzo de investigación, ya que dicho esfuerzo es parte del trabajo que debes realizar para poder poner esa historia de usuario a done.

Por tanto, todo ese esfuerzo previo de investigación antes de poder comenzar con la codificación de la historia lo añado a la puntuación total de la historia y creo dicho spike como una primera subtask o subtarea de esa historia. En tanto más compleja sea dicha investigación, más peso en puntos añadirá a la historia.

En cambio, si voy a tener que realizar una investigación relacionada con una historia de usuario o técnica en un Sprint previo al Sprint donde abordaré el desarrollo de dicha historia, sí que tiene sentido crear un ítem propio para ese spike, como historia técnica o como un issue type que sea spike.

Reflexión final

En cualquier proyecto, ya sea Scrum o no, los desarrolladores no están programando sin parar desde que empieza la jornada laboral hasta que se acaba.

Un desarrollador destina parte de su tiempo a aprender, a investigar y a aclarar dudas antes de tirar una línea de código. Tratar de desarrollar sin un conocimiento sólido es construir sobre barro.

Pero también es importante que el esfuerzo dedicado a ello quede bien reflejado. Recuerda que uno de los pilares de Scrum debe ser la transparencia.

Por tanto, de cara a realizar estadísticas y métricas (por ejemplo, qué porcentaje de esfuerzo dedica el equipo a desarrollar o a otras tareas) es importante contar con un buen registro del trabajo del DevTeam, ya que de ello sacarás interesantes conclusiones en cuanto al rendimiento del equipo.

Si te quedaron dudas puedes dejarlas en la sección de comentarios, estaré encantado de responderte.

Y si el artículo te ha resultado útil, te agradeceré mucho que lo compartas en alguna de las siguientes redes sociales. ¡Nos vemos en el próximo post!

Deja un comentario