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

1. 1АЛЕКСЕЙ ИОНОВ
Agile в масштабе
корпорации
Как не создать хаос?
Алексей Ионов, 2017

2. 2АЛЕКСЕЙ ИОНОВ

3. 3АЛЕКСЕЙ ИОНОВ
Agile мышление
Знать
Вашу
Цель
Понимать
Контекст
Как можно
скорее
получать
обратную
связьИспользовать
итерации
Сотрудничать в
команде
(партнерство, не
кооперация)
Минимизировать
потери

4. 4АЛЕКСЕЙ ИОНОВ
Проблемы с внедрением корпоративного Agile
1. Бюджетирование (финансы)
«Хочу выделять деньги на понятную мне
покупку»
2. Архитектура/инфраструктура
«Нанять/уволить людей проще, чем
продумать гибкую систему»
3. Организационная структура
«Деление на начальников и исполнителей
«зашито» у нас в ДНК»

5. 5АЛЕКСЕЙ ИОНОВ

6. 6АЛЕКСЕЙ ИОНОВ
Самосвал против вентиля

7. 7АЛЕКСЕЙ ИОНОВ
Финансировать потоки создания ценности
Анали-
тика
Разра-
ботка
Тести-
рование
ОЭ
Дора-
ботка
Тести-
рование
...
Поток 1 (системы РКО)
Поток 2 (системы ДБО)
• Бюджетирование по проектам лишает
компанию гибкости
• Передача всей ответственности на
исполнителя порождает безответственность
заказчика

8. 8АЛЕКСЕЙ ИОНОВ
Решения принимаются на всех уровнях
Портфель
Программа
Команда
Крупные
инициативы
Группы Систем
Конкретный
функционал
Уровень Бэклог
Стратегические
темы
Видение
Ключевые даты

9. 9АЛЕКСЕЙ ИОНОВ
Регулярная демонстрация/приемка результата
Время
Итерации
Релизы
Сборки
систем
«На протяжении всего проекта
разработчики и представители бизнеса
должны ежедневно работать вместе.»

10. 10АЛЕКСЕЙ ИОНОВ
«Фича /
Тема»
«Фича /
Тема»
«Фича /
Тема»
Крупные инициативы (Эпики) требуют одобрения
Эпик = 3000sp
«Фича /
Тема» «Фича /
Тема»
«Фича /
Тема»
«Фича /
Тема»
«Фича /
Тема» «Фича /
Тема»
«Фича /
Тема»
«Фича /
Тема»
«Фича /
Тема»
• Все Эпики проходят
процедуру рассмотрения
• Мы в Agile, поэтому
используем Сторипоинты
на всех уровнях
• Для работы на уровне
Портфеля и Программ
обязательно используется
Канбан
Портфель
Программы
Воронка
Рассмот-
рение
Анализ Бэклог
Разра-
ботка
Готово!

11. 11АЛЕКСЕЙ ИОНОВ

12. 12АЛЕКСЕЙ ИОНОВ
Архитектура – результат работы многих команд
Команда
Команда
Команда
Фасили-
тированное
обсуждение
«История»
«История»
«История»
Архитектор
как сервис
Текущие
задачи
Средне-
срочная
Будущие
задачи
Архитектурные
намерения

13. 13АЛЕКСЕЙ ИОНОВ
Больше система – дальше горизонт
Текущие
задачи
Средне-
срочная
Будущие
задачи
Архитектурные намерения
Энейблер
Энейблер
Энейблер
Энейблер
Энейблер
Энейблер
Энейблер
Энейблер
Энейблер

14. 14АЛЕКСЕЙ ИОНОВ
Самая простая архитектура, которая будет
работать, есть лучшая
«Изменение требований
приветствуется, даже на поздних
стадиях разработки.»
Самое дешевое
решение
Самое
интегрированное
решение
Самое красивое
решение
Самое
«правильное»
решение
Самое простое
решение
Самое легко
изменяемое
решение

15. 15АЛЕКСЕЙ ИОНОВ
При любом сомнении: прототипируйте!
Спайк
Энейблер
Спайк
Энейблер
Спайк
Энейблер
Энейблер
Спайк
Энейблер
Инновации не бесплатны. Это процесс постоянного
инвестирование в проверку гипотез, в том числе и не
несостоятельных.
Обсуж-
дение
Обсуж-
дение
Обсуж-
дение

16. 16АЛЕКСЕЙ ИОНОВ
Они это сделали, им и тестировать
КомандыАрхитекторы Эксплуатация
Проверка тестируемости, Тестирование
архитектурных решений, Тестирование
результатов разработки
Категорически неправильно делегировать функцию
тестирования, это демотивирует всех участников процесса
разрабатывать качественное решение!
Разработка под обязательное тестирование (TDD)
• Ответственность
Архитекторов и
Команд – в каждом
решении
• Быстрее доставка
ценности
• Требует гибкости в
своей основе

17. 17АЛЕКСЕЙ ИОНОВ
Монополия на инновации играет против компании
Одна из важных задач архитекторов – способствовать
инновациям со стороны команд разработки.
Итерация 1 Итерация 2 Итерация 3
Стаби-
лизация
Хакатон
Только члены команд имеют наилучшее представление о
возможной оптимизации.
Первенство в бизнесе невозможно без инноваций со
стороны команд в рабочее время.

18. 18АЛЕКСЕЙ ИОНОВ
Работа с архитектурой – это поток работ
Воронка
Рассмот-
рение
Анализ Бэклог
Разра-
ботка
Готово!
Портфель
Программа
Команда
Эпик Энейблеры
Фича Энейблеры
Стори Энейблеры
Уровни Бэклог

19. 19АЛЕКСЕЙ ИОНОВ

20. 20АЛЕКСЕЙ ИОНОВ
Перекосы в управлении
Все решает
руководство
(финансы,
планирование,
управление)
Все решает
команда разработки
(требования,
планирование,
управление)
«Диктаторы»
«Бурлаки»
«Мечтатели»
«Виноватые»

21. 21АЛЕКСЕЙ ИОНОВ
Уровни каскадирования
«Эпик»
«Фича/Тема»
«История»
Портфель
Программа
Команда
Требования Уровень
Управление
Бэклогом
На каждом
уровне
решения
принимаются
максимально
независимо!
Крупные
инициативы
Группы Систем
Конкретный
функционал

22. 22АЛЕКСЕЙ ИОНОВ
Уровни требований
«Эпик»
Epic
«Фича/Тема»
Feature/
Theme
«История»
User Story
Является
отдельным
требованием
Группирует
требования
следующего
уровня
Бизнес-
ценность
(MVP)
MAX трудоемкость
на один
элемент/команда
(всегда
минимизировать!)

23. 23АЛЕКСЕЙ ИОНОВ
Организация команд при масштабировании
PO | SM | Architect
PO | SM | Architect PO | SM | Architect Shared
services
PO | SM | Team
PO | SM | Team
PO | SM | Team
PO | SM | Team
PO | SM | Team
PO | SM | Team
CI/CD QA
DevOps
UX
Портфель
Программы
Команды

24. 24АЛЕКСЕЙ ИОНОВ
Принятие решений – каждый на своем уровне
Крупные
инициативы
Группы
Систем
Конкретный
функционал
Это стоящая
идея?
Является ли
идея Эпиком?
Какова
бизнес-
ценность?
Какова
сложность?
Какие риски?
Как максими-
зировать
ценность,
уточняя
требования?
Как исполь-
зовать опыт
разработки в
будущем?
Это стоящая
Разработка?
Является ли
Фичей?
Из чего
состоит? Что
самое
важное?
Каковы зави-
симости? Как
распре-
делить?
Как максими-
зировать
ценность,
уточняя
требования?
Как исполь-
зовать опыт
разработки в
будущем?
Это стоящая
История?
Является ли
отдельной?
Как реализо-
вать? Что
уточнить?
Какова
сложность?
Каковы зави-
симости?
Как максими-
зировать
ценность,
уточняя
требования?
Как исполь-
зовать опыт
разработки в
будущем?

25. 25АЛЕКСЕЙ ИОНОВ

26. 26АЛЕКСЕЙ ИОНОВ
«Ноты» каскадирования Agile

27. 27АЛЕКСЕЙ ИОНОВ
«Эпик»
Epic
«Фича/Тема»
Feature/
Theme
«История»
User Story
«Ноты» каскадирования Agile

28. 28АЛЕКСЕЙ ИОНОВ
«Эпик»
Epic
«Фича/Тема»
Feature/
Theme
«История»
User Story
Управляющие
портфелем
Энтерпрайз
Архитектор(ы)
Владельцы
Эпиков
Владельцы
Бизнеса
Системные
Архитекторы
Управляющие
Продуктами
Мастера
Производства
Владельцы
Продуктов
Мастера
Команд
Разработчики
внутри команд
Agile Команды
разработки
«Ноты» каскадирования Agile

29. 29АЛЕКСЕЙ ИОНОВ
Ситуация остается под контролем!
Пропускная
способность
потоков
создания
ценности
Оценка в
Сторипоинтах
и управление
бэклогом на
всех уровнях
Портфель
Программа
Команда
Крупные
инициативы
Группы
Систем
Конкретный
функционал
«Фича /
Тема»
«Фича /
Тема»
«Фича /
Тема»
Эпик = 3000sp
«Фича /
Тема» «Фича /
Тема»
«Фича /
Тема»
«Фича /
Тема»
«Фича /
Тема»
Анализ и
одобрение
Крупных
инициатив
(«Эпиков»)
Воронка
Рассмот-
рение
Анализ Бэклог
Разра-
ботка
Готово!
Предварительная и
пост-оценка
Бизнесом каждой
цели команды
Цель 1
Цель 2
Цель 3
Цель +
3
9
1
5

30. 30АЛЕКСЕЙ ИОНОВ
Алексей Ионов
Alexey_Ionov@epam.com