Es común que los desarrolladores siempre estén enfrentando nuevos desafíos, muchos de ellos son pequeños o abordables y algunas personas ya han resuelto un problema parecido en el mismo equipo o en la Internet. En otras ocasiones ellos se enfrentan a desarrollos completamente nuevos y ellos no tienen idea de cómo abordarlos.
El riesgo puede ser muy grande y el tiempo de la implementación del nuevo requerimiento podría tomar días o hasta años. Después de codificar el requerimiento, si es que pueden, los desarrolladores tienen que testear como está funcionando todo el sistema y si se cumplieron las expectativas. Nada parece claro y es difícil ver tierra en el mar. Es necesario hacer algo más antes de estimar la dificultad, impacto y tiempo para implementar el requerimiento.
Spikes
Los Spikes son una invención de la metodología Extreme Programming (XP), desarrollar un Spike es hacer una implementación de algo relacionado a un potencial requerimiento. ¿Por qué es necesario hacer un Spike antes de un requerimiento?
Los Spikes son útiles cuando el requerimiento es hacer un cambio arquitectural, probar una nueva tecnología, añadir una gran funcionalidad o cambiar una actual implementación y revisar si eso es posible, también es útil para saber mejor el tiempo que tomará el desarrollo, cómo la implementación resulta afectada, y revisar si las funcionalidades tendrán el comportamiento esperado. Definitivamente, el requerimiento es demasiado inmaduro y necesita algo de trabajo para convertirse en un requerimiento con un alcance lograble.
Además, ellos son usados para investigaciones, diseño, prototipados, o aumentar el conocimiento y reducir el riesgo de un alcance técnico.
Spikes emergiendo
Todos los requerimientos para construir una funcionalidad tienen un riesgo, esta información desconocida puede ser descubierta mientras el requerimiento esta construyéndose, en una conversación de equipo, usando el criterio del desarrollador, discutiendo, colaborando, negociando, etc. El equipo determina hacer un Spike cuando el riesgo es muy algo o ellos realmente necesitan saber más sobre un requerimiento que puede ser demasiado grande. Usando Spikes el equipo obtendrá la información con datos convincentes, entonces los miembros del equipo pueden ver y tomar mejores decisiones.
Cuando el equipo o el Product Owner determina que hay que hacer un Spike, este puede ser estimado y priorizado tal como los otros requerimientos. El mayor valor de un Spike es la información obtenida, no el código desarrollado.
Como enfrentar un Spike
La recomendación es implementar un Spike con un pequeño programa. Es importante investigar y leer, pero es aún más importante escribir código para experimentar, no profundizar solamente en la teoría. Lo complejo tiene que ser ignorado, solo hay que enfocarse en obtener algo funcionando, no importa si el código no es reusable porque éste es un experimento. Documentar y mostrar los resultados a los compañeros es imprescindible. Evitar el código de producción cuando es posible, si no lo es, entonces hay que usarlo, pero no se puede comitear.
Durante un Spike, los desarrolladores no pueden comenzar profundizando porque los Spikes no se encuentran bien definidos. El que investiga en esa niebla puede perderse en el mar de información o intentando hacer muchas cosas al mismo tiempo. También, es importante tener en mente que los Spikes no entregan valor al usuario directamente, por lo tanto, ellos deben ser usados con precaución.
Finalmente, Spikes pueden ser útiles algunas veces, pero la mayoría de los requerimientos no necesitan usar este tipo de desarrollos. Es importante tomarse un tiempo y decidir si es necesario el Spike y esa decisión puede ser crítica en algunos casos para el futuro del proyecto.
