Data Science and Agile (Frameworks for Effectiveness)

eugeneyan

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

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

[ mechanism agile datascience productivity ] · чтение на 14 мин

Это второй пост в материале из двух частей про Data Science и Agile. В прошлом посте мы обсудили те аспекты Agile, которые работают и не работают в процессе data science. Предыдущий пост можно найти здесь.

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

Краткое напоминание о том, что работает хорошо

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

Чётко определённые задачи со сроками: это помогает команде data science оставаться продуктивной и идти по плану, а также укладываться в заданные сроки — рынок движется быстро и не ждёт.

Ретроспективы и демо: ретроспективы помогают команде улучшаться с каждым спринтом и дают обратную связь и понимание болевых точек, которые стоит исправить. Демо помогают команде учиться и получать обратную связь друг от друга. Если в них участвуют стейкхолдеры, демо также дают представление о том, над чем работает команда data science.

А что насчёт аспектов, которые работают не очень?

Сложность с оценками: задачи data science, как правило, хуже определены, с более широким пространством поиска решений. Поэтому оценки оказываются более рискованными, с большей дисперсией ошибки. Один из способов обойти это — выделять бюджеты на story-points / человеко-дни и ограничивать эксперименты по времени (таймбоксинг).

Быстро меняющийся объём и требования: стремительно развивающаяся бизнес-среда может приносить с собой постоянно меняющиеся приоритеты организации. Чтобы смягчить это, проводите периодические приоритизации со стейкхолдерами для обеспечения согласованности. Это также помогает стейкхолдерам лучше понимать накладные издержки частого переключения контекста.

Ожидание инженерных результатов после каждого спринта: проектные менеджеры и топ-менеджеры с инженерным бэкграундом могут ожидать работающее ПО после каждого спринта. Чтобы изменить такое мышление, может потребоваться некоторое вовлечение и просвещение. Хотя результатом каждого спринта может быть не работающий код, он тоже ценен (например, результаты экспериментов, выводы исследований, полученные знания, следующие шаги).

Излишняя дисциплина со сроками: приятная проблема — быть слишком эффективными и согласованными с приоритетами бизнеса. Тем не менее команда data science должна заниматься инновациями. Если взять пример с Google, команда может закладывать 20% времени на инновации. Инновации необходимы для улучшений в 10 раз.

Как адаптировать Agile под Data Science

В свете обсуждённых выше моментов, как мы можем эффективнее применять agile/scrum к data science?

Здесь я поделюсь некоторыми фреймворками/процессами/идеями, которые хорошо сработали для меня и моих команд — надеюсь, они будут полезны и вам. А именно:

Итерации с таймбоксами Начинать с планирования и приоритизации, заканчивать демо и ретроспективой Письменно оформлять проекты до старта Обновлённое мышление, включающее инновации

Итерации с таймбоксами

Один фреймворк, который я считаю полезным, — «итерации с таймбоксами» (time-boxed iterations). Фокус в том, чтобы внутри каждого проекта было несколько фаз-итераций, и внутри каждой итерации идеи и результаты валидируются до удовлетворительного уровня прежде, чем переходить к следующей итерации.

Это обеспечивает постоянную обратную связь на каждой стадии проекта, особенно на ранних этапах, где наибольшая неопределённость. Худшее, что может случиться, — потратить значительное время и ресурсы на проект и обнаружить, что это не то, что на самом деле было нужно стейкхолдерам (потому что большинство людей не могут сформулировать, что им действительно нужно). Или что им не будут пользоваться. Кроме того, итерации с таймбоксами не дают R&D-начинаниям превратиться в чёрную дыру.

Давайте пройдёмся по каждой из четырёх перечисленных выше стадий.

Оценка осуществимости (Feasibility Assessment)

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

Если её можно решить на существующих данных, какого уровня производительности можно ожидать? Например, если задача — классификация товаров, грубая оценка точности (precision) — 50% или 90%? Эти начальные метрики сильно влияют на пригодность продукта: 50% сделали бы его трудным в использовании, хотя это всё равно значительно лучше случайного угадывания, учитывая тысячи категорий.

Главный вопрос на этой стадии: учитывая имеющиеся данные, можем ли мы получить разумный уровень производительности? Стоит ли тратить на это больше ресурсов?

Допустим, желаемый уровень точности — 95%. Если грубая оценка — 90%, то с некоторым временем и усилиями мы, возможно, сможем достичь 95% точности. Однако если грубая оценка — 70% (а разрыв в 25% довольно велик в data science), то, пожалуй, стоит отправить проект в бэклог и поработать над шагами по улучшению производительности. Это может включать дополнительный сбор данных, transfer learning, исследования и т. д.

Обычно этот шаг можно выполнить довольно быстро, примерно за 2–4 недели, при условии, что это внутренний проект и есть знакомство с данными.

Proof of Concept (POC)

Если начальная производительность по итогам оценки осуществимости оказалась удовлетворительной, мы переходим к разработке POC. Это предполагает создание минимально жизнеспособного продукта (MVP) для демонстрации технической осуществимости. Цель — иметь работающий код и модель(и) машинного обучения, чтобы валидировать первоначальную идею и реализацию.

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

Главный вопрос здесь: достаточно ли это хорошо, чтобы тратить дополнительные ресурсы на вывод в продакшен? Соответствует ли это требованиям к производительности (например, качество модели, задержка и т. д.)?

В зависимости от результатов POC мы решим, стоит ли (i) развернуть в продакшен и итерировать, или (ii) дорабатывать POC дальше (потому что мы так близко), или (iii) вернуться к проекту в другой раз, потому что разрыв между пригодным продуктом и существующим MVP слишком велик.

С опытной командой POC можно завершить примерно за 4–8 недель, в зависимости от сложности проекта.

Вывод в продакшен

Если до сих пор всё шло хорошо — отлично! Дальше мы выводим наше решение в продакшен, где оно может приносить реальную пользу. Обычно это предполагает работу с дата-инженерией (которая может помочь с планированием задач, масштабированием, мониторингом и т. д.) и с основной инженерной командой для интеграции в платформу.

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

Вывод в продакшен может занять от 3 до 9 месяцев, в зависимости от нескольких факторов, включая инфраструктуру (например, on-premise или облако), требования к технической производительности, безопасность и т. д.

Некоторые непосвящённые, жаждущие результатов, могут спросить: «Разве у нас уже нет работающего POC? Почему бы просто не развернуть его в продакшен? Зачем тратить ещё время?» Код продакшен-качества фокусируется на устойчивости, поддерживаемости, расширяемости, масштабируемости и т. д. Эти аспекты могут обходиться дорого.

Один инженер-программист с опытом работы в Google, Microsoft, Amazon и Oracle поделился на Quora, что исследовательский прототип занял 2 человеко-месяца, тогда как версия продакшен-качества потребовала 117 человеко-месяцев. Это примерно в 60 раз больше времени!

Операционная поддержка

Наконец, после развёртывания в продакшен, дата-продукт потребует некоторых усилий на сопровождение, а также на запрашиваемые новые фичи/модели.

Размер этих усилий зависит от сложности продукта, а также от объёма технического долга (который может возникнуть из-за поспешных развёртываний, плохого дизайна и т. д.).

В целом весь процесс от бизнес-запроса до продакшена может занять от 6 до 12 месяцев.

Фреймворк делает акцент на частых сверках со стейкхолдерами организации, гарантируя, что разрабатываемый дата-продукт соответствует потребностям организации, и позволяя получать обратную связь от стейкхолдеров. Есть также две главные контрольные точки — (i) оценка осуществимости и (ii) результаты POC, — где требуется критическое решение «идём дальше» прежде, чем эскалировать обязательства и ресурсы. Вместе взятое, это помогает обеспечить согласованность с организацией.

Начинать с планирования и приоритизации, заканчивать демо и ретроспективой

Есть ритуалы, которые я считаю очень полезными (и которыми наслаждаюсь) в начале и в конце каждого спринта. Они, скорее всего, уже являются частью вашей существующей agile-практики, но я подумал, что будет хорошо их подчеркнуть.

В начале каждого спринта важно пройти через планирование и приоритизацию.

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

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

Затем в конце каждого спринта у нас есть демо и ретроспектива — это особенно приятно.

Демо позволяют команде делиться контрольными точками и достижениями прошедшего спринта (спринтов). Это обеспечивает обучение всей команды, повышая ваш bus factor. Кроме того, это даёт остальной части команды возможность дать обратную связь по работе друг друга, что ведёт к улучшениям.

Наконец, у команды есть шанс «похвастаться» своей гордостью и радостью за прошедший спринт (спринты), и все вместе отмечают командные достижения, что очень мотивирует.

После этого у нас также есть ретроспектива, которая даёт каждому шанс подвести итоги текущего спринта. Что прошло хорошо? Что нет? Как мы можем улучшиться? Команда учится и извлекает пользу из каждого демо и ретроспективы, делая следующий спринт чуть более результативным и эффективным.

Письменное оформление проектов до старта

Я настоятельно рекомендую членам команды начинать каждый проект с того, чтобы потратить немного времени на планирование проекта и его письменное оформление.

Изложение мыслей в документе помогает прояснить собственные идеи, особенно когда идеи и проекты туманны.

Документ также служит картой, к которой можно обратиться в любой момент, чтобы убедиться, что проект идёт по плану. Вот стандартный шаблон, который я считаю полезным:

В чём проблема или возможность? В чём намерение? Какой желаемый результат и/или метрика успеха? Что является результатом (deliverable)? В чём выгоды? Какие есть зависимости и ограничения?

Во-первых, всегда начинайте с текущей ситуации — в чём проблема или возможность? Есть ли существующий подход к её решению? Каков текущий уровень производительности? Является ли это проблемой, в которой данные и data science могут помочь? Например, может быть так, что сайт электронной коммерции в настоящее время классифицирует новые товары вручную.

Предположим, каждый человек может классифицировать 2 000 товаров в день, при цели добавить 1 миллиард новых товаров за год — это выливается в 500 тысяч человеко-дней (или 2 000 человек, если считать 250 рабочих дней в году). Это явно узкое место для масштабирования.

Далее, от стейкхолдеров — каково высокоуровневое намерение? С этим намерением мы можем лучше понять цель (то есть «что»), и команда data science может определить наилучший способ (то есть «как») её достичь. В данном случае намерение состояло бы в том, чтобы масштабировать количество товаров, которое можно добавить на платформу, за счёт автоматизации.

Затем, исходя из этого намерения, каков прямой желаемый результат? Иначе говоря, какова метрика успеха, если она предопределена? Это задаёт цель, которая ведёт команду через процесс итераций с таймбоксами (см. выше). Например, если намерение — автоматизировать категоризацию товаров, конкретными числами могли бы быть 95% top-3 precision и recall с задержкой классификации 40 товаров в секунду. Такая задержка привела бы к классификации 1 миллиарда товаров за 290 дней. Этого может быть недостаточно, учитывая пики и спады добавления товаров — один из способов обойти это — масштабироваться горизонтально (то есть несколько API, обрабатывающих параллельно).

Учитывая намерение, желаемый результат и метрику успеха, что является результатом (deliverable)? Здесь команда data science проведёт мозговой штурм различных подходов для достижения намерения. Возможно, это мог бы быть API, интегрированный в платформу, куда продавцы могут загружать свои товары. Был бы полезен и востребован пакетный (batch) режим? Какие поля товара доступны для построения нашего классификатора (например, заголовок, изображение, атрибуты и т. д.)? В данном случае результатом мог бы быть API, который принимает поля товара и возвращает три наиболее вероятные категории. Этот API может быть доступен как внутренним, так и внешним пользователям.

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

Предположим, что 90% из 1 миллиарда товаров можно классифицировать автоматически — сколько рабочей силы будет сэкономлено?

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

Далее, есть ли какие-либо зависимости у этого проекта? Например, есть ли конкретные точки интеграции, такие как база данных товаров или интерфейс, где продавцы обновляют свои товары? Есть ли также определённые требования к частоте обновления данных и модели, чтобы модель оставалась актуальной и сохраняла приемлемую производительность?

Наконец, каковы ограничения для работы data science? Одним из возможных ограничений был бы язык (например, Python, Java, Scala, Go). Какие языки поддерживаются? Какие фреймворки разрешено использовать? Доступны ли распределённые вычисления? Какова максимально допустимая задержка разрабатываемого API? Сколько вычислительных ресурсов и памяти доступно на каждый сервер API? Это некоторые из ключевых вопросов, которые определят архитектуру итогового решения.

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

Обновлённое мышление, включающее инновации

Для этого нет ясного шаблона или подхода, который я мог бы предложить.

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

Например, инновационным проектам можно было бы выделять 2–3 недели ежеквартально. Они должны быть напрямую связаны с желаемым результатом, с дальнейшими выгодами для организации. Это также помогает получить поддержку проекта.

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

Ключевые выводы

Уф, это был длинный пост (и длинное чтение). Спасибо, что остались со мной до сих пор.

В целом Agile — хороший фреймворк для применения в контексте data science, с выгодами, которые мы можем напрямую получить. Хотя есть некоторые аспекты, которые могут не подходить, есть и некоторые адаптации, которые можно сделать, чтобы он лучше подходил для команд и проектов data science.

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

Если внедрение agile и внесение определённых (других) корректировок помогает вашей команде достигать целей — так тому и быть. Не позволяйте этому ограничивать команду от выполнения ценной работы и реализации её потенциала.

На этом я завершаю Agile-манифестом.

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

Yan, Ziyou. (Feb 2019). Data Science and Agile (Frameworks for Effectiveness). eugeneyan.com. https://eugeneyan.com/writing/data-science-and-agile-frameworks-for-effectiveness/.

или

@article{yan2019agile3, title = {Data Science and Agile (Frameworks for Effectiveness)}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2019}, month = {Feb}, url = {https://eugeneyan.com/writing/data-science-and-agile-frameworks-for-effectiveness/} }

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