Документ представляет собой анализ применения agile-методологий в крупных хранилищах данных, упоминая основы работы agile-организаций и ключевые принципы agile-манифеста. Описаны структуры команд и их роли, процесс управления бэклогом и планирования спринтов, а также важность минимально жизнеспособного продукта (MVP) для снижения рисков разработки. Также рассматривается мониторинг продукта и выбор методологии (Kanban или Scrum) для эффективного выполнения задач.

1. Аспекты применения
Agile
для крупных
Хранилищ Данных
06-07 июня 2017
Теренин
Алексей
Алексеевич
AATerenin.SBT@
sberbank.ru

2. Что такое Agile-организация?
1
… которые обладают всеми инструментами, навыками
и полномочиями для удовлетворения определенной
потребности клиента …
… и используют гибкие методы разработки продукта (Scrum,
Kanban, Design Thinking, Lean Startup, …) при максимальной
автоматизации внедрения (DevOps, Continuous Delivery, …)
… и максимальной гибкости поддерживающие процессов
(HR, закупки, финансирование, …)
Agile
организация – это…
… Объединение максимально самодостаточных само-
организующихся кросс-функциональных команд,…

3. Люди
и взаимодействие
Работающий
продукт
Сотрудничество
с заказчиком
Готовность
к изменениям
процессов
и инструментов
исчерпывающей
документации
согласования
условий контракта
следования перво-
начальному плану
важнее
Ценности Agile были изложены в 2001 году в Agile-манифесте
2

4. 3
Основополагающие принципы Agile-манифеста
3
Мы следуем таким принципам
3. Работающий продукт следует выпускать как
можно чаще, с периодичностью от пары недель до
пары месяцев
1. Наивысшим приоритетом для нас является
удовлетворение потребностей клиента, благодаря
регулярной и ранней поставке ценности
2. Изменение требований приветствуется, даже на
поздних стадиях разработки. Agile-процессы
позволяют использовать изменения для обеспечения
заказчику конкурентного преимущества
4. Разработчики и представители бизнеса должны
ежедневно работать вместе
5. Над продуктом должны работать мотивированные
профессионалы. Чтобы работа была сделана,
создайте условия, обеспечьте поддержку
и полностью доверьтесь им
6. Личное общение является наиболее практичным и
эффективным способом обмена информацией как с
самой командой, так и внутри команды
12. Команда должна систематически анализировать
возможные способы улучшения эффективности и
соответственно корректировать стиль
своей работы
11. Самые лучшие требования, архитектурные и
технические решения рождаются у
самоорганизующихся команд
7. Работающий продукт — основной показатель
прогресса
9. Постоянное внимание к техническому
совершенству и качеству проектирования
повышает гибкость
10. Простота — искусство минимизации лишней
работы — крайне необходима
8. Инвесторы, разработчики и пользователи должны
иметь возможность поддерживать постоянный ритм
бесконечно. Agile помогает наладить такой
устойчивый процесс разработки

5. КОМАНДА
1
КОМАНДА
2
КОМАНДА
N
ЧАПТЕР
1
ЧАПТЕР
2
ЧАПТЕР
N
ТРАЙБ
Основные единицы Agile-организации в Сбербанке –
«Трайб», «Команда» и «Чаптер»
КУРАТОР ТРАЙБА
ТРАЙБ –
группа взаимосвязанных
Команд сформирован-
ная вокруг определен-
ного продукта/бизнес-
цели и отвечающая
за бизнес-результат
КОМАНДА –
кросс-функциональная
совместно работающая
группа специалистов
обладающая всеми
навыками, инструментами
и полномочиями для
самостоятельной разработки
работающего продукта
КУРАТОР–
член Правления банка,
вовлеченный в Agile,
отвечает за бизнес-результат
нескольких Трайбов
ЧАПТЕР–
группа специалистов одной
области компетенций
4

6. Роли-команде
Команда
УК
ВП
УК
СМ
УК
Отвечает за выпуск продукта, соответствующего
потребности клиента
ВП
Владелец продукта
ВП
СМ
Скрам-мастер
Отвечает за эффективность рабочего процесса,
выстраивание эффективных взаимодействий с другими
командами и подразделениями, а также за развитие
самоорганизации и повышение зрелости Команды
СМ
Участник команды
Специалист, непосредственно участвующий
в создании продукта Команды в пределах своих
компетенций, является членом чаптера по линии своей
компетенции
УК
УК
5

7. Постановка задач в Agile ведется по принципу «ЧтоКак»
6

8. Для реализации стримов трайба команды детализируют стримы
в бэклоге команды
7
▪ Бэклог команды – это перечень всех требований к стриму трайба/программы,
переданных в команду либо созданных внутри нее
▪ Бэклог команды формируется по принципу pull
▪ Решение о включении элемента в бэклог и его приоритете принимает
Владелец продукта
▪ В бэклоге должны быть только необходимые элементы
▪ Бэклог команды фиксируется на доске команды и отражается
в производственной системе (например, Jira)
▪ Источники элементов бэклога
– Владелец продукта
– Команда
– Другие команды
– Трайб
▪ Элементы бэклога
– Эпики, Фичи, Истории (могут быть пользовательскими либо техническими)
– Техдолг
– Дефекты
Бэклог команды – это приоритизированный
владельцем продукта список элементов
Стрим1
Стрим2
Стрим …
Фича2
Эпик4
История 2
История 1
Высокий
приоритет
Низкий
приоритет
Фича1
История n
История 5
История 6
История 3
История 4
Эпик1
Эпик2
Эпик3

9. Бэклог состоит из следующих типов задач
Совет! Используйте такую цветовую индикацию в вашем бэклоге, чтобы наглядно отображать объем задач каждого типа
Помните, что в каждом спринте не менее 30% доступной трудомощности должно использоваться для работ по Architectural
Runway и техническому долгу
8
Задачи, обеспечивающие реализацию
клиентских задач
▪ Архитектура
▪ Инфраструктура
▪ Общие элементы
▪ Библиотеки
▪ Платформы
▪ Создание переиспользуемых
компонентов
Нужно приоритезировать так же,
как и видимые фичи
Нарастает по мере построения продукта
– отложенные ключевые решения или
плохо сделанная работа
▪ Рефакторинг
▪ Reengineering
▪ Автоматизация тестов
▪ Документирование
▪ ...
Появляются когда желтые элементы
игнорируются
Представляют непосредственную
ценность для конечного
пользователя
Дефекты, которые выявлены
и должны быть исправлены
Добавляются по мере разработки
продукта
PositivevalueNegativevalue
Visible Invisible
Дефекты Технический долг
Ценность
для клиента
(эпики, фичи,
истории)
Architectural
Runway
(эпики, фичи,
истории)

10. Владелец продукта создает бэклог и постоянно обновляет его, собирая
сведения из множественных источников
Высокий приоритет – тщательная
проработка на 4 спринта
Низкий приоритет – приблизительно
прорабатываемые позиции
Приоритизация
элементов бэклога
Исследования
пользователей
Клиент
Вводные от других
команд
Идеи
Маркетинг
Поставщики
Стримы трайбов
Стримы программ
Мониторинг продукта
…
Декомпозиция
и оценка
элементов бэклога
и передача ВП на
реприоритизацию
Советы
▪ Используйте 15 минут после ежедневного стэндапа либо
в конце дня для оценки поступивших элементов бэклога
▪ Используйте сессию по подготовке к планированию
спринта для декомпозиции и уточнения оценки
по приоритетным эпикам и фичам на следующие
два спринта
Команда
▪ Стримы
▪ Эпики
▪ Фичи
▪ Истории
▪ Дефекты
9
Координация, оценка
осуществимости
и корректировка
приоритетов

11. Истории с большей определенностью тщательнее проработаны
10
Множество эпиков и
историй, описывающих еще
не созданный функционал
ФичиБэклог команды
Фичи и эпики
являются
"большими"
историями!
Бэклог команды ЭпикиМенее тщательная проработка
Бэклог спринта ИсторииБолее тщательная проработка
Подмножество бэклога
продукта, предназначенное
для выполнения в рамках
спринта

12. 11

13. Краткое описание Agile-церемоний команды
Церемония Определение
12
▪ Встреча в первый день каждого спринта направленная на формирование цели и
бэклога начавшегося спринтаПланирование
Спринта
▪ Встреча участников команды, скрам мастера и владельца продукта
для планирования дня и выявления проблем
Стендап-митинг
▪ Встреча участников команды и любых других заинтересованных лиц для
демонстрации продукта команды, созданного за данный спринт
Демонстрация
▪ Ежедневный процесс поддержания бэклога в актуальном состоянии с регулярной
встречей владельца продукта и участников команды для подготовки к
планированию следующего Спринта
Актуализация
Бэклога Команды
▪ Встреча участников команды, владельца продукта и скрам мастера, а также Agile-
коуча для обсуждения совершенствования процессов работы команды и
выявления факторов, мешающих продуктивной работе
Ретроспектива
команды
К1
К2
К4
К3
К5
ПРОЦЕСС И ЦЕРЕМОНИИ AGILE4
1 раз в
спринт
Периодич-
ность
Ежедн.
1 раз в
спринт
1 раз в
спринт
1 раз в
спринт
3-4 ч.
Длитель-
ность
15-30
мин.
1 ч.
2-4 ч.
2 ч.

14. Планирование спринта
13
Цель: формирование бэклога спринта
Входная информация
 Состав стримов и дорожная карта трайба
 Бэклог команды
 Пользовательские истории/требования, планируемые на спринт
 Детальная архитектура сервиса
 Доска зависимостей
Активности
 Определение цели спринта
 Выбор пользовательских историй для реализации цели спринта с
учетом их оценки
 Калибровка бэклога за счет сравнения трудоемкости историй и
доступных ресурсов команды, например в случае отпусков или других
мероприятий
 Проверка наличия критериев приемки по всем историям
Результаты
 Цель спринта
 Бэклог спринта
K1
К1. Планирование спринта
▪ Встреча в первый день каждого спринта направленная на
формирование цели и бэклога начавшегося спринта
 Длительность: ̴ 2-4 ч.
 Периодичность: 1 раз в спринт
 Участники: Владелец Продукта, Скрам Мастер, команда

15. Ежедневный стендап
14
Цель: синхронизация работ, планирование на день и выявление
возникших проблем
Входная информация
 Состав стримов и дорожная карта трайба
 Бэклог спринта
 Доска зависимостей
Активности
 Анализ прогресса в достижении цели спринта
 Обсуждение результатов предыдущего дня, планов на текущий день
 Обсуждение возникших проблем и определение участников команды,
которые займутся их решением
 Определение вопросов, которые нужно поднять на Scrum of Scrums
 Каждый участник команды отражает на Доске Задач (аналоговой или
электронной) изменение статуса решаемых им задач
Результаты
 Планы на день
 Список проблем и планы их решения
K2
К2. Ежедневный стендап
▪ Встреча участников команды, скрам мастера и владельца продукта
для обсуждения результатов предыдущего дня, планов на день
и выявления проблем
 Длительность: 15 мин.
 Периодичность: Ежедневно
 Участники: Скрам мастер, Команда, Владелец продукта

16. Актуализация бэклога команды
15
Цель: подготовка к планированию следующего cпринта
Входная информация
 Состав стримов и дорожная карта трайба
 Бэклог команды
 Доска зависимостей
 Детальные архитектуры сервисов
Активности
В рамках процесса по поддержанию бэклога в актуальном состоянии
команды на ежедневной основе выполняют следующие активности:
 Обсуждение и описание новых элементов и добавление их в бэклог
команды
 Оценка трудоемкости и ценности элементов бэклога
 Принятие решений об удалении или разбиении элементов бэклога
Не позднее, чем за два дня до Планирования спринта команда
встречается для того, чтобы убедиться, что элементы потенциального
бэклога спринта проработаны, понятны команде и могут быть
запланированы в работу и, в случае, если это не так, сформировать план
по устранению препятствий.
Результаты
 Актуализированный и дополненный бэклог команды
 План следующего спринта
K3
К3. Актуализация бэклога команды
▪ Процесс поддержания бэклога в актуальном состоянии с регулярной
встречей владельца продукта и участников команды для
подготовки к планированию следующего Спринта
 Длительность: -
 Периодичность: Не реже, чем 1 раз в спринт
 Участники: Владелец Продукта, Скрам Мастер, команда

17. Демонстрация
16
Цель: Демонстрация работающего продукта, подтверждение достижения
цели спринта и получение командой обратной связи
Входная информация
 Бэклог спринта
 Результат спринта
Активности
 Демонстрация результата спринта (инкремента)
 Обсуждение прошедшего спринта
 Продолжительность составляет от двух до восьми часов
 Выработка предложений по совершенствованию результата спринта
Результаты
 Обратная связь для Команды
 Пополнение и пересмотр бэклога команды
 Релиз (не каждый спринт)
K4
К4. Демонстрация
▪ Встреча участников команды и других заинтересованных лиц для
демонстрации продукта команды, созданного за данный спринт
 Длительность: 2-4 ч.
 Периодичность: 1 раз в спринт
 Участники: Команда, Владелец продукта, Скрам мастер, Лидеры
тем программ, все заинтересованные лица (по желанию)

18. Ретроспектива
17
Цель: Совершенствование процессов работы команды, выявление
факторов, мешающих продуктивной работе, выработка и планирование мер
по их устранению
Входная информация
 Выявленные в ходе спринта проблемы и трудности в работе команды
 Обратная связь по результатам Демонстрации
Активности
 Анализ успешности спринта в отношении людей, отношений между
ними, процессов и инструментов
 Выявление позитивных и негативных факторов работы Команды
 Разработка плана по внедрению улучшений в процесс работы Команды
Результаты
 План улучшения работы Команды
K5
К5. Ретроспектива
▪ Встреча участников команды, владельца продукта и скрам
мастера, а также Agile-коуча для обсуждения совершенствования
процессов работы команды и выявления факторов, мешающих
продуктивной работе
 Длительность: 2 ч.
 Периодичность: 1 раз в спринт
 Участники: Владелец Продукта, Скрам Мастер, Agile-коуч (при
необходимости), команда

19. Фича2
Эпик4
История 2
История 1
Высокий
приоритет
Низкий
приоритет
Каждая новая история
проходит приоритизацию
и добавляется в бэклог
Любой элемент может
быть исключен
в любой момент
За каждый спринт
прорабатываются самые
приоритетные истории
Фича1
История n
История 5
История 6
История 3
История 4
Эпик1
Эпик2
Эпик3
Реализация и управление бэклогом; приоритизация
5
Владелец продукта приоритизирует бэклог, ориентируясь
на относительную ценность элементов
▪ Наиболее приоритетные элементы занимают верхние строчки
в бэклоге продукта
▪ Такие верхние элементы (в основном истории) являются
более детализированными и проработанными
▪ На нижних строчках бэклога продукта находятся
фичи и эпики
▪ Элементы включаются в спринт в порядке их приоритета
в бэклоге и реализуются в рамках производственного
процесса
Любой элемент может
быть реприоритизирован
в любой момент
4

20. Реализация и управление бэклогом: MVP
19
Минимально Жизнеспособный Продукт (MVP) – это продукт, который обладает исключительно минимальным набором свойств и
функций, которых достаточно для сбора обратной связи для последующих улучшений этого продукта.
Польза
Усилия
Risk
Разработка ведется не компонент
за компонентом…
... а целиком, от более простого
продукта к более сложному
Если пользователь хочет добраться от пункта
«А» в пункт «Б», какой способ разработки
принесет пользу быстрее?
Принципы разработки через MVP:
▪ Продукт создается итеративно  не старайтесь построить все и сразу!
▪ Продукт создается инкрементально  не пытайтесь создать идеальный и исчерпывающий продукт с самого начала!
▪ MVP позволяет снизить риски и учиться на ошибках за счет итеративной и инкрементальной разработки
▪ Agile – это «ранняя реализация пользы» – Allister Cockburn
ИСТОЧНИК: Allister Cockburn and Henrik Kniberg
Польза
Усилия
4

21. Мониторинг продукта
6
▪ Владелец продукта регулярно осуществляет мониторинг
– Метрик продукта
– Различных источников обратной связи (жалобы клиентов,
комментарии и предложения команды, результаты исследований)
▪ На основании мониторинга Владелец продукта корректирует бэклог
и может возвращаться на стадию исследования
5

22. Что собой представляет Хранилище Данных?
21
Хранилище данных – репозиторий данных, хранящий данные организации в
исторической перспективе с целью их использования для отчётности, принятия
стратегических и тактических решений, использования в оперативной
деятельности.
Хранилище данных – объединенная и совместная модель данных для сбора
всех данных организации.

23. Переход на Agile технологию разработки ЦХД
22

24. Внедрение Agile: Kanban vs Scrum
23
23
• На платформе ЦХД развиваются несколько продуктов
• У каждого продукта отдельная команда. Команда
выбирает эффективную методологию: Kanban, Scrum, …
• Есть интеграционный спринт платформы, включающий:
• Интеграцию кода продуктов
• Регрессионное тестирование платформы
• Проведение ПСИ и подготовку к внедрению
• Есть команды интеграции, сопровождения, архитектуры
Резюме:
• Agile позволил гибкое внедрение изменений
платформы ЦХД по приоритетам заказчика,
которые могут оперативно меняться.
• ЦХД с окружением обеспечивает возможно
работы независимых команд по Agile.
Пример Kanban доски

25. Жизненные циклы производства в АХД
24
Ядро
Область витрин +
отчеты
Часть влияющая
на смежные витрины
Часть не влияющая
на смежные витрины
Четырехнедельные смещенные друг относительно друга циклы
Внедрения раз в две недели. Требуется регресс и ПСИ.
Демонстрация
Продуктив
Ежедневные
релизы
2нед
Цикл платформы
регресс + ПСИ
Kanban
Scrum
Kanban’
Scrum
спринты 2
нед.
Kanban’
Scrum спринты
кратные 2 нед.
патч
пакет
патчей
патч
пакет
патче
й
патч
ПСИ
Kanban’
список
задач
на
вход
новые
задачи
пакет
патчей
пакет
патчей
Раз в неделю:
новый функционал
Раз в 2 недели:
SLA функционал
задачи
Сервисный подход
по обработке
поступающих
задач
Есть доступ к данным продуктивной среды и
возможность внесения изменений ежедневно
Все изменения только через
интеграционный спринт платформы