Data Driven Scrum™ (DDS) — это гибкая методология, специально разработанная для команд, занимающихся наукой о данных. Вкратце, DDS нацелен на улучшение сотрудничества и коммуникации внутри команды по работе с данными.
Джефф Салтц и Алекс Сазерленд создали Data Driven Scrum, чтобы устранить недостатки известных гибких подходов (таких как Scrum и Kanban), которые зачастую не учитывают уникальные особенности проектов в области науки о данных.
Достижение гибкости через 3 ключевые концепции
Существует три ключевые концепции, которые, позволяют команде получить преимущества гибкости в проекте по анализу данных. Такая гибкость помогает команде сосредотачиваться на задачах с наивысшим приоритетом, а также обеспечивает возможность изменения приоритетов для будущих задач по мере необходимости.
Эти три гибкие концепции заключаются в следующем:
1. Гибкость предполагает последовательность циклов итеративных экспериментов и адаптации.
2. Цель каждого цикла — сформировать идею или эксперимент, реализовать его, провести анализ, а затем использовать полученные результаты для создания следующей идеи или эксперимента.
3. Процесс от первоначальной идеи через её реализацию до анализа результатов должен служить основой для итерации. Завершение эмпирического процесса должно обозначать конец итерации, а не заранее установленное количество часов.
Использование DDS: Общий поток работы
1. Формулировка вопросов или экспериментов.
На первом этапе команды, работающие по DDS, проводят мозговой штурм, чтобы определить возможные вопросы, на которые нужно ответить, или эксперименты, которые необходимо выполнить.
2. Приоритизация вопросов.
Далее команда определяет приоритеты среди этих вопросов, выбирая задачу с наивысшим приоритетом для совместной работы. Это включает в себя выбор данных для использования и моделей, которые необходимо создать.
3. Интерпретация результатов.
После выполнения работы команда совместно анализирует полученные результаты.
4. Внедрение и планирование будущей работы.
На основе результатов команда внедряет их и определяет приоритеты для дальнейшей работы.
Роли в DDS
Как и в Scrum, в DDS выделяются три ключевые роли:
1. Владелец продукта (Product Owner):
Владелец продукта в DDS — это главный лидер, представляющий интересы клиента («голос клиента»). Он отвечает за определение прироста функциональности продукта (Product Increments), приоритизацию функций и возможностей, порядок их реализации, а также аспекты, которые нужно наблюдать и анализировать.
Владелец продукта управляет Бэклогом, расставляет приоритеты для его элементов, следит за их четким определением и обеспечивает прозрачность предстоящих задач и приоритетов команды.
2. Эксперт по процессам (Process Expert):
Эксперт по процессам играет роль коуча, фасилитатора и устраняющего препятствия. Он помогает команде понять и принять ценности, принципы и практики DDS, чтобы организация могла добиться выдающихся результатов, применяя DDS.
3. Члены команды DDS (DDS Team Members):
Подобно Scrum, каждая команда DDS обычно состоит из 3–9 человек. Команда включает в себя специалистов разных направлений (например, специалистов по данным, инженеров-программистов), которые обладают всеми необходимыми навыками для создания артефактов (например, моделей) с целью ответить на вопросы или выполнить эксперименты. Это включает проектирование, создание, тестирование и развертывание желаемого продукта.
Как владелец продукта, так и эксперт по процессам являются частью команды DDS и могут участвовать в создании, наблюдении и анализе на протяжении итерации. Команда самостоятельно организует свою работу, чтобы наиболее эффективно достичь цели, определенной владельцем продукта.
Артефакты DDS
В DDS есть четыре артефакта, описывающие работу, которую нужно выполнить:
1. Элемент (Item):
Элемент может принимать различные формы, такие как «пользовательские истории», «эксперименты» или «проверяемые гипотезы», популяризированные XP и Lean. В области науки о данных элементы обычно представляют собой вопросы, на которые команде нужно ответить, или гипотезы, которые нужно проверить.
2. Бэклог (Backlog):
Бэклог представляет собой упорядоченный по приоритету список элементов (то есть работы, которую нужно выполнить).
3. Доска разбивки элементов (Item Breakdown Board, IBB):
Доска разбивки элементов — это место, где каждый элемент из бэклога разбивается на задачи. Элементы бэклога делятся на составные задачи перед тем, как команда приступает к их выполнению. У каждого элемента есть собственная IBB. Работа по созданию IBB проводится в рамках уточнения бэклога.
Для каждого элемента должны быть определены как минимум три типа задач:
- Создать (Create): создание модели, алгоритма или другого артефакта.
- Наблюдать (Observe): сбор и анализ данных.
- Анализировать (Analyze): интерпретация результатов.
Доска задач (Task Board):
Доска задач — это визуальное представление элементов, которые находятся в работе. Когда команда начинает работу над элементом, задачи из его IBB переносятся на доску задач и размещаются в колонке «к выполнению» (to do).
Доска задач содержит несколько колонок (как минимум: «к выполнению» (to do), «в работе» (in progress), «выполнено» (done)), через которые задачи перемещаются, визуально отображая прогресс команды.
Итерация считается завершенной, когда все задачи элемента оказываются в колонке «выполнено» (done). Прежде чем задача считается завершённой, владелец продукта должен подтвердить её завершение (для этого можно добавить колонку «подтверждено завершение» (confirmed done)).
Как в Kanban, каждая колонка имеет ограничение на количество задач, находящихся в ней одновременно (лимит незавершенной работы, Work-In-Progress limit), чтобы оптимизировать поток задач.
Деятельность в DDS
Деятельность в DDS определяет работу, которую выполняет команда. Эти активности не ограничены по времени, а сосредоточены на определении и выполнении итераций. Ниже описаны ключевые концепции:
1. Уточнение бэклога (Backlog Refinement):
Команда не только работает над итерациями, но и выделяет время на оценку элементов бэклога, чтобы расставить их приоритеты. Эта оценка включает:
- Относительную оценку ценности элемента после завершения;
- Относительную оценку усилий, необходимых для завершения элемента;
- Относительную оценку вероятности успешного выполнения элемента.
Во время уточнения команда определяет единицы измерения (например, размер футболки: большой, средний, маленький) или числовую оценку для определения ценности, усилий и вероятности успеха.
Оценка усилий помогает приоритизировать элементы, но не определяет, что войдёт в итерацию. Например, если два элемента имеют одинаковую ценность, но один из них требует меньше усилий, команда может выбрать его.
Хотя владелец продукта отвечает за процесс приоритизации, остальные члены команды выделяют 5–10% своего времени на помощь владельцу продукта (например, разбиение элемента на более мелкие задачи, упрощение элемента, оценка усилий).
2. Приоритизация бэклога:
Команда оценивает элементы бэклога, предоставляя высокоуровневые оценки:
1. Ценности работы;
2. Объёма работы (усилий команды);
3. Вероятности успеха.
Владелец продукта, с учётом мнения заинтересованных сторон и команды, поддерживает актуальность и приоритеты бэклога, который изменяется в течение всего проекта.
3. Итерации:
Итерация — это набор из одного или нескольких элементов бэклога. Цель итерации — выпустить логически завершённый объём работы. Каждая итерация включает:
- Создание артефакта для ответа на вопрос (например, модели);
- Наблюдение за артефактом (например, его производительность на тестовых данных);
- Анализ полученных наблюдений.
Результаты итерации должны быть ценными, будь то созданный артефакт или проведённый анализ.
4. Длительность итерации:
Итерация основана на возможностях команды, а не на фиксированных временных рамках. Она должна представлять минимально возможный набор работы, который создаёт ценность и позволяет проверить гипотезу. Итерация не должна длиться дольше месяца, но может быть и короче (например, один день).
Итерация завершается, когда работа, необходимая для ответа на вопрос, выполнена. Параллельное выполнение нескольких итераций возможно, если наблюдения или задачи предыдущей итерации занимают время (например, сбор данных).
5. Прирост функциональности продукта (Product Increment):
Product Increment — это высокоуровневая цель команды, достигаемая за фиксированный срок (например, 3 месяца) с использованием нескольких итераций. Прирост помогает команде расставлять приоритеты для итераций и формировать ожидания клиентов.
События в DDS
В DDS предусмотрено четыре регулярных события, которые происходят по установленному графику, а не зависят от завершения итерации. Эти события, фасилитируемые экспертом по процессам DDS, помогают команде оставаться скоординированной.
Основные цели событий:
- Планировать итерации через выбор элементов бэклога.
- Проводить обзор результатов итерации, извлекать уроки для будущих итераций.
- Рефлексировать о том, как улучшить процессы команды через ретроспективы.
- Выявлять возможные препятствия в работе через ежедневные встречи.
1. Выбор элементов бэклога (Backlog Item Selection):
Проводится, когда команда готова начать новую итерацию (например, после завершения предыдущей или в случае, если текущая итерация не требует полного вовлечения, как в фазе «наблюдения»).
Команда рассматривает приоритетные элементы бэклога (уточнённые на этапе Refinement) и выбирает те, которые станут фокусом работы. Команда может вести несколько итераций одновременно, но, по возможности, должна отдавать приоритет завершению текущей итерации.
2. Ежедневная встреча (Daily Meeting):
Проводится каждый рабочий день и длится около 15 минут. Её цель — инспектировать и адаптировать процесс, помогая команде лучше управлять потоком работы (например, решать проблемы участников).
Формат схож со Scrum Standups: участники обсуждают, что они сделали вчера, что планируют сделать сегодня и какие препятствия нужно преодолеть.
3. Обзор итерации (Iteration Review):
Проводится регулярно (например, еженедельно) по графику, установленному владельцем продукта. Обзоры направлены на обсуждение выполненной функциональности, наблюдений и анализа, полученных за итерацию.
Участники: команда, заинтересованные стороны, клиенты и другие заинтересованные лица.
Цели обзора:
- Предоставить обратную связь о выполненной итерации.
- Обсудить идеи для новых функций, метрик и экспериментов.
- Обновить приоритеты элементов бэклога на основе новых инсайтов.
Завершённые задачи архивируются после обсуждения.
4. Ретроспектива (Retrospective):
Проводится на регулярной основе (например, раз в месяц) и является временем для анализа и улучшения процесса.
Команда обсуждает, что работает хорошо, а что требует улучшения, с целью постоянного совершенствования.
Цель:
К концу ретроспективы команда должна выбрать небольшое количество конкретных улучшений, которые она будет внедрять в дальнейшем.
Сравнение Data Driven Scrum (DDS) с традиционным Scrum и Kanban
Как DDS отличается от традиционного Scrum
1. Функциональные (основанные на возможностях) итерации:
В традиционном Scrum все итерации (спринты) имеют фиксированную продолжительность. В DDS же продолжительность итераций варьируется, чтобы выполнить логически завершённый объём работы, а не подгонять задачи под определённый временной интервал.
- Итерации DDS могут быть короче или длиннее среднего, например, если задача решается быстрым экспериментом.
2. Неопределённая продолжительность задач:
В DDS нет необходимости точно оценивать, что может быть выполнено за 1–2 недели, как это требуется в Scrum. Это особенно важно для задач в области анализа данных, где оценка усилий часто затруднена.
- Вместо детальных оценок используются высокоуровневые оценки (например, по принципу "размер футболки").
3. Коллективный анализ:
В традиционном Scrum наблюдение, анализ и реакция на обратную связь часто остаются обязанностью владельца продукта и происходят вне формального процесса. В DDS эти шаги встроены в основной рабочий процесс.
- Вся команда участвует в создании, наблюдении и анализе гипотез, данных или функций.
4. Отвязка встреч от итераций:
Поскольку итерации DDS могут быть очень короткими (например, однодневный анализ), встречи, такие как ретроспективы, проводятся с регулярной частотой, определённой командой, а не в конце каждой итерации.
5. Перекрытие итераций:
В DDS гораздо чаще встречаются пересекающиеся итерации. Например, пока задача «наблюдения» (например, сбор данных) занимает время, команда может начать следующую итерацию.
---
Как DDS опирается на традиционный Scrum
1. Роли:
Как и в Scrum, в DDS команды состоят из максимум 10 человек, включая владельца продукта и эксперта по процессам.
2. События:
В DDS также присутствуют ежедневные встречи, обзоры итераций и ретроспективы.
3. Процесс создания и приоритизации элементов:
Как и в Scrum, элементы создаются, приоритизируются и отображаются на доске задач.
4. Фокус на гибкости:
Оба подхода направлены на обеспечение гибкости команды через небольшие итерации.
Как DDS опирается на Kanban
1. Визуализация рабочего процесса:
DDS использует визуальные доски, чтобы отображать работу с помощью карточек. Колонки (например, «к выполнению», «в работе», «выполнено») помогают следить за выполнением задач.
2. Ограничение незавершённой работы (WIP):
DDS придерживается принципа Kanban об ограничении количества задач в работе для каждой колонки. Это помогает обеспечить плавное перемещение карточек по доске.
DDS объединяет элементы Scrum и Kanban, адаптируя их к уникальным потребностям проектов в области науки о данных, чтобы обеспечить гибкость, визуализацию работы и коллективный подход к анализу.
Подписывайтесь на канал в Dzen, а так же на телеграмм канал https://t.me//ART_M_channel