экстремальное программирование

Содержание

Слайд 2

XP
Экстремальное программирование – это упрощенная методика организации производства для небольших и средних

XP Экстремальное программирование – это упрощенная методика организации производства для небольших и
по размеру команд специалистов, занимающихся разработкой программного продукта в условиях неясных и быстро меняющихся требований.

Слайд 3

XP

Короткие циклы;
Планирование по нарастающей;
Гибкий график реализации функциональности;
XP базируется

XP Короткие циклы; Планирование по нарастающей; Гибкий график реализации функциональности; XP базируется
на автоматических тестах, разработанных и программистами, и заказчиками;
Обмен сведениями через общение, тесты и исходный код;
Эволюционирующий дизайн.

Признаки применения XP:

Слайд 4

XP

Основная проблема разработки ПО - РИСК

Виды рисков:
Смещение графиков;
Закрытие проекта;
Система

XP Основная проблема разработки ПО - РИСК Виды рисков: Смещение графиков; Закрытие
теряет полезность;
Велико количество дефектов и недочетов системы;
Несоответствие системы решаемой проблеме;
Изменение характера бизнеса;
Недостаток возможностей системы;
Текучка кадров.

Слайд 5

4 переменные:
Затраты;
Время;
Качество;
Объем работ.
Внешние силы (заказчики, менеджеры) должны определить

4 переменные: Затраты; Время; Качество; Объем работ. Внешние силы (заказчики, менеджеры) должны
значения для любых трех переменных, а команда разработчиков выбирает результирующее значение для четвертой переменной (управляет четвертой переменной).

Модель контроля переменных

XP

Слайд 6

Обычная стратегия разработки ПО предусматривает стадии:
Формулировка требований;
Анализ требований;
Проектирование системы;

Обычная стратегия разработки ПО предусматривает стадии: Формулировка требований; Анализ требований; Проектирование системы;
Реализация системы;
Тестирование системы;
Внедрение системы.
Стоимость внесения изменений растет экспоненциально в зависимости от времени.

Стоимость внесения изменений в систему

XP

Слайд 7

Основное предположение XP:
Сегодня требуется реализовать только то, без чего сегодня не обойтись.
Стоимость

Основное предположение XP: Сегодня требуется реализовать только то, без чего сегодня не
внесения изменений в систему растет пропорционально √t, где t – время работы над системой.

Стоимость внесения
изменений в систему

XP

Слайд 8


Простой дизайн без лишних элементов;
Автоматические тесты;
Постоянная практика в

Простой дизайн без лишних элементов; Автоматические тесты; Постоянная практика в деле модификации
деле модификации дизайна системы.

Три ключевых фактора XP:

XP

Слайд 9

Коммуникация
Простота
Обратная связь
Храбрость

Четыре ценности XP:

XP

Коммуникация Простота Обратная связь Храбрость Четыре ценности XP: XP

Слайд 10


Кодирование;
Тестирование;
Общение;
Проектирование.

Четыре основных вида деятельности XP:

XP

Кодирование; Тестирование; Общение; Проектирование. Четыре основных вида деятельности XP: XP

Слайд 11

Быстрая обратная связь;
Приемлемая простота;
Постепенное изменение;
Приемлемые изменения;
Качественная работа.
Менее

Быстрая обратная связь; Приемлемая простота; Постепенное изменение; Приемлемые изменения; Качественная работа. Менее
важные принципы:
Обучение обучению;
небольшие начальные инвестиции;
надежное экспериментирование;
открытая честная коммуникация;
работа в соответствии с человеческими инстинктами;
принимаемая ответственность;
локальная адаптация;

Базовые принципы XP:

XP

Слайд 12

Бизнес-культура;
Обычный стиль работы разработчиков, настроенный на тщательное планирование;
Крупномасштабные проекты,

Бизнес-культура; Обычный стиль работы разработчиков, настроенный на тщательное планирование; Крупномасштабные проекты, требующие
требующие большой команды программистов;
Рабочая среда, препятствующая легкости обратной связи.

Ограничения применения XP:

XP

Слайд 13

Практики XP

Игра в планирование
Тестирование
Парное программирование
Рефакторинг
Простой дизайн
Коллективное владение кодом
Постоянная интеграция
Заказчик на месте с

Практики XP Игра в планирование Тестирование Парное программирование Рефакторинг Простой дизайн Коллективное
разработчиками
Частые выпуски версий
40-часовая рабочая неделя
Стандарты кодирования
Метафора системы

Слайд 14

Игра в планирование (Planning Game)

Задачи команды
Оценка времени для реализаций каждого из пожеланий;
Оценка

Игра в планирование (Planning Game) Задачи команды Оценка времени для реализаций каждого
времени связанной с выбором технологии
Распределение задачи между командами;
Оценка рисков, связанных с каждым из пожеланий;
Определение порядка в котором будет реализованы задачи.
Задачи заказчика
Определяет набор пожеланий и конкретизирует каждую итерацию;
Определяет дату завершения работы(Realize)
Определяет приоритеты задач
Планирование должно выполняться как можно чаше

Слайд 15

Первичное обследование

В начале работы над проектом разработчики и заказчики обсуждают новую систему,

Первичное обследование В начале работы над проектом разработчики и заказчики обсуждают новую
чтобы выявить наиболее существенные функции.
Однако они не пытаются идентифицировать все вообще функции. По мере развертывания работ заказчики будут обнаруживать все новые и новые функции. Поток функций не иссякнет вплоть до момента завершения проекта. Вновь выявленная функция разбивается на одну или несколько пользовательских историй, которые записываются на учетной карточке или чем-то подобном.
Пример, «Вход в систему», «Добавление пользователя», «Удаление пользователя», «Изменение пароля»
Разработчики совместно оценивают истории в баллах. Эти оценки относительны, а не абсолютны.

Слайд 16

Объединение, разбиение и скорость

Если история слишком велика, то ее следует разбить на

Объединение, разбиение и скорость Если история слишком велика, то ее следует разбить
меньшие части.
Если история слишком мала, ее следует объединить с другими
История «Пользователи могут безопасно переводить деньги на свой счет, со своего счета или с одного счета на другой» может быть разбита на истории:
• Пользователь может войти в систему
• Пользователь может выйти из системы
• Пользователь может положить деньги на свой счет
• Пользователь может снять деньги со своего счета
• Пользователь может перевести деньги с любого из своих счетов на другой

Слайд 17

Планирование выпуска

Каждую неделю завершатся реализация нескольких историй. Сумма оценок завершенных историй дает

Планирование выпуска Каждую неделю завершатся реализация нескольких историй. Сумма оценок завершенных историй
скорость.
Зная скорость, заказчик может получить представление о стоимости каждой истории, а также о ее значимости для бизнеса и о приоритете. Это позволяет заказчику решить, какие истории реализовывать первыми.
Разработчики и заказчик согласуют дату первого выпуска проекта. Обычно это занимает 2–4 месяца. Заказчик указывает, какие истории реализовать в этом выпуске и примерный порядок реализации. Не разрешается выбирать больше историй, чем укладывается в текущую скорость.

Слайд 18

Планирование итерации

Разработчики и заказчик определяют длительность итерации: обычно 1 или 2 недели.

Планирование итерации Разработчики и заказчик определяют длительность итерации: обычно 1 или 2
И снова заказчик решает, какие истории реализовать на первой итерации, но не может выбрать больше историй, чем позволяет текущая скорость.
Порядок реализации историй в пределах итерации – вопрос решаемый самими разработчиками.
Заказчик не может изменять истории после начала итерации. Он вправе изменять или переупорядочивать любые истории, кроме тех, над которыми разработчики уже трудятся.
Итерация заканчивается в заранее оговоренный день, даже если не все истории реализованы. Оценки всех завершенных историй суммируются, и вычисляется скорость на данной итерации. Эта величина ис-пользуется для планирования следующей итерации.

Слайд 19

Определения понятия ≪готово≫

История не считается реализованной, пока не пройдут все приемочные тесты.

Определения понятия ≪готово≫ История не считается реализованной, пока не пройдут все приемочные
Эти тесты автоматизированы.
Пишут их заказчики, бизнес аналитики, специалисты по контролю качества, тестировщики и даже программисты в начале каждой итерации.
Тесты определяют детали истории и являются неоспоримым авторитетом в вопросе о поведении историй.

Слайд 20

Планирование задач (1)

В начале новой итерации разработчики и заказчики вырабатывают план. Разработчики

Планирование задач (1) В начале новой итерации разработчики и заказчики вырабатывают план.
разбивают истории на задачи.
Задачей называется объем работы, с которым один разработчик может справиться за 4–16 часов.
Истории анализируются совместно с заказчиком, и задачи формулируются максимально полно.
Список задач записывается в лекционном блокноте, на доске или на любом другом носителе.
Затем разработчики выбирают себе задачи, которые хотели бы реализовать, присваивая каждой задаче произвольную оценку в баллах.

Слайд 21

Планирование задач (2)

Разработчик может выбрать любую задачу вне зависимости от специализации.
Каждый

Планирование задач (2) Разработчик может выбрать любую задачу вне зависимости от специализации.
разработчик знает, сколько баллов он заработал на задачах на предыдущей итерации; это число составляет бюджет разработчика.
Никто не берет себе задач на большую сумму, чем его бюджет.
В середине итерации команда устраивает рабочее совещание. В этот момент должна быть реализована половина историй, запланированных на данную итерацию. Если это не так, то команда пытается перераспределить задачи и ответственность таким образом, чтобы к концу итерации все истории были реализованы.

Слайд 22

Подведение итогов итераций

Раз в две недели текущая итерация заканчивается и начинается новая.
В

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

Слайд 23

Мониторинг (1)

Мониторинг и управление XP-проектом сводятся к записи результатов каждой итерации и

Мониторинг (1) Мониторинг и управление XP-проектом сводятся к записи результатов каждой итерации
использованию этих данных для прогнозирования следующих итераций. Рассмотрим, например, рис.. Этот график называется диаграммой скорости.

Слайд 24

Мониторинг (2)

Диаграмма выгорания показывает, сколько баллов оставалось набрать в конце каждой недели

Мониторинг (2) Диаграмма выгорания показывает, сколько баллов оставалось набрать в конце каждой
до следующей важной контрольной точки. Наклон этого графика – индикатор даты завершения.

Слайд 25

Тестирование (Testing)

Тестирование применяемое в XP
Тестирование модулей (unit testing)
Приемочное тестирование (acceptance testing)

Тестирование (Testing) Тестирование применяемое в XP Тестирование модулей (unit testing) Приемочное тестирование (acceptance testing)

Слайд 26

Разработка через тестирование (англ. test-drivendevelopment) - техника программирования, при которой модульные тесты для

Разработка через тестирование (англ. test-drivendevelopment) - техника программирования, при которой модульные тесты
программы или её фрагмента пишутся до самой программы (англ. test-firstdevelopment) и, по существу, управляют её разработкой. Является одной из основных практик экстремального программирования.

Слайд 27

Методика разработки через тестирование (Test-DrivenDevelopment, TDD) позволяет получить ответы на вопросы об

Методика разработки через тестирование (Test-DrivenDevelopment, TDD) позволяет получить ответы на вопросы об
организации автоматических тестов и выработке определенных навыков тестирования.
«Чистый код, который работает» - в этой короткой, но содержательной фразе, кроется весь смысл методики разработки приложений через тестирование.

Тест - это процедура, которая позволяет либо подтвердить, либо опровергнуть работоспособность кода.

Слайд 28

Это предсказуемый способ разработки программ. Разработчик знает, когда работу следует считать законченной,

Это предсказуемый способ разработки программ. Разработчик знает, когда работу следует считать законченной,
и можете не беспокоиться о длинной череде ошибок.
У разработчика появляется шанс усвоить уроки, которые преподносит ему код. Если он воспользуется первой же идеей, которая пришла ему в голову, у него не будет шанса реализовать вторую, лучшую идею.
Коллеги по команде могут рассчитывать на разработчика, а он, в, свою очередь, на них.
Разработчику приятнее писать такой код.

Чистый код, который работает, - это цель, к которой стоит стремиться, и этому есть причины:

Слайд 29

Чтобы избавиться от множества проблем, разрабатывают код, исходя из автоматических тестов. Такой

Чтобы избавиться от множества проблем, разрабатывают код, исходя из автоматических тестов. Такой
стиль программирования называется разработкой через тестирование. В рамках этой методики:
Пишем новый код только тогда, когда автоматический код не сработал.
Удаляем дублирование.

Слайд 30

Проектируя код, мы постоянно запускаем его и получаем представление о том, как

Проектируя код, мы постоянно запускаем его и получаем представление о том, как
он работает, это помогает нам принимать правильные решения.
Мы самостоятельно пишем свои собственные тесты, так как мы не можем ждать, что кто-то другой напишет тесты для нас.
Наша среда разработки должна быстро реагировать на небольшие модификации кода.
Архитектура программы должна базироваться на использовании множества сильно связанных компонентов, которые слабо сцеплены друг с другом, благодаря чему тестирование кода упрощается.

Два столь простых правила на самом деле генерируют сложное индивидуальное и групповое поведение со множеством технических последствий:

Слайд 31

Красный - напишите небольшой тест, который не работает, а возможно, даже не

Красный - напишите небольшой тест, который не работает, а возможно, даже не
компилируется.
Зеленый - заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал.
Рефакторинг - удалите из написанного вами кода любое дублирование.

Два упомянутых правила определяют порядок этапов программирования:

Слайд 32

Разработка через тестирование

Не писать код, пока не будет написан автономный тест, который

Разработка через тестирование Не писать код, пока не будет написан автономный тест,
не проходит.
Не писать автономный тест большего объема, чем необходимо для неудачного завершения или неудачной компиляции.
Не писать больше кода, чем необходимо для того, чтобы ранее не проходивший тест завершился успешно.
Написание теста до кода способствует проектированию кода, который было бы удобно вызывать.
Предварительное написание тестов заставляет писать слабо связанные программы!
Тесты могут выступать как чрезвычайно полезная документация. Она всегда актуальна. Она не лжет.

Слайд 33

Приемочные тесты – формальный процесс тестирования, который проверяет соответствие системы требованиям и

Приемочные тесты – формальный процесс тестирования, который проверяет соответствие системы требованиям и
проводится с целью:
определения удовлетворяет ли система приемочным критериям;
вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.

Слайд 34

Приемочное тестирование выполняется на основании набора типичных тестовых случаев и сценариев, разработанных на

Приемочное тестирование выполняется на основании набора типичных тестовых случаев и сценариев, разработанных
основании требований к данному приложению. 
Решение о проведении приемочного тестирования принимается, когда:
продукт достиг необходимого уровня качества;
заказчик ознакомлен с Планом Приемочных Работ (ProductAcceptancePlan) или иным документом, где описан набор действий, связанных с проведением приемочного тестирования, дата проведения, ответственные и т.д.

Слайд 35

Заказчик описывает подлежащие тестированию сценарии после того, как история пользователя (userstory) была

Заказчик описывает подлежащие тестированию сценарии после того, как история пользователя (userstory) была
корректно реализована.
История может содержать один или несколько приемочных тестов – столько, сколько необходимо для проверки работоспособности системы.

Фаза приемочного тестирования длится до тех пор, пока заказчик не выносит решение об отправлении приложения на доработку или выдаче приложения.

Слайд 36

Традиционно приемочные тесты состоят из ряда тестовых сценариев – последовательности действий, выполняемых

Традиционно приемочные тесты состоят из ряда тестовых сценариев – последовательности действий, выполняемых
тестировщиком (или поданных на вход инструмента тестирования), которые проверяют правильность работы приложения.
Наличие автоматизированных приемочных тестов позволяет сосредоточиться на порученной задаче и поддерживать продуктивность на оптимальном уровне. В них применимы те же принципы разработки, управляемой тестами, но на более высоком концептуальном уровне, чем позволяют автономные тесты.

Слайд 37

Парное программирование — техника программирования, при которой исходный код создаётся парами людей, программирующих

Парное программирование — техника программирования, при которой исходный код создаётся парами людей,
одну задачу, сидя за одним рабочим местом.
Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего. При необходимости клавиатура свободно передается от одного к другому. В течение работы над проектом пары не фиксированы: рекомендуется их перемешивать, чтобы каждый программист в команде имел хорошее представление о всей системе. Таким образом, парное программирование усиливает взаимодействие внутри команды.

Слайд 38

Программирование парами (Pair Programming)

Преимущества парного программирования
Любые решения принимаются не одним программистов а

Программирование парами (Pair Programming) Преимущества парного программирования Любые решения принимаются не одним
двумя;
Какую бы часть системы не взять, в ней будут хорошо разбираться как минимум два человека;
В паре партнеры контролируют друг друга – снижение вероятности написания не корректного, не аккуратного кода;
Партнеры в парах постоянно меняются, это дает возможность всем членам команды знать функционал системы

Слайд 39

Отсутствует возможность сосредоточиться. Непрерывно отвлекают.

Недостатки:

Отсутствует возможность сосредоточиться. Непрерывно отвлекают. Недостатки:

Слайд 40

Рефакторинг (Refactoring)

Refactoring – процесс изменения программной системы таким образом, что ее внешнее

Рефакторинг (Refactoring) Refactoring – процесс изменения программной системы таким образом, что ее
поведение не изменяется, а внутренняя структура улучшается.
У каждого программного модуля есть три функции:
та функция, которую он реализует во время выполнения
модуль должен допускать изменение. Почти все модули на протяжении своей жизни изменяются, и задача разработчика – обеспечить возможность и простоту внесения изменения. Модуль, который трудно изменять, следует считать непригодным и нуждающимся в исправлении, даже если он работает.
модуль должен быть доступным для понимания. Разработчики, не знакомые с модулем, должны иметь возможность прочитать и понять его, не прилагая сверхъестественных умственных усилий. Модуль, который не информативен, также непригоден и нуждается в исправлении.

Слайд 41

Простой дизайн (Simple Design)

Цели Simple Design:
Спроектировать систему один раз и на всегда

Простой дизайн (Simple Design) Цели Simple Design: Спроектировать систему один раз и
невозможно. В XP – проектирование происходит постоянно.
Simple Design :
Обеспечение корректного срабатывания всех тестов;
Отсутствие дублирующего кода;
Хорошо выраженные намерения программиста для конкретного участка кода;
Минимальное количество классов и методов;

Слайд 42

Коллективное владение кодом (Collective Code Ownership)

Каждый член команды может вносить изменения в

Коллективное владение кодом (Collective Code Ownership) Каждый член команды может вносить изменения
любой код системы;
Разработчик может выбрать любую задачу. Специалисты по базе данных не обязаны ограничиваться только задачами, связанными с базой.
Специалисты по разработке ГИП могут при желании выбрать задачу, касающуюся базы данных. Хотя на первый взгляд это может показаться неэффективным, но выгода очевидна: чем больше каждый разработчик знает о проекте в целом, тем успешнее и информированнее вся команда.
Добиваемся, чтобы за проект отвечала команда целиком, независимо от специализации.

Слайд 43

Улучшение дизайна

Плохой код не должен доживать до заката. Код все время должен

Улучшение дизайна Плохой код не должен доживать до заката. Код все время
оставаться максимально чистым и выразительным.

Слайд 44

Постоянная интеграция (Continuous Integration)

Интеграция модулей в систему выполняется постоянно, несколько раз в

Постоянная интеграция (Continuous Integration) Интеграция модулей в систему выполняется постоянно, несколько раз
день.
Обеспечение интеграции осуществляется за счет систем совместной работы.

Слайд 45

Заказчик в команде (On-Site Customer)

Постоянная доступность заказчика, который может ответить на возникшие

Заказчик в команде (On-Site Customer) Постоянная доступность заказчика, который может ответить на
вопросы, пускай даже по телефону;
Наличие заказчика в команде позволяет работать с оптимальной скоростью.

Слайд 46

Частые выпуски версий (Small Realize)

Версии должны выпускаться в эксплуатацию, как
можно чаще. Работа

Частые выпуски версий (Small Realize) Версии должны выпускаться в эксплуатацию, как можно
над каждой версией должна
занимать как можно меньше времени. При этом
каждая версия должна быть осмысленной.

Слайд 47

40 – часовая рабочая неделя (40-hour Week)

40 – часовая рабочая неделя (40-hour Week)

Слайд 48

Стандарты кодирования (Coding Standards)

Весь код выглядит так, будто его писал один –

Стандарты кодирования (Coding Standards) Весь код выглядит так, будто его писал один
очень квалифицированный – человек.
Благодаря стандартам:
Члены команды не тратят время на глупые споры о вещах, которые фактически никак не влияют на скорость работы над проектом;
Обеспечивается эффективное выполнение остальных практик.