Алексей Ионов. Agile в масштабе корпорации: как не создать хаос?

1АЛЕКСЕЙ ИОНОВ

Agile в масштабе корпорацииКак не создать хаос?

Алексей Ионов, 2017



Agile мышление

Знать Вашу Цель

Понимать Контекст

Как можно скорее

получать обратную

связьИспользовать итерации

Сотрудничать в команде

(партнерство, не кооперация)

Минимизировать потери


Проблемы с внедрением корпоративного Agile

1.Бюджетирование (финансы)«Хочу выделять деньги на понятную мне покупку»

2.Архитектура/инфраструктура«Нанять/уволить людей проще, чем продумать гибкую систему»

3.Организационная структура«Деление на начальников и исполнителей «зашито» у нас в ДНК»



Самосвал против вентиля


Финансировать потоки создания ценностиАнали-тика

Разра-ботка

Тести-рование

ОЭ

Дора-ботка

Тести-рование

...

Поток 1 (системы РКО)

Поток 2 (системы ДБО)

• Бюджетирование по проектам лишает компанию гибкости

• Передача всей ответственности на исполнителя порождает безответственность заказчика


Решения принимаются на всех уровнях

Портфель

Программа

Команда

Крупные инициативы

Группы Систем

Конкретный функционал

Уровень Бэклог

Стратегические темы

Видение

Ключевые даты


Регулярная демонстрация/приемка результата

Время

Итерации

Релизы

Сборки систем

«На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.»


«Фича / Тема»



Крупные инициативы (Эпики) требуют одобрения

Эпик = 3000sp

«Фича / Тема» «Фича /

Тема»




Тема»




• Все Эпики проходят процедуру рассмотрения

• Мы в Agile, поэтому используем Сторипоинтына всех уровнях

• Для работы на уровне Портфеля и Программ обязательно используется Канбан

Портфель

Программы

Воронка Рассмот-рение Анализ Бэклог Разра-

ботка Готово!



Архитектура – результат работы многих команд

КомандаКомандаКоманда

Фасили-тированное обсуждение

«История»«История»

«История»Архитектор как сервис

Текущие задачи

Средне-срочная

Будущие задачи

Архитектурные намерения


Больше система – дальше горизонт

Текущие задачи

Средне-срочная

Будущие задачи

Архитектурные намерения

Энейблер

Энейблер

Энейблер

Энейблер

Энейблер

Энейблер

Энейблер

Энейблер

Энейблер


Самая простая архитектура, которая будет работать, есть лучшая

«Изменение требований приветствуется, даже на поздних стадиях разработки.»

Самое дешевое решение

Самое интегрированное

решение

Самое красивое решение

Самое «правильное»

решение

Самое простое решение

Самое легко изменяемое решение


При любом сомнении: прототипируйте!

Спайк

Энейблер

Спайк

Энейблер

Спайк

Энейблер

Энейблер

Спайк

Энейблер

Инновации не бесплатны. Это процесс постоянного инвестирование в проверку гипотез, в том числе и не несостоятельных.

Обсуж-дение




Они это сделали, им и тестировать

КомандыАрхитекторы Эксплуатация

Проверка тестируемости, Тестирование архитектурных решений, Тестирование

результатов разработки

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

Разработка под обязательное тестирование (TDD)

• Ответственность Архитекторов и Команд – в каждом решении

• Быстрее доставка ценности

• Требует гибкости в своей основе


Монополия на инновации играет против компании

Одна из важных задач архитекторов – способствовать инновациям со стороны команд разработки.

Итерация 1 Итерация 2 Итерация 3 Стаби-лизация Хакатон

Только члены команд имеют наилучшее представление о возможной оптимизации.

Первенство в бизнесе невозможно без инноваций со стороны команд в рабочее время.


Работа с архитектурой – это поток работ

Воронка Рассмот-рение Анализ Бэклог Разра-

ботка Готово!

Портфель

Программа

Команда

Эпик Энейблеры

Фича Энейблеры

Стори Энейблеры

Уровни Бэклог



Перекосы в управлении

Все решает руководство (финансы,

планирование, управление)

Все решает команда разработки

(требования, планирование, управление)

«Диктаторы»

«Бурлаки»

«Мечтатели»

«Виноватые»


Уровни каскадирования

«Эпик»

«Фича/Тема»

«История»

Портфель

Программа

Команда

Требования Уровень Управление Бэклогом

На каждом уровне решения

принимаются максимально независимо!





Уровни требований

«Эпик»Epic

«Фича/Тема»Feature/Theme

«История»User Story

Является отдельным требованием

Группирует требования следующего

уровня

Бизнес-ценность

(MVP)

MAX трудоемкостьна один

элемент/команда (всегда

минимизировать!)


Организация команд при масштабировании

PO | SM | Architect

PO | SM | Architect PO | SM | Architect Shared services

PO | SM | TeamPO | SM | Team

PO | SM | Team

PO | SM | TeamPO | SM | Team

PO | SM | Team

CI/CD QA

DevOps

UX

Портфель

Программы

Команды


Принятие решений – каждый на своем уровне




Это стоящая идея?

Является ли идея Эпиком?

Какова бизнес-

ценность?

Какова сложность? Какие риски?

Как максими-зироватьценность, уточняя

требования?

Как исполь-зовать опыт разработки в будущем?

Это стоящая Разработка? Является ли

Фичей?

Из чего состоит? Что

самое важное?

Каковы зави-симости? Как

распре-делить?




Это стоящая История?

Является ли отдельной?

Как реализо-вать? Что уточнить?

Какова сложность? Каковы зави-симости?






«Ноты» каскадирования Agile


«Эпик»Epic





«Эпик»Epic



Управляющие портфелем

Энтерпрайз Архитектор(ы)

ВладельцыЭпиков

Владельцы Бизнеса

СистемныеАрхитекторы

Управляющие Продуктами

Мастера Производства

Владельцы Продуктов

МастераКоманд

Разработчики внутри команд

Agile Командыразработки



Ситуация остается под контролем!Пропускная способность потоков создания ценности

Оценка в Сторипоинтахи управление бэклогом на всех уровнях

Портфель

Программа

Команда







Эпик = 3000sp


Тема»




Анализ и одобрение Крупных инициатив («Эпиков»)

Воронка Рассмот-рение

Анализ Бэклог Разра-ботка

Готово!

Предварительная и пост-оценка Бизнесом каждой цели команды

Цель 1

Цель 2

Цель 3

Цель +

3

9

1

5


Алексей Ионов[email protected]

Business

Алексей Ионов. Agile в масштабе корпорации: как не создать хаос?