Data Science and Agile (What Works, and What Doesn't)

eugeneyan

Начните отсюда Статьи Выступления Прототипирование О себе

Data Science и Agile (что работает, а что — нет)

[ agile datascience productivity 🔥 ] · чтение на 13 мин

С тех пор как я в последний раз писал о том, что модерировал панель на тему Data Science и Agile, некоторые обращались ко мне за моими взглядами на это. Эта тема также обсуждается в сообществе data science, с вопросами о том, как внедрить agile в команду data science и как получить прирост производительности.

Может ли agile хорошо работать с data science? (Подсказка: если бы не мог, этого поста и следующего просто не существовало бы.)

Продолжение: Data Science и Agile (фреймворки для эффективности)

Продолжение: За что я люблю Scrum в data science

В этом посте мы обсудим сильные и слабые стороны Agile в контексте Data Science. Рискуя вызвать раздражение у практиков agile, я могу называть Agile и Scrum взаимозаменяемо. Тем не менее учтите, что Scrum — это один из agile-фреймворков процесса, и существуют другие, например Kanban и т. д. В следующем посте я поделюсь некоторыми agile-корректировками и практиками, которые доказали свою полезность — по крайней мере, в командах, которыми я руководил. Оставайтесь на связи!

Data science — это отчасти разработка ПО, отчасти исследования и инновации и полностью про использование данных для создания эффекта и ценности. Те аспекты data science, которые хорошо работают с agile, обычно ближе к инженерной природе, тогда как те, что ближе к исследованиям, вписываются хуже.

Какие аспекты agile хорошо работают с data science?

TL; DR:

Планирование и приоритизация в начале каждого спринта. Чёткое определение задач с результатами и сроками. Ретроспективы и демо в конце каждого спринта.

Планирование и приоритизация в начале каждого спринта

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

Планирование и приоритизация начинаются с взаимодействия со стейкхолдерами. Scrum обеспечивает явную приоритизацию вместе со стейкхолдерами и даёт фреймворк, чтобы иметь хороший обзор запланированных (и выполненных) задач, а также связанной с ними сложности и необходимых усилий. Со Scrum у стейкхолдеров есть представление об их «бюджете» на каждый спринт, что даёт им лучший контекст для принятия решений о компромиссах в объёме работ и участия в планировании спринта.

Регулярные встречи по планированию и приоритизации дают (внутренним и внешним) стейкхолдерам лучшее понимание издержек, связанных с каждой data science инициативой, и накладных расходов, связанных с частой сменой приоритетов и переключением контекста. Это обеспечивает выравнивание между командой данных и её стейкхолдерами, при котором стейкхолдеры осознанно относятся к своему бюджету на работу с данными, а команда данных понимает потребности организации и то, как она может эффективно вносить вклад.

Такое планирование и приоритизация помогают команде данных практиковать один из семи навыков высокоэффективных людей — «Сначала главное».

Чёткое определение задач с результатами и сроками

Одна из распространённых проблем data science проектов — недостаток фокуса или сход с пути из-за исследований, уходящих в кроличью нору. Отчасти это связано с врождённым любопытством, движущим большинством data scientist'ов, а отчасти — с нечёткой природой задач data science.

Заблаговременное определение задач с чёткими сроками помогает смягчить эту проблему. Наличие ясного, ожидаемого результата для каждой задачи соответствует одному из семи навыков высокоэффективных людей — «Начинай, представляя конечную цель».

При поступлении нового запроса полезно, чтобы лид data science или кто-то более опытный помог определить задачи и результаты. Например, если мы пытаемся понять, почему упал net promoter score (NPS, мера клиентского опыта), ожидаемые результаты могут включать анализ различных аспектов клиентского опыта, таких как:

Доставка (например, своевременность, состояние посылки при получении). Продукт (например, рейтинги товаров, отзывы, цена). Клиентский сервис (например, время ожидания, число точек контакта, оценки клиентского сервиса). Метрики приложения (например, спамные уведомления, медленная загрузка, запутанный UI).

Это помогло бы сузить причины падения NPS. Далее мы можем оценить влияние более низкого NPS на бизнес. Тратят ли меньше клиенты с более низким NPS (т. е. размер корзины, частота покупок, абсолютные траты)? Менее ли они активны в приложении или отключили уведомления? Есть ли риск их оттока?

Определение этих вопросов и гипотез заранее задаёт вехи для data scientist'ов по ходу их анализа. Кроме того, обсуждение этих задач со стейкхолдерами может дать полезную информацию и обратную связь, опирающуюся на их экспертизу.

Процесс схож при создании продуктов на данных, где у большинства проектов похожий поток:

Извлечение данных: минимальный набор денормализованных данных по всем источникам данных организации. Подготовка данных: единообразное форматирование, приведение строк к нижнему регистру, заполнение пропусков, обработка выбросов и редко встречающихся значений. Feature engineering: label/one-hot кодирование, нормализация/масштабирование непрерывных переменных, различная дополнительная инженерия признаков. Валидация: настройка фреймворка для валидации (т. е. случайная выборка, выборка по времени); определение правильных метрик машинного обучения и AB-тестирования. Машинное обучение: быстрая оценка нескольких моделей, выбор наиболее подходящих техник, тюнинг параметров, дополнительный feature engineering, ансамблирование. MVP и демонстрация результатов стейкхолдерам: ожидаемые улучшения текущих метрик, ожидаемые усилия и стоимость вывода в продакшен, дорожные карты. AB-тестирование: разделение трафика и выборка; учёт размера выборки и мощности, сбор результатов AB-тестирования и данных.

Приведённые выше примеры перечисляют лишь некоторые из требуемых задач на очень высоком уровне. Естественный вопрос от стейкхолдеров будет таким: «сколько времени это займёт?». Data scientist'ы с несколькими годами опыта обычно могут дать достаточно точную оценку необходимых усилий. Тем не менее это может варьироваться в зависимости от среды (например, инфраструктура, безопасность, бюрократия), качества данных и навыков data scientist'а(ов).

Возьмём, к примеру, разработку продукта на данных — должна ли она занять два года? Если она улучшит результаты организации в 10 раз, то, возможно. Если улучшение составляет 10%, то, может, и нет, хотя это зависит от обстоятельств. Поэтому установка чётких сроков до начала проекта, исходя из оценочной ценности проекта, помогает задать правильный контекст для команды data science. В зависимости от срока — будь то 6 недель или 6 месяцев на создание MVP — команда data science может распределить усилия по каждому из шагов соответствующим образом.

Ретроспективы и демо в конце каждого спринта

Два ритуала, которые мне особенно нравятся, — это ретроспективы и демо-сессии в конце каждого спринта. Их цель — помочь команде учиться друг у друга, отпраздновать наши достижения и получить обратную связь о том, как сделать лучше в следующем спринте. Учитывая, что каждый занимает около 30–60 минут, но при этом так сильно способствует росту команды, удовлетворённости и благополучию, они имеют очень высокую отдачу от инвестиций (времени).

На каждой ретроспективе команда осмысляет спринт прошедшей недели. Есть много способов это делать, но вот подход, который, как я обнаружил, работает. Каждый заполняет доску пунктами о том, что он обнаружил:

Приятное: какие аспекты спринта и задач им понравились? Какие достижения нам стоит отпраздновать? Раздражающее: какие аспекты работы были раздражающими? Были ли эти трудности скорее технической природы? Или бизнесовой? Или политической? Что мы можем сделать, чтобы стало лучше? Какие уроки из этого извлекли? Озадачивающее: что озадачило вас в течение недели? Сталкивался ли кто-то ещё в команде с этим раньше? Есть ли какие-нибудь идеи о следующих шагах?

Если ретроспектива проводится еженедельно, она помогает команде расти и извлекать пользу из каждого спринта. При улучшении на 5% от каждой еженедельной ретроспективы, через год команда станет в 1,05 ^ 52 = 12 раз лучше!

На демо-сессии команда собирается, чтобы поделиться значимыми вехами, завершёнными за прошедший(ие) спринт(ы). Необязательно, чтобы каждый делал демо каждую неделю — обычно демо проводят после значимого куска работы или конкретной вехи, что может занимать от 2 до 8 недель.

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

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

Какие аспекты Agile затрудняют его применение в Data Science

TL; DR:

Усилия в Data Science хуже определены и потому их сложнее оценивать. Объём и требования могут меняться очень быстро. Ожидания, что спринты Data Science должны иметь результаты, как инженерные спринты. Быть слишком хорошим/дисциплинированным в Scrum.

Усилия в Data Science хуже определены и потому их сложнее оценивать

Задачи data science хуже определены по сравнению с инженерными задачами — это усложняет оценку. Например, когда поступает задача, не всегда очевидно, какие данные следует использовать. После того как датасет выбран, сколько усилий нужно на исследование данных, их очистку и подготовку, feature engineering, оценку нескольких моделей и затем достижение целевой метрики? Хотя процесс можно как следует определить, объём усилий на каждую задачу может сильно варьироваться от проекта к проекту.

Предположим, вам дали задачу повысить конверсию на e-commerce сайте за счёт улучшения его алгоритма ранжирования, с целью прироста как минимум на 5% (при меньшем значении это, возможно, трудно будет обнаружить через AB-тестирование). Это относительно крупный проект для оценки объёма, со множеством неопределённостей.

Будут ли данные чистыми и соответствующими нашим предположениям, или в данных будут странные артефакты? Если в данных есть проблемы, почему? Трекер работает некорректно? Или это из-за необычного поведения пользователей? Как это влияет на анализ и на разрабатываемую систему? Как следует моделировать эту задачу? Должна ли это быть задача learning to rank, где товары ранжируются по каждой категории и поисковому запросу? Или это задача классификации на основе клика, или добавления в корзину, или оформления заказа? Или, может быть, это задача регрессии на основе кликов, добавлений в корзину, оформлений заказа или выручки? Какой должна быть метрика успеха? Клики? Покупки? Выручка? Должно ли это быть абсолютное значение (т. е. общее число покупок) или ставка (т. е. коэффициент конверсии)?

На основе простого примера выше, намерение и желаемые результаты ясны. Однако существует множество путей к достижению этой цели.

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

Объём и требования могут меняться очень быстро

В силу природы бизнеса объём и/или требования стейкхолдеров могут быстро меняться. По мере того как данные исследуются в поисках ответов, требуемые анализы и решение могут меняться прямо по ходу работы. Например, у стейкхолдеров могут быть твёрдые убеждения о причине проблемы и нужном решении, но данные могут указывать на нечто иное. В результате запланированный объём работ и задачи придётся развернуть соответствующим образом. Это может нарушать ход спринта, если делается слишком часто.

По сравнению с разработкой ПО, data science как дисциплина относительно моложе и менее зрелая. (Да, кто-то может возразить, что data science — это просто статистика, которая зрела, в более привлекательной обёртке. Возможно, это лучше разобрать в другом эссе.) Разработка ПО — довольно зрелая дисциплина с относительно хорошо определёнными задачами и паттернами проектирования, а потому с задачами, которые легче оценивать по объёму. Data science моложе, с задачами, которые сложнее определить, и решениями, которые не так очевидны. Это различие делает разбиение проектов на маленькие, хорошо определённые задачи более трудным.

Ожидания, что спринты Data Science должны иметь результаты, как инженерные спринты

Многие люди, знакомые с agile или scrum — скорее всего, из инженерного контекста — ожидают рабочий код в конце каждого спринта. При первом применении scrum к data science большинство project-менеджеров пытаются иметь чётко определённый итог или результат. В контексте инженерии это может быть настройка какой-то инфраструктуры, реализация новой фичи или разработка нового фронтенда. В этих случаях явно есть осязаемый результат, который можно «подержать в руках» (вроде как) и отчитаться наверх, например через демонстрацию новой фичи или фронтенда.

Однако в случае data science это становится немного хитрее. Иногда работа data science включает анализ, где кто-то ожидает ответа, или модель машинного обучения, которая вносит вклад в измеримое улучшение определённых метрик. Такие критерии приёмки трудно определить при оценке объёма задач и назначении PM-тикетов. Более того, учитывая, что data science отчасти исследование, любящие сроки PM могут находить отсутствие чётких дедлайнов дезориентирующим. Это приводит к расстроенным PM, чьи ожидаемые результаты не достигнуты, и к чрезмерно напряжённым data scientist'ам, у которых нет времени и пространства, чтобы творить и находить оптимальные решения.

Быть слишком хорошим/дисциплинированным в Scrum

Бывает ли когда-нибудь проблемой то, что ты слишком хорош в чём-то? Пожалуй, да. Иногда, когда команды становятся очень выровненными с бизнесом и очень дисциплинированными в соблюдении scrum-специфичных дедлайнов, может возникнуть проблема иного рода.

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

В сочетании с командой data science, привыкшей к scrum и дедлайнам, это может привести к (приятной) проблеме чрезмерной сосредоточенности на завершении задач до конца спринта и выполнении своих story points. Это выглядит продуктивным («Посмотрите, сколько story points мы выполнили! Какая красивая burn-down диаграмма»), но может быть обманчиво неэффективным — срочное (и иногда менее важное) приоритизируется и выполняется эффективно в ущерб важному, но не срочному.

Сильные стороны команды data science — в «прислушивании к данным» и исследованиях. Применение инноваций для улучшения результатов организации должно быть частью их мандата.

Так может ли Data Science быть Agile или нет?

«Этот пост кажется противоречивым — сначала ты говоришь мне, что agile хорошо работает с data science, а затем поднимаешь все проблемы с ним.»

Надеюсь, изложив некоторые плюсы и минусы, вы получите лучшее представление о том, как применять agile к data science, и о потенциальных подводных камнях. Несмотря на некоторые трудности, я считаю, что agile и data science хорошо сочетаются друг с другом — иначе я не внедрял бы его в своих прошлых командах.

Чтобы разобраться с некоторыми из поднятых проблем, можно внести несколько простых корректировок в процесс и образ мышления — о них я расскажу в следующем посте. Оставайтесь на связи!

Обновление: это первый пост из двухчастного материала про Data Science и Agile. В следующем посте мы обсудим некоторые фреймворки для эффективного применения Agile к Data Science. Следующий пост вы можете найти здесь.

Если вы нашли это полезным, пожалуйста, цитируйте эту статью как:

Yan, Ziyou. (Jan 2019). Data Science and Agile (What Works, and What Doesn't). eugeneyan.com. https://eugeneyan.com/writing/data-science-and-agile-what-works-and-what-doesnt/.

или

@article{yan2019agile2, title = {Data Science and Agile (What Works, and What Doesn't)}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2019}, month = {Jan}, url = {https://eugeneyan.com/writing/data-science-and-agile-what-works-and-what-doesnt/} }

Присоединяйтесь к 11 800+ читателям, получающим обновления о машинном обучении, RecSys, LLM и инженерии.