Эффективный процесс разработки ПО на
основе гибких подходовШамрай Александр
Обзор методологий
Развитие процессов разработки ПО
1970 1980
1990
2000
2010
Водопад
Спираль, RAD, RUP
Crystal, Scrum, XP, FDD, Lean,
Kanban
ВодопадТребовани
я
Проектирование
Реализация
Проверка
Развертывание
Проблемы с моделью• Публичные отчеты
o 31% проектов было отменены до их завершения. o 53% проектов выехали больше чем за 189% от их первоначальной
оценки. o Только 16% проектов были завершены в срок и в рамках бюджета. o Для крупных компаний, завершенные проекты поставляли только
42% от первоначально заложенных функций.
• Одни из основных причинo Отсутствие привлечения пользователей: 13% от всех проектов o Незаконченные требования и спецификации: 12% всех проектов o Меняющиеся требования и спецификации: 12% процентов всех
проектов
Железный треугольник
Требования
Затраты
Управление на
основе плана
График
Фиксировано
Управляемо
Качество в водопадеФиксированные требования, сроки, затраты
Качество
Водопад остается на плаву
• Модель решала возникающие проблемы• Модель представлялась логичной и
перспективной• Она работала• Она отражает реальность рынка
Итеративные процессы
Спираль RAD RUP
Спиральная модель
RAD
RUP
Адаптивные (гибкие) процессы
Agile-манифест • Мы постоянно открываем для себя более
совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что: o Люди и взаимодействие важнее процессов и инструментовo Работающий продукт важнее исчерпывающей документацииo Сотрудничество с заказчиком важнее согласования условий
контрактаo Готовность к изменениям важнее следования первоначальному
плану
• То есть, не отрицая важности того, что справа, мы всё таки больше ценим то, что слева.
Принципы Agile• Наивысшим приоритетом для нас является удовлетворение
потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
• Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
• Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
• На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
• Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
• Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
Принципы Agile• Работающий продукт — основной показатель прогресса. • Инвесторы, разработчики и пользователи должны иметь
возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
• Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
• Простота — искусство минимизации лишней работы —крайне необходима.
• Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
• Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
XP
Scrum
Lean
Гибкие методологии
50%
24%
6%
5%
3% 12%
Scrum Scrum/XP XPГибрид Lean Другое
Железный треугольник
Требования
СрокиЗатраты
Фиксировано
Управляемо
ROIВодопад Agile
Требования
Проектирование
Реализация
Проверка
Развертывание
Оплата
Итерация1 - оплата
Итерация2 - оплата
Итерация3 - оплата
Работа с требованиями
Product Owner
Роль Product Owner• The Product Owner is the one and only person
responsible for managing the Product Backlog and ensuring the value of the work the team performs. This person maintains the Product Backlog and ensures that it is visible to everyone.
Ken Schwaber “Scrum Guide”
ЖЕЛАТЕЛЬНЫЕ ХАРАКТЕРИСТИКИ
• Дальновидный• Лидер и часть команды • Дипломат• Уполномоченные и ответственный
Взаимодействия• Работа с командой
o Член команды
• Работа со Scrum Mastero Product Owner – что делаемo Scrum Master – как делаем
• Работа с заинтересованными лицамиo Заказчикo Пользовательo Отделы продаж, маркетинга, обслуживания и т.д.
Масштабирование роли
Главный Product Owner
Product Owner
подсистемы 1
Product Owner
модуля 1
Product Owner
модуля 2
Product Owner
модуля 3
Product Owner
подсистемы 2
Product Owner
подсистемы 3
Product Owner A
Команда А
Product Owner B - Главный
Команда B
Product Owner C
Команда C
Видение продукта
Желаемые качества
• Общее и унифицированное• Обширное и увлекающее• Определять функции
Журнал продукта
Качества журнала продукта
• В достаточной степени подробный• Позволяет оценить • Обновляемый• Имеет приоритет
Выявление и описание элементов
• Заполнять журнал вместе с командой и заинтересованными лицами
• Описывать элементы в достаточной для реализации детализации
• Использовать темы для группировки и структурирования требований
Поддержка журнала продукта
• Новые элементы выявляются и описываются, уже существующие изменяются или удаляются по необходимости.
• Журнал продукта имеет приоритеты. Наиболее важные в настоящее время элементы находятся сверху.
• Самые приоритетные элементы готовятся к предстоящему планированию Спринта: они декомпозируются и уточняются.
• Команда устанавливает размеры для элементов журнала продукта.
Декомпозиция элементов
Я как корпоративный пользователь хочу создавать встречи
Устанавливать тему и описание встречи
Устанавливать участников встречи
Выбирать пользователей из домена
Выполнять рассылку уведомлений
Указывать важность встречи
Размер элементовРазмер элемента
0 Сделано Сделано
1 XS Очень маленькая
2 S Маленькая
3 M Средняя
5 L Большая
8 XL Очень большая
13 XXL Вдвойне большая
20 XXXL Огромная
Покер планирования
Варианты использования
Что такое вариант использования?
• Вариант использования – это спецификации набора действий, выполняемых системой, который дает заметный результат, который, как правило, значим для одного или нескольких субъектов или других заинтересованных сторон системы.
• Понятия:o Основное действующее лицоo Предварительные условияo Основной потокo Альтернативные потоки
Пример – основной поток
• Вариант использования – Регистрация курса• Действующие лица:
o Основное – Студент
1. Поток событий1. РЕГИСТРАЦИЯ. Студент вводит имя и пароль и система проверяет
зарегистрирован ли студент.2. СОЗДАНИЕ ГРАФИКА. Система отображает доступные функции для
студента. Это три функции: создать график, изменить график, удалить график. Студент выбирает «создать график».
3. ВЫБОР КУРСА. Система получает список доступных курсов и отображает его для студента. Студент выбирает максимум 4-ре основных курса и два дополнительных из представленного системой списка. Студент может удалять или добавлять курсы из списка пока он их не сохранил.
4. СОХРАНЕНИЕ ГРАФИКА. После завершения выбора необходимых курсов студент выполняет сохранения графика. Система проверяет правильно ли выбраны курсы и отображает их студенту в виде списка с уникальным идентификационным номером и с подтверждением сохранения. После подтверждения студентом сохранения система сохраняет график.
Пример – альтернативные
потоки2. Альтернативные потоки
1. ИЗМЕНЕНИЕ ГРАФИКА. Из основного шага СОЗДАНИЕ ГРАФИКА, когда студент имеет уже сохраненные графики. Система получает и отображает сохраненные графики и позволяет их использовать как отправную точку для редактирования графика. Вариант использования возвращается на шаг ВЫБОР КУРСА.
2. УДАЛЕНИЕ КУРСА ИЗ ГРАФИКА. Из основного шага СОЗДАНИЕ ГРАФИКА, когда студент выбирал курс и выбирает его удаление. Система спрашивает подтверждение удаление. После подтверждения студентом удаления, система удаляет курс из графика.
3. УДАЛЕНИЕ СУЩЕСТВУЮЩЕГО ГРАФИКА. Из основного шага СОЗДАНИЕ ГРАФИКА, когда студент имеет сохраненные графики и выбирает удаление одного из него. Система отображает содержимое график и спрашивает подтверждение удаление. После подтверждения студентом удаления, система удаляет график.
4. НЕОПРЕДЕЛЕННЫЙ ПОЛЬЗОВАТЕЛЬ. Из основного шага РЕГИСТРАЦИЯ, когда система не может найти введенные имя и пароль, она отображает ошибку.
5. ВЫХОД. Система в любой момент времени позволяет студенту выйти. Если студент редактирует график система отображает предупреждение о несохраненной информации и ожидает подтверждения выхода.
Формирование элементов журнала
Главный поток
Альтернативный поток 1
Альтернативный поток 2
Альтернативный поток 3
User story 1
User story 2
User story 3
User story 4
Масштабирование Agile
Team
Port
foli
oP
rog
ram
Tra
in P
lan
nin
g
Developers & Testers
Team
B
acklo
g
Stories fit in sprints
(Implemented by) Tasks
Features &
Enablers fit in PSI’s
Epics fit in time
boxes
Sprints
Architectureevolves
continuously
Spikes are research, design, refactor Stories
Features & Enable Development
Architecture & Technology Roadmap Enabler 1 Enabler 2
Epic Roadmap
Stories
Features and components
Scrum/AgileMaster
Rele
ase
P
lan
nin
g
Pla
n
Dem
o
SI&T
Rough Planning
Feature 2
Feature 1
Epic1 Epic 2
Pla
n
Dem
o
Nonfunctional
requirements
(
NFRs
Stories
Investment Themes
RoadmapsFeatureBriefs Enable
r 1
©2010 Leffingwell, LLC. Reproduced with permission
Port
foli
o
Backlo
g
Epic
Pro
ject
Backlo
g
Product Owner
NFRs
Team
B
acklo
gTeam
B
acklo
g
Tra
in P
lan
nin
g
Sprints
Rele
ase
P
lan
nin
g
Pla
n
Dem
o
Pla
n
Dem
o
Enabler 2
Pla
n
Dem
o
Pla
n
Dem
o
Feature 4
Feature 3
Enabler 3
Enabler 4
Вопросы?