презентация доклада на Expert Labs в Омске 22 октября 2010

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

49. Персоны

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

51. Story Mapping

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

53. Innovation Games

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

55. Вопросы ?

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