Agile 1 Основные особенности Отказ классических подходов

Agile 1

Основные особенности Отказ классических подходов Направленность на проекты с постоянно меняющимися требованиями Небольшие команды исполнителей Высокая значимость технических, организационных и социальных составляющих процесса. 2

Особенности Agile-проектирования Выпуск реального бизнес-продукта Очень короткими циклами Чувство выполненного долга Быстрая обратная связь Доверие клиента Сниженный риск Оперативная реализация бизнес-требований 3

Манифест гибкой разработки ПО (Agile Manifesto) Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану 4

Приоритеты Agile-методологий Люди и взаимодействия Работающий продукт Сотрудничество с заказчиком Готовность к изменениям 5

Известные Agile-методологии 6

7

Экстремальное проектирование Автор Кент Бек , 1999 г. Ориентировано на группы до 10 человек. Группа размещается в одном помещении. Процесс проектирования: Изменяющиеся требования Гибкий и динамичный Итеративный 8

Отличия от классических моделей проектирования ПО Есть Нет Сбора и управления требованиями Этапа планирования Кодирование Тестирование Выслушивание заказчика Проектирование 9

Динамика проекта определяется Непрерывностью связи с заказчиком Выбором простейшего решения реализации ПО Быстрой обратной связью Профилактикой возможных проблем 10

Методы экстремального проектирования Игра в планирование Небольшие версии Метафора Простой дизайн Тестирование Рефакторинг Парное программирование Коллективное владение Непрерывная интеграция 11

Методы экстремального проектирования 40 часовая рабочая неделя Локальный заказчик Стандарты кодирования 12

ХР. Игра в планирование Заказчик задает Объем работ Приоритеты Сроки Бюджет Композиция версий Разработчик определяет Процесс проектирования Временные оценки Подробный график работ Возможные риски 13

ХР. Небольшие версии Быстрый запуск простой системы Каждая версия продукта минимально отличается от предыдущей Выпуск новой версии осуществляется 1 раз в 2 недели 14

ХР. Метафоры Это глобальное «видение» проекта, которое понятно заказчику и исполнителю «Замена» большой архитектуры 1 -2 понятными заказчику и исполнителю диаграммами 15

ХР. Простой дизайн Выполнение многочисленных тестов Нет дублирующей логики Минимизация числа классов и методов В дизайн добавляется только то, что нужно и только тогда, когда нужно. 16

ХР. Тестирование Модульные тесты разрабатываются разрабатывают исполнители Функциональные тесты составляют заказчики Репозитарий тестов постоянно пополняется Тест разрабатывается вместе с кодом программы, перед кодом программы, после кода программы Тестирование пронизывает весь процесс разработки ПО. 17

ХР. Рефакторинг Программы до и после рефакторинга функционально эквивалентны Перед изменением – можно ли так изменить программу, чтобы сделать изменения простым После изменения – можно ли упростить программу так, чтобы тесты все равно проходили Рефакторинг – преобразование программы, при котором внешняя оболочка не меняется, изменения происходят только с ее составляющими 18

ХР. Парное программирование Разработчики программного кода работают в парах Партнер с клавиатурой и мышью реализует код Партнер без клавиатуры и мыши обдумывает принятое решение и возможные его альтернативы Состав пар меняется Эффективность парного программирования в 2 раза выше, чем обычного 19

ХР. Коллективное владение При необходимости код модифицируется немедленно, независимо от авторского кода Код – общая собственность Историю каждой строчки можно найти в системах тестирования. Коллективное владение + рефакторинг = многократное использование кода 20

ХР. Непрерывная интеграция Код интегрируется 1 раз в несколько часов. Интеграция нового кода заканчивается после прохождения системой всех тестов. Ответственность за интеграцию кода несет пара программистов, которая внесла изменения. 21

ХР. 40 -часовая рабочая неделя Сверхъурочные работы - нежелательны Если постоянно требуется переработка – неправильная организация проекта Отпуск - обязателен 22

ХР. Локальный заказчик В составе команды разработчика – представитель заказчика Представитель занимается функциональным тестированием системы Представитель отвечает на возникающие вопросы и расставляет приоритеты. 23

XP. Стандарты кодирования Должен быть единый стандарт кодирования: Способов форматирования исходного текста Методов и классов, идентификаторов Способов комментирования текста. Стандарт добровольно воспринят всеми разработчиками 24