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

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

Глава 10. Краткий обзор

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

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

• история об управлении автомобилем;

• четыре ценности – коммуникация, простота, обратная связь и храбрость;

• принципы;

• четыре базовые активности – кодирование, тестирование, слушание и проектирование.

Наша задача – структурировать четыре активности. Мы должны не только структурировать активности, мы должны сделать это в соответствии с длинным списком подчас противоречивых принципов. В то же время мы должны попытаться улучшить экономическую производительность разработки программного обеспечения таким образом, чтобы все получили возможность слушать.

Нет проблем.

Э-э-э...

Целью данной книги является объяснение того, как работают входящие в ХР методики, поэтому в данной главе я бегло перечислю основные группы используемых в рамках ХР методик. В следующей главе я покажу, как подобные смехотворно простые решения могут дать столь значительный результат. Там, где некоторая методика слаба, сила остальных методик покрывает недостатки слабой. В последующих главах некоторые темы будут рассмотрены более детально.

Для начала перечислю все методики.

• Игра в планирование (planning game) – быстро определяет перечень задач (объем работ), которые необходимо реализовать в следующей версии продукта. Для этого рассматриваются бизнес-приоритеты и технические оценки. Если со временем план перестает соответствовать действительности, происходит обновление плана.

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

• Метафора (metaphor) – эта простая общедоступная и общеизвестная история, которая коротко описывает, как работает вся система. Эта история управляет всем процессом разработки.

• Простой дизайн (simple design) – в каждый момент времени система должна быть спроектирована так просто, как это возможно. Чрезмерная сложность устраняется, как только ее обнаруживают.

• Тестирование (testing) – программисты постоянно пишут тесты для модулей. Для того чтобы разработка продолжалась, все тесты должны срабатывать. Заказчики пишут тесты, которые демонстрируют работоспособность и завершенность той или иной возможности системы.

• Переработка (refactoring) – программисты реструктурируют систему, не изменяя при этом ее поведения. При этом они устраняют дублирование кода, улучшают коммуникацию, упрощают код и повышают его гибкость.

• Программирование парами (pair programming) – весь разрабатываемый код пишется двумя программистами на одном компьютере.

• Коллективное владение (collective ownership) – в любой момент времени любой член команды может изменить любой код в любом месте системы.

• Непрерывная интеграция (continuous integration) – система интегрируется и собирается множество раз в день. Это происходит каждый раз, когда завершается решение очередной задачи.

• 40-часовая неделя (40-hour week) – программисты работают не более 40 часов в неделю. Это правило. Никогда нельзя работать сверхурочно две недели подряд.

• Заказчик на месте разработки (on-site customer) – в состав команды входит реальный живой пользователь системы. Он доступен в течение всего рабочего дня и способен отвечать на вопросы о системе.

• Стандарты кодирования (coding standards) – программисты пишут весь код в соответствии с правилами, которые обеспечивают коммуникацию при помощи кода.

В данной главе кратко рассказывается о том, что подразумевается под каждой из этих методик. В следующей главе (Как это работает?) мы рассмотрим взаимосвязи между методиками, благодаря которым слабость одной методики нейтрализуется силой другой методики.

Игра в планирование

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

Представители бизнеса должны принимать решения в следующих областях.

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

• Приоритет – если с самого начала вы можете реализовать только возможности А или В, то какую из них следует реализовать в первую очередь? Ответ на этот вопрос должен быть определен в первую очередь представителем бизнеса, а не программистом.

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

• Сроки выпуска версий – в какие важные даты очередные версии программного продукта должны появляться в производстве?

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

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

• Оценка – как много времени потребуется для того, чтобы реализовать ту или иную возможность?

• Последствия – существует набор бизнес-решений, которые следует