Estoy trabajando en un equipo pequeño (4-6) en un proyecto que consiste en crear un modelo de aprendizaje automático para predecir el resultado de partidos deportivos en tiempo real. Esto también implica extraer los datos y almacenarlos en una base de datos para que podamos hacer predicciones en tiempo real. También construiremos un sitio web simple para mostrar estos datos. El cliente actualmente tiene su propio blog deportivo popular, por lo que planea que el sitio que estamos creando sea una adición (probablemente solo otra pestaña) a su sitio web o un sitio completamente separado; el cliente no especificó cuál, ya que probablemente depende de la calidad de nuestras predicciones.
Ignorando el aspecto del sitio web orientado al usuario por el momento (ya que el sitio web definitivamente se puede hacer ágil), el aspecto técnico por sí solo podría llevar meses. Dada una tarea profundamente técnica como esta, ¿es posible usar Agile? No parece que la demostración del trabajo técnico realizado en cada sprint sea útil para las partes interesadas o los usuarios, y no sé qué/si los requisitos podrían cambiar. ¿Esta tarea es más adecuada para la cascada o hay alguna manera de ser ágil?
Todo en su pregunta sugiere que está explorando un nuevo problema, no simplemente creando algo que ya sabe exactamente cómo construir. Debido a que la cascada le pide que cree su diseño por completo antes de comenzar a construirlo, usar la cascada sería inherentemente problemático.
En Agile, y específicamente en Scrum, el objetivo de hacer que un producto aumente y ponerlo frente a los usuarios es saber si está haciendo lo correcto. Es un marco diseñado para problemas adaptativos complejos y que parece encajar perfectamente en su situación.
No sé mucho sobre su proyecto, pero parece que la medida principal del éxito será la calidad de las predicciones. Entonces, para usted, le preguntaría quién juzgará eso y quién tiene interés en eso y esa persona es la parte interesada más importante en su revisión (o personas). Esperaría que sus objetivos de sprint y sus elementos pendientes fueran menos
Como [usuario], quiero poder hacer clic en X y ver Y
y más
Como [usuario], quiero que el algoritmo considere las estadísticas de recepción pasadas del jugador por trimestre para que tenga en cuenta la fatiga del juego tardío en la predicción.
En cada sprint, querrá ver cómo ha mejorado la calidad de las predicciones y cuál es el siguiente trabajo correcto para mejorarlas. No me preocuparía demasiado por la interfaz de usuario. Mi enfoque personal sería eliminar una interfaz básica de inmediato en el primer sprint respaldado con un algoritmo tonto (al principio puede ser un lanzamiento de moneda para todo lo que importa) y luego esa interfaz produce cada vez mejor. información sobre la marcha. Dicho esto, se podría argumentar que la interfaz es tan poco importante que a su usuario no le importa y ni siquiera se molestará con ella en el futuro previsible. Mi conjetura es que si puede hacer predicciones con un alto nivel de precisión, puede generar un archivo de texto para todas sus preocupaciones de usuario.
Los enfoques ágiles implican un aprendizaje validado . Wikipedia define los pasos del aprendizaje validado como:
En realidad, esto se corresponde extremadamente bien con un modelo de desarrollo iterativo como Scrum, y se incorpora dentro de los eventos estándar del marco, como Sprint Planning y Sprint Review.
Es probable que tenga dificultades porque su equipo no está haciendo todo lo siguiente:
La Guía Scrum establece un marco sólido para hacer estas cosas, y las prácticas modernas relacionadas con el refinamiento de la acumulación se tratan en libros como User Stories Applied , y el uso de un Producto Mínimo Viable (MVP) se trata en libros como The Lean Startup .
Ningún libro le dará todas las respuestas que necesita, y este sitio no es un servicio de recomendación de libros. Sin embargo, esto debería orientarlo en la dirección correcta.
Mientras tanto, si tiene preguntas concretas sobre cómo dividir o descomponer una historia de usuario determinada, puede publicarla como una pregunta separada (¡y detallada!) si necesita una respuesta más pragmática para un aspecto específico de su desafío del equipo.
Encontré el enfoque Kanban significativamente más fácil de usar que Scrum en un tipo de proyecto de I + D (usamos Scrum con éxito durante 5 años antes en otros proyectos). Y funciona cuando tampoco tenemos una sola pieza de interfaz de usuario. Puede hacer una demostración de lo que pueda, de la manera que pueda (puede usar el informe de prueba de BDD u otros informes) cada vez que tenga un incremento de producto (hito). Cuando la mayor parte de su trabajo son picos tecnológicos (al menos al principio, este será el caso en un proyecto de ML), concéntrese en los objetivos, limitando el trabajo en progreso y cronometrando los picos (por ejemplo, revise el enfoque después de 2 días de análisis y análisis inicial). esfuerzo para no sumergirse en un agujero de conejo)
nathan cooper
erik