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

Основные принципы «живой» разработки:

1. Люди, участвующие в разработке проекте. Более важно их общение, чем процессы и инструменты.

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

3. Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта.

4. Отработка изменений более важна, чем следование планам.

Agile Development Method, SCRUM, DSDM (Dynamic Systems Development Method), Future-Driven Development.

«Живые» методы позволяют большую часть усилия разработчиков сосредоточить на задачах разработки и удовлетворении реальных потребностей пользователей. Отсутствие множества документов и необходимости поддерживать их в связанном состоянии – позволяет быстро и качественно реагировать на изменения. По утверждению авторов XP, эта методика представляет собой не столько следование каким-то схемам, сколько применение комбинаций следующих техник (каждая техника важна – без их использования разработке идёт не по принципу XP):

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

2. Частая смена версий. Самая первая работающая версия должна появиться как можно быстрее и тут же должна начать использоваться. Следующие версии подготавливаются через достаточно короткие промежутки времен.

3. Метафора. Достаточно в простом и понятном виде должна описывать основной механизм работы системы. Это напоминает архитектуру, но должно быть гораздо проще.

4. Простые проектные решения. В каждый момент времени система должна быть сконструирована настолько просто насколько это возможно. Не надо добавлять функций заранее (только после явной просьбе об этом).

5. Разработка на основе тестирования. Разработчики сначала пишут тесты, потом пытаются реализовать свои модули так, чтобы тесты срабатывали.

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

7. Программирование парами. Кодирование выполняется двумя программистами на одном компьютере. Объединение в пары произвольно и меняется от задачи к задаче. Тот, в чьих руках клавиатура, пытается наилучшим способом реализовать текущую задачу, второй – анализирует работу первого и даёт советы, обдумывает последствия тех или иных решений, предлагает альтернативные идеи.

8. Коллективное владение кодом. В любой момент времени любой член команды может изменить любую часть кода. Никто не должен выделять свою собственную область ответственности. Команда отвечает за весь код.

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

10. 40-а часовая рабочая неделя. Сверхурочная работа – признак больших проблем в проекте. Сверхурочные работы могут быть не более двух недель подряд, так как это не продуктивно.

11. Включение заказчиков в команду. В составе команды разработчиков постоянно находится представитель заказчиков, который доступен в течение всего рабочего дня и способен отвечать на все вопросы о системе.

12. Использование кода как средства коммуникации. Код рассматривается как важнейшее средство общения в команде. Ясность кода – один из основных приоритетов. Такие стандарты должны обеспечивать минимальность выражений и должны быть приняты всеми членами команды.

13. Открытое рабочее пространство. Команда размещается в одном просторном помещении для упрощения коммуникаций и проведений коллективных обсуждений.

14. Изменение правил по необходимости. Каждый член команды должен принять перечисленные правила, но при необходимости, команда может поменять их, если все её члены пришли к согласию.

XP рассчитано на использование в небольших командах. Большой размер команды разрушает, необходимое для успеха, простоту коммуникаций и делает невозможным применения многих перечисленных приёмов.

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

Минусы XP: невыполнимость больших и сложных проектов; невозможно планировать сроки и трудоёмкость на долгую перспективу; невозможно предсказать результаты длительного проекта в терминах соотношения качества результата и затраченных ресурсов и времени; не приспособленность для тех случаев, в которых возможное решение не находится сразу на основе ранее полученного опыта, а требует проведения предварительных исследований.