5. Проблемы с моделью
• Публичные отчеты
o 31% проектов было отменены до их завершения.
o 53% проектов выехали больше чем за 189% от их первоначальной
оценки.
o Только 16% проектов были завершены в срок и в рамках бюджета.
o Для крупных компаний, завершенные проекты поставляли только 42%
от первоначально заложенных функций.
• Одни из основных причин
o Отсутствие привлечения пользователей: 13% от всех проектов
o Незаконченные требования и спецификации: 12% всех проектов
o Меняющиеся требования и спецификации: 12% процентов всех
проектов
6. Железный треугольник
Фиксировано
Требования
Управление
на основе
плана
Затраты График
Управляемо
8. Водопад остается на
плаву
• Модель решала возникающие проблемы
• Модель представлялась логичной и
перспективной
• Она работала
• Она отражает реальность рынка
14. Agile-манифест
• Мы постоянно открываем для себя более
совершенные методы разработки
программного обеспечения, занимаясь
разработкой непосредственно и помогая
в этом другим. Благодаря проделанной работе
мы смогли осознать, что:
o Люди и взаимодействие важнее процессов и инструментов
o Работающий продукт важнее исчерпывающей документации
o Сотрудничество с заказчиком важнее согласования условий
контракта
o Готовность к изменениям важнее следования первоначальному
плану
• То есть, не отрицая важности того, что справа,
мы всѐ таки больше ценим то, что слева.
15. Принципы Agile
• Наивысшим приоритетом для нас является удовлетворение
потребностей заказчика, благодаря регулярной и ранней
поставке ценного программного обеспечения.
• Изменение требований приветствуется, даже на поздних
стадиях разработки. Agile-процессы позволяют использовать
изменения для обеспечения заказчику конкурентного
преимущества.
• Работающий продукт следует выпускать как можно чаще, с
периодичностью от пары недель до пары месяцев.
• На протяжении всего проекта разработчики и представители
бизнеса должны ежедневно работать вместе.
• Над проектом должны работать мотивированные
профессионалы. Чтобы работа была сделана, создайте
условия, обеспечьте поддержку и полностью доверьтесь им.
• Непосредственное общение является наиболее практичным и
эффективным способом обмена информацией как с
самой командой, так и внутри команды.
16. Принципы Agile
• Работающий продукт — основной показатель прогресса.
• Инвесторы, разработчики и пользователи должны иметь
возможность поддерживать постоянный ритм бесконечно.
Agile помогает наладить такой устойчивый процесс
разработки.
• Постоянное внимание к техническому совершенству и
качеству проектирования повышает гибкость проекта.
• Простота — искусство минимизации лишней работы —
крайне необходима.
• Самые лучшие требования, архитектурные и технические
решения рождаются у самоорганизующихся команд.
• Команда должна систематически анализировать
возможные способы улучшения эффективности и
соответственно корректировать стиль своей работы.
25. Роль 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”
26. ЖЕЛАТЕЛЬНЫЕ
ХАРАКТЕРИСТИКИ
• Дальновидный
• Лидер и часть команды
• Дипломат
• Уполномоченные и ответственный
27. Взаимодействия
• Работа с командой
o Член команды
• Работа со Scrum Master
o Product Owner – что делаем
o Scrum Master – как делаем
• Работа с заинтересованными лицами
o Заказчик
o Пользователь
o Отделы продаж, маркетинга, обслуживания и т.д.
28. Масштабирование роли
Главный
Product
Owner
Product Owner Product Owner Product Owner
A B - Главный C
Product Product Product
Owner Owner Owner
подсистемы 1 подсистемы 2 подсистемы 3
Команда А Команда B Команда C
Product Product Product
Owner Owner Owner
модуля 1 модуля 2 модуля 3
32. Качества журнала
продукта
• В достаточной степени подробный
• Позволяет оценить
• Обновляемый
• Имеет приоритет
33. Выявление и описание
элементов
• Заполнять журнал вместе с командой и
заинтересованными лицами
• Описывать элементы в достаточной для
реализации детализации
• Использовать темы для группировки и
структурирования требований
34. Поддержка журнала
продукта
• Новые элементы выявляются и описываются, уже
существующие изменяются или удаляются по
необходимости.
• Журнал продукта имеет приоритеты. Наиболее
важные в настоящее время элементы находятся
сверху.
• Самые приоритетные элементы готовятся к
предстоящему планированию Спринта: они
декомпозируются и уточняются.
• Команда устанавливает размеры для элементов
журнала продукта.
35. Декомпозиция
элементов
Устанавливать тему и
описание встречи
Выбирать
пользователей из
домена
Я как корпоративный
Устанавливать
пользователь хочу
участников встречи
создавать встречи
Выполнять рассылку
уведомлений
Указывать важность
встречи
36. Размер элементов
Размер элемента
0 Сделано Сделано
1 XS Очень маленькая
2 S Маленькая
3 M Средняя
5 L Большая
8 XL Очень большая
13 XXL Вдвойне большая
20 XXXL Огромная
39. Что такое вариант
использования?
• Вариант использования – это спецификации
набора действий, выполняемых
системой, который дает заметный
результат, который, как правило, значим для
одного или нескольких субъектов или других
заинтересованных сторон системы.
• Понятия:
o Основное действующее лицо
o Предварительные условия
o Основной поток
o Альтернативные потоки
40. Пример – основной
поток
• Вариант использования – Регистрация курса
• Действующие лица:
o Основное – Студент
1. Поток событий
1. РЕГИСТРАЦИЯ. Студент вводит имя и пароль и система проверяет
зарегистрирован ли студент.
2. СОЗДАНИЕ ГРАФИКА. Система отображает доступные функции для
студента. Это три функции: создать график, изменить график, удалить
график. Студент выбирает «создать график».
3. ВЫБОР КУРСА. Система получает список доступных курсов и отображает
его для студента. Студент выбирает максимум 4-ре основных курса и два
дополнительных из представленного системой списка. Студент может
удалять или добавлять курсы из списка пока он их не сохранил.
4. СОХРАНЕНИЕ ГРАФИКА. После завершения выбора необходимых курсов
студент выполняет сохранения графика. Система проверяет правильно
ли выбраны курсы и отображает их студенту в виде списка с уникальным
идентификационным номером и с подтверждением сохранения. После
подтверждения студентом сохранения система сохраняет график.
41. Пример –
альтернативные потоки
2. Альтернативные потоки
1. ИЗМЕНЕНИЕ ГРАФИКА. Из основного шага СОЗДАНИЕ ГРАФИКА, когда
студент имеет уже сохраненные графики. Система получает и
отображает сохраненные графики и позволяет их использовать как
отправную точку для редактирования графика. Вариант использования
возвращается на шаг ВЫБОР КУРСА.
2. УДАЛЕНИЕ КУРСА ИЗ ГРАФИКА. Из основного шага СОЗДАНИЕ
ГРАФИКА, когда студент выбирал курс и выбирает его удаление.
Система спрашивает подтверждение удаление. После подтверждения
студентом удаления, система удаляет курс из графика.
3. УДАЛЕНИЕ СУЩЕСТВУЮЩЕГО ГРАФИКА. Из основного шага СОЗДАНИЕ
ГРАФИКА, когда студент имеет сохраненные графики и выбирает
удаление одного из него. Система отображает содержимое график и
спрашивает подтверждение удаление. После подтверждения студентом
удаления, система удаляет график.
4. НЕОПРЕДЕЛЕННЫЙ ПОЛЬЗОВАТЕЛЬ. Из основного шага
РЕГИСТРАЦИЯ, когда система не может найти введенные имя и
пароль, она отображает ошибку.
5. ВЫХОД. Система в любой момент времени позволяет студенту выйти.
Если студент редактирует график система отображает
предупреждение о несохраненной информации и ожидает
подтверждения выхода.
42. Формирование
элементов журнала
Главный поток
Альтернативный User
поток 1 story 2
User Альтернативный User
story 1 story 3
поток 2
Альтернативный User
story 4
поток 3
