Cómo manejar grandes proyectos de I+D utilizando Scrum (o cualquier otro marco ágil)

Además de nuestras tareas habituales de desarrollo de software, tenemos algunas tareas importantes de I+D que nos resultan difíciles de encajar en nuestro marco scrum.

El problema principal es que no hay absolutamente ningún valor para el usuario antes de que se complete todo el proyecto, y es muy difícil desglosarlo.

Digamos que quiero crear un algoritmo que pueda distinguir a los gatos de los perros. Es posible que ya tengamos uno con un rendimiento del 98 %, pero necesitamos uno nuevo (desde cero) que pueda ofrecer el 99 %. Los pasos principales se verán así:

1. hacer un estudio de literatura
2. Adquirir algunas fotos de gatos y perros. Quizás también algún código para manejar las imágenes.
3. Entrene un algoritmo basado en los datos y pruebe la precisión.
4. Hacer una validación final de los resultados.
5. Implementar el prototipo de trabajo en un producto.

Los pasos 1, 2, 4 y 5 son fáciles y se pueden desglosar más si es necesario. Sin embargo, el paso 3 es demasiado grande y demasiado incierto para ser solo una historia en sí misma. La experiencia muestra que el progreso será algo así como:

1. Entrene el algoritmo usando el método de facto que se encuentra en el estudio de literatura
2. Tenga en cuenta que necesita un mejor rendimiento, pero podría obtenerlo incorporando información especial en este caso de uso específico.
3. Aplique el ajuste n. ° 1 que resulta mejorar el rendimiento en un x%
4. Aplicar ajuste #2 .....
5. .....
6. n ajustes más tarde, ha alcanzado la meta de 99% de predicciones corregidas.

Sin embargo, dado que la adaptación/retoque es la parte principal del trabajo, a menudo es imposible predecir la cantidad de retoques necesarios, el efecto de un retoque y el tipo de retoques por adelantado. Creemos que planificar un proyecto como este es muy difícil.

Entendemos que uno de los objetivos principales (no los más importantes) del desarrollo ágil es que pueda adaptarse y cambiar de dirección según sea necesario, y eso es excelente. Pero, ¿cómo planificar/estimar una historia como esta, donde nos resulta muy difícil evaluar la carga de trabajo por adelantado e igualmente difícil desglosar el problema?

Cualquier comentario es bienvenido