Много лет назад, работая над докторской диссертацией, я на горьком опыте понял, что исследования требуют плана с временными рамками и контрольными точками. И хорошо продуманные планы все еще могут не дать желаемых результатов. Когда планы терпят неудачу, вы должны реагировать, строя новые планы. Эти свежие планы также нуждаются в тайм-боксах и контрольных точках. И если новые планы терпят неудачу, вам придется повторять, пока вы не достигнете своей цели.

Идея остается аналогичной, когда речь идет об управлении исследованиями в отрасли. Чаще всего работа по науке о данных относится к сфере прикладных исследований. Таким образом, становится важным подход, дружественный к итерациям, с хорошими контрольными точками и ограничением времени.

Сегодня алгоритмы машинного обучения, управляемые данными, повсеместно используются в программных решениях, которые мы потребляем. Применим ли гибкий процесс, столь распространенный в разработке программного обеспечения, к проектам по науке о данных и машинному обучению?

Кратко об Agile

Давайте рассмотрим agile-процесс. Фундаментальный принцип Agile заключается в итеративном создании продукта. Каждая итерация требует уточнения требований на основе обратной связи. Уточненные требования влияют на план итерации. Далее следует разработка, тестирование и обратная связь. В идеале эти итерации разбиты по времени на 2–3-недельные спринты. Джеймс Нг кратко описывает это в своем посте — планировать, строить, тестировать, изучать, повторять.

Это поможет нам уточнить предыдущие вопросы. Применим ли стандартный гибкий процесс со всеми его ритуалами к проектам по науке о данных?

Agile для науки о данных: проблемы

Многие специалисты по данным считают, что в науке о данных сложно использовать agile. У Илро Ли есть мнение, в котором подробно рассказывается, почему стандартное применение гибких процессов может быть удушающим для специалиста по данным. Лично я видел две жалобы:

  • Оценка сроков затруднена: результат подхода заранее неизвестен. Часто подход порождает несколько «потоков», которые нужно развивать. Планирование, расстановка приоритетов и выполнение этих задач в рамках спринта могут быть сложными. Это приводит к неопределенности в оценке.
  • Слишком много церемоний:Задания, ориентированные на исследования, даже если они разбиты на небольшие задачи, требуют времени для выполнения. Поэтому ежедневные стендапы становятся рутиной. Невозможно демонстрировать рабочую деталь после каждого спринта.

Какая польза от Agile для науки о данных?

Во-первых, давайте рассмотрим, как продвигаются проекты по науке о данных. На следующем рисунке показаны различные этапы проекта по науке о данных. Многое из этого взято из другого поста. Я добавил пару личных предпочтений — написание одностраничногозаранее и поддержание вики. Стрелки назад показывают, что результаты каждого этапа могут привести к возврату, что является естественным индикатором принципиально итеративного процесса.

Исходя из приведенного выше обсуждения, в контексте науки о данных трудно следовать строгому гибкому процессу. Тем не менее, я считаю, что он по-прежнему обеспечивает очень полезную основу по следующим причинам:

  • Фундаментальная идея итеративного улучшения по-прежнему должна быть направляющей силой для проектов по науке о данных.
  • Идея спринта действительно требует ограничения времени. Ритуалы тоже имеют свои достоинства. Планирование/расстановка приоритетов способствует структурированному мышлению.
  • Стендапы действительно улучшают командное взаимодействие, что приводит к лучшему мышлению и разрешению блокирующих.
  • Демонстрации приносят ответственность. Они вводят культуру рассказывания историй, что очень важно для объяснения использования статистических методов и машинного обучения при решении бизнес-задач.

Расслабленный Agile?

Что мы должны сделать, чтобы Agile стал значимым для науки о данных? Вот мои рекомендации:

  1. Напишите заранее. Убедитесь, что у проектов есть краткое описание, записанное заранее. В нем есть гипотеза и разделы «почему», «что» и «как». Мы определяем ожидаемый результат — мы разрабатываем модель или внедряем ее? Если мы строим модель, то какие KPI? Мы делаем анализ осуществимости или PoC? Если мы делаем PoC, каковы точные критерии «годен/не годен»? Мы конкурируем с существующей моделью? Если мы строим новую модель, можем ли мы определить базовую линию? Вики хорошо подходит для таких статей, особенно для того, чтобы поддерживать ее актуальность и доступность для всех заинтересованных сторон.
  2. Создавайте истории. Разбейте шаги к желаемому результату проекта на истории. И истории в задачи.
    *** Нам не нужно полностью соответствовать «пользовательским историям», поскольку трудно разбить проект по науке о данных на фрагменты, которые независимо значимы для конечного пользователя. Вместо этого сделайте так, чтобы истории представляли собой шаг к конечной цели проекта. Например, история для нас может быть «Сопоставить набор данных для модели обучения на основе представления для foo». Еще один пример: «Построить базовую модель для foo: к модели, основанной на обучении с представлением», а еще один может быть «Анализ различий в распределении между данными обучения/тестирования/полевых данных». .
    ***В идеале нужно, чтобы история была завершена в течение двухнедельного спринта. Но если это не так, можно просто перенести его на следующий спринт. Задачи в истории фиксируют, какая часть была выполнена в течение спринта, и какие задачи вызвали расплеск истории.
  3. Разрешить добавление новых задач в историю. Часто первоначальный набор задач не приводит к желаемому результату для истории. Когда мы применяем гибкие процессы к разработке программного обеспечения, мы ожидаем обратной связи от заинтересованных сторон в конце спринта. В науке о данных заинтересованному лицу, такому как менеджер по продукту, трудно предоставить входные данные, когда истории не совсем соответствуют пользовательским историям. Шаги уточнения исходят от технической группы как результаты выполнения задач. Например, история: «Анализ различий в распределении между данными поезда/испытания/поля» может изначально содержать задачи: «Создать расхождения KL для признаков», «Анализ распределения вероятностей относительно xyz». Можно добавить дополнительную задачу, например, «Анализ признаков на основе значений Шепли». Ловушка расширения истории заключается в том, что для ее завершения требуется больше времени. Затрудняет предварительную оценку усилий. Но это гарантирует, что мы приблизимся к желаемому результату, который в любом случае должен быть целью.
  4. Избегайте расширения объема истории.Это аналог "разрешить добавлять новые задачи в историю". Например, если в статье говорится «Анализ различий в распределении между данными поездов/испытаний/полей», любой вывод, ведущий к экспериментам с перераспределением данных для построения модели, должен быть отдельной историей. Это может показаться тривиальным, однако я видел, как это происходило, когда кто-то объединял идеи анализа и экспериментирования в более крупную цель получения идей. Избегание расширения объема истории предотвращает отступление и добавляет контрольную точку к существующему шагу. Это имеет первостепенное значение для обеспечения прозрачности для заинтересованных сторон.
  5. Сократите частоту ожиданий до двух раз в неделю: задачи по науке о данных не обновляются каждый день. Для специалиста по обработке и анализу данных обновление «Вчера я сделал Х, планирую продолжить Х сегодня» и повторение в течение нескольких дней становится обесточивание. Другой аспект стендапов — обсуждение блокирующих. На мой взгляд, как только люди чувствуют себя ответственными, они поднимают блокировщики на различных каналах, не обязательно нуждаясь в стендапе. Выступления пару раз в неделю делают его интересным благодаря содержательным обновлениям.
  6. Поощряйте демонстрацию после завершения истории:смягчайте критерии демонстраций в конце каждого спринта. История не обязательно заканчивается в спринте. Однако, поскольку демонстрация приносит ответственность и помогает привить культуру повествования, ее наличие в конце истории двигает все в правильном направлении.
  7. Установите ожидания. Учитывая эти послабления, необходимо установить ожидания для всех заинтересованных сторон — продакт-менеджеров, технических специалистов и владельца продукта. В этом контексте полезно отметить несколько моментов из agile-манифеста и установить, что следует следовать ему в его истинном духе:
    *** Люди и взаимодействие важнее процесса
    *** Реагирование на изменение вместо следования плану
    Я видел, что как только ожидания установлены, и механизм становится прозрачным, люди обычно настраиваются на достижение общей цели.

Заключительные слова

Я описал непринужденный гибкий процесс для проектов по науке о данных. На мой взгляд, смягченный процесс по-прежнему обеспечивает прозрачность, в которой нуждаются заинтересованные стороны. Структура со встроенными итерациями помогает специалистам по данным отмечать контрольные точки, создавать новые потоки и закрывать потоки, которые не питают особых надежд, не чувствуя, что их творчество задушено.

Какие подводные камни вы видите в этом подходе? Какие модификации или дополнительные шаги вы рекомендуете?