WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 | 2 || 4 |

«Краткое содержание О серии ХР 12 Предисловие 13 Введение 15 Часть 1. Проблема Глава 1. Риск: основная проблема 24 Глава 2. Эпизод из программистской практики 28 Глава 3. Экономика разработки ...»

-- [ Страница 3 ] --

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

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

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

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

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

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

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

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

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

Рассмотрим подробнее, что такое простота и что такое наборы тестов.

Самая простая сработает Давайте сделаем шаг назад и подойдем к решению проблемы постепенно.

В формировании этой стратегии участвуют все четыре ценности.

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

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

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

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

Следуя этим ценностям, мы должны:

• сформировать стратегию проектирования, в результате использова ния которой формируется простой дизайн;

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

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

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

Принятые нами ранее принципы также хорошо воплощаются в страте гии дизайна.

• изначальные инвестиции — прежде чем получить первую отдачу от дизайна, мы должны инвестировать в проектирование си стемы так мало, насколько это возможно.

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

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

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

136 Глава 17 • Стратегия проектирования • Путешествие налегке — стратегия проектирования не должна фор мировать какого-либо «лишнего» дизайна. Дизайн должен быть до статочным для того, чтобы решать наши текущие задачи (необходи мость делать качественную работу), но не более того. Если нам придется постоянно все менять, мы должны иметь возможность на чать с самого простого и постоянно пересматривать то, что у нас имеется на текущий момент.

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

Еще один способ взглянуть на это предлагает заданный себе вопрос:

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

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

Проблема, связанная с этой стратегией, — это неопределенность.

На практике:

• иногда «завтра не наступает никогда» (то есть возможность, кото рую вы спроектировали заранее, больше не интересует заказчика);

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

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

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

Рис. 9. Если с течением времени стоимость изменений остается невысокой Это ведет нас к созданию следующей стратегии проектирования.

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

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

3. Повторяем.

4. Если мы видим возможность упростить наш дизайн, мы немедлен но делаем это. Основные принципы, позволяющие нам определить 138 Глава 17 • Стратегия проектирования степень простоты дизайна, рассматриваются в разделе «Что являет ся самым простым?» Эта стратегия может показаться смехотворно простой. И действитель но, она очень проста. Но она не смехотворна. Используя данную страте гию, вы можете создавать большие сложные системы. Однако это непро сто. Ничего нет сложнее, чем работать в рамках строгих ограничений по времени и при этом всегда находить время «чистить» код.

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

Как работает «проектирование при помощи переработки»?

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

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

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

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

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

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

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

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

Этот дизайн нарушает правило Once And Only Once (OAOO) объект но-ориентированного дизайна (код должен присутствовать в системе один раз и только один раз). Чтобы исправить ситуацию, мы начали работать над формированием дизайна, показанного на рис.

140 Глава 17 • проектирования Рис. 11. Контракт ссылается на класс Function (функция), но не имеет подклассов В течение года, пока мы работали над этой системой, мы сделали мно жество небольших шажков в направлении желаемого дизайна. Мы пере кладывали обязанности подклассов класса Contract (контракт) либо на подклассы Function (функция), либо на подклассы Product В самом конце работы над заказом мы не смогли полностью избавиться от подклассов Contract, однако они стали существенно менее содержа тельными, чем в начале, и было очевидно, что мы держим курс на отказ от их использования. Все это время мы продолжали добавлять в новую функциональность.

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

Что является самым простым?

Таким образом, лучшим является самый простой дизайн, который обес печивает срабатывание всех тестовых случаев. Чтобы сделать это опреде ление эффективным, необходимо объяснить, что именно мы подразуме ваем, когда говорим «самый простой».

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

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

Когда я говорю «самый простой дизайн», я имею ввиду следующие че тыре ограничения в порядке приоритета.

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

2. Система не должна содержать дублирующегося кода (1 и 2 пункты вместе составляют собой правило Once and Only Once).

3. Система должна состоять из наименьшего возможного количества классов.

4. Система должна содержать в себе наименьшее возможное количе ство методов.

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

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

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

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

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

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

Как это может работать?

Традиционная стратегия сокращения с течением времени затрат на разра ботку программного обеспечения заключается в том, чтобы снизить веро 142 Глава 17 • Стратегия проектирования ятность переработки и затраты, связанные с переработкой. ХР предлагает действовать с точностью до наоборот. Вместо того чтобы снижать частоту переработки, ХР наслаждается переработкой. День без переработки — это день без солнечного света. Но как это может обходиться дешевле?

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

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

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

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

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

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

Однако некоторые факторы могут стереть наши выводы в порошок.

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

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

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

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

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

144 Глава 17 • проектирования Еще одним преимуществом визуального проектирования является ско рость. За время, которое требуется для того, чтобы закодировать один ва риант дизайна, вы можете сравнить три визуальных представления раз личных вариантов дизайна.

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

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

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

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

• инвестиции — предполагает, что мы должны рисовать небольшое количество картинок за один раз.

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

• Быстрая обратная — предполагает, что мы должны быстро определить, приближают ли нас картинки к цели или нет.

• Работать в соответствии с человеческими инстинктами — предпо лагает, что мы ожидаем рисование картинок от тех, кому удобнее работать с картинками.

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

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

Если вы имеете дело с разновидностью исходного кода, который луч ше выражается при помощи картинок, тогда определенно вы должны вы ражать его, редактировать его и поддерживать его в виде картинок. Хоро шим примером являются средства из категории CASE, которые позволяют вам целиком и полностью определять поведение всей системы при помо щи графических изображений. Часто эту методику называют генерацией кода (code generation), или автоматической генерацией кода, однако для меня это — язык программирования. В этом случае я возражаю не против картинок, а против попыток хранения одной и той же информации о сис теме в двух разных синхронизированных между собой представлениях.

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

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

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

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

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

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

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

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

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

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

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

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

То же самое можно сказать и о заказчике. Каждый раз, когда заказчик думает о чем-то конкретном, что должна делать программа, он превращает это в еще один кусок уверенности и размещает его внутри программы. Те перь уверенность заказчика тоже находится внутри программы рядом 148 Глава 18 • Стратегия тестирования с уверенностью программиста. Общая уверенность в работоспособности программы со временем все увеличивается и увеличивается.

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

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

Массимо Арнольди (Massimo пишет:

К сожалению, по крайней мере для меня (и не тестирование — это нечто про тиворечащее человеческой природе. Где-то очень глубоко в каждом из нас сидит гряз ная неряшливая свинья, и если ее выпустить на свободу, мы будем писать программы совсем без тестов. Спустя некоторое время после этого у нас внутри победу одержива ет рациональная сторона, мы останавливаемся и начинаем писать Следует обра тить что программирование в паре снижает риск пробуждения свиньи, так как маловероятно, что в одно и то же свиньи проснутся в обоих партнерах временно. (Источник: электронная почта.) Тесты, которые необходимо писать в рамках ХР, являются изолирован ными и автоматическими.

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

[ тестирования | Во-вторых, тесты автоматические. Тесты наиболее полезны тогда, когда | уровень стресса повышается, когда люди работают слишком много, когда I человеческий здравый смысл начинает ослабевать. В подобных ситуациях было бы неплохо обладать быстрым и простым способом проверки рабо I системы. Именно поэтому тесты работают автоматически — вы запускаете их и фактически сразу же получаете короткий односложный ответ: система работает корректно или система работает некорректно.

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

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

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

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

150 Глава 18 • Стратегия тестирования Кто пишет тесты?

Как я уже говорил в самом начале главы, тесты возникают из двух источ ников:

• программисты;

• заказчики.

Программисты пишут тесты для каждого из методов. Тесты, разраба тываемые программистами, называются тестами модулей (unit test). Про граммист создает тест при следующих условиях:

• если интерфейс метода совершенно неясен, вы пишете сначала тест, а затем метод;

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

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

• если позже вы обнаруживаете проблему, вы должны написать тест, который изолирует эту проблему;

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

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

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

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

В данном случае тесты называются Функциональные тесты не обязательно должны в любой момент вре мени срабатывать на все 100%. Дело в том, что эти тесты появляются из источника, который не является источником кода системы. По этой при чине я не могу представить себе универсального способа синхронизации Кто пишет тесты? функциональных тестов и кода системы в такой степени, в какой син хронизированы с кодом системы тесты модулей. В то время как для тес тов модулей может быть только две оценки — 100% или ноль, работоспо собность функциональных тестов, как правило, оценивается в процентном отношении. Ожидается, что спустя некоторое время все функциональные тесты должны срабатывать на все 100%. По мере приближения сроков выпуска очередной версии продукта, заказчик должен категоризировать не срабатывающие функциональные тесты. Некоторые из них являются для него более важными, чем другие, Исправление более важных функ циональных тестов необходимо выполнять в первую очередь.

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

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

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

152 Глава 18 • Стратегия тестирования Другие тесты Функциональные тесты и тесты модулей являются сердцем используемой в рамках ХР стратегии тестирования, однако помимо них существуют так же и другие тесты, использование которых может быть оправданно в опре деленных ситуациях. Команда ХР должна проанализировать, в какой мо мент работы над проектом можно сбиться с пути, при этом необходимо определить, какие новые тесты могут оказаться полезными. Возможно, по требуется использовать следующие разновидности тестов (или любые дру гие тесты, описания которых можно найти в любой посвященной этому во просу книге):

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

• Стресс-тест (stress test) — этот тест разрабатывается для того, что бы сымитировать наиболее высокую нагрузку на систему. Стресс тесты применяются для тестирования сложных систем, для кото рых сложно делать предположения о характеристиках, связанных с производительностью.

• Тест (monkey test) — этот тест предназначен для того, что бы продемонстрировать, что система корректно реагирует на бес смысленный, неподдерживаемый или запрещенный ввод.

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

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

За простой и, очевидно, корректный ответ на вопрос о том, как следует внедрять ХР, я хочу поблагодарить Дона Уэллса (Don Wells).

Выберите самую неприятную для вас проблему.

2. Решите ее, применяя способ ХР.

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

Две очевидные составляющие, с которых можно начать процесс вне дрения, — это тестирование и игра в планирование. Очень многие проек ты страдают от проблем, связанных с низким качеством кода, а также от дисбаланса полномочий между бизнесом и разработчиками. Вторая книга из серии книг, посвященных ХР, под названием Extreme Programming lied: Playing to Win («Применение экстремального программирования: игра чтобы победить») будет посвящена именно этим темам, так как с ния именно этих компонентов ХР удобнее всего приступать к внедрению этой дисциплины.

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

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

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

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

0. Купите какую-нибудь закуску, например шоколадки, сухарики или крекеры.

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

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

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

Я разговаривал со многими командами, которые говорили: «О, да! Мы уже работаем в рамках ХР. У нас все, как в ХР. Все, за исключением тес тирования. Тестирование мы делаем по старинке. Да, и еще у нас есть 200 документ, в котором изложены точные требования заказчи ка. Но все остальное мы делаем в точности как в ХР». Именно поэтому данная глава состоит из нескольких разделов, каждый из которых соот ветствует одной из методик. Если вы уже внедрили у себя одну из мето дик, которая используется в рамках ХР, вы можете игнорировать соответ ствующий раздел. Если вы намерены внедрить у себя какую-то новую методику, обратитесь к соответствующему разделу.

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

• тестирование;

• проектирование;

• планирование;

• менеджмент;

• разработка.

Тестирование Когда вы приступите к приведению существующего кода в соответствие с требованиями ХР, тестирование станет для вас, наверное, наиболее ра зочаровывающим процессом. Код, написанный до того, как вы пишете те сты, кажется пугающим. Вы никогда не знаете, где именно вы находитесь и в каком направлении без опасений можно сделать шаг. «Что, если я от редактирую эту строку? Будет ли это изменение безопасным?» Вы не уве рены в этом.

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

Переход от старого кода к новому коду — это как выход из темноты на солнечный свет. Вы начнете ловить себя на том, что вы избегаете рабо 158 Глава 20 • Адаптация ХР для существующего проекта тать со старым кодом. Вы должны сопротивляться этой тенденции. Един ственным способом обрести контроль над ситуацией в данном яв ляется переработка старого кода в соответствии с новыми более прогрес сивными правилами. В противном случае в темноте начнут скапливаться страшные чудовища, которые в любой момент могут выпрыгнуть наружу.

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

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

• Если вы хотите добавить новую функциональность в не тестирован ный код, вначале напишите тесты для существующей функциональ ности.

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

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

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

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

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

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

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

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

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

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

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

Программисты, неожиданно наделенные новой ответственностью, вряд ли сразу же начнут делать большую работу. Как менеджер, в течение пе 160 Глава 20 • Адаптация ХР для существующего проекта реходного периода вы должны с особенной тщательностью напоминать всем об избранных правилах действий. В состоянии стресса каждый бу дет пытаться вернуться к старому стилю поведения вне зависимости от того, эффективным ли был этот стиль или нет.

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

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

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

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

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

Проблемы? Проблемы?

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

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

Моральный дух будет очень низким.

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

Все же если вы собрались переводить проблемный проект на исполь зование ХР, сделайте это драматическим событием. Полумеры, скорее все го, не помогут — все останется в более-менее прежнем состоянии. Тща тельно проанализируйте весь имеющийся код. Сможете ли вы обойтись без него? Может быть, будет лучше забыть о его существовании? Если да, то выбросите его. Целиком. Разожгите огромный костер и торжественно сожгите старые ленты резервного копирования. Сделайте неделю пере дышки. И после этого начните все заново со свежими силами.

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

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

Исследование Предварительная подготовка к работе — это неестественное состояние системы, и этот этап должен быть завершен как можно быстрее. Какую фразу я услышал совсем недавно? «Если программа начинает эксплуати роваться на производстве, значит, программа завершена». ХР утверждает прямо противоположное. Если программа еще не эксплуатируется на про изводстве, это значит, что мы тратим деньги и при этом не зарабатываем деньги. Я рассматриваю эту ситуацию так, как будто это мой бумажник.

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

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

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

Если недели недостаточно для того, чтобы освоиться с некоторой тех нологией, эту технологию следует классифицировать как рискованную.

Это не означает, что вы не можете ее использовать. Однако вы должны изучить ее более тщательно и рассмотреть возможные альтернативы.

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

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

Если это возможно, они должны имитировать реалистичный уровень на 164 Глава 21 • Жизненный цикл идеального грузки на используемое в производстве аппаратное обеспечение и сеть. Это не означает, что вы должны в лабораторных условиях воспроизвести ко пию промышленной аппаратной платформы. Очень многие оценки мож но сделать на основании расчетов. Например, прикинув примерный объем данных, передаваемых в рамках одного запроса, вы сможете вычислить, какой пропускной способностью должен обладать канал связи. После этого вы можете провести эксперимент, чтобы увидеть, возможно ли реализо вать это на Программисты должны также экспериментировать с архитектурными идеями — как построить систему с несколькими уровнями отмены дей ствий? Попробуйте реализовать этот механизм тремя разными способами и определите, какой из них самый эффективный. Подобные небольшие исследования в области архитектуры особенно важны в случае, если к вам приходит пользователь системы и рассказывает вам истории, кото рые вы не знаете, как реализовать.

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

Пока команда практикуется с технологиями, заказчик практикуется с историями. Не ждите, что этот процесс будет протекать гладко и без запинок. Поначалу истории будут не такими, как вам хотелось бы. Чтобы решить проблему, необходимо обеспечить заказчика быстрой обратной свя зью. Как можно быстрее сообщайте ему вашу оценку предоставляемых им историй. Вы должны сообщить ему, что правильно, а что — нет. Какие данные должны указываться в истории, а какие — нет. В скором времени заказчик научится включать в историю именно то, что нужно программи стам, и не включать в нее то, в чем программисты не нуждаются. Ключе вым является вопрос: «Могут ли программисты с уверенностью оценить усилия, которые потребуются для реализации истории?» Иногда оказы вается, что историю требуется реализовать иначе. Иногда оказывается, что программисты должны на некоторое время приостановить свое жение вперед и заняться экспериментированием.

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

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

Этот процесс описан в разделах, посвященных игре в планирование. Если в ходе исследовательской фазы вы достаточно хорошо подготовились, фаза планирования (формирование графика работ) не займет у вас больше, чем один-два дня.

План работ над первой версией продукта должен быть рассчитан на срок от двух до шести месяцев. За более короткое время вы вряд ли смо жете решить какие-либо значительные проблемы бизнеса. (Однако если вы в состоянии справиться за более короткое время, это просто замеча тельно! В книге Тома Гилба (Tom под названием Principles of Software Management «Принципы менеджмента в области разработки программного обеспечения» содержатся идеи, направленные на сокраще ние даты выхода первой версии продукта.) Если для работы над первой версией требуется больше времени, значит, риск разработки становится слишком большим.

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

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

Подбор историй для последующих итераций целиком и полностью осу ществляется на усмотрение заказчика. При этом должен задать себе вопрос: «Какая возможность системы является для нас наиболее по лезной?» Именно самые полезные возможности включаются в состав сле дующей итерации.

Занимаясь реализацией итераций, вы следите за отклонением от пла на. Потребовалось ли для реализации чего-либо в два раза больше време 166 Глава 21 • Жизненный цикл идеального ХР-проекта ни, чем вы думали? Может быть, вы управились в два раза быстрее? Реа лизованы ли тестовые случаи в срок? Насколько приятно вам работать?

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

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

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

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

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

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

Я уверен в лозунге: «Сделайте, чтобы это заработало, сделайте, чтобы это было написано правильно, сделайте, чтобы это работало быстро» (Make it run, make it right, make it fast). На завершающих стадиях рабо ты над версией наступает отличное время для оптимизации, потому что именно в это время вы получаете максимально возможное количество знаний, внедренных в дизайн системы, вы получаете наиболее реали стичные оценки производственной нагрузки на систему и, кроме того, Обслуживание и поддержка вы скорее всего получаете в свое распоряжение реальную производствен ную аппаратную платформу.

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

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

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

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

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

Разработка системы, которая уже функционирует в условиях реально го производства, — это не одно и то же, что и разработка системы, кото 168 21 • Жизненный цикл идеального рая еще не эксплуатируется на реальном предприятии. Вы более осто рожно относитесь к любым осуществляемым вами изменениям. Вы долж ны быть готовы прервать дальнейшую разработку для того, чтобы прореа гировать на проблемы, которые возникли на производстве. Вы имеете дело с реальными данными, с которыми надо обходиться чрезвычайно осторож но. Вы должны позаботиться о миграции этих данных при любом в доста точной степени значительном изменении дизайна. Если бы фаза предвари тельной разработки не была бы столь рискованной и опасной, вы могли бы оттягивать момент внедрения системы неограниченно долгое время.

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

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

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

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

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

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

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

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

Смерть Хорошо умереть — это также важно, как и хорошо жить. Для ХР это яв ляется такой же истиной, как и для людей.

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

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

Существует также и другая, не очень хорошая причина для смерти — система находится в неудовлетворительном состоянии. Заказчик нужда ется в новых возможностях, а вы не можете добавить их по экономиче Глава 21 • Жизненный цикл идеального ХР-проекта ским соображениям. Количество дефектов может вырасти до величины, которая является неприемлемой.

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

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

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

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

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

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

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

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

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

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

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

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

При этом необходимо, чтобы бизнес-решения принимались отдельно — заказчиком (см. описание игры в планирование).

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

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

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

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

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

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

174 Глава 22 • Роли для людей Как программист ХР вы должны обладать навыками, которые не тре буются или по крайней мере не являются настолько важными в рамках других стилей разработки. Например, программирование в паре — это не такое уж и сложное искусство, им вполне можно овладеть, однако зача стую оно вступает в противоречие с некоторыми особенностями людей, которые, как правило, занимаются программированием. Подозреваю, что я должен выразить свою мысль более простым языком: многие програм мисты являются малообщительными людьми. Конечно, из этого правила есть исключения, кроме того, если ты не чувствуешь себя свободно в об щении, этому не сложно научиться. Однако факт остается фактом: для того, чтобы успешно делать свою работу, вы должны близко общаться с другими членами команды и координировать с ними свою деятельность.

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

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

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

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

• выглядеть глупыми;

• показаться бесполезными;

• стать устаревшими;

• быть недостаточно хорошими.

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

Заказчик Заказчик — это вторая половина базовой двойственности экстремального программирования. Программист знает, как программировать. Заказчик знает, что программировать. Конечно, не с самого начала, но заказчик же лает узнать столь же много, сколь знает программист.

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

Вам придется принимать решения. Для всех тех заказчиков, с которы ми мне приходилось работать, это было наиболее сложным навыком. Все они привыкли к информационным технологиям, которые не приносят и половины той пользы, которую им обещают, а та половина, которую по лучает заказчик, оказывается наполовину неправильной. Заказчики при учены не уступать информационным технологиям ни одной лишней йоты, так как они ожидают, что в любом случае окажутся разочарованными. ХР не работает с такими заказчиками. Если вы являетесь заказчиком ХР, ко манда должна быть способной сказать вам с полной уверенностью: «Вот это более важно, чем вот это», «Эта история слишком большая, ее части 176 Глава 22 • Роли для людей будет достаточно», «Этих нескольких историй вполне достаточно». И когда время начинает поджимать, а оно фактически всегда начинает поджимать, команда будет нуждаться в том, чтобы вы заново обдумали свои требова ния и, возможно, пересмотрели некоторые из них. «Ну что ж, я думаю, что мы вполне сможем обойтись без этого до следующего квартала». Спо собность принимать подобные решения иногда позволит вам сохранить вашу команду и снизить стресс настолько, что они будут способны сде лать для вас все, что в их силах.

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

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

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

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

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

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

Ревизор Как ревизор вы должны быть совестью команды.

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

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

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

178 Глава 22 • Роли для людей Навык, который вы должны развивать в себе больше всех остальных,— это умение собирать необходимую для вас информацию, не беспокоя при этом весь остальной процесс больше, чем это необходимо. Конечно, вы должны немножко побеспокоить работающих соратников для того, чтобы выяснить, сколько времени им в реальности потребовалось для выполне ния той или иной задачи. Однако это необходимо делать так, чтобы люди обращали на это как можно меньше внимания. Вы не должны становить ся для них занозой в мягком месте так, что они будут избегать встречи с вами.

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

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

каким образом ХР используется в других ко мандах;

какие идеи лежат в основе ХР и какое отношение они имеют к текущей ситуации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вард Каннингхэм Cunningham) рассказывал мне о книге, посвя щенной освоению техники горнолыжного спуска. Эта книга называлась The Athletic Skier Половина книги была посвящена настройке и подгонке горнолыжных ботинок таким образом, чтобы вы уверенно стояли на лыжах, чувствовали склон и поддерживали равнове сие во время спуска. После этого в книге говорилось: «Однако после того, как вы выполните 80% всех этих упражнений, вы улучшите вашу ситуа Warren Witherell and Doug Evrard, The Athletic Skier, Johnson Books, 1993.

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

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

Тут возникает дилемма. Не является ли ХР вещью из разряда «все или ничего»? Должны ли вы обязательно следовать каждой из входящих в ХР методик или вы рискуете не заметить вообще никаких улучшений? Вовсе нет. Вы можете получить заметное увеличение продуктивности, даже если вы будете использовать только часть методик ХР. Однако я подозреваю, что вы сможете получить гораздо больше, если вы будете по максимуму использовать все методики в комплексе.

Что делает ХР сложной?

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

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

ХР очень проста в своих деталях, однако ее сложно реализовать на прак тике.

Повторю это снова. ХР легко понять, но сложно реализовать. Именно так. Методики, составляющие ХР, может изучить каждый, кто занимается программированием. Это несложная часть работы. Сложная часть — это собрать и поддерживать в состоянии баланса. Отдельные составные ча сти ХР поддерживают друг друга, однако существует множество проблем, опасений, страхов, событий и ошибок, которые могут вывести процесс из состояния баланса. Причина, по которой вам приходится «жертвовать» наиболее технически опытным членом команды, чтобы он исполнял роль инструктора, состоит в том, что задача поддержки процесса в состоянии баланса — это очень непростая задача.

Я не хочу пугать вас. Я не хочу пугать вас больше, чем это необходимо.

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

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

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

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

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

186 Глава 24 • Что делает ХР сложной?

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

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

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

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

Небольшие проблемы могут привести к значительным эффектам. Про верки и балансирование ХР достаточно надежны, однако процесс может в некоторой степени варьироваться. При этом необходимо учитывать, что даже на первый взгляд незначительные вещи могут привести к значитель ным отклонениям. Когда мы работали над системой управления выплата ми в команде Chrysler C3, у команды возникли проблемы с реализацией работы к сроку. Мы никак не могли добиться того, чтобы наши предвари тельные оценки совпадали с реальностью. В каждой очередной итерации мы каждый раз не успевали реализовывать одну или две истории. Для того чтобы определить корень проблемы, мне потребовалось три или че тыре месяца. Я услышал, как кто-то говорит о «синдроме первого втор ника». Я переспросил, что это означает, и один из членов команды объяс нил мне: «Синдром первого вторника — это ощущение, которое возникает на следующий день после совещания, посвященного планированию оче редной итерации, когда ты приходишь на работу, смотришь на свои исто Что делает ХР сложной? рии и не представляешь себе, как можно реализовать все это за то время, которое было оценено как достаточное».

Дело оказалось в следующем. Изначально я описал процесс следующим образом.

1. Распределение заданий между участниками.

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

3. Перераспределение в случае, если кто-то оказывается перегружен ным.

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

1. Коллективная оценка заданий.

2. Распределение заданий между участниками.

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

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

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

Управление проектами, основанное на незначительных отклонениях то в одну сторону, то в другую сторону, идет в разрез с традиционными ме тодиками управления, основанными на предварительном планировании 188 Глава 24 • Что делает ХР сложной?

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

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

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

Дисциплину ХР не следует применять абсолютно для любых проектов.

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

Я не буду говорить вам нечто вроде: «Не следует использовать ХР для разработки программ управления стратегическими ракетами». Я никогда не разрабатывал программное обеспечение подобного рода, поэтому я не могу сказать вам, на что это похоже. Исходя из этого я не могу сказать вам, будет ли работать ХР в данной ситуации. Однако при этом я так же не могу с уверенностью сказать вам, что в данном случае ХР абсолютно 190 Глава 25 • Когда не следует использовать ХР точно не будет работать. Если вы занимаетесь разработкой программ для стратегических ракет, вы должны самостоятельно решить, подходит ли для вас ХР или нет.

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

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

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

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

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

Иногда очень умные программисты с трудом овладевают ХР. Для очень умных людей тяжело поменять их умение делать правильные дальновид ные предположения на тесную коммуникацию и постоянную эволюцию системы.

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

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

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

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

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

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

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

В подобной ситуации самым правильным решением будет заменить тес тирование длительным предварительным размышлением. Однако в этом случае то, что вы делаете, нельзя будет назвать ХР. Когда я программи рую в рабочей среде подобной категории, я не чувствую себя способным свободно видоизменять дизайн системы;

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

Pages:     | 1 | 2 || 4 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.