Опыт применения SCRUM

SCRUM
Опыт применения Scrum (Agile)
методологии управления
проектом в консалтинге
Докладчик: Игорь Хмаро (PMP)
KhmaroIP@gmail.com
1.
Сравнение классического проекта и
Scrum-проекта
2.
Как мы делали наш Scrum-проект
3.
Какие были трудности и как мы их
преодолевали
4.
Какие продукты проекта мы получили
5.
Выводы
СОДЕРЖАНИЕ
1.
Сравнение классического проекта и
Scrum-проекта
2.
Как мы делали наш Scrum-проект
3.
Какие были трудности и как мы их
преодолевали
4.
Какие продукты проекта мы получили
5.
Выводы
СОДЕРЖАНИЕ
Идеал
ПРОБЛЕМА ПОЛНОТЫ
ТРЕБОВАНИЙ
Реальность
Фиксируются:
Требования (WBS)
Ресурсы
Время
Движимый
приоритетом
известных
требований
Движимый
планом
Оцениваются:
Ресурсы
Время
ТРОЙСТВЕННОЕ ОГРАНИЧЕНИЕ
Журнал спринта
Спонсор
Руководитель
проекта
Группа
локальных
разработчиков
Заказчики и
пользователи
Команда
управления
проектом
Группа
удалённых
разработчиков
ВЗАИМОДЕЙСТВИЕ В КЛАССИЧЕСКОМ
ПРОЕКТЕ
Скрам
мастер
Заказчик 1
Заказчик 2
Владелец
продукта
Команда
разработчиков
Заказчик 3
ВЗАИМОДЕЙСТВИЕ В SCRUM ПРОЕКТЕ
ЦИКЛ ПРОИЗВОДСТВА ПРОДУКТОВ
Более
раннее получение первых
продуктов
Гибкость
Меньше
документации и бюрократии
Эффективная
обратная связь
ПРЕИМУЩЕСТВА SCRUM
ПРАВИЛЬНОЕ ПОНИМАНИЕ
ГИБКОСТИ В SCRUM
Размер
команды от 3 до 9 человек
Команда
разработчиков в одном кабинете
Опытные
разработчики широкого профиля
Активный
владелец продукта
Отсутствие
фиксированной даты
окончания всего проекта
Открытый
бюджет проекта
ОГРАНИЧЕНИЯ SCRUM
 Инструменты:
 Мероприятия:
 Журнал
спринта
 Сбор
 Список
требований
 Оценка
 Карточки
 Колода
Poker
требований
карт для Scrum
 Отчёты
 Фокус-фактор
требований
требований
 Планирование
спринта
 Спринт
 Отмена
спринта
 Демонстрация
результатов
 Ретроспектива
спринта
 Ежедневные
ОСНОВНЫЕ ИНСТРУМЕНТЫ И
МЕРОПРИЯТИЯ SCRUM
Скрамы (летучки)
1.
Сравнение классического проекта и
Scrum-проекта
2.
Как мы делали наш Scrum-проект
3.
Какие были трудности и как мы их
преодолевали
4.
Какие продукты проекта мы получили
5.
Выводы
СОДЕРЖАНИЕ
Получение
качества
первых результатов было важнее
Факторы
среды предприятия интенсивно менялись
Высокая
степень неопределённости в требованиях
Начальный
уровень зрелости компании в
управлении проектами
Желание
сократить объём проектной
документации и бюрократии
Малая
команда разработчиков
ПОЧЕМУ БЫЛ ВЫБРАН SCRUM?
 Инструменты:
 Журнал
спринта
 Мероприятия:
 Сбор
требований
 Оценка
требований

Список требований

Карточки требований
 Планирование

Колода карт для
Scrum Poker
 Спринт

Отчёты

Фокус-фактор
 Отмена
спринта
спринта
 Демонстрация
результатов
 Ретроспектива
спринта
ОСНОВНЫЕ ИНСТРУМЕНТЫ И
МЕРОПРИЯТИЯ SCRUM
ЖУРНАЛ СПРИНТА
 Инструменты:

Журнал спринта
 Список
требований
Карточки требований
 Колода карт для
Scrum Poker
 Отчёты
 Фокус-фактор

 Мероприятия:
 Сбор
требований
 Оценка
требований
 Планирование
спринта
 Спринт
 Отмена
спринта
 Демонстрация
результатов
 Ретроспектива
спринта
ОСНОВНЫЕ ИНСТРУМЕНТЫ И
МЕРОПРИЯТИЯ SCRUM
СПИСОК ТРЕБОВАНИЙ - BACKLOG
 Инструменты:
 Мероприятия:
Журнал спринта
 Список требований
 Сбор
 Карточки
 Планирование

требований
Колода карт для
Scrum Poker
 Отчёты
 Фокус-фактор

требований
 Оценка
требований
спринта
 Спринт
 Отмена
спринта
 Демонстрация
результатов
 Ретроспектива
спринта
ОСНОВНЫЕ ИНСТРУМЕНТЫ И
МЕРОПРИЯТИЯ SCRUM
Используется:
• В процессе оценки
трудоёмкости
• Во время планирования
спринта
• Во время исполнения
спринта
КАРТОЧКА ТРЕБОВАНИЯ
 Инструменты:
Журнал спринта
 Список требований
 Карточки требований

 Колода
карт для
Scrum Poker
Отчёты
 Фокус-фактор

 Мероприятия:
 Сбор
требований
 Оценка
требований
 Планирование
спринта
 Спринт
 Отмена
спринта
 Демонстрация
результатов
 Ретроспектива
спринта
ОСНОВНЫЕ ИНСТРУМЕНТЫ И
МЕРОПРИЯТИЯ SCRUM
КОЛОДА КАРТ SCRUM POKER
 Инструменты:
 Мероприятия:
 Сбор
требований

Журнал спринта

Список требований
 Оценка

Карточки требований
 Планирование

Колода карт для
Scrum Poker
 Спринт
 Отчёты

Фокус-фактор
 Отмена
требований
спринта
спринта
 Демонстрация
результатов
 Ретроспектива
спринта
ОСНОВНЫЕ ИНСТРУМЕНТЫ И
МЕРОПРИЯТИЯ SCRUM
 Титульный
лист
 Информация
о проекте: Руководитель проекта,
Дата отчёта, Получатели отчета
 Сводка
об исполнении: цель спринта, общее
состояние, отставание от расписания,
результат, риски, проблемы, изменения, фокус
фактор.
 Детализированный
отчёт: запланированные
требования, незапланированные работы,
график исполнения спринта, ссылка на файл с
требованиями, подробное описание рисков и
проблем
СТРУКТУРА ОТЧЕТА
ОТЧЁТЫ
ПРОГНОЗ ДАТЫ ЗАВЕРШЕНИЯ ПРОЕКТА
 Инструменты:
 Мероприятия:
 Сбор
требований

Журнал спринта

Список требований
 Оценка

Карточки требований
 Планирование

Колода карт для
Scrum Poker
 Спринт

Отчёты
 Фокус-фактор
 Отмена
требований
спринта
спринта
 Демонстрация
результатов
 Ретроспектива
спринта
ОСНОВНЫЕ ИНСТРУМЕНТЫ И
МЕРОПРИЯТИЯ SCRUM
Простои
Болезни
Незапланированные
работы
Потери
T = 100%
R
Фокус-Фактор – это коэффициент, который показывает реальную
производительность Команды Разработчиков по отношению к
теоритически возможной. Фокус фактор рассчитывается по формуле:
ФФ = R / T, где
 R - действительная производительность команды разработчиков
измеренная в ИЧД,
 T - доступные человеко-дни в течение Спринта.

ФОКУС-ФАКТОР
 Команда
 Спринт
разработчиков 4 человека,
- 2 недели,
 Доступные
человеко-дни Т = 5 дней в неделю * 2 недели * 4
человека = 40 человеко-дней.
 Команда
взяла в работу 3 требования по 5, 8, 20 ИЧД, общей
трудоёмкостью 33 ИЧД.
 По
окончании Спринта выяснилось, что даже 33 ИЧД сделать не
успели. Сделали только задачи по 20 и 8 ИЧД, R = 20 + 8 = 28 ИЧД.
 Фокус
фактор составил: ФФ = R / T = 28 / 40 = 0,7.
ПРИМЕР РАСЧЁТА ФОКУС-ФАКТОРА
РЕТРОСПЕКТИВЫ СПРИНТОВ
1.
Сравнение классического проекта и
Scrum-проекта
2.
Как мы делали наш Scrum-проект
3.
Какие были трудности и как мы их
преодолевали
4.
Какие продукты проекта мы получили
5.
Выводы
СОДЕРЖАНИЕ
• Задачи консалтинга не всегда укладывались в один
спринт
• Маленькая рабочая группа приводила к снижению
продуктивности команды
• Возникали незапланированные задачи
• Владелец продукта был не достаточно
активен/доступен/компетентен в понимании требований
• Неоднозначность формулировок требований и
различное понимание конечного продукта
• Нематериальность некоторых результатов консалтинга
ТРУДНОСТИ
1.
Сравнение классического проекта и
Scrum-проекта
2.
Как мы делали наш Scrum-проект
3.
Какие были трудности и как мы их
преодолевали
4.
Какие продукты проекта мы сделали
5.
Выводы
СОДЕРЖАНИЕ
 Схемы процессов as is
 Анализ проблем в процессах
 Схемы процессов to be
 Регламенты процессов
ПРОДУКТЫ ПРОЕКТА
ПРОДУКТЫ ПРОЕКТА
ПРОДУКТЫ ПРОЕКТА
ПРОДУКТЫ ПРОЕКТА
1.
Сравнение классического проекта и
Scrum-проекта
2.
Как мы делали наш Scrum-проект
3.
Какие были трудности и как мы их
преодолевали
4.
Какие продукты проекта мы получили
5.
Выводы
СОДЕРЖАНИЕ
1.
SCRUM методология годится не для всех проектов,
но если она подходит для данного проекта, то даёт
более быстрые результаты с более высоким КПД.
2.
SCRUM легок в понимании, но непрост в освоении.
3.
Для успеха SCRUM-проекта важно найти
правильного Владельца продукта.
ВЫВОДЫ
4.
Продуктом консалтинга в первую очередь являются
работающий бизнес-процесс. Но этот продукт не
всегда можно получить в течение одного спринта и
он трудно поддаётся измерению.
5.
Попробуйте SCRUM в своих проектах, это позволит
вам ощутить взаимосвязи процессов в проекте
очень быстро. Этот опыт можно будет использовать
и в классических проектах «водопад».
ВЫВОДЫ

Докладчик: Игорь Хмаро (PMP)

KhmaroIP@gmail.com
СПАСИБО ЗА ВНИМАНИЕ
 http://scrum.org
- Руководство по Скраму. Кен Швабер и
Джеф Сазерленд
 How
to make a good Product Owner. Adam Cogan
 http://agilemanifesto.org
Agile-манифест разработки
программного обеспечения
 Waterfall
versus Agile – comparing software development
methodologies
 Agile-манифест
обеспечения
разработки программного
 http://dsdm.org/
ПОЛЕЗНЫЕ ССЫЛКИ
ОСНОВЫ SCRUM
 Владелец
продукта:
 Доступность
для проведения мероприятий Скрама: планирование
спринтов, демонстрация продуктов, ретроспективы спринтов.
 Упорядочивание
 Доступность
 Понимание
 Доверие
списка требований.
для уточнения вопросов.
каждого требования в списке требований.
к команде в оценках трудоёмкости требований.
 Уважение
к цели Спринта. Понимание того, что команда только
делает запланированные вещи. Многие вещи могут подождать
следующих спринтов.
 Полномочия
на увеличение бюджета проекта.
ТРЕБОВАНИЯ К ВЛАДЕЛЬЦУ ПРОДУКТА