7. ИТОГО
• Лишь 30% проектов по разработке ПО заканчиваются
полным успехом
• При этом, лишь 20% функций разработанного ПО
используются постоянно
А в чем причина?
9. Обычный подход к разработке ПО
ТРЕБОВАНИЯ
АНАЛИЗ
ДИЗАЙН
РАЗРАБОТКА
ТЕСТИРОВАНИЕ
ПРИЕМКА
Приемка
пользователем
Пользователь
рассказывает
Нет взаимодействия с пользователем
• Недостаток
коммуникации
• Нет обратной связи
от пользователя
10. Время
Обычный подход к разработке ПО
ТРЕБОВАНИЯ
АНАЛИЗ
ДИЗАЙН
РАЗРАБОТКА
ТЕСТИРОВАНИЕ
ПРИЕМКА
• Петли обратной связи
• Отсутствие прямого
взаимодействия с
пользователем
• Затраты времени на
согласование и уточнение
• Не укладываемся в срок
• Выпускаем то, что успели
• Пользователь не доволен
?
?
?
?
?
??
?
rework
rework
rework
rework
+rework
+rework
+rework
+rework
START
А РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т ПА РТ Д Т П
DEADLINE DEADLINE
!?
!?
11. Как это выглядит для заказчика?
Заключили
контракт
ГДЕ?!
Магия
ЧТО ЭТО?!
12. То есть:
Делаем не то Делаем долго
Недостаток
прямого общения
Не прозрачно
13. Как это выглядит для подрядчика
- Расскажите, как вы видите
конечный продукт?
- Я в этом ничего не понимаю.
Вы специалист, сделайте мне
«красиво». Встретимся через
год.
• Надо догадаться,
что нужно
пользователю
• Действуем исходя
из предположений
14. Как это выглядит для подрядчика - 2
- Я ничего в этом не понимаю.
Вы специалист, вот вам
деньги, расскажите как
правильно.
- Вот так будет правильно.
- Я с вами не согласен.
• Не доверяем
экспертному мнению
• «Вы сделали то, что
я просил, но
оказывается, мне
нужно не это»
16. Условия успеха Waterfall
• Заказчик точно знает чего хочет
• Разработчики точно знают как это реализовать технически
• Требования не меняются в процессе реализации
• Рынок меняется медленно
Das ist fantastisch!
21. Основные особенности Agile-подхода
• Обязательное участие представителя заказчика
• Ориентация на пользователя при проектировании продукта
• Все необходимые специалисты вместе
• Работа небольшими порциями законченного функционала
• Как можно более ранняя поставка
• Ранняя проверка гипотез (MVP - Minimum Viable Product)
22. Итеративный подход
ЦЕЛЬ
Итеративный и инкрементальный
подход
• Клиент постепенно осознает свои
потребности
• Цель может меняться в процессе
• Разработчики постепенно понимают, как
их удовлетворять
• Итеративно проверяем, то ли мы делаем
• Можем раньше поставить готовый
промежуточный результат
25. AGILE MANIFESTO
ЛЮДИ И ВЗАИМОДЕЙСТВИЕ
ВАЖНЕЕ процессов и инструментов
РАБОТАЮЩИЙ ПРОДУКТ
ВАЖНЕЕ исчерпывающей документации
СОТРУДНИЧЕСТВО С ЗАКАЗЧИКОМ
ВАЖНЕЕ согласования условий контракта
ГОТОВНОСТЬ К ИЗМЕНЕНИЯМ
ВАЖНЕЕ следования плану
2001
http://agilemanifesto.org
26. Основные принципы AGILE-разработки
• Наивысшим приоритет - удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке.
• Работающий продукт следует выпускать как можно чаще (от пары
недель до пары месяцев).
• На протяжении всего проекта разработчики и бизнес (заказчики)
должны ежедневно работать вместе
• Непосредственное общение как с самой командой, так и внутри
команды есть наилучший способ обмена информацией
• Самые лучшие требования, архитектурные и технические решения
рождаются у самоорганизующихся команд.
• Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.
• Работающий продукт — основной показатель прогресса.
http://agilemanifesto.org
41. Особенности Scrum
• Список задач по продукту (Product Backlog) со сквозными
приоритетами
• Работа быстрыми итерациями фиксированной длительности
(Sprint)
• Фиксация списка задач на итерацию (Sprint Backlog)
• Регулярная демонстрация сделанного за итерацию (Product
Increment)
• Ежедневное статусное собрание
• Постоянное улучшение работы команды
• Выделенный представитель бизнеса
49. Product owner с точки зрения руководства
• Владеет продуктом от имени организации
• Несет ответственность перед руководством
• Принимает любую обратную связь, но…
• Самостоятельно принимает решения
50. Product owner с точки зрения команды
• Отвечает за ценность
проделываемой командой
работы
• Отвечает за прозрачность и
ясность баклога для команды
• Несет ответственность перед
заинтересованными лицами
51. Product Owner в Scrum
PRODUCT
OWNER
Владеет
и Создает
Участвует
Отвечает на
вопросы
команды
Участвует в
демонстрации
52. Менеджер проекта vs Product owner
Менеджер проекта Product owner
Цель – сдать проект Цель – создать продукт c
максимальной ценностью
Управляет людьми,
расписанием, рисками
Управляет требованиями к
продукту
Оптимизация сроков,
стоимости и бюджета
Оптимизация поставки
бизнес-ценности
55. Менеджер проекта vs Scrum-Мастер
Менеджер проекта Scrum-Мастер
Цель – сдать проект Цель – создать
эффективную команду
Раздает задачи Координирует людей
Управляет планами Управляет процессом
Управляет рисками Устраняет препятствия
58. Состав команды
• Частичная занятость
– Эксперты в предметной
области
– Заинтересованные лица
• Полная занятость
– Product owner
– Scrum-мастер
– Все специалисты, нужные
для достижения цели
PO
SM
Эксперты
+
Заинтересованные
лица
61. Свойства и структура Scrum-команды
• 5-9 человек, стабильная команда
• Кросс-функциональная
(все необходимые компетенции)
• PO отвечает за продукт
• Способен сбалансировать интересы всех
заказчиков
• Отвечает за бизнес-показатели
• SM растит команду
• Командная ответственность
• В команде все равны
• Плоская команда (нет подкоманд)
• Самоорганизация в команде
62. Принципы самоорганизации
• Коллективное принятие решений
– Обеспечивает ответственность за результат
– Не работает без доверия и общей цели
• Общая цель
• Доверие
– Для доверия нужна взаимная ответственность
• Взаимная ответственность
– Не работает без прозрачности
• Прозрачность