Я работаю в небольшой команде (4-6 человек) над проектом, который включает в себя создание модели машинного обучения для прогнозирования результатов спортивных матчей в режиме реального времени. Это также включает в себя сбор данных и их сохранение в базе данных, чтобы мы могли делать прогнозы в реальном времени. Мы также создадим простой веб-сайт для отображения этих данных. В настоящее время у клиента есть собственный популярный спортивный блог, поэтому он планирует, что сайт, который мы создаем, будет либо дополнением (скорее всего, еще одной вкладкой) к их веб-сайту, либо полностью отдельным сайтом — клиент не уточнил, какой именно, поскольку, скорее всего, зависит от качества наших прогнозов.
На данный момент игнорируя аспект веб-сайта, ориентированный на пользователя (поскольку веб-сайт определенно можно сделать гибким), только технический аспект может занять месяцы. Учитывая сложную техническую задачу, подобную этой, можно ли использовать agile? Не похоже, чтобы демонстрация технической работы, выполняемой в каждом спринте, была бы полезна заинтересованным сторонам или пользователям, и я не знаю, какие/если требования могут измениться. Эта задача лучше подходит для водопада или есть способ быть гибким?
Все в вашем вопросе говорит о том, что вы исследуете новую проблему, а не просто создаете то, что вы уже точно знаете, как построить. Поскольку водопад просит вас полностью создать свой дизайн, прежде чем вы начнете его создавать, использование водопада по своей сути будет проблематичным.
В Agile и, в частности, в Scrum, цель создания приращения продукта и представления его пользователям состоит в том, чтобы узнать, делаете ли вы то, что нужно. Это фреймворк, разработанный для решения сложных адаптивных задач, и он идеально подходит для вашей ситуации.
Я мало что знаю о вашем проекте, но похоже, что основным мерилом успеха будет качество прогнозов. Итак, для вас я хотел бы спросить, кто будет судить об этом и кто заинтересован в этом, и этот человек является наиболее важной заинтересованной стороной в вашем обзоре (или люди). Я ожидаю, что ваши цели спринта и ваши невыполненные задачи будут меньше
Как [пользователь], я хочу иметь возможность щелкнуть X и увидеть Y
и более
Как [пользователь], я хочу, чтобы алгоритм учитывал прошлую статистику получения игроком по кварталам, чтобы он учитывал усталость в конце игры в прогнозе.
В каждом спринте вы хотели бы посмотреть, как вы улучшили качество прогнозов и что нужно сделать, чтобы сделать их лучше. Я бы не слишком беспокоился о пользовательском интерфейсе. Мой личный подход заключался бы в том, чтобы сразу же в первом спринте убрать базовый интерфейс, который поддерживается тупым алгоритмом (сначала это может быть подбрасыванием монеты для всего, что имеет значение), а затем этот интерфейс просто работает все лучше и лучше. информация, как вы идете. Тем не менее, можно привести аргумент, что интерфейс настолько неважен, что ваш пользователь не заботится о нем, и вы даже не будете беспокоиться об этом в обозримом будущем. Я предполагаю, что если вы можете делать прогнозы с высоким уровнем точности, они могут выводиться в текстовый файл для всех ваших пользовательских забот.
Гибкие подходы предполагают проверенное обучение . Википедия определяет этапы подтвержденного обучения как:
На самом деле это очень хорошо согласуется с итеративной моделью разработки, такой как Scrum, и включено в стандартные события фреймворка, такие как планирование спринта и обзор спринта.
Скорее всего, вы боретесь с трудностями, потому что ваша команда не выполняет всего следующего:
Руководство по Scrum излагает прочную основу для выполнения этих задач, а современные методы уточнения бэклога описаны в таких книгах, как « Применение пользовательских историй» , а использование минимально жизнеспособного продукта (MVP) — в таких книгах, как «Бережливый стартап » .
Ни одна книга не даст вам всех ответов, которые вам нужны, и этот сайт не является службой рекомендаций по книгам. Тем не менее, это должно указать вам правильное направление.
Тем временем, если у вас есть конкретные вопросы о том, как разделить или декомпозировать данную пользовательскую историю, вы, безусловно, можете опубликовать их в виде отдельного (и подробного!) вопроса, если вам нужен более прагматичный ответ для конкретного аспекта вашей вызов команды.
Я обнаружил, что подход Kanban значительно проще в использовании, чем Scrum, в проектах типа R&D (мы успешно использовали Scrum в течение 5 лет до этого в других проектах). И это работает, когда у нас также нет единого элемента пользовательского интерфейса. Вы можете демонстрировать то, что можете, так, как можете (вы можете использовать отчет о тестировании BDD или другие отчеты), всякий раз, когда у вас есть приращение продукта (веха). Когда большая часть вашей работы связана с техническими всплесками (по крайней мере, в начале это будет иметь место в проекте машинного обучения), сосредоточьтесь на целях, ограничив незавершенную работу и установив временные рамки для всплесков (например, пересмотрите подход после 2 дней анализа и первоначального анализа). стараться не нырнуть в кроличью нору)
Натан Купер
Эрик