4. Правила:
1. Изобразить слово или фразу на
карточке.
2. Изображения не должны содержать
ни цифр, ни букв.
3. Угадавший зарабатывает один бал.
4. Побеждает тот у кого больше всего
балов.
10 минут
5. Картинка того, какую ценность представляет продукт и каких бизнес целей помогает
достичь.
1
7. - High/Medium/Low
- MoSCoW
- Business value
- Стоимость риска и возможности
- Стоимость и эффект от внедрения
3
8. 4
Презентация Product Vision
Презентация Product Backlog
Проясняем и добавляем деталей к User story
Определяем критерии завершения User story
Проводим оценку User story
Разбивает Epic на User story
Разбиваем большие User story
Удаляем лишние PBI
Добавляем нужные PBI
9. 5
Cрок 3-4 месяца
Внедряемый функционал
Основывается на Product vision
План выбора User Stories и их
приоритетов
План изменений продукта
Фокусировка команды 3-4 месяца
10. 6
Готовые User story
Важные User story
Учитываем технические и логические зависимости
2 часа на выбор User story
2 часа на разбивку User story на Tasks
Определение необходимых компетенций
Определение необходимых ресурсов
Определить Цель Sprint
Презентация плана (Product owner)
11. Формула:
Как, <роль/персона юзера>,
я <что-то хочу получить>,
<с такой-то целью> .
Story points:
Title: Жилые дома
Priority:
Description:
Спонсор проекта хочет, чтобы в городке были 2
коттеджа для того, чтобы в них могли с комфортом жить
2 семьи.
Acceptance Criteria:
[ ] -В домах 1 и 2 готовы коробка и крыша
[ ] -В домах есть электричество
[ ] -В домах можно начинать внутреннюю отделку
Complexity: Business value:
10 Must have
HighHigh
6.1
Материалы:
2 доски, одна напротив другой
Маркеры 8 штук
10-20 карточек с терминами
Ватман для фиксации балов
Вопросы по завершению игры:
Что было сложно изобразить?
Что больше всего запомнилось?
Какие понятия термины не понятны?
Что нужно детальней обьяснить?
Каждая Идея остается идей пока она грамотно не зафиксирована на бумаге.
И первый документ с которого рождается проект есть Вижин продукта или проекта.
В Вижине продукта должно быть за фиксировано:
Целевая группа – для кого делается продукт
Потребности этой группу
Из чего состоит продукт, как он решает потребности этих пользователей
Ценности этого продукта
Если смотреть на это стороны проекта, то добавляются такие важные данные как
Цель проекта
Учасники проекта
Результаты проекта и активности
Ключевые контрольные поставки
Риски
Ограничения
Объём работ
Бизнес какой-то проект до добавляется такая составляющая как расходы и доходы.
Все это очень удобно и наглядно можно описать с помощью таких канвасов как Бизнес модел канвас и Проджект канвас.
Зачем это нужно в Скрам, да затем чтобы команда понимала какие изначально ставятся задачи и цели во главе этого продукта, и прикладывали все усилия к тому чтобы этих целей достичь.
В классике Вижин продукта/проекта представлен каким-то инициирующим документом проект, например Устав проекта.
Все с этого начинается.
Следующий очень важный артефакт в Scrame и в процессе создания продукта это создание Product Backlog.
Что такое Product Backlog, это плоский список составляющих частей продукта/результата которого команда планирует достичь.
Product Backlog создается на основании Product vision/Business vision.
Product Backlog определяет рамки проекта, он не статичный и постоянно Эволюционирует растет, уменьшаются.
Создает и отвечает за Product Backlog Product owner.
Только Product owner может добавлять и удалять элементы из Product Backlog.
Отдельный элемент Product Backlog называется Product Backlog Items (PBI).
Product Backlog Items есть двух типов:
Business User Stories
Non Business User Stories
Business User Stories – относятся все User Stories которые дадут Бизнес ценность, все остальные это не бизнес User Stories .
Есть еще такое понятие как Epic – это набор связаны User Stories.
Non Business User Stories – чаще всего добавляет команда проекта со Скрам мастером в Беклог.
Пример:
После того как Product Backlog сформирован, следующей очень важной задачей для Product Owner становится приоритезировать Product Backlog Items.
Эта задача не менее сложна чем его подготовить, особенно сложно оценить если это касается денег.
Также не всегда прослеживается прямая зависимость отдельных элементов продукта и Бизнес выгоды, поэтому чаще всего заказчики хотят все и сразу.
Есть много методик как это можно сделать, но на данном тренинге мы их рассматривать не будем так как это больше задача практик по бизнес анализу, чем по Scrum.
Вам нужно знать что это должно быть сделано, дальше вы поймете почему.
Следующая очень важное мероприятие это Product Backlog Grooming.
Данное мероприятие начинается с того что Product Owner презентует команде:
Презентация Product Vision
Презентация Product Backlog
Дальше команда проясняет и дополняет User stories необходимой информацией, а также критериями завершения.
Разбирать User story начинают с самых приоритетных, двигаясь в низ.
Если User story дополнена всей необходимой информацией ее оценивают.
Если User story очень большая ее дробят на User story по меньше.
Оценить желательно все User story, но детализировать нужно только на первые 2-3 спринта, так как после реализации Спринтов содержание Product Backlog может измениться.
User story не должны быть изначально сильно детализированы, так как это не вызовет дискуссии и каждый может понять написанное по совему.
Называют такое понятие Over Groomed – лишняя детализация, уменьшает коммуникации!
После проведения Product Backlog Grooming, Product Owner должен провести реприоритезация PBI, по следующим параметрам:
1. Бизнес потребности
2. Потребности команд
3. Организационные потребности
Одна из хороших практик которая может помочь на Backlog Grooming это User story maping.
Следующая задача не обязательная в Scrum, но рекомендуемая поэтому мы ее тоже проговорим.
Эта практика называется Release Planing
Не обязательно – но рекомендовано
Средний срок 3-4 месяца (бизнес ценность)
Внедряемый функционал
Основывается на Product vision
План выбора User Stories и их приоритетов
План изменений продукта
Фокусировка команды 3-4 месяца
1. Не являются детальным описанием требований
2. Простое описание функционала
3. Два атрибута для планирования (Размер, )
4. Это небольшие инкременты ценной функциональности
5. Не детализированы в самом начале проекта
Хорошая история:
Написана так чтобы можно было протестировать
Без технического жагрона
Небольшие истории лучше больших
Тесты должны быть написаны до кода.
История должна выполняться без привязки к конкретным элементам.
Каждая история должна содержать оценку.
История должна приводить к конкретному результату.
История должна вмещаться в Sprint.
Эмпирический процесс-не прерывное улучшение.
Цель – показать результаты и обсудить
Планируется - на последнем Daily Scrum
Когда - после завершения последней User Story
Где – в комнате команды
Как – в живую, без слайдов
Кто презентует – команда
Формат проведения – Вопросы ответы
Длительность – 1 час на одну неделю Sprint
Результат – принятые User Stories или новые User Stories
После Sprint Review
Выбрать цель встречи – что будем менять (процесс, коммуникации)
Сфокусированная беседа – только по теме
Обсуждение вариантов улучшения
Разработка плана улучшения
Выполнение ритуала на согласие (Понимаю, Принимаю, Поддерживаю)