1.
PM Labs
Омск, 22/10/2010
Scrum в заказной
разработке
Асхат Уразбаев
Тренер и консультант по гибким методологиям

2.
Асхат Уразбаев
• ScrumTrek
• Agile Coach
• Управляющий партнер
• В прошлом
• Программист, менеджер
проектов, методолог

3.
h"p://scrumtrek.ru/company/clients/

4.
Проблемы в разработке ПО

5.
Требования меняются
― Согласование такого контракта обычно занимает у нас около
четырех месяцев. За это время со 100% вероятностью мы
передумаем или вы прекратите использовать продукт. Может
быть мы сэкономим время, объявим о провале и начнем обвинять
друг друга?
― Я сдался еще до того, как отдал вам контракт

6.
Почему требования
меняются?

7.
Недостаток информации

8.
Недостаток фантазии

9.
Избыток фантазии

10.
Заказчик меняет требования
• Логичный вывод – требования
зафиксировать

11.
Каскадная модель (Waterfall)

12.
Контрактные обязательства
фиксируют…
• Объем работ
• Сумму контракта
• Дату поставки

13.
Проблема точки невозврата
• Заказчик боится
принимать
окончательное
решение
(подписывать
требования)

14.
Заказчик
• Заказчик – наемный менеджер
• Если что – он тоже виноват
Согласования,
утверждения,
совещания, рабочие
группы и другие
методы избегания
ответственности

15.
Сбор
требований
Разработка
Тестирование
Приемка
у
заказчика
ПОЛЕЗНОЕ ВРЕМЯ
Сроки реализации растут

16.
Итеративная разработка

17.
Полезное время итеративной
разработки
ПОЛЕЗНОЕ ВРЕМЯ
Разработка требований
Кодирование и
тестирование
Приемка

18.
Оценка в Agile
• Команда оценивает каждую фичу
– Например, в условных единицах (story
points)
• Известна эмпирическая усредненная
скорость команды (сумма условных
единиц в итерацию)

19.
Баклог – инструмент
управления требованиями
Функциональность
Оценка

20.
Баклог как способ
управления требованиями
• Заказчик может поменять любую
несделанную фичу на
эквивалентную по размерам
• Фичи оценивает вендор
• Заказчик может добавить или
удалить фичу.
• Заказчик может поменять порядок
несделанных фич
• В любой момент заказчик может
принять решение остановить
разработку
• Заказчик формально принимает
сделанные фичи

21.
Фиксированный
объем
работ
Фиксированный
бюджет

22.
Почему итеративная разработка
дешевле?

23.
Отмененная
функциональность
Новая
функциональность
Первоначальная и
разработанная
функциональность
Не делаем лишних фич

24.
Экономим трудозатраты
Без
автотестов
С
автотестами
Поддержка
(баги)
Автотесты
Функциональность

25.
Descoping

26.
Как вы делаете предварительную
оценку?

27.
Старинные методы оценки

28.
Учет рисков
• Традиционный подход: накинем на
оценку сверху:
– Изменения требований
– Проблемы при сдаче
– Труднореализуемые Мегафичи
• Scrum
– Оценка более адвекватна (при условии
согласовании с заказчиком правил Scrum)

29.
Проблема приемки
• Что если заказчик
будет менять фичи
по ходу итерации
или не принимать
в конце итерации?

30.
Приемочные тесты
• Создавать приемочные тесты
• Приемочные тесты согласовывать с
заказчиком до начала планирования
итерации

31.
Создание
требований
Демонстрация
Приемка
Ретроспектива
Декомпозиция
Оценка
Таймбоксинг
Фичи
Фичи
+
приемочные
тесты
Фичи
+
задачи
с
оценкой
Команда
Команда
Product
Owner
Команда

32.
В сухом остатке
• Работаем короткими итерациями
• Сдаем заказчику результаты в конце
каждой итерации
• Требования фиксируются на следующую
итерацию (например, в виде приемочных
тестов)
• Используем баклог для управления
изменениями

33.
Роли в Scrum:
ScrumMaster
Поддерживает «здоровье» команды, помогает
команде стать самоорганизующейся
Ответственность:
• Фасилитирует (модерирует) митинги
• Поддерживает прозрачность, доверие и
взаимную ответственность
• Устраняет внешние препятсвия
• Отвечает за процесс

34.
Роли в Scrum:
TEAM
• Самоорганизованная / самоуправляемая
- Колективно принимают решения
- Сами координируют и организуют свою
работу
• Кроссфункциональная

35.
Роли в Scrum:
Product Owner
• Задача: Добиться целей проекта
• Ответственность:
• Представляет интересы заказчика и
заинтересованных лиц
• Формирует и координирует Баклог
• Отвечает за Концепцию
• Управляет датой релиза и его
содержанием

36.
Цель проекта?

37.
Цель– максимизировать
свою прибыль?
• Даже если результат не нужен заказчику

38.
Цель – максимальная
удовлетворенность заказчика?

39.
Сервис,
который
хочет
заказчик
Сервис,
который
нужен
заказчику

40.
Цель – максимальная
ценность бизнесу заказчика

41.
Партнерство
• Общие цели
• Взаимная поддержка

42.
Стратегия Win/Win
• Прекраснодушие или разумная бизнес
стратегия?

43.
Заказчики
• Карьеристы
• Жучилы
• Пофигисты
• Занятые

44.
Воркшоп
или как собрать требования за 5 дней

45.
Воркшоп
• Длительное (от нескольких часов до
нескольких дней) мероприятие
• С заказчиком, заинтересованными
лицами, конечными пользователями
• Альтернатива долгим письменным
согласованиям

46.
Концепция проекта

47.
Концепция проекта
aka Project Charter, паспорт проекта, план
управления проектом и т.д.
(короткий документ)
• Бизнес-цели
• Позиционирование
• Критерии успеха
• Правила взаимодействия
• Заинтересованные лица и участники

48.
Персоны

49.
Федя Финдиректор
Проблемы
• Как снизить процент услуг,
оказываемых «налево»?
• Как обеспечить быстрый
доступ руководства к
данным по продажам?
• Как получить
консолидированные
отчеты прямо в Cognos?
Ценности
• Минимальные затраты $
на внедрение
• Отсутствие необходимости
проводить тренинг, чтобы
не останавливать работу
Тип:
Заказчик
 CFO
 Возраст:
30
лет
 Использует:
офисные
приложения,
Cognos
 Пользователь
Win7
на
корпоративном
ноутбуке

50.
Story Mapping

51.
Воркшоп по созданию баклога
Активность
Действие
Дополнения

52.
Innovation Games

53.
Менеджер
проекта в
Scrum
• Учитель, а не менеджер
• Исповедует философию
компании
• Ориентирован на
долгосрочный успех
• Умеет работать в команде
• Умеет организовать работу
команды
• Умеет организовать работу
заказчика
• Разбирается в процессе

54.
Вопросы ?

55.
Асхат Уразбаев
• askhat@scrumtrek.ru
• Twitter: zibsun
• Skype: askhatu
• ЖЖ: zibsun.livejournal.com