Семинар для скрам-мастеров. ВТБ

1.

СЕМИНАР ДЛЯ СКРАМ-МАСТЕРОВ
ФЕВРАЛЬ, 2021 Г.

2.

СОДЕРЖАНИЕ
!
Scrum
Ролевая модель НПП и роль Скрам-мастера
Принципы нового производственного процесса (ПроПро)
Фасилитация событий НПП
Метрики и отчеты
?
Где брать информацию?
С чего начать?
Полезные материалы
2

3.

Kahoot-викторина
1. Перейдите на сайт kahoot.it / отсканируйте QR-код;
2. Введите PIN (будет указан у нас на экране);
3. Придумайте и введите свой «Nickname»;
4. Максимально быстро (и правильно) отвечайте на
вопросы!
Длительность:
Ссылка на викторину: https://bit.ly/3jmL4bN
15 минут
3

4.

Что такое Скрам?
Scrum
Фреймворк, предназначенный для разработки, поставки и поддержки сложных продуктов.
Он основан на теории эмпирического управления (эмпиризме). Источник знаний в эмпирическом управлении
– опыт, а источник решений – реальные данные.
Scrum использует итеративный и инкрементальный подход, чтобы улучшать прогнозируемость и управлять
рисками. Процесс эмпирического управления основан на «трех китах»: прозрачности, инспекции и
адаптации.
5
Ц
Е
Н
Н
О
С
Т
Е
Й
С
К
Р
А
М
Смелость​ / Courage
Делать правильные и сложные вещи. Меняться, даже если это потребует признания своих ошибок. Избегать
выпуска неготового и бесполезного продукта. Принимать реальность и неопределенность, выгоды и риски.
Фокус / Focus
Фокусироваться на Целях Спринта, на целях команды и на работе в Спринте. Ежедневный и постоянный фокус на
том, что наиболее важно в данный момент для получения результата.
Преданность / Commitment
Преданность и обязательства каждого участника относительно команды и Цели Спринта. Обязательство
сотрудничать, делать все, что в его силах на пути к цели, обязательство делать качественный и ценный продукт,
обучаться и искать улучшения.
Уважение / Respect
Уважать людей, их умения, разнообразие их опыта, идеи и мнения. Делиться опытом и экспертизой. Решать
проблемы пользователей, не создавать для них ненужных функций и не тратить на это лишний бюджет компании.
Открытость / Openness
Быть прозрачными в своей работе, проблемах и вызовах, связанных с ней. Быть открытым к взаимодействию и
сотрудничеству. Быть открытым к изменениям. Давать честную обратную связь.
4

5.

Для повышения эффективности производственного процесса
члены команд имеют свои командные роли
Описание командных ролей
Принципы формирования кросс-функциональной команды
1
2
3
Команда
имеет
end-to-end
ответственность
для реализации решения связанного с обслуживанием
Клиента (в т. ч. соответствие требованиям ИТ качества)
Автономная и самоорганизуемая – в зависимости
от
типа
команды
выбирается
подходящий
операционный ритм (Scrum, Kanban и др.)
4
Кросс-функциональная – различные компетенции
работают вместе в команде
5
9+-3 человека в одной кросс-функциональной команде,
все люди выделены на 100%
6
7
8
9
1
Формируется для создания и развития продукта
команды
Команда
1
Лидер команды – отвечает за поставку
ценности продукта команды и вовлечение всех
заинтересованных лиц; принимает ключевые
бизнес решения; приоритизирует бэклог для
достижения максимального бизнес-эффекта и
определяет
минимально
жизнеспособный
продукт; осуществляет приемку результатов
3
Скрам-мастер
команды
обеспечивает
применения Agile практик и производственного
процесса внутри команды. Роль выполняет один
из участников команды
4
Участник команды - сотрудники, выделенные
на 100% на постоянной основе, занимающиеся
реализацией бэклога продукта
Лидер
команды
3
Участник
Команды/Скраммастер
4
Участник
Команды
4
Участник
Команды
*В случае удаленной работы имеют общие средства для эффективной коммуникации
необходимые
2
2
Участники Команды работают вместе в одной локации*
Команда создает и поддерживает
артефакты по решению
ИТ
лидер
Команды1
–
отвечает
за
технологическую поставку продукта команды;
принимает ключевые технологические решения;
координирует работы, связанные с созданием,
изменением и сопровождение информационных
систем; участвует в решении бизнес-задач и
приоритизации бэклога
ИТ Лидер
команды
Долгосрочная – на срок не менее 1 года
Структура Команды может быть изменена в случае
корректировки целей команды
1
4
Участник
Команды
В случае принятия решений 1 ключом ИТ-Лидер команды наделяется полномочиями и ответственностью Лидера команды
5

6.

Ролевая модель Стрима. Скрам-мастер команды
SM
Общее описание
Скрам-мастер команды отвечает за эффективность рабочего процесса, его постоянное совершенствование, использование командой практик гибкой
разработки и выстраивание эффективных взаимодействий с другими командами
Основные задачи и обязанности
Внедрение
Agile-практик
Создание
высокоэффективной
команды
Обеспечение
непрерывного
совершенствования
▪
▪
▪
▪
Обучение членов команды Agile-принципам
Запуск команды, настройка процессов, обеспечивающих достижение целевых результатов
Работа над непрерывным развитием и совершенствованием методов работы и их внедрение в повседневную деятельность
команды
Разработка процедур обмена знаниями и экспертным опытом в пределах команды
▪
▪
▪
▪
▪
▪
Синхронизация различных видов деятельности команды, управление рисками и взаимоотношениями между командами
Фасилитация всех церемоний команды
Поддержка координации и синхронизации между командами (при необходимости)
Объективная оценка возникающих проблем, поиск и устранение ошибок руководствуясь Agile-принципами
Отслеживание прогресса и достижения целей команды в рамках ежедневных стендапов с применением диаграмм сгорания
Организация и поддержка ретроспектив команды
▪
Развитие самоорганизации, командного духа в команде, непрерывное совершенствование, стимулирование принятия
правильных, а не легких решений
Выявление проблем и примеров успешной работы команды
Информирование членов команды о возможных направлениях совершенствования, общение с членами команды
в формате "один на один"
Коучинг Лидера команды и членов команды
Устранение препятствий, стоящих перед командой (например зависимостей от других команд), ведение списка препятствий
▪
▪
▪
▪
Артефакты в сфере
ответственности
▪
▪
Поддержка анализа
бэклога командой
с лидером команды
Ретроспективы команды
Недопустимые действия
▪
▪
▪
Распределение задач между сотрудниками
Начальственный тон общения при работе с командой, принятие
безапелляционных решений о методах работы
Создание иерархии внутри команды
▪
▪
Категоричные оценки в адрес членов команды
по собственному усмотрению
Отвлечение от главного приоритета: обеспечения
успеха команды
6

7.

Какую поддержку можно ожидать от Скрам-мастеров команды
Организационные
процессы
Технические и
продуктовые
процессы
Социальные
процессы
Учат команды самостоятельно организовывать свою работу
Помогают повышать уровень освоения новой модели в команде
Ориентируют
команды
по совершенствованию
Предвосхищают
урегулирования
Ограждают команды от шума и отвлекающих факторов
Помогают выявлять и устранять организационные и психологические
барьеры
Четко
формулируют
ожидания
Помогают членам команды понять свою роль
Обучают лидера команды с учетом особенностей роли
Способствуют
обмену опытом
Обеспечивают обмен знаниями внутри команды и между командами
Формируют внутреннее сообщество для распространения гибких методов
Помогают проводить совещания (особенно Ретроспектива) на уровне
команд
Помогают
разработки
Помогают освоить инструменты, такие как Jira, Confluence и пр.
Помогают
развивать agileмышление
Устраняют
препятствия в
работе команд
Техническая
поддержка
процессов
и инструментов
на
возникновение
определить
и
принятие
конфликтов
запланированных
и
подготовить
используют
мер
стратегии
артефакты
для
7

8.

Скрам-мастер. МИФ & ПРАВДА
Оцените правдоподобность высказываний ниже и аргументируйте свое мнение, опираясь на принципы Agile.
15
минут
1. Скрам-мастер начинает делать работу за команду, чтобы
9. Скрам-мастер принимает решения на Ретроспективе за
помочь успеть в срок. В конце концов они же сами его просят, а
команду поднимает на обсуждение во время встречи темы,
он это делать умеет.
которые кажутся важными только ему или отдает все внимание
кому-то одному.
2. Скрам-мастер администрирует карточки на доске команды, а
также "пушит" разработчиков, когда они забывают обновить
10.Скрам-мастер формирует привычки самостоятельного
статусы.
управления информационными инструментами.
3. Скрам-мастер помогает команде в формировании ценностей, 11.Скрам-мастер коучит команды на измерение метрик спринта
правил и целей сотрудничества.
и оценку трендов.
4. Скрам-мастер всегда соглашается с позицией менеджмента 12.Скрам-мастер сам выявляет и приглашает на обзор всех
среднего звена, например, даже когда они считают себя
стейкхолдеров. На самом обзоре Скрам-мастер лично активно
единственными ответственными за изменения организации, и
собирает и записывает отзывы.
отводят Скрам-мастеру функцию секретаря-администратора.
13.Скрам-мастер коучит команды на управление зависимостями,
5. Скрам-мастер фасилитирует Скрам-события при
рисками, решение конфликтов и препятствий.
необходимости.
14.Скрам-мастер убеждается, что Ретроспектива проходит
6. Скрам-мастер всегда сам создает встречи и бронирует
позитивно и продуктивно, обучает всех участников
переговорки так как это одна из главных его обязанностей.
укладываться в отведенное время. Он принимает участие в
Ретроспективе наравне с другими членами команды, но
7. Скрам-мастер единственный интересуется диаграммой
продолжает нести ответственность за Скрам-процесс.
сгорания задач, постоянно анализирует метрики, строит отчеты
и иногда рассказывает об этом команде.
15.Скрам-мастер сам лично устраняет любые "блокеры"
внешние и внутренние, даже те, которые команда может решить
8. Скрам-мастер учит соблюдать баланс между целями Команды
самостоятельно. Становится героем и спасителем команды от
разработки (высокое качество) и ВП (больше фич).
всех сложностей.
8

9.

Результативность работы Скрам-мастера
Неудача
• Неуд. качество работы / Недостаточная
ценность работы.
• Нежелание участников команды развиваться.
• Непоследовательные результаты работы.
• Механический Скрам.
• Зависимость команды от Скрам-мастера.
Успех
• Высокое качество и результативность работы,
есть ценность работы.
• Непрерывное обучение и саморазвитие.
• Понимание фреймворка, ценностей и теории
Скрама и ПроПро.
• Автономность команды от Скрам-мастера.
9

10.

Scrum Values Game (1/4)
Ответы
10

11.

Scrum Values Game (2/4)
Ответы
11

12.

Scrum Values Game (3/4)
Ответы
12

13.

Scrum Values Game (4/4)
Ответы
13

14.

ПЕРЕРЫВ

15.

Цель и принципы внедрения производственного процесса (ПроПро)
Максимальная автоматизация
Артефакты ведутся в единой информационной системе.
Использование современных инженерных практик
Измеряемость
Постоянный автоматизированный контроль
количественных и качественных метрик
Универсальность
Универсальный процесс для любого типа
изменений
Фокус на создание ценности
Быстрая поставка ценности клиентам в соответствии с
приоритетами бизнеса
Совместная работа
Работа в кросс-функциональных командах,
обладающих компетенциями и
полномочиями для принятия решений
ЦЕЛЬ ВНЕДРЕНИЯ
ПРОИЗВОДСТВЕННОГО
ПРОЦЕССА В ПРОГРАММЕ
МПД
Обеспечение
максимальной
прозрачности процесса
разработки и внедрения на
всех уровнях управления
Архитектурное совершенство
Ответственность команд за целостные архитектурные решения
и устранение технического долга
Инкрементальность
Прирост ценности для клиента/заказчика
каждый спринт исходя из концепции MVP
Разумный набор артефактов
Минимальное количество артефактов, необходимых для
создания качественного программного продукта
15

16.

Этапы и контрольные точки производственного процесса
История «сгорает»
в этой точке
История считается
реализованной
Задачи «сгорают»
в зависимости от
контекста – тут
или позднее
Работа в спринтах
16

17.

DOR И DOD’Ы НА КОНТРОЛЬНЫХ ТОЧКАХ
DoR
Этап 1. Инициация и бизнес-анализ
Этап 2. Техническое проектирование
DoD1
Готовность
к ИФТ
Готовность к
ПСИ
Этап 3. Разработка
DoD2
Готовность к
эксплуатации
Этапы 4-6. ИФТ, ПСИ и установка
в Промышленную среду
* Готовность к ИФТ - проведено внутреннее
тестирование, определяет «сгорание» задачи
на burndown графике в Jira
17

18.

ПРОЦЕСС ПРОИЗВОДСТВА ПО В ХОДЕ РЕШЕНИЯ БИЗНЕС И
ТЕХНОЛОГИЧЕСКИХ ЗАДАЧ РЕАЛИЗУЕТСЯ ЧЕРЕЗ ПРОИЗВОДСТВЕННЫЕ
ЦИКЛЫ: СПРИНТЫ И СУПЕРСПРИНТЫ
Банк
Квартальный обзор бизнес результатов (КОБР) | Quarterly Business Review (QBR)
Стрим
Планирование суперспринта
Актуализация бэклогов команд будущего суперспринта (предварительная подготовка)
Синхронизация стримов
(раз в две недели)
Синхронизация команд
(раз в неделю)
Демонстрация стрима
(в конце суперспринта)
Scrum of Scrums
(не чаще 1 раза в Спринт)
Ретроспектива стрима
(в конце суперспринта)
Суперспринт (12 недель)
Команда
Спринт 1
(2 недели)
Спринт 2
(2 недели)
Спринт 3
(2 недели)
Спринт 4
(2 недели)
Спринт 5
(2 недели)
Спринт 6
(2 недели)
Спринт (2 недели)
Ср.
Чт.
Пт.
Пн.
Вт.
Ср.
Чт.
Пт.
Пн.
Ежедневный стендап
Актуализация бэклога команды будущих спринтов
Планирование спринта
Демонстрация
Ретроспектива
Вт.
СПРИНТ – временной период создания
готовой к использованию
функциональности, повышающей
ценность одного или нескольких
Технологических продуктов для клиента
и/или Банка в целом Технологического
продукта, и горизонт планирования
Команды разработки (2 недели)
СУПЕРCПРИНТ – период планирования
Стрима в 12 недель. Суперспринты
разделяются на 6 Спринтов каждый.
В рамках спринтов и
суперспринтов проходят мероприятия,
обеспечивающие принципы
прозрачности, инспекции и адаптации
для производственного процесса
Команды следуют регулярному
операционному ритму, чтобы
стимулировать эффективную
межкомандную коммуникацию
18

19.

СИНХРОНИЗАЦИЯ КОМАНД (ссылка)
Цель
Входная
информация
Активности
i
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
Синхронизация и актуализация бэклогов команд на суперспринт
Обсуждение возникших проблем на достижении цели суперспринта
Разрешение зависимостей с другими командами
Дорожная карта развития продуктов команд
Бэклоги команды
Заявленные потребности для обсуждении с командами других стримов
Доска зависимостей стрима
Представление и обсуждение планов по продуктам команд
Синхронизация приоритетов в бэклогах команд и сроков разработки зависимых задач
Разбор зависимостей между стримами, выработка мер по устранению негативных зависимостей
Разбор зависимостей между продуктами команд, выработка мер по устранению негативных
зависимостей
Определение архитектурной составляющей дорожной карты
Результаты
▪ Синхронизированные бэклоги стримов
▪ Пополнение и пересмотр бэклога команд
Участники
Лидеры команд, ИТ Лидеры команд одного
стрима
Лидеры связанных стримов, в случае
значимого влияния бэклогов стримов
Коуч команды и Scrum Мастера
▪ Общие решения по устранению негативных
зависимостей
Члены команд (по необходимости)
Лидер стрима
Заинтересованные стороны при наличии общих
приоритетных задач
Частота: 1 раз в неделю, Длительность: 60-120 мин.
19

20.

Планирование спринта
Цель
▪
▪
Формирование бэклога спринта
Выбор пользовательских историй для спринта
Входная
информация
▪
▪
▪
▪
▪
Состав стримов и дорожная карта команды
Бэклог команды, DoD, скорость команды
Пользовательские истории/требования, планируемые на спринт
Детальная архитектура решения
Доска зависимостей, решения с ретроспективы
▪
▪
▪
▪
Определение цели спринта
Выбор пользовательских историй для реализации цели спринта с учетом их оценки
Калибровка бэклога за счет сравнения трудоемкости историй и доступных ресурсов команды,
например, в случае отпусков или других мероприятий
Проверка наличия критериев приемки по всем историям
Результаты
▪
▪
Цель спринта
Бэклог спринта
Участники
Лидер команды (ведущий) и ИТ Лидер команды
Члены команды
Скрам-мастер команды
Активности
i
Частота: 1 раз за спринт, Длительность: 30-60 мин.
20

21.

Актуализация бэклога команды будущих спринтов
Цель
Входная
информация
Активности
i
▪
Подготовка к планированию следующего cпринта
▪
▪
▪
▪
▪
Состав стримов и дорожная карта команды
Бэклог команды
Доска зависимостей
Детальная архитектура решения
▪
В рамках процесса по поддержанию бэклога в актуальном состоянии команды на ежедневной
основе выполняют следующие активности
– Обсуждение и описание новых элементов и добавление их в бэклог команды
– Оценка трудоемкости и ценности элементов бэклога
– Принятие решений об удалении или разбиении элементов бэклога
Не позднее, чем за два дня до Планирования спринта команда встречается
для того, чтобы убедиться, что элементы потенциального бэклога спринта проработаны, понятны
команде и могут быть запланированы в работу и, в случае, если это не так, сформировать план
по устранению препятствий
Результаты
▪
▪
Участники
Лидер команды (ведущий) и ИТ Лидер команды
Члены команды и прочие Стейкхолдеры по мере надобности
Скрам-мастер команды (опционально)
Актуализированный и дополненный бэклог команды
План следующего спринта
Частота: по необходимости, Длительность: 1-2 часа
21

22.

Планирование Спринта и Актуализация бэклога: советы для
фасилитаторов
На что обратить внимание при планировании Спринта и актуализации бэклога:
1. Привлечение Лидера Команды (Владельца Продукта): присутствует на встрече, является источником
приоритетов.
2. Цель спринта поставлена. В качестве вспомогательных вопросов:
• Какую ценность можно добавить продукту за следующий спринт?
• Как организовать работу, необходимую для создания ценности?
• Какой функционал мы сможем продемонстрировать на демо в конце спринта?
3. При планировании учтены следующие факторы:
• Приоритеты от Лидера и IT-Лидера команды
• Результаты предыдущего спринта, обратная связь от заказчиков и стейкхолдеров
• Ограничения, наложенные бизнесом, или особые требования
• Ёмкость команды на следующий спринт
• Зависимости от других направлений
4. Корректность нарезки бэклога в соответствии с правилами на проекте (декомпозиция, соответствие
квотам, отклонение от емкости не более, чем на 20%, типы задач, берущихся в спринт)
5. Понимание команды как работать в JIRA (статусная модель, добор задач в спринт, списание времени)
6. Соблюдение критериев готовности, команда понимает критерии готовности и не берет в спринт
задачи, которые им не соответствуют
7. Action Points с ретроспективы добавлены в спринт, команда понимает ценность этих действий
8. По итогам планирования спринта сформирован бэклог на спринт/актуализирован бэклог
9. Убедиться, что команда понимает, что после старта спринта задачи НЕ переоцениваются, НЕ
исключатся (только при замене на аналогичную по размеру), новые задачи НЕ добавляются (только в
рамках контейнеров).
10. Временные рамки события должны быть соблюдены
22

23.

Ежедневный стендап
Цель
Входная
информация
Активности
i
▪
▪
▪
▪
▪
▪
▪
▪
▪
▪
Синхронизация работ, планирование на день
Выявление возникших проблем и степень влияния на спринт
Состав стримов и дорожная карта команды
Бэклог спринта
Доска зависимостей
Анализ прогресса в достижении цели спринта
Обсуждение результатов предыдущего дня, планов на текущий день
Обсуждение возникших проблем и определение участников команды,
которые займутся их решением
Определение вопросов, которые нужно поднять на Синхронизации команд
Каждый участник команды отражает на Доске Задач (аналоговой или электронной)
изменение статуса решаемых им задач
Результаты
▪
▪
▪
Участники
Все члены команды
Лидер команды и ИТ Лидер команды (опционально)
Скрам-мастер команды
Планы на день
Синхронизация
Список проблем и планы их решения
Частота: каждый день, Длительность: 15 мин.
23

24.

Ежедневный стендап (рекомендуемый формат проведения)
Цель встречи – синхронизация усилий команды для приближения к Цели спринта, планирование задач на день,
выравнивание личных планов, а также напоминание о взятых на себя обязательствах.
Три главных вопроса к каждому участнику:
• Что ты делал вчера (чтобы приблизиться к Цели спринта)?
• Что ты будешь делать сегодня (чтобы приблизиться к Цели спринта)?
• Какие проблемы есть у тебя или у команды на пути (к Цели спринта)?
Задача Скрам-мастера - НАУЧИТЬ команду:
1.
2.
3.
4.
Придерживаться регулярности и тайминга (одно и то же время и место, 15 минут);
Придерживаться цели встречи и выбранного формата (например, 3 вопроса):
Вовлекаться в процесс (приближение к Цели спринта, игровая форма проведения встречи)
Визуализировать процесс (Доска в Jira, Парковка вопросов, Правила Daily, Стендап-боты)
24

25.

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

26.

Демонстрация (возможный формат события)
№
План проведения
Детали
Тайминг (мин)
1
Цель спринта и описание продукта
Указать цель спринта и описать продукт команды
5
2
Запланированный объем
Задачи, критические баги, запланированные в спринт
5
3
Демонстрация и сбор обратной связи
Демонстрация разработанной функциональности
20
4
Что не успели и причины
Указать проблемы, обозначить открытые вопросы
5
5
Демонстрация и обсуждение BurnDown chart’a
Обсуждение результатов спринта
5
6
Обсуждение будущих задач с заинтересованными лицами
Актуализация бэклога, фиксирование/уточнение
требований
10
7
Цель следующего спринта и верхнеуровневый план работ
Обозначение цели следующего спринта, синхронизация с
заказчиком
5
Правильно
Обеспечить участие ключевых заинтересованных сторон
Обеспечить обновление ключевых показателей работы
команды
Подготовить лидера команды к ответу на вопросы о
рентабельности инвестиций
Неправильно
Проводить большинство демонстраций вместо команды.
Вместо этого дайте Лидеру команды и команде
возможность установить отношения
с заинтересованными сторонами
Не готовить развернутый план презентации
Начинать с вопроса "зачем",
чтобы напомнить присутствующим
о бизнес-предложении
Фиксировать обратную связь и совместно с лидером
команды вносить в бэклог запросы на включение новых
характеристик
Обсуждать следующую группу характеристик в бэклоге
ценности или цели следующего спринта
26

27.

Ретроспектива
▪
Совершенствование процессов работы команды, выявление факторов, мешающих
продуктивной работе, выработка и планирование мер по их устранению
▪
▪
▪
Выявленные в ходе спринта проблемы и трудности в работе команды
Обратная связь по результатам Демонстрации
DoD
▪
▪
▪
Анализ успешности спринта в отношении людей, отношений между ними, процессов
и инструментов
Выявление позитивных и негативных факторов работы Команды
Разработка плана по внедрению улучшений в процесс работы Команды
Результаты
▪
▪
План улучшения работы Команды
Обновленные критерии готовности (DoD) (при необходимости)
Участники
Лидер команды и ИТ Лидер команды
Члены команды
Скрам-мастер команды (ведущий)
Цель
Входная
информация
Активности
i
Частота: 1 раз за спринт, Длительность: 1-2часа
27

28.

Ретроспектива (этапы и их цели)
10%
20%
Открытие
Вовлечение команды в
обсуждение
Первичный анализ
ситуации в команде
Анализ результатов
предыдущего ретро
30%
30%
Сбор Данных
Сбор данных, фактов и
эмоций для
дальнейшего более
детального обсуждения
10%
Идеи
План
Закрытие
• Поиск закономерностей,
анализ причин и
следствий
• Генерация идей для
улучшения работы
команды
• Выбор решений
• Разработка плана
действий со сроками и
инициативными
ответственными
• Подведение итогов и
фиксация
договоренностей
1. Обсудить и принять
решение
2. Голосовать точками
3. Голосовать руками
4. Screening matrix
5. Фильтр Манна
6. Рисуем матрицу с
осями Быстро-Долго,
Дёшево-Дорого или
Сильный эффектСлабый эффект.
7. Молчаливое
ранжирование
1. Проговорить план
действий
2. Спасибо
3. Helped, hindered,
hypothesis, чтобы
доработать ретро
4. ROI
5. Одно слово
6. Эмоция
Примеры Техник
1. ИПОЗ Сбор ожиданий
от ретроспективы
(анонимно или
открыто), обсуждение
полученных данных
• Исследователь
• Покупатель
• Отпускник
• Заключенный
2. Прогноз погоды
3. Ожидания от встречи
4. Safety Check
5. Интересы
10%
1. Позитивное и
возможности для
роста
2. Хорошо, Плохо,
Грустно
3. Плохо, Новое,
Хорошее, Доделать
4. Временная Шкала
Спринта с отметками
событий
1.
2.
3.
4.
5.
Брейнсторминг
Синтез
5 почему
Метод Уолта Диснея
Матрица идей
Доля времени, затрачиваемого на этап в рамках мероприятия
28

29.

Ретроспектива (Пример Открытия № 1,2,3)
Открытие (Прогноз погоды)
Цель
Настроить людей на работу в ходе Ретроспективы. Проанализировать их эмоциональный настрой.
Описание
Подготовьте флипчарт с изображением шторма, дождя, облаков и солнца. Предложите каждому участнику отметить своё
настроение на листе
Открытие (Ожидания)
Цель
Настроить людей на работу в ходе Ретроспективы. Понять их ожидания от встречи.
Описание
Подготовьте флипчарт с изображением. Предложите каждому участнику записать на стикерах и высказать свои ожидания от
встречи
Открытие (Интересы) – для новых команд
Цель
Настроить людей на работу в ходе Ретроспективы. Выявить взаимные интересы.
Описание
Предложите команде встать в круг на расстоянии 30 см друг от друга. Если кто-то из людей работает удаленно, это расстояние
может составлять 1,5 м. Предложите клубок веревки и мяч любому игроку. Он должен взять конец веревки и сделать утверждение
про себя, которое не связано с работой. Если это утверждение верно для других членов команды, они поднимают руку и говорит
“Да, это я”. Участник передает клубок человеку, который поднял руку. Если таких людей больше одного, он выбирает одного из них.
Если никто не откликается, владелец мяча делает другое утверждение и т д.
29

30.

Ретроспектива (Пример Открытия № 4 – для команды, знакомой с
форматом встречи)
Открытие (ИПОЗ)
Цель
Настроить людей на работу в ходе Ретроспективы. Понять их отношение к Ретроспективе.
Описание
Каждый участник описывает (анонимно) свое отношение к предстоящей ретроспективе как Исследователь, Покупатель, Отпускник
или Заключенный (ИПОЗ). Фасилитатор ретроспективы собирает результаты и создает гистограмму, чтобы показать данные
наглядно, а затем направляет обсуждение к тому, что значит полученный результат для группы.
Шаги
1. Объясните, что вы проводите опрос для того, чтобы узнать, как люди видят свое участие в этой ретроспективе.
2. Покажите флипчарт и определите условия:
И — Исследователи стремятся открыть для себя новые идеи и знания. Они хотят узнать все, что можно, об
итерации/релизе/проекте.
П — Покупатели рассматривают всю доступную информацию и будут счастливы отправиться домой с одной новой полезной
идеей.
О — Отпускники не заинтересованы работать в ходе ретроспективы, но рады отвлечься от ежедневной рутинной работы.
Впрочем, на какое-то время они тоже могут почувствовать интерес к групповому взаимодействию.
З — Заключенные чувствуют, что их заставили здесь находиться, и предпочли бы заняться чем-то другим.
3. Раздайте участникам небольшие листочки бумаги или маленькие карточки для записей, чтобы они описали свое отношение к
сегодняшней ретроспективе. Попросите их для соблюдения конфиденциальности сложить листочки пополам.
4. После того как участники закончили писать и сложили карточки, соберите их и перемешайте.
5. Попросите одного из членов команды фиксировать в виде гистограммы данные, пока вы зачитываете написанное на карточках.
6. Спросите у группы: «Что вы скажете об этих данных?» Затем проведите небольшую дискуссию о том, как отношение аудитории
будет влиять на ретроспективу. Обсудите вопрос: «Как эти категории связаны с нашим отношением к повседневной работе?»
30

31.

Ретроспектива (Примеры Сбора Данных)
Цель
Сбор данных, фактов и эмоций для дальнейшего более детального обсуждения
Сбор данных (Позитивное и возможности для роста)
Описание
Каждый участник пишет на стикерах:
1) Позитивный опыт прошлого спринта
2) Идеи для улучшения работы
Каждый участник рассказывает про то, что было написано на стикерах
Идеи участников разбиваются на кластеры
Сбор данных (Хорошо, Плохо, Грустно)
Описание
Каждый участник пишет на стикерах:
1) То, что было хорошо, радовало
2) То, что было плохо, раздражало
3) То, что демотивировало или расстраивало
Каждый участник рассказывает про то, что было написано на его стикерах
Сбор данных (Плохо, Новое, Хорошее, Доделать)
Описание
Каждый участник пишет на стикерах:
1) То, что было плохо, что надо убрать
2) То, что было хорошо, то что надо закрепить
3) Идеи, новое, то, что внедрить
4) То, что нужно доделать/доработать
31

32.

Ретроспектива (Примеры Генерации идей)
Цель
Создание базы идей для улучшения работы команды
Генерация идей (5 почему)
Описание
Эта техника позволяет провести глубинный анализ причин проблемы. Необходимо выбрать одну проблему. Далее задать
вопрос: «Почему это происходит?». Запишите ответ и снова задайте вопрос «Почему?». Продолжайте до тех пор пока
команда не найдет корневую причину. Считается, что пяти итераций обычно бывает достаточно. Важно следить, чтобы
проблему не объясняли тем, что кто-то плохо выполняет свои функции.
Генерация идей (Синтез)
Описание
Эта техника подходит для больших групп. Все участники разбиваются на группы (опционально на пары). В группах участники
обсуждают решение проблемы. Далее каждая группа по очереди в течении 2-3 минут презентует свои идеи. Наиболее
перспективные идеи выбираются для работы с ними в следующем спринте.
Сбор данных (Таблица идей)
Описание
Эта техника позволяет посмотреть на несколько проблем, провести анализ и придумать идеи для решения. После того, как
были выбраны 2-4 ключевые проблемы, разместите их в строчках. Нарисуйте на флипчарте 4 колонки: «Хорошо», «Что
делать иначе», «Свежие Идеи», «Благодарности». Далее каждый участник пишет на стикере идеи и презентует их всем,
размещая на флипчарте (нашей матрице идей) в нужной строке и колонке.
32

33.

Ретроспектива (Примеры Генерации идей)
Цель
Создание базы идей для улучшения работы команды
Генерация идей (Brainstorm)
Описание
Эта техника позволяет сгенерировать наибольшее число идей. Основные принципы:
• Главное количество, а не качество
• Не критикуем и не обсуждаем
• Все идеи записываем
Варианты процесса:
• Каждый говорит с места
• Каждый по кругу говорит одну идею
• Каждый сначала пишет 5 минут в тишине, а потом презентует свои идеи
Генерация идей (Метод Уолта Диснея)
Описание
Сформируйте 3 команды:
• Мечтатели – отвечающие за генерацию идей, не оглядываясь на трудности
• Критики – отвечающие за критику идей, ищущие потенциально слабые места у идей
• Реалисты – отвечающие за примирение критиков и мечтателей, ищут золотую середину
Идеи, придуманные мечтателями, отправляются на разбор к критикам, а потом на реабилитацию к реалистам, и наконец
обратно к мечтателям, где снова начнут свое путешествие, пока наконец вы не поймете, что нашли то, что нужно (обычно
поиск прорывного, но при этом практичного решения занимает три-четыре круга).
33

34.

Ретроспектива (Примеры Разработки Плана)
Цель
Выбор наиболее ценных идей для улучшения работы в следующем в Спринте, разработка плана по их внедрению
Выбор идей (Голосовать руками)
Описание
Каждый участник одновременно со всеми остальными показывает один из знаков:
• Большой палец вверх – поддерживаю реализацию решения
• Большой палец в строну – готов делать все что от меня требуется, но не факт, что идея/план мне нравится
• Большой палец вниз – активно против
Считаем, что консенсус достигнут, если все участники показали 1 или 2.
Выбор идей (Голосовать точками)
Описание
Каждый участник молча одновременно с остальными ставит/клеит точку на 3 наиболее ценные идеи. Те идеи, которые
набрали самое большое количество точек (голосов) считаются самыми ценными и берутся в работу. Техника подходит также
для определения наиболее важных проблем.
Выбор идей (Молчаливое ранжирование)
Описание
На флипчарте нарисуйте ось ценности идеи. Каждый участник берет одну из идей и помещает ее на ось (в зависимости от
ценности идеи). Следующий участник берет следующую идею и также помещает ее на ось. И так далее пока не закончатся
идеи. Весь процесс происходит в полном молчании. Далее каждый следующий участник может переместить одну из идей.
Процесс продолжается до тех пор пока участники не перестанут вносить изменения. Если возникает спор, то можно 2 минуты
обсудить проблему. 2-4 наиболее ценные идеи берем в работу.
34

35.

Ретроспектива (Примеры Разработки Плана)
Цель
Выбор наиболее ценных идей для улучшения работы в следующем в Спринте, разработка плана по их внедрению
Выбор идей (Фильтр Мана)
Описание
Каждую идею оцените по следующим показателям:
• Дорого – 0 баллов, Дешево – 1 балл
• Сложно – 0 баллов, Просто – 1 балл
• Неэффективно – 0 баллов, Эффективно – 1 балл
Выберите несколько идей, набравших наибольшее количество баллов.
Выбор идей (Фильтрующая матрица, Screening matrix)
Описание
Эта техника подходит для ситуаций, в которых выбор сделать непросто. Составьте таблицу, где каждая строка вариант
решения, а каждый столбец требования к решению. Если решение удовлетворяет требованию ставим +, если нет, то -.
Проанализируйте результаты. Возможно можно выбрать какой-то гибридный вариант решения, который удовлетворит
большему числу требований.
Выбор идей (Список задач)
Описание
Мозговой штурм для создания списка задач, которые необходимо выполнить для реализации идеи по улучшению. Выбор
добровольных ответственных за выполнение задач.
35

36.

Ретроспектива (Примеры Закрытия)
Цель
Подведение итогов ретроспективы или сбор обратной связи для улучшения следующей встречи
Закрытие (Спасибо)
Описание
Каждый участник говорит «Спасибо за…» одному или нескольким участникам команды. Эта техника позволяет закончить
ретроспективу на позитивной ноте. Можно показать пример поблагодарив кого-то из команды первым.
Закрытие (Ретро про ретро)
Описание
Обсудите с участниками ретро то, как прошло ретро. Какие были сильные стороны и хорошие моменты, а какие слабые. Эта
техника позволяет адаптировать формат ретро под команду.
Закрытие (ROI)
Описание
Каждый участник от 1 до 5 оценивает каждую из стадий ретроспективы. Насколько оправдано было потраченное время. Тех,
кто ставит 1-3 спросите что они хотели получить и не получили, что можно улучшить. Тех, кто оценил на 4-5, спросите что они
получили и что было хорошо
Закрытие (Одно слово, Эмоция)
Описание
Каждый участник описывает проведенное ретро одним словом/эмоцией. Результат можно обсудить.
36

37.

Ретроспектива: Советы для фасилитаторов
Напоминайте о Ретро в течение Спринта
Посоветуйте команде в течение Спринта «по горячим следам» фиксировать идеи того, что хотелось бы обсудить на Ретро.
Хорошая практика: книга жалоб и предложений
Меняйте форматы и готовьтесь ко встрече
Старайтесь пробовать разные варианты упражнений для каждого этапа Ретроспективы. Это позволит участникам смотреть
на привычные проблемы и свою работу под неожиданными углами.
Вовлекайте всех
Убедитесь, что все участники Ретроспективы принимают активное участие и высказывают своё мнение. Каждый должен быть
услышан. Не позволяйте Ретро превратиться в диалог самых активных участников!
Обсуждайте план действий и прогресс с предыдущей Ретроспективы
Решения, принятые на Ретро, должны быть «живыми» и к чему-то вести. Не позволяйте команде забыть о достигнутых
договоренностях, предлагайте обсудить прогресс: сделано ли что-то, есть ли результат, было ли принятое решение удачным.
Визуализируйте и записывайте
Все мысли, идеи и действия обязательно должны быть зафиксированы. Поощряйте участников записывать свои мысли, и
сами фиксируйте ключевые моменты обсуждения.
Устанавливайте тайм-боксы для активностей и следите за временем
Все упражнения для Ретро должны быть ограничены во времени и сфокусированы. Сделайте таймер видимым для
участников, периодически напоминайте, сколько времени осталось. Если время вышло, переходите к следующей части
упражнения или другой активности. Не до конца разобранные идеи и проблемы – в бэклог улучшений.
Помните о цели Ретро
Помните, что ваша задача – выйти с Ретро с планом улучшений, который вы учтете на Планировании. Он может состоять
даже из одного пункта, но он должен быть! Ретроспектива – не просто встреча для общения.
37

38.

КЛЮЧЕВЫЕ ОТЧЕТЫ JIRA
BurnDown Chart
• Отражает
количество оставшейся работы в
Спринте
• Инструмент команды для мониторинга
и анализа работы в ходе Спринта
Velocity Chart
Sprint Report
• Отражает скорость работы команды в
ходе работы в Спринтах
• Отчет по выполненным и невыполненным
задачам в Спринте
• В рамках одного Спринта показывает
плановое значение объема работ
и фактическое
• Инструмент команды для мониторинга и
анализа Спринта
• Инструмент команды для анализа
скорости работы в Спринте
• Отражает информацию о задачах
добавленных или удаленных из Спринта
• Отражает объем выполненной работы по
Спринту в OTE
Более подробно по ссылке: http://wiki.corp.dev.vtb/pages/viewpage.action?pageId=164734693
38

39.

ДЭШБОРД КОМАНДЫ ОТ ЦЕНТРА МОНИТОРИНГА
Более подробно про отчеты по ссылке: http://wiki.corp.dev.vtb/pages/viewpage.action?pageId=113874051
39

40.

BURNDOWN CHARTS
5-7
минут
Охарактеризуйте работу команд по графикам
1
2
3
4
5
6
(с) PSM Workbook
40

41.

JIRA BURNDOWN CHART – ИНСТРУМЕНТ КОМАНДЫ ДЛЯ АНАЛИЗА
РАБОТЫ В СПРИНТЕ
Целевое наименование
спринта
График строится только по OTE
(Original Time Estimate –
Первоначальная оценка времени)
Команда еще не приступила к задаче / решает блокер /
не успевает вовремя “сжигать задачу” и т.д.
Требуется внимание команды
Линия тренда – линия
“идеального сгорания”
Info:
Спринты начинаются / заканчиваются АВТОМАТИЧЕСКИ
• Завершение – 22:00 вторник
• Старт спринта – 22:00 среда
Команда “сожгла” задачу быстрее, чем планировалось.
Возможно, переоценка задачи. Требуется внимание команды
41

42.

AGILE ЗРЕЛОСТЬ КОМАНДЫ
ЦЕЛЬ: Мониторинг эволюции зрелости кроссфункциональных команд с целью своевременного
выявления проблемных областей, разработки плана
развития и определения лучших практик
Для команды: обсуждая критерии соответствия
команда определяет перспективы развития
Для людей, поддерживающих команду: на основании
результатов определяют основные направления помощи
и изменений, в том числе, организации
http://wiki.corp.dev.vtb/pages/viewpage.action?pageId=46355025
42

43.

ПРОСТРАНСТВО ПРО ПРОПРО
http://wiki.corp.dev.vtb/pages/viewpage.action?pageId=46353773
43

44.

ЕСТЬ ОТКРЫТЫЕ ВОПРОСЫ?
1. Задайте их консультантам Accenture на странице:
http://wiki.corp.dev.vtb/pages/viewpage.action?pageId=149406357
2. Задайте их консультантам Accenture по адресу:
В рамках программы МПД организован чат СкрамМастеров для обмена знаниями.
Чтобы присоединиться к сообществу в Телеграм перейдите
по ссылке*:
https://t.me/joinchat/BUF5tRr1_JMqmGtndwqFuw
[email protected]
3. Адресуйте вопрос напрямую методологам по адресу:
[email protected]
4. Задайте вопрос на QA сессии:
[email protected]
Тема письма: ВОПРОС:QA ПроПро
*Большая просьба без необходимости не пересылать ссылку.
44

45.

С ЧЕГО НАЧАТЬ МНЕ, КАК СКРАМ-МАСТЕРУ?
№
Рекомендация
Где найти материалы
1
Войти в чат Скрам-мастеров МПД по ссылке (для МПД): https://t.me/joinchat/BUF5tRr1_JMqmGtndwqFuw
Слайд 44
2
Проверить, что все события ПроПро стоят в календаре и регулярно проводятся в соответствии с целями.
Если нет, организовать добавление в календарь и проведение согласно рекомендациям по фасилитации.
Слайд 18
3
Инициировать создание командных договоренностей (ревью правил, обсуждение с командой их
необходимости или достаточности).
Слайд 51
4
Убедиться, что у команды есть своё пространство в Сonfluence, что там отражена вся актуальная
информация и верные ссылки. Инициировать обновление/создание.
5
Актуализировать/Создать DoR и DoD команды, внести их на страницу команды в Сonfluence DSO.
Слайд 17
6
Начать проводить Ретроспективу, начиная с текущего Спринта или попробовать новые форматы.
Ретроспектива – регулярная встреча (1 раз в Спринт, после Демо).
Слайды 27-37 (Ретро), Слайд
47 (полезные ссылки)
7
Обсудить с командой ключевые метрики ПроПро (предварительно ознакомиться с ними).
Слайд 55
8
Устроить обмен знаниями: поговорить со Скрам-Мастером смежной команды.
Слайд 44 (например, чат СМ)
9
Ознакомиться с материалами на «Про ПроПро».
Слайд 43
10
Ознакомиться с материалами по работе в JIRA. Проверить корректность настроек доски команды. Убедиться
в том, что все члены команды одинаково понимают статусную модель и ключевые принципы работы в JIRA.
12
Пообщаться с Лидером Команды. Помочь Лидеру Команды в работе со стейкхолдерами, с JIRA, Confluence, с
бэклогом (приоритизация, декомпозиция).
Слайды 48, 53, 54
13
Составить Звездную карту команды или Canvas Команды, чтобы определить сильные стороны команды и
зоны роста.
Слайды 49, 50
14
Обсудить с командой несколько вопросов из Scrum Values Game (например, как часть Ретроспективы)
Слайды 10-13, 58-60
45

46.

Полезные материалы
46

47.

Рекомендуемая литература
Полезные ресурсы и материалы
1. Scrum guide
Facilitation_Mater
ials
2. Facilitation technics (в приложении)
3. Серия статей и материалов на тему Scrum Roles в рамках Scrum Master learning Path
4. Серия статей и материалов на тему Scrum Artifacts в рамках Scrum Master learning Path
5. Серия статей и материалов для Скрам-мастеров: Suggested Reading for Professional Scrum Master;
6. Серия статей про Product Backlog Refinement (PBR): Часть 1, Часть 2, Часть 3
7. Статья «Как научиться проводить крутые ретро?» и шпаргалка для проведения ретроспективы;
Полезные инструменты
1. Сервисы для выбора формата ретроспективы:
1. retromat.org,
2. www.funretrospectives.com
2. Сервисы для дистанционного Planning poker: самый простой и более продвинутый,
Книги
1. Эстер Дерби и Диана Ларсен «Agile ретроспектива: как превратить хорошую команду в великую» (174 стр)
2. Хенрик Книберг «Scrum и XP: Заметки с передовой» (94 стр)
47

48.

МАТРИЦА СТЕЙКХОЛДЕРОВ
1.Определение всех стейкхолдеров. На данном этапе
необходимо составить список всех людей или групп людей,
являющихся стейкхолдерами вашего проекта. Вписывайте
тех, кто с наибольшей долей вероятности может как-то на
него повлиять.
2. Определение ключевых потребностей всех
стейкхолдеров. Этот этап нужен для того, чтобы в
дальнейшем определить влияние того или иного
стейкхолдера на ваш проект.
3. Анализ влияния и важности каждого стейкхолдера с
помощью матрицы или карты стейкхолдеров. Нарисуйте
систему координат XY, где x – это уровень важности, а y –
уровень влияния. Из составленного списка стейкхолдеров,
обозначьте их на системе координат в соотношении
важности/влияния. К “влиянию” относят возможность
стейкхолдера влиять на решения по ключевым вопросам в
ходе проекта. А “важность” — это вклад стейкхолдера в
результат проекта.
48

49.

ПРОФИЛЬ КОМАНДЫ
49

50.

ЗВЕЗДНАЯ КАРТА
«—» отсутствие компетенции или низкий
уровень,
✔ — наличие базовых знаний и умений,
достаточных для работы в данной области
знаний,
★ — высокий уровень квалификации,
способность решать сложные задачи в данной
области.
Важно четко сформулировать критерии, по
которым будет определяться уровень
квалификации, и сделать их доступными для
всех сотрудников.
50

51.

ПРАВИЛА КОМАНДЫ
Определение правил команды
1. Правила команды разрабатываются совместно и
определяют, как группа будет работать вместе
Пример правил команды
1. Даем обязательства командой
2. Делимся опытом
3. Все приходят на встречи вовремя
2. Описывают модель позитивного поведения в группе
для наибольшей эффективности работы
4. Ошибки принадлежат команде, а не человеку
5. Пытаемся понять позицию собеседника
3. Наиболее эффективны, если они:
Просты и прямолинейны
Ограничены в количестве
Видны на каждой встрече
6. Предпочитаем общение лицом к лицу
4. Им следуют, если правила:
Осуществимы
Можно поделиться с коллегами менее чем за 30
секунд
В общем доступе (как раздаточный материал,
приклеены на доске)
9. Готовимся ко встречам заранее
7. Уважаем друг друга
8. Знаем видение и дорожную карту продукта
10. Храним документацию в общем доступе
11. Даем честную обратную связь
12. Следуем DoR и DoD
51

52.

Покер планирования ‒ это игровой способ оценивать и определять
относительный размер пользовательских историй
Команда согласовывает систему оценки, которая будет использоваться (в случае ПроПро ч/д)
Например, числа Фибоначчи: 1, 2, 3, 5, 8, 13, 21
1 Один из участников команды кратко представляет пользовательскую историю, размер
которой предстоит определить
2 Каждый из членов команды самостоятельно оценивает объем работы, ориентируясь на исходный вариант
пользовательской истории, с помощью приложения для покер-планирования Скрам
3 В команде проводится голосование, и участники с максимальным и минимальным количеством баллов
рассказывают другим участникам, почему поставили такую оценку
4 Голосование проводится еще раз, и после достижения консенсуса пользовательская история получает
оценку в стори поинтах
Важно соблюдать относительную точность, например если характеристика А вдвое сложнее
характеристики В, то она должна получить, соответственно, в два раза большую оценку.
Оценщики должны также учитывать общие трудозатраты на реализацию характеристики
(например на проектирование, разработку и компонентное тестирование)
52

53.

Алгоритм разделения историй
1 Подготовьте исходную историю
Соответствует ли история критериям
INVEST1 (кроме, возможно, "компактности")?
Размер истории –
от 1/10 до 1/6
скорости команды?
Объедините ее с
другой историей или
переформулируйте
ее, чтобы получить
ожидаемый результат
или краткую исходную
историю
Вы закончили Продолжайте
разделять
истории
Можно ли разделить
историю таким
образом, чтобы
сначала была
реализована базовая
функциональность, а
позже-дополнительная
функциональность?
Простота/сложность
Последовательность действий
Можно ли разделить историю таким
образом, чтобы в первую очередь
были реализованы начало и конец
последовательности действий,
а затем промежуточные шаги?
Отсрочка производительности
Можно ли разделить историю таким
образом, чтобы сначала были
реализованы функциональные
требования, и только затем
нефункциональные?
Можно ли упростить историю, выделив
базовый функционал, представляющий
наибольшую ценность?
Да
Описывает ли история
последовательность
действий?
Последний шанс
Разделение по бизнес-правилам
Можно ли разделить историю
таким образом, чтобы реализовать
сначала часть бизнес-правил и
расширить функционал позже?
Операции
Можно ли создать историю
для каждой операции?
Если историю можно разделить,
любая ли первая история, с которой
мы начнем, будет сложнее
в реализации, чем последующие?
Описывает
ли история
сложный
интерфейс?
Можно ли разделить историю так, чтобы сначала
реализовать работу с одним интерфейсом, а позже
расширить функционал работой с остальными
интерфейсами?
Есть ли возможность
Вариации
интерфейсов реализовать сначала
более простую версию?
Включает пи история в себя различные
бизнес-правила? (например, присутствует
ли термин "поиск с гибкими датами", который
предусматривает несколько реализаций?)
Оперирует ли история
различными группами
данными?
Выделите спайки
История до сих пор не разделена?
Есть ли истории,
которые можно
отложить или
удалить?
Можно ли выбрать
Различные группы данных основную историю,
с которой можно
Можно ли разделить
начать работу
историю таким образом,
и сразу получить
чтобы в первую очередь
ценность для
была реализована только
бизнеса,
часть бизнес-правил,
информацию
а позже расширить
для рисков и т. п.?
функционал?
Можете ли Вы выделить небольшую часть
истории, с которой будет начата работа?
Опишите эту часть в виде
отдельной истории,
реализуйте ее, и начните
процесс разделения истории
с самого начала
Размер каждой
истории от 1/10
до 1/6 скорости
команды?
Все истории
соответствуют
INVEST?
Включает ли история в себя
различные операции? (например,
речь идет об "управлении" чем-то
или "конфигурировании" чего-то?)
2 Примените
шаблоны
разделения
Последний шанс
3 Оцените разделение
Все новые истории
примерно одного размера?
Можно ли в первую очередь
реализовать базовые
действия, а затем дополнить
функционал историями
с остальными действиями?
Сложна ли реализация
нефункциональных требований
(например, производительности)
истории?
Можно ли получить одни и те же данные
через разные интерфейсы?
Можно ли сгруппировать
остальные истории и
отложить решение по их
реализации?
Основной объем работ
Нет
Можете ли Вы выделить 1-3
вопроса, которые не дают Вами
начать работу над историей?
Создайте спайк для исследования
этих вопросов, выполните его и
начните процесс разделения заново
Вы закончили!
Но Вы можете
попробовать другие
шаблоны и
улучшить результат
Попробуйте
применить другой
шаблон к исходной
истории или к
полученным
историям большего
размера
Попробуйте
другой шаблон
Попробуйте
другой шаблон.
Возможно, есть
избыточная
информация
в каждой из
полученных
историй
Попробуйте
другой шаблон
для получения
такого результата
Сделайте перерыв
и попробуйте еще раз
1 INVEST – история должна быть Independent (Независимая), Negotiable (Обсуждаемая), Valuable (Полезная), Estimable (Эстимируемая), Small (Компактная), Testable (Тестируемая)
ИСТОЧНИК: http://www.richardlawrence.info/splitting-user-stories/
53

54.

S.P.I.D.R.1 подход для разделения2 пользовательских историй
Spikes - пользовательские истории, которые не могут быть оценены
до того как команда проведет Исследования
Сделайте большую историю меньше, исключив spike.
Иногда просто сделав spike оставшаяся работа станет
управляемого размера
В других случаях новые знания, получаемые из spike, помогают
облегчить поиск пути разделения пользовательской истории
Rules - Правила
Иногда история большая из-за бизнес-правил,
тех.стандартов и т.п., которые должны
поддерживаться.
Определите возможно ли поддержать только
часть важных правил в одной истории
Добавьте поддержку дополнительных правил
в последующих историях
Отделите нефункциональные требования
Data - Данные
Поищите способы разделить историю на основе
типов данных, которые должны поддерживаться.
Может ли первая история поддерживать
действительные данные, а для другой добавить
недействительные данные?
Как на счет частых и менее часто
встречающихся типов данных?
1
2
Paths - Пути
Определите пути в истории и выделите каждый в
отдельную историю.
Нарисуйте простую диаграмму того что
происходит в истории. Каждая
последовательность шагов может быть историей
Выделите один большой шаг диаграммы в
историю
Отделите пути разных пользователей
Interfaces - Интерфейсы
Разделите историю по нескольким интерфейсам,
если их поддержка делает историю существенно
более долгой для разработки.
Разделите истории по типу или версии браузера
Создайте сначала минимального интерфейс или
не делайте детальный дизайн
SOURCE: The SPIDR technique for splitting any user story https://www.mountaingoatsoftware.com/blog/five-simple-but-powerful-ways-to-split-user-stories
Чтобы взять Историю в спринт необходимо чтобы ее размер был от 1/10 до 1/6 скорости команды в спринт
54

55.

КЛЮЧЕВЫЕ МЕТРИКИ ПРОПРО (РЕЕСТР МЕТРИК)
Метрики
ID
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Артефакты производственного процесса
Выработаны DOR и DOD команды
Наличие практик DevOps
% estimated issue
Backlog size
Burndown
Commitment vs Completion, %
Defect Age
Lead time
Sprint health
Sprint Velocity
T2M
Velocity
Бэклог внесен в JIRA
Доля дефектов в ПРОМ, %
Состав бэклога
Т2М, дни
% недоступности при установке релизa
% недоступности систем при установке релизов
MTTR (Mean Time to Rеcovery)
Балльная оценка инцидентов
Время простоя
Доступность критичных ИТ-систем, %
Инциденты
Категории инцидентов
Кол-во обращений по ИС
Количество инцидентов
Оценка инцидентов в баллах, шт. и баллы
Точки сбоя
% покрытия автотестами
% пройденных тест-кейсов нового функционала
% пройденных тест-кейсов регрессионного тестирования
Automated Test Coverage
Расположение целевых критичных ИС на EoL оборудовании
Целевые ИС Банка расположены на 2 ЦОД уровня надежности Tier3
Change Fail Percentage
Successful Builds
Частота поставок
Team Satisfaction
Выполнение SLA
Доля ключевых систем, с настроенным релизным процессом, %
Удовлетворенность внутреннего клиента, %
Заполняемость в разрезе стримов, команд, ролей
Команда разработки укомплектована на 60+% от запланированной численности
Потребность в ресурсах
Источник
Confluence
Confluence
DevOps
Jira
Jira
Jira
Jira
Jira
Jira
Jira
Jira
Jira
Jira
Jira
Jira
Jira
Jira
SM
SM
SM
SM
SM
SM
SM
SM
SM
SM
SM
SM
tbd
tbd
tbd
tbd
tbd
tbd
TeamCity
TeamCity
TeamCity
Анкета
Анкета
Анкета
Опрос
СУПИТР
СУПИТР
СУПИТР
Все метрики будут доступны на дашбордах, которые можно найти в этом пространстве:
http://wiki.corp.dev.vtb/display/MON/Dashboard+Roadmap
55

56.

КЛЮЧЕВЫЕ МЕТРИКИ ПРОПРО (КВОТИРОВАНИЕ)
Квотирование бэклога команды разработки
Плановая квота для задач того же типа, что и для трудозатрат, по
умолчанию:
• Новая функциональность - 40%
• Архитектурные задачи - 20%
• Технический долг - 30%
• Дефект - 10%
Может пересматриваться для отдельной команды при условии, сумма
квот по всем задачам должна составлять 100%.
Процент отклонения от квот по типам задач команды
E(факт) – фактические трудозатраты на задачи одного из типов
E(полн) – общий объем трудозатрат на задачи всех 4х типов
Q(план) – плановое значение квоты, утвержденное на
Суперспринт
Показывает точность соблюдения квот по типам задач как отклонение
от плановых квот:
• =0% - точное соблюдение квоты;
• <0% - недоиспользование квоты;
• >0% - переиспользование квоты.
Допустимым отклонением от квоты считаем +/-5%. При большем
отклонении необходим анализ с последующей корректировкой
планирования и/или пересмотром квот.
Все метрики будут доступны на дашбордах, которые можно найти в этом пространстве: http://wiki.corp.dev.vtb/display/MON/Dashboard+Roadmap
56

57.

КЛЮЧЕВЫЕ ОТЧЕТЫ JIRA (ОБОРАЧИВАЕМОСТЬ)
Индекс соблюдения сроков по типам задач для команды, также известный как Schedule Performance Index