En ocasiones, los Desarrolladores se encontrarán con elementos del Product Backlog que no sepan descomponer o estimar, debido a la falta de conocimiento sobre la tecnología de que se trate o al nivel de incertidumbre asociado a esta. En estos casos, Extreme Programming contempla la posibilidad de que uno o varios desarrolladores abran un spike -nunca he usado el término traducido al español, si es que tiene traducción-. El spike es un elemento del Product Backlog orientado a la investigación o experimentación, cuya finalidad es obtener el aprendizaje necesario para implementar la funcionalidad solicitada por el Product Owner o cliente.

Para representar el spike, tenemos dos opciones:

– El elemento del Product Backlog o historia de usuario original se desgaja en dos: uno referido a la investigación, a la obtención de información o conocimiento adicionales, y el otro referido a la funcionalidad en sí.

– También puede que el spike sea una tarea del Sprint Backlog, asociada al elemento del Product Backlog sobre la funcionalidad de interés.

En todo caso, lo recomendable es definir un timebox o duración máxima para el spike, habitualmente en días. Por tanto, limitamos de antemano el tiempo que vamos a invertir aprendiendo sobre la tecnología en cuestión.  

Por cierto, como decía, el concepto proviene del Extreme Programming, si bien el spike es igualmente utilizado en Scrum y Agile en general.

Ejemplos de spike

Veamos un par de ejemplos de spikes:

– Supongamos que queremos mostrar la reputación digital de nuestros usuarios a través de un proveedor. Necesitamos probar sus APIs y saber si se ajustan a nuestras necesidades. Por un lado, escribimos una historia de usuario que sea el spike: “Crear un prototipo que utilice las APIs del proveedor ACME y valorar su rendimiento”; y, por otro, creamos la historia “principal”, por ejemplo: “Como usuario comprador, quiero poder ver la reputación digital de los usuarios vendedores, para así decidir si procedo o no con la compra de sus productos”.

– Queremos aceptar pagos mediante tarjeta de crédito, pero los Desarrolladores carecen de experiencia implementando pasarelas de pago online. El spike en este caso podría ser “Investigar opciones existentes para procesar pagos online mediante tarjeta de crédito”, mientras que el elemento principal sería “Como usuario, quiero poder pagar con mi tarjeta de crédito, para así completar la compra de un producto”.

Spike en Scrum: ¿debemos hacer el spike y la implementación en el mismo Sprint?

En mi experiencia, lo deseable es que la investigación y la implementación se hagan en el mismo Sprint, para evitar los riesgos que mencionaremos en el siguiente apartado, y para así favorecer la continuidad en el trabajo relativo a un elemento del Product Backlog que, en el fondo, es el mismo. Mejor aplicar de inmediato lo que acabamos de aprender, sin necesidad de esperar al siguiente Sprint. Si no nos diera tiempo a hacerlos en el mismo Sprint, ambos elementos, el spike y el principal, volverían al Product Backlog.

Si bien agilistas como Don McGreal y Ralph Jocham defienden la conveniencia de abordar el spike y la implementación en el mismo Sprint, otros autores como Mike Cohn consideran que, al contrario, lo más adecuado es separarlos, es decir, hacer el spike en un Sprint y la implementación de la funcionalidad en otro. De esta manera, el nivel de incertidumbre del Sprint en el que se realiza el spike disminuiría, puesto que no incluiría la historia principal, que no sabemos estimar. Además, la ventaja del spike es que el Product Owner o cliente podría ordenar los elementos del Product Backlog teniendo visibilidad sobre la necesidad de realizar un trabajo de investigación previo, el cual no supone entrega de funcionalidad en sí mismo. Por tanto, el Product Owner podría priorizar el spike en un Sprint y, a la vista de los resultados de esa investigación, priorizar o no el elemento principal en la siguiente iteración.  

Riesgos asociados a los spikes

El peligro que entrañan los spikes no es su uso sino el abuso. Descubrimos el concepto y empezamos a incluir un spike en cada Sprint, cada vez que se presenta la ocasión. En un santiamén podemos estar inmersos en Sprints de I+D, en Sprints que son un spike en su totalidad (“spike Sprints”). Si dejamos que esto ocurra, no estaremos entregando working software al final de cada iteración y entraremos en territorio waterfall. Otro caso típico es el de los Desarrolladores que se dedican exclusivamente a la investigación, aislándose del trabajo “mundano” del Sprint. Aboguemos por un uso sensato del spike y no nos despistemos.

¿Has utilizado los spikes? ¿Cuál ha sido tu experiencia?

Imagen de portada: True Detective – Season 1: Trailer – Official HBO UK