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

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

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

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

Для повышения эффективности производственного процесса члены команд имеют свои командные роли
Команда
1 В случае принятия решений 1 ключом ИТ-Лидер команды наделяется полномочиями и ответственностью Лидера команды

Ролевая модель Стрима. Скрам-мастер команды
Общее описание
Скрам-мастер команды отвечает за эффективность рабочего процесса, его постоянное совершенствование, использование командой практик гибкой разработки и выстраивание эффективных взаимодействий с другими командами
Развитие самоорганизации, командного духа в команде, непрерывное совершенствование, стимулирование принятия правильных, а не легких решений
Выявление проблем и примеров успешной работы команды
Информирование членов команды о возможных направлениях совершенствования, общение с членами команды
в формате "один на один"
Коучинг Лидера команды и членов команды
Устранение препятствий, стоящих перед командой (например зависимостей от других команд), ведение списка препятствий
Обеспечение непрерывного совершенствования

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

Скрам-мастер. МИФ & ПРАВДА
Скрам-мастер начинает делать работу за команду, чтобы помочь успеть в срок. В конце концов они же сами его просят, а он это делать умеет.
Скрам-мастер администрирует карточки на доске команды, а также "пушит" разработчиков, когда они забывают обновить статусы.
Скрам-мастер помогает команде в формировании ценностей, правил и целей сотрудничества.
Скрам-мастер всегда соглашается с позицией менеджмента среднего звена, например, даже когда они считают себя единственными ответственными за изменения организации, и отводят Скрам-мастеру функцию секретаря-администратора.
Скрам-мастер фасилитирует Скрам-события при необходимости.
Скрам-мастер всегда сам создает встречи и бронирует переговорки так как это одна из главных его обязанностей.
Скрам-мастер единственный интересуется диаграммой сгорания задач, постоянно анализирует метрики, строит отчеты и иногда рассказывает об этом команде.
Скрам-мастер учит соблюдать баланс между целями Команды разработки (высокое качество) и ВП (больше фич).
Скрам-мастер принимает решения на Ретроспективе за команду поднимает на обсуждение во время встречи темы, которые кажутся важными только ему или отдает все внимание кому-то одному.
Скрам-мастер формирует привычки самостоятельного управления информационными инструментами.
Скрам-мастер коучит команды на измерение метрик спринта и оценку трендов.
Скрам-мастер сам выявляет и приглашает на обзор всех стейкхолдеров. На самом обзоре Скрам-мастер лично активно собирает и записывает отзывы.
Скрам-мастер коучит команды на управление зависимостями, рисками, решение конфликтов и препятствий.
Скрам-мастер убеждается, что Ретроспектива проходит позитивно и продуктивно, обучает всех участников укладываться в отведенное время. Он принимает участие в Ретроспективе наравне с другими членами команды, но продолжает нести ответственность за Скрам-процесс.
Скрам-мастер сам лично устраняет любые "блокеры" внешние и внутренние, даже те, которые команда может решить самостоятельно. Становится героем и спасителем команды от всех сложностей.
Оцените правдоподобность высказываний ниже и аргументируйте свое мнение, опираясь на принципы Agile.
15 минут

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

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

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

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

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

ПЕРЕРЫВ

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

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

DOR И DOD’Ы НА КОНТРОЛЬНЫХ ТОЧКАХ
* Готовность к ИФТ - проведено внутреннее
тестирование, определяет «сгорание» задачи
на burndown графике в Jira
DoR
DoD1
Готовность к ИФТ
DoD2
Готовность к эксплуатации
Готовность к ПСИ

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

СИНХРОНИЗАЦИЯ КОМАНД (ссылка)

Планирование спринта

Актуализация бэклога команды будущих спринтов

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

Ежедневный стендап

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

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

Демонстрация (возможный формат события)
Обеспечить участие ключевых заинтересованных сторон
Обеспечить обновление ключевых показателей работы команды
Подготовить лидера команды к ответу на вопросы о рентабельности инвестиций
Начинать с вопроса "зачем",
чтобы напомнить присутствующим
о бизнес-предложении
Фиксировать обратную связь и совместно с лидером команды вносить в бэклог запросы на включение новых характеристик
Обсуждать следующую группу характеристик в бэклоге ценности или цели следующего спринта
Проводить большинство демонстраций вместо команды. Вместо этого дайте Лидеру команды и команде возможность установить отношения с заинтересованными сторонами
Не готовить развернутый план презентации
Неправильно
Правильно

Частота: 1 раз за спринт, Длительность: 1-2часа
Ретроспектива

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С ЧЕГО НАЧАТЬ МНЕ, КАК СКРАМ-МАСТЕРУ?

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

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

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

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

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

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

Покер планирования ‒ это игровой способ оценивать и определять относительный размер пользовательских историй
Важно соблюдать относительную точность, например если характеристика А вдвое сложнее характеристики В, то она должна получить, соответственно, в два раза большую оценку.
Оценщики должны также учитывать общие трудозатраты на реализацию характеристики
(например на проектирование, разработку и компонентное тестирование)

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

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

КЛЮЧЕВЫЕ МЕТРИКИ ПРОПРО (РЕЕСТР МЕТРИК)
Все метрики будут доступны на дашбордах, которые можно найти в этом пространстве: http://wiki.corp.dev.vtb/display/MON/Dashboard+Roadmap
В приложение?

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

КЛЮЧЕВЫЕ ОТЧЕТЫ JIRA (ОБОРАЧИВАЕМОСТЬ)
Показывает точность выполнения плана по задачам как отношение освоенного объёма к плановому объёму, возможные варианты значений:
=1 - точное выполнение плана;
<1 - отставание от плана;
>1 - опережение плана.
Допустимым показателем выполнения плана считаем Оборачиваемость в диапазоне от 0,85 до 1,15. При отклонении необходим анализ:
<0,85 - причин отставания от плана и выработки корректирующих действий;
>1,15 - причин опережения плана, если причина в неточном планировании, то выработки корректирующих действий, если причина в оптимизации работы, то анализ оптимизации для распространения лучших практик.
Типы задач соответствуют типам элементов бэклога: новая функциональность, архитектурная задача, технический долг, линейная деятельность.
Индекс соблюдения сроков по типам задач для команды, также известный как Schedule Performance Index
- фактические трудозатраты команды за период на задачи одного типа
- плановые трудозатраты команды за период на задачи одного типа

Scrum Values Game
Ответы

Scrum Values Game
Ответы

Scrum Values Game
Ответы

Формулировка цели и бэклога спринта
I
R
R
Приоритизация и управление бэклогом команды
C
C
Обеспечение ценности продукта команды
C
C
C
Определение даты и цели релиза продукта команды
C
C
C
C
Определение и актуализация дорожной карты продукта команды
R
C
C
Определение параметров MVP
R
Скрам-мастер
Команда
Лидер команды
C
Формулировка видения продукта команды
I
I
R
R
Определение целей и целевых показателей по продукту команды
R
A
R
R
A
R
R
A
R
A
R
A
R
A
C
Обеспечение необходимых компетенций в команде
ИТ Лидер Команды
A
C
R
R
Матрица распределения ответственности уровня "Команда" (1/3)
R
A
C
R
A
A
A
A
бизнес
технологические
два ключа
два ключа

Приемка историй на основании критериев приемки
R
R
Обеспечение соответствия DoD результата спринта
C
Мониторинг целевых бизнес показателей и метрик продукта команды
Определение критериев приемки истории/задач
C
C
Обеспечение качества технологической поставки продукта команды
Определение критериев готовности (DoR) и завершенности (DoD)
R
Скрам-мастер
Команда
Лидер команды
C
Обеспечение качества комплексной реализации продукта команды
I
I
R
Выполнение цели спринта в виде релиза спринта
R
R
A
R
R
R
R
Синхронизация дорожной карты продукта команды
ИТ Лидер Команды
A
R
Матрица распределения ответственности уровня "Команда" (2/3)
R
A
A
I
R
R
R
R
R
C
R
I
C
бизнес
технологические
бизнес
технологические
бизнес
технологические