domingo, 7 de mayo de 2017

¿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 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.

Hay 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.

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:
    • 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 :-)

2 comentarios:

  1. Hola,
    "Al tratarse de exploraciones rápidas, los spikes deben de estar limitados en el tiempo (time boxed)".... Es decir, ¿ no se estiman, verdad ?

    ¡ Gracias Alexander por este post !

    ResponderEliminar
    Respuestas
    1. Hola Elvira,

      No, los spikes no se estiman de forma usual, se define su objetivo y se llega a un consenso entre equipo y Propietario del Producto del tiempo al que se les va a limitar.

      Gracias por leer, saludos,

      Alex

      Eliminar