Экстремальное программирование (Extreme Programming, XP) возникло как эволюционный метод разработки ПО "снизу вверх". Этот подход является примером так называемого метода "живой" разработки (Agile Development Method). В группу "живых" методов входят, помимо экстремального программирования, методы SCRUM, DSDM (Dynamic Systems Development Method, метод разработки динамичных систем), Feature-Driven Development (разработка, управляемая функциями системы) и др.
Основные принципы "живой" разработки ПО зафиксированы в манифесте "живой" разработки, появившемся в 2000 году.
- Люди, участвующие в проекте, и их общение более важны, чем процессы и инструменты.
- Работающая программа более важна, чем исчерпывающая документация.
- Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта.
- Отработка изменений более важна, чем следование планам.
"Живые" методы появились как протест против чрезмерной бюрократизации разработки ПО, обилия побочных, не являющихся необходимыми для получения конечного результата документов, которые приходится оформлять при проведении проекта в соответствии с большинством "тяжелых" процессов, дополнительной работы по поддержке фиксированного процесса организации, как это требуется в рамках, например, CMM. Большая часть таких работ и документов не имеет прямого отношения к разработке ПО и обеспечению его качества, а предназначена для соблюдения формальных пунктов контрактов на разработку, получения и подтверждения сертификатов на соответствие различным стандартам.
"Живые" методы позволяют большую часть усилий разработчиков сосредоточить собственно на задачах разработки и удовлетворения реальных потребностей пользователей. Отсутствие кипы документов и необходимости поддерживать их в связном состоянии позволяет более быстро и качественно реагировать на изменения в требованиях и в окружении, в котором придется работать будущей программе.
Тем не менее, XP имеет свою схему процесса разработки (хотя, вообще говоря, широко используемое понимание "процесса разработки" как достаточно жесткой схемы действий противоречит самой идее "живости" разработки), приведенную на рисунке.
По утверждению авторов XP, эта методика представляет собой не столько следование каким-то общим схемам действий, сколько применение комбинации следующих техник. При этом каждая техника важна, и без ее использования разработка считается идущей не по XP, согласно утверждению Кента Бека (Kent Beck), одного из авторов этого подхода наряду с Уордом Каннингемом (Ward Cunningham) и Роном Джефрисом (Ron Jeffries).
Живое планирование (planning game)
Его задача — как можно быстрее определить объем работ, которые нужно сделать до следующей версии ПО. Решение принимается, в первую очередь, на основе приоритетов заказчика (т.е. его потребностей, того, что нужно ему от системы для более успешного ведения своего бизнеса) и, во вторую, на основе технических оценок (т.е. оценок трудоемкости разработки, совместимости с остальными элементами системы и пр.). Планы изменяются, как только они начинают расходиться с действительностью или пожеланиями заказчика.
Схема потока работ в XP
Частая смена версий (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 программистов), что подчеркивается и авторами этой методики. Больший размер команды разрушает необходимую для успеха простоту коммуникации и делает невозможным применение многих перечисленных приемов.
Достоинствами XP, если его удается применить, является большая гибкость, возможность быстро и аккуратно вносить изменения в ПО в ответ на изменения требований и отдельные пожелания заказчиков, высокое качество получающегося в результате кода и отсутствие необходимости убеждать заказчиков в том, что результат соответствует их ожиданиям.
Недостатками этого подхода являются невыполнимость в таком стиле достаточно больших и сложных проектов, невозможность планировать сроки и трудоемкость проекта на достаточно долгую перспективу и четко предсказать результаты длительного проекта в терминах соотношения качества результата и затрат времени и ресурсов. Также можно отметить неприспособленность XP для тех случаев, в которых возможные решения не находятся сразу на основе ранее полученного опыта, а требуют проведения предварительных исследований.
XP как совокупность описанных техник впервые было использовано в ходе работы на проектом C3 (Chrysler Comprehensive Compensation System, разработка системы учета выплат работникам компании Daimler Chrysler). Из 20-ти участников этого проекта 5 (в том числе упомянутые выше 3 основных автора XP) опубликовали еще во время самого проекта и в дальнейшем 3 книги и огромное количество статей, посвященных XP. Этот проект неоднократно упоминается в различных источниках как пример использования этой методики [6,7,8]. Приведенные ниже данные собраны на основе упомянутых статей [9], за вычетом не подтверждающихся сведений, и иллюстрируют проблемы некоторых техник XP при их применении в достаточно сложных проектах.
Проект стартовал в январе 1995 года. С марта 1996 года, после включения в него Кента Бека, он проходил с использованием XP. К этому времени он уже вышел за рамки бюджета и планов поэтапной реализации функций. Команда разработчиков была сокращена, и в течение примерно полугода после этого проект развивался довольно успешно. В августе 1998 года появился прототип, который мог обслуживать около 10000 служащих. Первоначально предполагалось, что проект завершится в середине 1999 года и результирующее ПО будет использоваться для управления выплатами 87000 служащим компании. Он был остановлен в феврале 2000 года после 4-х лет работы по XP в связи с полным несоблюдением временных рамок и бюджета. Созданное ПО ни разу не использовалось для работы с данными о более чем 10000 служащих, хотя было показано, что оно справится с данными 30000 работников компании. Человек, игравший роль включенного в команду заказчика в проекте, уволился через несколько месяцев такой работы, не выдержав нагрузки, и так и не получил адекватной замены до конца проекта.
Экстремальное программирование — или, сокращенно, XP — является ответом сообщества программистов на наступление формальных подходов к созданию программных продуктов и призвано вернуть в среду разработчиков дух творчества.
Любая идея, доведенная до абсурда, вырождается в собственную противоположность. Именно такая ситуация складывается в североамериканской промышленности ПО с RAD-средствами разработки. В некоторый момент инструменты, предназначенные для быстрой разработки приложений, стали вытеснять в умах менеджеров все остальное, в том числе разработчиков, заказчиков и сам проект. Неоправданное, гипертрофированное внимание к Процессу в ущерб другим факторам разработки породило массу формальных процедур — но качество полученных продуктов и количество успешных проектов оказалось разочаровывающим.
Противостоять нажиму формализма в работе программистов призвана инициатива группы разработчиков, объединившихся под лозунгом Экстремального Программирования, или XP. И хотя наши разработчики, в основном, еще далеки от проблем своих заокеанских коллег, тем не менее, многие методы с успехом могут быть использованы в нашей практике.
Рассмотрим основные принципы экстремального программирования — с небольшими сокращениями повторений, характерных для американского дефинитивного стиля и с некоторыми дополнениями. Приведенная терминология не всегда соответствует оригинальной и является компиляцией из нескольких источников — однако она передает основные положения и дух экстремального программирования в мере, достаточной для практического использования.
В основе экстремального программирования лежит несколько совершенно конкретных, часто выраженных в численном виде принципов, определяющих, что, когда и как должно делаться. Не воспринимая эти числа как догму, нужно, тем не менее, иметь в виду, что они появились как результат анализа многочисленных успешных и неуспешных проектов, так что для внесения своих поправок, как минимум, должны быть веские основания.
Экстремальный цикл
В основе экстремального программирования — очень короткий, постоянно повторяющийся цикл разработки, составляющий одну-три недели. К концу каждого цикла вы должны иметь полностью рабочий, функциональный и протестированный релиз приложения. Эти циклы должны быть повторяющимися и бесперебойными на протяжении всего проекта.
Предпосылкой для такого режима работы является многократно проверенный факт, что требования редко бывают полными, своевременными и корректными. Иными словами, как бы хорошо вы ни планировали свое приложение, имейте в виду, что его 100% придется переделывать. Более того, его, возможно, придется переделывать даже на завершающей стадии. Не откладывайте переделки на конец работы, делайте их регулярно
.
Как следствие постоянно изменяющихся требований следует другой принцип — позднее принятие решений.
Позднее принятие решений
"Поздний анализ" означает "принимайте конкретные решения только тогда, когда это нужно". В большинстве случаев принятые на начальной стадии решения относительно кода приходилось отменять под влиянием новых требований или других обстоятельств. Не принимайте никаких решений по поводу кода, которого у вас еще нет,— тогда вы развяжете себе руки при реализации текущих задач. Как правило, многое из запланированного оказывается вообще не востребованным. Поэтому планировать кодирование полезно перед началом каждого цикла, но не "раз и навсегда".
С другой стороны, любая начатая часть работы, любая подсистема должна быть закончена прежде, чем начнется работа над другими секциями кода. Такая методика известна как кодирование в глубину.
Кодирование в глубину
Кодирование в глубину (по аналогии с названием метода обхода бинарного дерева) обозначает, что в течение цикла должна быть полностью разработана и протестирована отдельная функциональность и проигнорированы соседние с ней области. Подразумевается, что готовая часть будет включать прикладную логику, пользовательский интерфейс, документацию и набор тестовых заданий для демонстрации работоспособности. Те, кто писали документацию по давно завершенной системе, поймут, насколько это важно.
Легко также впасть в искушение — и вместо насущных и актуальных задач перейти к более отдаленным, но и более легким или удобным частям приложения. Это не правильно — таким образом нарушается принцип работоспособности приложения к концу цикла.
Из готовых, законченных функциональностей складываются истории пользователя, и именно "закрытие" отдельного класса проблем пользователя в самый быстрый срок должно стать основной целью. В противном случае может сложиться ситуация, когда на 90% готовое приложение нельзя показать заказчикам и пользователям, поскольку оно до конца не выполняет ни одной функции.
Помимо концентрации на одной задаче в каждом конкретном цикле важное значение имеют также скорость проекта и фактор загрузки.
Идеальный день разработчика и фактор загрузки
Важным первичным инструментом при расчетах является идеальный день разработчика — то есть день, когда разработчик полностью концентрируется на решении проблем проекта. Это тот срок, в который разработчик может выполнить заданный объем работы при максимальной загрузке. Но было бы большой ошибкой использовать разработчика в этом режиме без крайней необходимости. Ритм работы экстремального программирования отнюдь не экстремален — и даже не должен подходить к отметке "горячо", по крайней мере в начале разработки.
Фактор загрузки — это отношение реальных календарных рабочих дней к идеальным дням разработчика; он характеризует "температуру" разработки. Нормальными считаются факторы от двух до пяти, причем чем больший фактор вы можете позволить — тем больший запас адреналина есть в запасе у вашей команды. Опытные менеджеры используют "три" как стартовое значение, но для новых неосвоенных технологий следует использовать четыре или пять.
Другим временным фактором является скорость проекта.
Скорость проекта
Скорость проекта — это скорость реализации частей программы, определенных для заданного цикла. В качестве основных ориентиров прогресса в разработке выступают реализации историй пользователей.
История пользователей
История пользователей — это аналог Use Case, но имеющий несколько другой оттенок. История пользователя — это компактный документ (предположительно около трех предложений) составленный пользователем и описывающий одну отдельную операцию для данного пользователя в духе "я захожу в программу и...". В отличие от глобальных Use Case, где рассматриваются целые классы пользователей, историю пользователя легко определить, спланировать на конкретный цикл и реализовать в определенный срок. Скажем, "ввод накладной" значительно более ясен и детерминирован, чем "обработка входных документов".
Истории пользователей до последнего момента не принимают детального вида, в духе позднего принятия решений. Реализация истории должна быть ограничена по срокам от одной до трех недель разработки — в противном случае такая история должна быть разбита на более мелкие. Главное — избежать ситуации, когда нечто достаточно долго делается без обратной связи, поскольку все сделанное потенциально является предметом критики и переработки.
План релиза
План релиза, утверждаемый на специальном совещании, дает точный ответ на вопрос, какие именно истории пользователей будут реализованы в данном релизе. Преимущество отдается небольшим инкрементальным релизам. Выбранные к реализации истории транслируются в конкретные задания программирования, такие как создание формы ввода или процедуры запроса к БД. Обычно после нескольких итераций оценки необходимых операций осуществляются очень точно. Как только план выполнения итераций выходит из-под контроля и, по крайней мере, после каждых нескольких удачных итераций повторно собираются совещания по поводу нового плана релиза
.
Выбранные истории являются основой для планов итераций.
План итераций
План итераций ограничивает количество заданий, которые будут выполняться в данной итерации. Выборка производится на основании текущей скорости проекта, то есть на основе оценки идеального срока, умноженного на фактор загрузки. Истории пользователей получают приоритеты внутри цикла и трансформируются в задачи разработки, каждая из которых выполняется в течении одного-трех идеальных рабочих дней.
Если в результате детализации ожидаемое время разработки превосходит время цикла, то некоторые истории переносятся на более поздний срок. Этот эффект снежного кома — вполне обычная практика, поскольку детальные задачи часто распадаются на отдельные части, когда сумма времени для каждой превосходит время для целого.
Не стоит искать виновных в этой ситуации. Такое свойство планирования, как недооценка деталей, это и есть та причина, по которой не производится предварительное планирование. Детальный предварительный план всегда будет пересмотрен в будущем, и поэтому изначально и гарантированно нереален. Планирование производится только на основании предыдущего цикла, с коррекцией скорости проекта и с учетом перенесенных заданий.
Параллельно с выборкой историй пользователей план предусматривает создание набора тестов приемки, которые будут сопровождать код в процессе всех последующих сборок.
Тесты приемки
Тесты приемки создаются на основании историй пользователей и желательно до, а не после создания программных модулей. Без прохождения тестов история не может считаться реализованной ни в какой мере. Фактически, тесты приемки — это те же истории пользователей, но умноженные на возможные ошибки ввода и другие варианты поведения системы, то есть рассматриваются различные варианты конкретной истории. Естественно, что для многократного тестирования необходимо создать автоматические процедуры, вводящие тестовые наборы и ведущие журналы тестов.
Тестирование — не приложение к приложению, а, скорее, наоборот. Часто контроль качества (QA) и составление тестов возлагается на отдельную группу, в состав которой входят представители заказчиков.
Представители заказчиков
Представители заказчиков являются важнейшим звеном успешной разработки по технологии XP. Представители должны не просто контактировать, но буквально физически присутствовать в непосредственной близости и работать в команде разработчиков. Любая проблема должна быть обнаружена на самом раннем этапе, любые пожелания или вопросы должны решаться в реальном времени. Представители заказчика являются источником историй пользователей и тестовых наборов данных, они принимают участие в планировании плана релизов. Кроме того, открытый процесс позволяет инспектировать спорные участки кода в любой момент времени, создавая полностью прозрачную атмосферу между разработчиками и заказчиками.
Хотя это не очевидно, но практически происходит экономия времени заказчика, который все время находится в курсе дел — дополнительно время экономится на детальных спецификациях в начале работы, поскольку любой аспект можно выяснить в процессе работы. Впоследствии не придется инструктировать персонал заказчика, поскольку заказчик уже располагает высококачественными специалистами по данному продукту.
При этом многие документы-посредники становятся ненужными, поскольку многое решается устно, без вовлечения технических и бюрократических механизмов. Значение имеют только конечные результаты работы — но не промежуточные решения и дискуссии, так что нет необходимости документировать все возможные ходы мысли и альтернативы.
Помимо тесного взаимодействия с заказчиками, особого внимания требует и структура группы разработчиков.
Структура группы разработчиков
Для быстрой разработки применяется особая методология организации работы, основанная на теории психологии малых групп. Основной принцип: все разработчики должны быть доступны друг для друга, как организационно, так и физически,— преимущественно желательно располагать группу в одной большой комнате. Структура в группе — одноранговая, то есть существует только профессиональный авторитет, но не административное деление. Доказано, что самая продуктивная обстановка — умеренный шум большой рабочей комнаты, тишина или музыкальное сопровождение дают худшие результаты.
Все производственные вопросы решаются в самой группе, включая используемые методы, инструменты или технологии — эти параметры решения задачи не могут быть навязаны извне: как правило, профессионалы в коллективе решают поставленные задачи оптимально. Крое того, каждый разработчик самостоятельно выбирает подходящие задания, в зависимости от потребности группы и собственных способностей.
Одной из самых качественных технологий программирования на сегодня является парная технология, когда один программист вводит код, а другой при этом смотрит на экран и по ходу корректирует его или задает вопросы относительно реализации. Такая подстрочная критика кода, как показывает практика, в несколько раз повышает качество начального кода, сводя возможность ошибок в начальном коде к минимуму.
Второй принцип — принцип замены партнеров — означает, что пары меняют партнеров один-два раза в течение дня, причем группы работают над различными частями системы. Кажется, что такая метода не позволяет сконцентрироваться на отдельной области — однако практика опровергает это. Концентрация на одной области приводит к укоренению стиля, не всегда оптимального, а отсутствие критики кода может привести "хакера" к тяжело обнаружимым ошибкам. Постоянная смена области приложения, напротив, повышает не только квалификацию в результате обмена опытом, но также и мотивацию повышения собственного мастерства.
В обстановке групповой работы важное значение получает максимальная простота и эффективность используемого кода.
Простота и эффективность используемого кода
Часто предоставленный сам себе разработчик решает использовать новую технологию или инструмент, который, по его мнению, обещает дополнительную производительность или выгоду. На самом деле это редко оправдывается, а в атмосфере, когда ваш код завтра будет прочитан и использован партнерами по команде, у вас просто не остается возможностей для экспериментов за чужой счет. Фактически, все члены команды изначально должны выбрать технологии, которыми владеют все или большинство членов команды. Например, любой разработчик должен уметь программно обрабатывать текстовые файлы, многие знают C++, Java, Perl, SQL и подобные инструменты. Использование редких технологий и инструментов, например сложных, особенно заказных RAD и т.п., может вызвать не только проблемы понимания, но и впоследствии проблемы поддержки. Учитывайте, что освоение сложного инструмента может занять больше времени, чем вся разработка проекта.
К сожалению, программный код, созданный по самым лучшим образцам, со временем имеет тенденцию к деградации под воздействием изменений и исправлений. Поэтому нужно взять за правило производить постоянный и бескорыстный рефракторинг.
Рефракторинг
Это наведение порядка в коде, переработка отдельных файлов и их групп с целью наведения порядка, удаления максимального количества ненужных фрагментов, объединения классов на основе схожей функциональности, коррекция комментариев, осмысленное переименование объектов и так далее. Рефракторинг должен стать лучшим отдыхом программиста в промежутке между решением сложных проблем. Не следует также забывать и о постоянном тестировании модулей.
Тестирование модулей
В отличие от тестов приемки, создаваемых заказчиками и отражающих истории пользователей, тестирование модулей — это сугубо технологическая проверка корректности классов на основании готовой или созданной специально для этих целей автоматизированной системы. Настоящая методика тестирования предусматривает создание сначала тестов и только после — самих классов, что исключает "подгонку" тестов к работающим прототипам и уклонение от острых ситуаций.
Классы-тесты должны быть неотъемлемой частью библиотеки или пакета, их отсутствие вызывает сомнения в работоспособности класса. Создаваемый для приложения код должен проходить все более сложные тесты — и таким образом изначально создаваться для некоторого реального окружения. Игнорирование этого принципа может усложнить тестирование впоследствии, когда уже трудно восстановить работу многих модулей.
Тесты служат четырем целям: во-первых, они, собственно, помогают протестировать функциональность; во-вторых, это естественная форма проектной документации, то есть на вопрос "что делает этот класс" можно ответить "пытается пройти набор функциональных тестов". Третье: тесты — это готовая часть описательной документации, сопровождающей класс после разработки, всегда отвечающая на вопрос "как использовать данный класс". И, наконец, это средство групповой разработки.
Выгода от написания модульных тестов хорошо проявляется в отношении группового авторства: фиксированный набор тестов, созданный модератором класса, всегда может гарантировать, что последующие изменения, произведенные другими членами команды, по-прежнему позволяют классу удовлетворять тестам.
Групповое авторство
Одной из проблем программирования является недоступность по той или иной причине разработчика определенного фрагмента кода, в результате чего его поддержка становится сложной или невозможной. Многие заказчики и группы попадали и попадают в зависимость от "гуру" — и всегда с негативными последствиями.
В обстановке, когда "все делают все", идеи свободно высказываются и распространяются в группе. Более того, каждый может вносить изменения в любую строку кода. Это сложно понять с первого раза, отсутствие одного "супервизора" может сбить с толку — но это работает. По крайней мере, вполне распространена ситуация, когда весь коллектив выполняет одно неверное указание системного архитектора. Зависимость группы от одного, даже высококвалифицированного человека — весьма опасный путь. Участие в обсуждении архитектуры всех сотрудников не только повышает самооценку, улучшает квалификацию, но и приводит к значительно лучшим результатам разработки.
Коллектив, оказывается, способен самостоятельно выработать единое мнение и распределить авторитет и ответственность, пользуясь естественными механизмами человеческой психики. И поскольку каждый принимает участие в обсуждении архитектурных и организационных вопросов, то вполне логично, что и собственность на полученный продукт будет коллективной.
Так, начав с технических и организационных проблем, мы дошли до вопросов самореализации, развития личности и новой социальной модели. Как видите, Экстремальное Программирование является весьма исчерпывающей системой ценностей, и вы вполне можете применить ее к своей специфике.
