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

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

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

Каким образом ХР снижает перечисленные ранее риски?

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

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

• Система теряет полезность – в рамках ХР создается и поддерживается огромное количество тестов, которые запускаются и перезапускаются после внесения в систему любого изменения (несколько раз на дню), благодаря этому удается тщательно следить за качеством разрабатываемой программы. ХР постоянно поддерживает систему в превосходном состоянии. Дефектам просто не дают накапливаться.

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

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

• Изменение характера бизнеса – в рамках ХР цикл работы над очередной версией программы существенно укорачивается. Таким образом, ко времени выхода очередной работоспособной версии программного продукта бизнес не успевает претерпеть существенных изменений. В процессе работы над очередной версией заказчик может попросить отказаться от разработки некоторой функциональности и вместо нее добавить в программный продукт другие, совершенно новые возможности. Команда разработчиков даже не обратит внимания на то, работает ли она над реализацией новых программных механизмов, или осуществляется разработка возможностей, определенных еще несколько лет назад.

• Недостаток возможностей – в рамках ХР осуществляется реализация только наиболее высокоприоритетных задач.

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

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

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

Если мы признаем, что риск является основной проблемой, которую требуется решить, то в каком месте следует искать решение этой проблемы? Перед нами стоит задача сформировать стиль разработки программного обеспечения, который позволил бы существенно снизить все перечисленные риски. Кроме того, мы должны как можно понятнее объяснить эту дисциплину программистам, менеджерам и заказчикам. Также мы должны сформировать набор рекомендаций, позволяющих адаптировать данную дисциплину для конкретных локальных условий (другими словами – определить, что в этой дисциплине является незыблемым, а что можно варьировать в зависимости от конкретных обстоятельств).

Именно об этом пойдет речь в первой и второй частях книги. Шаг за шагом мы тщательно изучим каждый из аспектов проблемы, сформируем круг вопросов, на которые нам предстоит найти ответ, а затем мы решим проблему. Мы начнем с рассмотрения базовых предположений, а затем получим решение, которое будет диктовать, каким именно образом должна осуществляться разнообразная деятельность (планирование, тестирование, разработка, дизайн и внедрение), связанная с разработкой программного продукта.

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

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

Я смотрю на мой набор карточек с задачами. На самой верхней из них написано: Экспорт значения квартальных издержек на момент обращения к системе. Я вспоминаю, что на сегодняшнем утреннем совещании ты сообщил присутствующим, что завершил блок вычисления значения квартальных издержек. Я обращаюсь к тебе (моему гипотетическому соратнику) с вопросом, не найдется ли у тебя времени помочь мне с разработкой блока экспорта. Ты отвечаешь: Конечно! Это одно из основных правил ХР: если к тебе обращаются с просьбой о помощи, ты обязан ответить да. Таким образом мы становимся партнерами по программированию в паре.

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

Ты спрашиваешь у меня: Как выглядят тестовые случаи для этой задачи?

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

Ты спрашиваешь: Какие поля требуется заполнить?

Я не знаю, надо спросить у Эдди.

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