Предисловие

XP рассматривает кодирование в качестве ключевого фактора на протяжении всего проекта. Именно код является связующим звеном в общении между различными командами разделеными географически. Жизненный цикл и поведение сложных объектов определяется посредством тест-кейсов, т.е. опять же через код. Отчеты об ошибках также содержат тест-кейсы, детализирующие проблему. Таким образом вся разработка опирается на код. Однако процедура разработки подразумевает не только «надежное кодирование», но и поставку этого кода в соответствии с графиком, а это уже намного сложнее. Для этого необходимо использовать лучшие методики, и в частности XP, включая unit-тестирование, программирование в парах, и рефакторинг.

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

Вводная часть

Эта книга

Эта книга помогает настроиться на восприятие XP, понять его корни, философию, мифы. Цель ее – помочь сделать вывод о применимости или неприменимости методики XP в вашем проекте. Для тех кто уже использует XP, эта книга позволяет понять его еще лучше.

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

Что такое XP

Что такое XP? XP – это эффективный, гибкий, предсказуемый, научный и в то же время забавный способ разработки программного обеспечения. Кроме того, данный подход характеризуется малым риском.

От других методологий XP отличается:

¨ Использованием короткого цикла разработки с упреждающей обратной связью, конкретной и непрерывной

¨ Инкрементальным подходом в планировании, позволяющим быстро перейти к плану проекта в целом, корректирующемуся на протяжениии всего жизненного цикла проекта

¨ Гибкостью в сроках реализации отдельных функций в соответствии с меняющимися запросами рынка

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

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

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

¨ Надежностью программного продукта, основанной на сочетании краткосрочных «инстинктов» программистов и долгосрочных интересов проекта.

Раздел1. Постановка задачи

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

Глава1. Риск: Основная проблема

Одна из основных проблем разработки програмного обеспечения, это риск.Ниже приведены некоторые примеры рисков:

¨ Сдвиг графика поставки – в день предполагаемой поставки вы сообщаете заказчику, что программное обеспечение будет готово не ранее чем через 6 месяцев

¨ Проект закрыт – после многочисленных сдвигов проект закрыт даже не будучи переданым в производство

¨ Система «прокисла» - программное обеспечение было успешно передано в производство, но через пару лет стоимость изменений и количество ошибок настолько возросло, что система должна быть замещена

¨ Интенсивность дефектов – система передана в производство, но количество дефектов так велико, что ее нельзя использовать

¨ Непонимание требований бизнеса - программное обеспечение передано в производство, но оно не решает тех задач, которые были поставлены первоначально

¨ Изменения требований бизнеса - программное обеспечение передано в производство, но требования ради которых оно было разработано, 6 месяцев назад были заменены другими более актуальными

¨ Наличие неактуальных возможностей – программное обеспечение имеет целый ряд интересных возможностей не нужных заказчику (не приносящих ему денег)

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

Каким же образом XP решает проблему рисков перечисленных выше ?

¨ Сдвиг графика поставки – XP предполагает выполнение проекта в виде коротких релизов продолжетельностью не более нескольких месяцев так, что задержка каждого из них. Внутри каждого релиза XP использует 1-4 недельные итерации по включению функциий, требуемых пользователем , что позволет легко отслеживать текущее состояние дел. Внутри каждой итерации XP планирует отдельные задачи, сроком 1-3 дня каждая. И наконец XP предполагает первоочередную реализацию функций с высшим приоритетом так, что если какая-то функция и будет задержана, то она не будет очень важной

¨ Проект закрыт – XP просит заказчика выбрать наименьший по объему релиз, но имеющий максимальную пользу с точки зрения бизнеса

¨ Система «прокисла» - XP предполагает создание и поддержку всеохватывающего набора тестов, которые проводятся после каждого изменения (несколько раз в день), чтобы гарантировать качество очередного “baseline”. Таким образом система поддерживается в состоянии «постояной готовности».

¨ Интенсивность дефектов – XP предполагает тестирование продукта как со стороны программиста, так и со стороны заказчика, т.е. разраработкой тестов занимаются две независимые стороны.

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

¨ Изменения требований бизнеса – XP предполагает проведение разработки в виде серии коротких релизов так, что количество изменений в рамках одного релиза не так велико. При этом заказчику позволяется оперативно скорректировать набор функций и что особенно ценно заменить, если это необходимо функции еще не реализованные (отнесенные на последующие релизы) новыми функциями.

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

¨ Текучесть кадров – XP предролагает, что именно программисты проводят оценку сроков выполнения работы и тем самым осознанно берут на себя определенную ответственность за своевременное выполнение проектов. При этом программисты систематически проводят анализ графика работы и пересматривают его при необходимости.

1.1. Наша миссия

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

Глава2. Эпизоды разработки

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

Я смотрю на стопку карточек с перечнем задач. Верхняя содержит задачу: «Export Quarter-to-day-Withholding». Я вспоминаю, что на утреннем митинге ты сообщил мне, что закончил программирование процедуры “Quarter-to-day”. Поэтому я спрашиваю тебя (моего товарища по команде) не мог ли бы ты помочь мне с процедурой “Export”.

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

Ты спрашиваешь, «Какие сценарии тестирования (test case)имеются для данной задачи?».

Я отвечаю, «Когда будет запущена процедура экспорта, значения величин в записях должны соответствовать значениям элементов»

«Какие поля должны быть заполнены?» спрашиваешь ты.

«Я не знаю. Давай спросим Эдди.»

Мы прерываем Эдди на 30 секунд. Он объясняет назначение пяти полей, которые интересуют нас.

Затем мы смотрим на структуру уже существующих test-case и обнаруживаем, что часть из них может быть непосредственно использована в нашем случае.

Часть test-case требует небольшой модификации. Кроме того необходимо написать несколько новых test-case. Мы начинаем немедленно готовить набор test-case для тестирования нашей задачи и заканчиваем его в течение часа.

Когда мы пытаемся запустить подготовленные test-case они естественно не идут. Запускаем test-case под отладчиком и быстро находим ошибку. Я занимался исправлением ошибок в коде, а ты пытался объяснить, как можно упростить код. Наконец мне это надоело, я подвинул клавиатуру тебе и предложил делать исправления самому. Наконец все test-case прошли. Кроме того ты переработал еще несколько test-case упростив их.

Мы увидели, что компьютер, на котором проводится интеграция освободился. Мы загрузили последние изменения и получили последний релиз. Затем прогнали все имеющиеся test-case, разработанные нами только-что и те, что были созданы ранее другими членами команды. Все работало. Мы получили новый релиз.

Мы только что описали типичный цикл разработки в рамках XP. Следует отметить, что:

¨ Программирование осуществляется в парах

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

¨ Пары занимаются не только отладкой тестов. Они также проводят постоянный редизайн системы. Изменения касаются не только какой-то одной области. Это может быть анализ, дизайн, интеграция и тестирование всей системы. Работы в каждой области проводятся по мере необходимости.

¨ Интеграция немедленно следует за разработкой, включая интеграционное тестирование.

Глава3. Экономика разработки программного обеспечения

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

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

¨ Тратить меньше, что обычно сложно так как каждый начинает практически с одинаковыми инструментами и уменьем.

¨ Зарабатывать больше, что возможно только при наличии превосходных отделений маркетинга и продажи.

¨ Тратить позднее, а зарабатывать раньше т.е. уделять больше внимания получению денег, чем их трате.

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

3.1. Опции

Существует и другой взгляд на экономику программного продукта – как на набор опций:

¨ Прекращение проекта – всегда можно что-то взять из проекта, даже если он остановлен. И чем больше можно взять, тем лучше.

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

¨ Отсрочка – возможна ситуация, когда вы не инвестируете средства для решения какой-то проблемы, а ожидаете, когда проблема разрешиться сама собой. С точки зрения заказчика более ценен тот менеджер проекта, который может отложить инвестиции, но не потерять возможности сделать это позднее.Чем больше величина отсрочки, и чем большая сумма денег не истрачена, тем лучше.

¨ Рост – если ситуация на рынке благоприятна, то вы должны быть готовы быстро нарастить объемы производства, чтобы использовать создавшуюся ситуацию.Чем быстрее можно увеличть объем и чем дольше это нарастание может продолжаться, тем лучше.

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

При этом следует учитывать пять факторов:

¨ Объем инвестиций, необходимый для реализации данной опции

¨ Цена, которую вы готовы заплатить за то, чтобы данная опция была реализована

¨ Цена опции на данный момент

¨ Количество времени, которое вы готовы потратить на реализацию данной опции

¨ Неопределенность окончательной цены даной опции

Последний фактор наиболее важен так как позволяет предвидеть ситуацию.

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

¨ Точная и регулярная обратная связь о ходе выполнения проекта

¨ Наличие возможностей по значительному снижению числа изменений требований

¨ Небольшие начальные вложения

¨ Возможность двигаться быстрее

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

3.2. Пример

Предположим, что вы в процессе программирования обнаружили, что можете добавить некоторое свойство и стоить это будет вам $10. Вы расчитываете, что эту опции можно будет продать за $ 5. Таким образом, чистая прибыль от реализации данной опции будет $5.

Предположим, что в губине души вы не уверены какова будет реальная потребительная стоимость данной опции для заказчика. Пусть неопределенность в стоимости этой опции составляет 100%. Тогда минимальная стоимость будет равна: $7.5 ( действительно 7.5 + 100%=7.5 + 7.5 = $15).

Допустим, что стомость затрат через год не изменится и будет составлять те же $10.

Как же количественно оценить вариант стратегии: реализовать опцию сейчас или отложить на будущее.

Примем уровень прибыли за 5%. Тогда вы быдите продать данную опцию за $ 7.87 ($7.5 + 5%). Эта величина больше чем $5 (максимальная чистая прибыль). Поэтому более разумно отложить реализацию данной опции на будущее.

Глава4. Четыре переменные

XP предлагает модель процесса разработки, в которой в качестве управляющих выбраны четыре переменные– стоимость, время, качество и рамки проекта (scope).

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

Некоторые заказчики и менеджеры считают, что могут управлять всеми 4-мя переменными. На самом деле необходимо выбрать переменные, подлежащие контролю и проанализировать их влияние на оставшиеся. Если результат не устраивает, можно изменить значения входных переменных или сменить их набор.

4.1. Взаимодействие между перемеными

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

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

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

¨ Рамки проекта – чем уже рамки проекта, тем лучшего качества будет разрабатываемый продукт. При этом полагается, что основные требования заказчика тем не менее выполнены. С другой стороны сужение рамок проекта, позволяет провести разработку быстрее и дешевле.

Нельзя однако упрощать отношения между этими 4-мя переменными. Например, если вы затратите больше денег, то это не значит, что проект можно выполнить существенно быстрее. Известно, что девять женщин не смогут родить ребенка в течение одного месяца. Иногда добавляют, что это не смогут сделать и восемнадцать женщин.

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

Однажды заказчик заявил, что для реализации всех свойств необходимо иметь 40 программистов. Мой ответ был таков, что 40 человек не нужны с самого начала. Можно говорить о одном-двух программистов, затем их число допустимо увеличить до четырех, и только через 2 года следует нанять 40 инженеров.

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

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

4.2. Рамки проекта

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

Программисты зачастую говорят, что заказчики не могут объяснить, что им нужно. И это абсолютная правда. Требования вначале никогда не бывают ясными.

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

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

Однако, если в конце каждой фазы разработки утрачиватся какие-то важные свойства продукта заказчика это не сделает счастливым. Чтобы избежать этого XP использует две стратегии:

¨ Необходимо постоянно практиковаться в проведении оценок с использованием обратной связи по реальным результатам. Првильная оценка уменьшает вероятность потери функциональности.

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

Глава5. Стоимость изменений

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

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

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

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

¨ Простой дизайн, без всякой избыточности – ничего того, что нужно будет только в будущем не должно быть включено в текущий дизайн

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

¨ Постоянная практика в редизайне продукта позволяет вам не бояться модифицировать систему, когда это становиться необходимым

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

Глава6. Учимся управлять автомобилем

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

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

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

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

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

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

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

Эти особенности, рассматриваемые подробно в следующей главе позволяют нам понять состояние программного продукта в процессе его разработки.

Глава7. Четыре особенности

Наша разработка будет успешной, если она проводится учитывая некоторые особенности, служащие как человеческим, так и коммерческим нуждам, это: взаимодействие, простота, обратная связь и смелость.

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

Краткосрочные цели отдельных индивидуумов часто находятся в противоречии с долгосрочными целями общества. Общество давно знакомо с этими проблемами и для их решения опирается на определенный набор ценностей таких как: мифы, ритуалы, систему наказаний и поощрений. Без этих ценностей люди как правило стараются преследовать только свои личные краткосрочные интересы.

Итак XP имеет четыре наиболее ценные особенности:

7.1. Взаимодействие

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

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

Одна из целей XP – поддерживать взаимодействи на должном уровне путем использования таких приемов, которые требуют взаимодействия в обязательном порядке. Это unit-тестирование, программирование в парах, оценка поставленных задач. Все это заставляет программистов, заказчиков и менеджеров общаться друг с другом.

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

7.2. Простота

Вторая особенность XP это простота. Например, тренер спрашивает команду: «Какая простейшая вещь, которая возможно сможет работать?»

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

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

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

7.3. Обратная связь

Третьей особенностью XP является обратная связь. Конкретная информация о текущем состоянии проекта поистинне бесценна. Оптимизм – следует рассматривать как профессиональный риск в профессии программиста. Обратная связь своего рода лекарство от этой болезни.

Обратная связь может работать в различных временных масштабах:

Интервал времени от нескольких минут до дней.

Например, программисты пишут unit-тесты для всех элементов системы, которые могут содержать ошибку. Программисты имеют ежеминутную обратную связь о состоянии системы. Заказчики проводят анализ графика выполнения проекта каждые 2-3 недели, чтобы удостовериться, что все идет по плану. В случае необходимости проводится коррекция графика работ.

Интервал времени от нескольких недель до месяцев

Заказчики и тестеры разрабатывают футкциональные тесты для проверки всех свойств системы. Они получают непосредственую обратную связь о текущем состоянии системы. Заказчики каждые 2-3 недели анализируют план-график выполнения работ и корректируют его при необходимости.

Несколько замечаний по поводу передачи продукта в производство.

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

К сожалению, зачастую выбирается противоположная стратегия. Почему-то считается, что после передачи системы в производство нельзя провести «интересные» изменения, поэтому чем дольше держать систему в состоянии разработки, тем лучше.

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

Обратная связь неразрывно связана с такими особенностями как «Взаимодействие» и «Простота». Чем более информативна обратная связь, тем проще взаиводействие. Если у кого-то есть сомнения в коде, который вы написали и это подтверждается тестами, то это ценнее тысячи часов обсуждений об эстетике дизайна. Чем проще система, тем легче ее тестировать.

7.4. Смелость

Даже если вы следуете изложенным выше принципам: взаимодействие, простота и обратная связь – этого тем не менее недостаточно. Если вы не будете двигаться вперед с максимальной скоростью, кто-нибудь обгонит вас и съест ваш ланч.

Ниже приводится реальный пример смелости. В середине 8-ой итерации, при 10 запланированных команда обнаружила фундаментальную ошибку в архитектуре. Исправление одной ошибки порождало другие, что являлось следствем просчета в архитектуре. Команда сделала все правильно. Как только причина стала ясна, ошибка в архитектуре была исправлена. Это немедленно привело к тому, что половина тестов стала непригодной. Несколько дней концентрированной работы позволило скорректировать все тесты. Это потребовало определенной смелости.

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

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

В отрыве от первых трех особенностей, перечисленных выше «Смелость» ничего не значит. Однако в сочетании с ними ценность ее становится неоспоримой.

«Взаимодействие» поддерживает «Смелость» так как позволяет работать в условиях повышенного риска. Например, после обсуждения кода команда пришла к выводу, что его необходимо заменить. Вы понимаете, что это ведет к дополнительному риску, но сознательно идете на это.

«Простота» так же поддерживает «Смелость». Чем проще система, тем легче вы соглашаетесь на какие-то в ней изменения.

Следует однако понимать, что все наши рассуждения не имеют какой-либо практической ценности, если команда не будет монолитной и каждый будет работать сам по себе.

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

Глава8. Основные Принципы

Четыре особенности, которые обсуждались в предыдущей главе порождают дюжину или около того основных принциповлежпщих в основе нового (XP) подхода разработки.

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

Эти принципы могут помочь нам при выборе альтернативных решений.

8.1. Фундаментальные принципы

Ниже приведем фундаментальные принципы, используемые в XP:

8.1.1. Быстрая обратная связь

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

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

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

8.1.2. Предполагаемая простота

Рассматривайте каждую проблему, как смехотворно простую. Время, которое вы сэкономите на решение 98% проблем, для которых это справедливо даст вам определенный резерв для оставшихся 2%. Опыт показывает, что этот принцип труднее всего принять на веру. Нам традиционно советуют планировать будущее, выполнять дизайн так, чтобы был возможен “reuse”. Вместо этого XP предлагает хорошо работать над разрешением сегодняшних проблем (тестирование, рефакторинг, взаимодействие и т.д.) и верить в свои способности добавить более сложные свойства продукта в будущем, когда это будет необходимым. Подобный подход экономически оправдан.

8.1.3. Инкрементальные изменения

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

8.1.4. Приятие изменений

Лучшая стратегия это та, которая сохраняя основные свойства продукта помогает решить наиболее острые проблемы.

8.1.5. Качественная работа

Никто не любит нестабильную работу. Все хотят делать хорошую работу. Из четырех переменных, предлагаемых в рамках XP модели (рамки проекта, стоимость, время и качество) качество не является полностью независимой. Единственной возможнми оценками могут быть «отлично» и «безумно отлично» в зависимости от того поставлена ли на карту жизнь или нет. Другими словами, если вы не восхищаетесь своей работой и не делаете ее хорошо проект не будет успешным.

8.2. Дополнительные принципы

Ниже приведены несколько дополнительных принципов:

¨ Работать в соответствии с человеческими инстинктами, а не против них

8.2.1. Обучение процессу познания

Вместо того, чтобы пользоваться сентенциями типа: «Александр должен выполнять тестирование так же как и XYZ», необходимо сконцентрировать свои усилия на обучении процедуре тестирования как таковой и какое количество тестов должно быть разработано. Кроме того необходимо определить объем дизайна, рефакторинга и все остального, что должно быть сделано. Некоторые действия необходимо сделать со всей определенностью; необходимость других может быть неочевидной на данный момент. Реально разработчику необходимо принять конкретное решение по каждой рассматриваемой ситуации.

8.2.2. Малые начальные инвестиции

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

8.2.3. Играть на выигрыш

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

Существует разница между игрой, нацеленной на победу и игрой, в которой вы стараетесь не проиграть.

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

8.2.4. Конкретные эксперименты

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

Результатом обсуждения требований также должна являться серия экспериментов. Таким образом, каждое абстрактное решение дожно быть протестировано.

8.2.5. Открытое, честное взаимодействие

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

Если перед тем как ответить на вопрос докладчик ищет глазами, а кто же его слушает, это служит верным признаком того, что с проектом что-то не в порядке.

8.2.6. Работа в соответствии с человеческими инстинктами, а не против них

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

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

8.2.7. Принятие ответственности

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

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

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

8.3. Адаптация к местным условиям

Все, о чем написано в этой книге должно быть адаптировано к конкретным условиям вашей организации и принятому процессу разработки. Это не значит, что данная книга учит вас непосредственно процессу разработки. Она просто помогает понять, что можно сделать лучше. Процесс разработки – это ваша забота и ответственность. И нельзя об этом забывать.

8.4. Некоторые замечания

Отправлясь в путешествие, которое называется XP нельзя двигаться быстро при наличии огромного количества багажа. Необходимо брать в дорогу лишь самое необходимое. Основными критериями, которыми следует руководствоваться при этом являются следующие:

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

8.5. Честные измерения

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

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

Глава9. Назад к основам

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

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

Затем следует определить, что же такое рамки проекта. Какого рода проблемы следует принимать во внимание, а какие можно игнорировать.

Я вспоминаю, когда впервые решил написать программу на Бэйсике, то обнаружил, что не могу написать приложение больше, чем 20 строк. Попытавшись написать текст программы на бумаге перед тем как набивать его на компьютере я пришел к тому же результату написав всего 3 строки. Тут то я понял, что необходимо уметь не только программировать, но знать, что-то еще.

9.1. Кодирование

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

Когда вы занимаетесь кодированием, то имеете возможность лучше разобраться в структуре программы. Кроме того кодирование помогает в общении между членами команды. Например, если кто-то пытается объяснить вам свою мысль, то существует большая вероятность неправильного понимания. Если же вы кодируете вместе, то вам ясно видна логика программы и понятны идеи автора. Подобное взаимодействие легко может перерасти в обучение. Анализируя чужую идею вы можете развить ее и предложить свою. Если вам тяжело объяснить свою идею, то вы можете выразить ее опять же при помощи кода.

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

9.2. Тестирование

Английские философы – позитивисты Локк, Беркли, Юм утверждали, что если чего-то нельзя измерить, то это не существует. Применимо к коду подобное утверждение совершенно верно. Функции программного продукта, которые не могут быть выявлены тестированием – просто не существуют.

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

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

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

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

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

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

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

¨ Unit-тесты - разрабатываются программистами, чтобы убедить себя в том, что отдельные подпрограммы, написанные ими работают так, как они это понимают.

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

9.3. Умение слушать

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

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

Таким образом умение слушать – это третий вид деятельности, характерный для процесса разработки.

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

Однако простая рекомендация типа: «Вы должны слушать друг друга и заказчика» мало, что дает. Необходимо каким-то образом структурировать, создать некий стандарт, описывающий процедуру общения с формальной стороны. Это необходимо для того, чтобы в процессе обсуждений и анализа требований ничего не было упущено. Прежде всего необходимо понять, а что же подлежит обсуждению. При этом все детали должны быть приняты во внимание и достигнута полная ясность по реализации каждой из них.

9.4. Проектирование

Почему нельзя процесс разработки представить просто как последовательность обсуждений, написание test-case их прогон, повторное обсуждение и т.д.?

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

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

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

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

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

Умелый дизайн – ключ к успеху всего проекта.

9.5. Заключение

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

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

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

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

Таким образом, успешному выполнению проекта помогают четыре компонента:

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

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

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

Исходным материалом для разработки программного продукта в рамках XP могут служать:

¨ Четыре особенности – взаимодействие, простота, обратная связь, и смелость

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

Поскольку целью данной книги ставиться объяснение как же все это должно работать ниже приведен перечень основных принципов, лежащих в основе XP:

¨ Деловая игра «Планирование» – быстрое определение рамок следующего релиза путем комбинирования приоритетов бизнеса и технических оценок. Если реальность перечеркивает предварительный план – скорректировать план.

¨ Короткие релизы – быстрый запуск в производство простейшей системы и затем выпуск новых версий в течение очень короткого времени.

¨ Метафора – краткое руководство для команды, представляющее популярное объяснение того как работает система в целом.

¨ Простой дизайн –система должна быть спроектирована настолько просто насколько это возможно на каждый момент времени. Излишняя сложность должна быть устранена как только будет обнаружена.

¨ Тестирование – программисты постоянно обновляют и расширяют набор unit-тестов, которые используются на протяжении всей разработки и должны безошибочно выполняться при любой модификации продукта. Заказчик рарабатывает свои тесты, чтобы подтвердить работоспособность всех заявленых функций.

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

¨ Программирование в парах – кодирование полностью проводиться двумя программистами на ОДНОМ компьютере.

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

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

¨ 40-часовая рабочая неделя – продолжительность рабочей недели не должна превышать как правило 40 часов. Переработка в течение 2-недель подряд недопустима.

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

¨ Стандарты кодирования – программисты пишут программу в соответствии с правилами, обепечивающими взаимодействие посредством кода.

Далее приведенные выше принципы разъясняются более детально.

10.1. Деловая игра «Планирование»

При выполнении проекта соображения бизнеса и соображения техничиские не должны превалировать друг над другом. Разработка программного продукта предполагает диалог, в ходе которого вырабатывается компромисс между Возможным и Желаемым.

¨ Рамки проекта – какими свойства должны реализованы, чтобы система пользовалась спросом? Именно бизнес должен определить ту границу, ниже которой лежит область «Недостаточно», а выше – «Слишком много». Приоритеты – если бы нужно было выбирать между «А» и «В», что с вашей точки зрения должно быть реализовано в первую очередь? Бизнес может ответить на этот вопрос намного лучше, чем программист.

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

¨ Дата выпуска релизов – какие даты выпуска конечной версии продукта или его составляющих наиболее важны с точки зрения запросов рынка.

Бизнес не может принимать свои решения в вакууме. В процессе разработки технические решения являются основой для принятия решений в бизнесе.

При этом технические специалисты должны предоставить ответы на следующие вопросы:

¨ Оценка – сколько времени требуется на реализацию конкретной функции?

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

¨ Процесс – процесс объясняет как должна быть организована работа и команда ее выполняющая. Процесс также предполагает определенную культуру общения внутри команды. Хотя нужно понимать, что написание кода, в процессе разработки является основным – все остальное вторично.

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

10.2. Короткие релизы

Каждый релиз должен быть настолько короток по времени насколько это возможно. При этом он должен содержать функции наиболее ценные с точки зрения бизнеса. Естественно, если присутствует некая фунция, то она должна быть реализована в полном объеме. Нет никакого смысла выпускать релиз, к котором некая фунция реализована только наполовину.

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

10.3. Метафора

Всякий XP –проект должен руководствоваться одной общей метафорой. Метафора позволяет понять работу основных элементов системы и их взаимодействие.

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

10.4. Простой дизайн

¨ Каждая цель является важной для программистов.

¨ Дизайн содержит минимальное количество классов и методов.

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

Это является противоположным тому подходу, которому зачастую следуют разработчики: «Напишите код сейчас, а дизайн для него сделаете завтра».

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

10.5. Тестирование

Любой программный модуль без набора тестов для автоматического тестирования просто не существует. Программисты пишут unit-тесты, чтобы быть более уверенными в работоспособности конкретного модуля. Заказчики пишут функциональные тесты, чтобы убедиться в правильности функционирования программы.

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

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

10.6. Рефакторинг

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

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

Если вы видите, что можно реализовать функцию в течение 1 минуты, но код не будет оптимальным либо вам потребуется 10 минут, чтобы провести детальный дизайн – потратьте 10 минут.

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

10.7. Программирование в парах

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

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

¨ Почему не работают тесты, которые должны работать?

¨ Существуют ли какие-то пути упростить систему в целом и тем самым устранить текущие проблемы

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

Если вы ответственны за выполнение работы в незнакомой для вас области, то целесообразно иметь в паре опытного члена команды.

10.8. Коллективная собственность

Любой, кто видит возможность улучшить какую-то часть кода должен сделать это в любой момент времени.

Это контрастирует с двумя другими моделями ответственности за код: - полное отсутствие ответственности и индивидуальная ответственность.

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

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

Результатом строгого владения кодом стало то, что код перестал быть понимаемым командой поскольку люди с неохотой обращались к владельцу кода, если требовалось его изменение. Таким образом код оставался стабильным, но не мог эволюционировать так быстро как это было необходимо. И если владелец кода покидал команду ….

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

10.9. Непрерывная интеграция

Интеграция и тестирование кода проводится каждые несколько часов, максимум один раз в день. Наиболее простой способ - использовать отдельный компьютер специально предназначенный для этого. Когда этот компьютер свободен очередная пара с кодом, подготовленным для интеграции загружает текущий релиз, загружает подготовленные изменения и прогоняет все тесты, чтобы убедиться в полной работоспособности очередной версии.

Интеграция нового кода обязательно должна закончиться прогоном всех тестов: разработанных ранее и написанных специально для тестирования последних изменений. При этом предполагается предварительная отладка новых тестов.

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

10.10. 40-часовая рабочая неделя

10.11. Представитель заказчика

10.12. Стандарты кодирования

Глава11. Как все это может работать?

11.1. Деловая игра «Планирование»

11.2. Короткие релизы

11.3. Метафора

11.4. Простой дизайн

11.5. Тестирование

11.6. Рефакторинг

11.7. Программирование в парах

Очевидно, что нельзя написать весь код работая в парах. Это будет слишком медленно. А что если два человека не уживаются друг с другом? Тем не менее, соображения, приведенные ниже существенно сглаживают подобную ситуацию:

¨ Наличие стандартов кодирования уменьшает ссоры из-за пустяков

¨ Если каждый участник чувствует себя свежим и отдохнувшим, то это уменьшает возможность непродуктивных …хм….обсуждений

¨ Написание тестов в парах позволяет улучшить взаимопонимание перед тем как взяться за реализацию конкретной опции

¨ Наличие метафоры позволяет участникам «Пары» согласовать свои соображения по наименованиям отдельных модулей и основам дизайна.

¨ Наличие простого дизайна позволяет обоим участникам отчетливо понять текущее состояние проекта.

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

11.8. Коллективная собственность

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

¨ Интеграция проводится в течение достаточно короткого времени, что уменьшает риск возможных конфликтов

¨ Набор прогоняемых тестов постоянно расширяется, поэтому риск возникновения серьезных проблем в коде постоянно уменьшается

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

¨ Следование стандартам кодирования позволяет избежать проблем, связанных с непониманием чужой программы из-за различных стилей программирования

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

11.9. Непрерывная интеграция

Возможно вы не сможете проводить интеграцию каждые несколько часов работы. Кроме того, интеграция требует достаточно большого времени и всегда есть опасность какой-то случайной ошибки, которая затормозит процесс. Тем не менее:

¨ Вы можете прогонять тесты после каждого изменения так, что опасность возникновения ошибок относительно невелика

¨ Программируя в парах, вы уменьшаете вдвое поток изменений, требующих интеграции

¨ Наличие процедуры рефакторинга, позволяет выполнять изменения небольшими порциями, что уменьшает возможность возникновения конфликтов

Со временем вы сможете проводить интеграцию каждые несколько часов. Кроме того, если интеграция не проводится быстро возрастает опасность конфликтов и соответственно затраты на интеграцию.

11.10. 40-часовая рабочая неделя

Возможно вы работаете больше, чем 40 часов в неделю так как не успеваете выполнить свой план. Тем не менее:

¨ Деловая игра «Планирование» помогает вам выполнить наиболее значимую работу

¨ Сочетание деловой игры «Планирование» и тестирования уменьшает вероятность неприятных сюрпризов, связанных с тем, что объем работ существенно превышает запланированный.

¨ Постоянная практика помогает вам программировать с высокой скоростью

Со временем ваша производительность будет такова, что за 40-часовую рабочую неделю вы сможете выполнить весь запланированный объем работ. Кроме того, если члены команды будут слишком усталыми их производительность резко упадет.

11.11. Представитель заказчика

Возможно вам не удастся прикрепить к команде разработчиков представителя заказчика на все время выполнения проекта. Заказчик может использовать его с большей пользой для бизнеса где-нибудь в другом месте. Те не менее:

¨ Представитель заказчика может оказать пользу при работе над проектом разрабатывая функциональные тесты

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

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

11.12. Стандарты кодирования

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

¨ В целом технология XP делает для программистов привлекательной работу в команде, добивающейся успеха

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

11.13. Заключение

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

Перевод глав из книги