Algunas veces los desarrolladores se encuentran en el Product Backlog con elementos que no saben descomponer o estimar porque es una nueva tecnología de la que se tiene poca información .
En estos casos en XP o Extreme Programming suele abrirse un spike que es un elemento de Product Backlog para investigar o experimentar para investigar y poder implementar la tecnología que solicita el cliente.
Para representar este elemento tenemos dos opciones:
-El elemento se divide en dos ,uno para realizar la investigación y el otro para una vez terminada implementar la funcionalidad.
-También puede ser que el spike sea una tarea del Sprint Backlog que esta asociada al un elemento del Product Backlog
Es recomendable definir un timebox para el spike que no deben ser mas que unos días
El concepto proviene de XP aunque es utilizado en agile y en Scrum.
Ejemplos de spike
Te voy a poner 2 ejemplos de como puede ser un spike:
Supongamos que queremos saber la reputación que tienen los usuarios que venden productos de segunda mano en una pagina .
Podemos crear dos historias de usuario ,una que sea el spike,» crear un prototipo que utilice apis vara validar la reputación de los usuarios de una pagina de compra-venta» y luego la historia de usuario principal que seria «como comprador quiero poder ver la reputación de los usuarios que venden productos por la pagina para decidir si compro su producto o no».
-Se quiere aceptar pagos mediante tarjeta de crédito pero los desarrolladores no tienen experiencia ,el spike seria «investigar opciones para procesar pagos online mediante tarjeta de crédito o debito» mientras que la historia de usuario principal sería «Como usuario ,quiero poder pagar con tarjeta de crédito o debido los productos de mi carrito ,para así completar el proceso de compra
Spike en Scrum: ¿Cómo implementarlo ?
Lo ideal es que la investigación y la implementación se hagan en el mismo sprint,lo mejor es aplicar cuanto antes lo que acabamos de aprender y si no nos diera tiempo pasaremos el spike y el elemento principal al Product Backlog.
Mike Cohn defiende que es mejor realizar el spike en un sprint y después de los resultados de la investigación decidir si se prioriza o no la implementación de esa historia principal en el siguiente sprint .
Desde mi punto de vista esta es la mejor solución porque disminuye el nivel de incertidumbre.
Riesgos asociados
El peligro que entraña los spikes es que se abuse demasiado por eso debe utilizarse cuando no hay más remedio no como algo habitual porque solo reducirá el incremento real y la entrega de valor en cada sprint.
¿Has utilizado los spikes? ¿Cuál ha sido tu experiencia?
