Адаптация ХР для существующего проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Планирование

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

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

Менеджмент

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

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

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

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

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

Разработка

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

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

Проблемы?

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

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

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

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

Глава 21.