Экстремальное программирование
Экстремальное программирование (Extreme Programming, XP) возникло как эволюционный метод разработки ПО «снизу-вверх». Этот подход является примером так называемого метода «живой» разработки (Agile Development Method). В группу «живых» входят, помимо экстремального программирования, методы SCRUM, DSDM (Dynamic Systems Development Method, Метод разработки динамичных систем), Feature-Driven Development (Разработка, управляемая характеристиками результата) и пр.
Основные принципы «живой» разработки ПО зафиксированы в манифесте «живой» разработки [3].
· Люди их общение более важны, чем процессы и инструменты
· Работающая программа более важна, чем исчерпывающая документация
· Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта
· Отработка изменений более важна, чем следование планам
Тем не менее, XP имеет свою схему процесса разработки (хотя широко используемое понимание «процесса разработки» противоречит «живости» разработки).
Рисунок 4. Схема процесса XP.
По утверждению авторов XP, эта методика представляет собой использование комбинации следующих техник (при этом каждая техника важна, и без ее использования разработка считается идущей не по XP).
· Живое планирование (planning game)
Его задача как можно быстрее определить объем работ, который нужно сделать до следующей версии ПО. Решение принимается на основе, в превую очередь, бизнес-приоритетов заказчика и, во-вторую, технических оценок. Планы изменяются, как только они начинают расходится с действительностью или пожеланиями заказчика.
· Частая смена версий (small releases)
Самая первая работающая версия должна появиться как можно быстрее, и тут же должна начать использоваться. Следующие версии подготавливаются через достаточно короткие промежутки времени.
· Метафора (metaphor) системы
Метафора в достаточно простом и понятном команде виде должна описывать основной механизм работы системы.
· Простые проектные решения (simple design)
В каждый момент времени система должна быть сконструирована так просто, насколько это возможно. Не надо добавлять функции «заранее» — только после ясной просьбы об этом. Вся лишняя сложность удаляется, как только обнаруживается.
· Разработка на основе тестирования (test-driven development)
Разработчики сначала пишут тесты, потом пытаются реализовать свои модули так, чтобы тесты срабатывали. Заказчики заранее пишут тесты, демонстрирующие основные возможности системы, чтобы можно было увидеть, что система действительно заработала.
· Постоянная переработка (refactoring)
Программисты постоянно перерабатывают систему для устранения излишней сложности, увеличения понятности кода, повышения его гибкости, но не изменяя его поведения, что проверяется прогоном тестов. При этом предпочтение отдается более элегантным и гибким решениям, по сравнению с просто дающими нужный результат.
· Программирование парами (pair programming)
Весь код пишется двумя программистами на одном компьютере. Объединение в пары произвольно и меняется от задачи к задаче. Тот, в чьих руках клавиатура, пытается наилучшим способом решить текущую задачу. Второй программист обдумывает последствия, новые тесты, менее прямые, но более гибкие возможности решения.
· Коллективное владение кодом (collective ownership)
В любой момент любой член команды может изменить любую часть кода, но он же несет ответственность за эти изменения.
· Постоянная интеграция (continuous integration)
Система собирается и проходит интеграционное тестирование как можно чаще, по несколько раз в день, каждый раз, когда пара программистов оканчивает реализацию очередной функции.
· 40-часовая рабочая неделя
Сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа 2 недели подряд — это истощает программистов и делает их работу значительно менее продуктивной.
· Включение заказчика в команду (on-site customer)
В составе команды разработчиков постоянно находится представитель заказчика, который доступен в течении всего рабочего дня и способен отвечать на все вопросы о системе.
· Использование кода как средства коммуникации
Код рассматривается как важнейшее средство общения внутри команды. Ясность кода — один из основных приоритетов. Следование стандартам кодирования, обеспечивающим такую ясность, обязательно. Такие стандарты, помимо ясности кода, должны обеспечивать минимальность выражений (запрет на дублирование кода и информации) и должны быть приняты всеми членами команды.
· Открытое рабочее пространство (open workspace)
Команда размещается в одном, достаточно просторном помещении, для упрощения коммуникации и возможности проведения коллективных обсуждений при планировании и принятии важных технических решений.
· Изменение правил по необходимости (just rules)
Каждый член команды должен принять перечисленные правила, но при возникновении необходимости команда может поменять их ,если все ее члены пришли к согласию по поводу этого изменения.
Как видно, XP рассчитано на использование в рамках небольших команд (не более 10 программистов) , что подчеркивается и авторами этой методики, больший размер команды разрушает легкость коммуникации.
Литература
[1] W. W. Royce. Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, pp. 1–9, August 1970.
Переиздана: Proceedings of the 9th International Software Engineering Conference, Computer Society Press, pp. 328–338, 1987.
[2] Kroll, The Spirit of the RUP. www-106.ibm.com/developerworks/rational/library/ content/RationalEdge/dec01/ TheSpiritoftheRUPDec01.pdf
[3] http://www.agilemanifesto.org/
[4] И. Соммервилл. Инженерия программного обеспечения. Вильямс, 2002.
[5] У. Ройс. Управление проектами по созданию программного обеспечения. М., Лори, 2002.
[6] А. Якобсон, Г. Буч, Дж. Рамбо. Унифицированный процесс разработки программного обеспечения. Питер, 2002.
[7] Э. Дж. Брауде. Технология разработки программного обеспечения. Питер, 2004.
[8] К. Бек. Эктремальное программировнаие. Питер, 2002.
[9] I. Jacobson, M. Christenson, P. Jonsson, G. Overgaard. Object-Oriented Software Engineering. A Use Case Driven Approach. Addison-Wesley, 1994.