Эффективный процесс разработки ПО на

основе гибких подходовШамрай Александр

Обзор методологий

Развитие процессов разработки ПО

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

Вопросы?