¿Cómo pueden los equipos ganar conocimiento y despejar incertidumbre?

Equipo preparando spikes para adquirir conocimiento

Estuve conversando con un gestor de proyecto y me contaba que la madurez de los equipos que proporcionaban sus proveedores habituales había cambiado drásticamente. Históricamente, hace más de 5 años, en todo equipo había uno o dos seniors que lideraban las decisiones técnicas, lo que redundaba en un buen software. Hace 5 años los seniors empezaron a desaparecer paulatinamente de los equipos, pero si las cosas iban mal, como cliente presionaba al proveedor y aparecía un senior que salvaba el proyecto. Desde hace 3 años ya no hay seniors que salven proyectos... eso les llevó a comprender que la continuidad de los equipos, aunque sean externos, es crucial, que el conocimiento es un gran valor, así que hoy en día están construyendo software con equipos de Scrum pensados a largo plazo.

Recientemente estuve hablando con una programadora de un equipo que se había constituido a base de juniors, para ellos todo era nuevo, miraran a donde miraran todo era desconocido, la experiencia de sus compañeros recién salidos de universidad era mínima, y me preguntaba qué podía hacer. Le contesté que había que adquirir conocimiento y despejar incertidumbre, era hora de crear spikes exploratorios y traer visibilidad al trabajo para construir funcionalidades de forma eficiente.

Un spike viene a ser una actividad de desarrollo en forma de historia técnica que se incluye en la pila de producto con el objetivo de dar respuesta a una cuestión o de reunir información para una toma de decisión posterior o el diseño de una solución.

Los spikes también sirven para adquirir el conocimiento previo necesario para entender mejor la solución y/o la necesidad asociada a una historia de usuario y así reducir la incertidumbre respecto a la implementación de la misma. Esta técnica se conoce como "construir un spike" y se pueden materializar en pruebas de concepto o prototipos que permiten evaluar la viabilidad de una historia usuario. En este caso los resultados de la actividad exploratoria nos permiten tomar decisiones adecuadas para refinar o definir el alcance de una historia de una forma sólida.

Existen dos tipos de spikes:

• Spike técnico: si no estamos seguros de cómo desarrollar algo desde un punto de vista técnico creamos este tipo de spike, una breve actividad que se centra en encontrar un enfoque de desarrollo, en determinar la factibilidad y el impacto de las estrategias de diseño.
• Spike funcional: sirven a los equipos para descubrir los detalles de las funcionalidades y los diseños a través de la creación de prototipos y llegar a entender exactamente lo necesita el cliente.

A parte de ganar conocimiento y despejar dudas, los spikes permiten a los equipos dar estimaciones sólidas a historias de usuario posteriores. Al tratarse de exploraciones rápidas, los spikes deben de estar limitados en el tiempo (time boxed), usualmente de unas horas o unos días.

Los spikes se escriben en forma de historia técnica, imaginemos la siguiente historia de usuario de ejemplo:

Como ciclista

Quiero pagar mi compra con tarjeta de crédito

Para poder comprar accesorios para mi bicicleta

Historia para la que podemos construir un spike en forma de la siguiente historia técnica:

Explorar la pasarela de pago de tarjetas de crédito de nuestro banco

para conocer la viabilidad de la inclusión de la misma en nuestro producto

Donde los criterios de aceptación hacen referencia a las cuestiones que necesitan ser respondidas.

Como los demás elementos de la pila de producto los spikes se demuestran en la revisión de sprint donde el Propietario del Producto las ha de aceptar.

Son elementos de la pila adaptados:

• Pequeñas
• Demostrables
• Dan respuestas basadas en evidencia:
• Pruebas de concepto o prototipos funcionando
• Elementos existentes similares
• Limitadas en el tiempo
• El fracaso es uno de sus resultados, su objetivo es que aprendamos o tengamos criterio para la toma de decisiones

Quiero agradecerle a Cristina la conversación que tuvimos y que dio pie a este post :-)