Постоянно продолжающаяся интеграция

 

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

Однако в ХР:

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

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

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

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

 

Часовая рабочая неделя

 

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

Однако в ХР:

• игра в планирование заставляет вас делать наиболее важную работу в первую очередь;

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

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

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

 

Заказчик на месте разработки

 

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

Однако в ХР:

• представитель заказчика приносит пользу для проекта, так как он пишет функциональные тесты (предприятию-заказчику все равно придется этим заниматься);

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

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

 

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

 

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

Однако в ХР:

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

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

 

Заключение

 

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

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

 

Рис. 4. Диаграмма, иллюстрирующая взаимодействие всех методик

 

Глава 12.

Стратегия менеджмента

 

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

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

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

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

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

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

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

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

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

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

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

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

 

Метрики

 

Основным инструментом оценки в ХР является метрика. Например, отношение ожидаемого времени разработки к календарному времени является базовой мерой оценки в ходе игры в планирование. Эта мера позволяет команде установить скорость проекта (Project Velocity). Если отношение увеличивается (меньшее количество календарного времени для заданного ожидаемого объема разработки), это означает, что работа команды продвигается успешно. Или это может означать, что команда не делает ничего, кроме удовлетворения требований; подобная, с виду вполне благополучная ситуация может стать причиной возникновения проблем в дальней перспективе.

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

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

Со временем метрики теряют актуальность. На практике любая метрика, значение которой приблизилось к отметке 100%, перестает быть полезной. Это замечание, конечно же, не относится к показателю тестов модулей. Этот показатель всегда должен равняться 100%. Однако показатель тестов модулей – в большей степени предположение, а не метрика. Вы не можете отметить на диаграмме, что показатель функциональных тестов равен 97%, имея в виду, что осталось приложить усилия в размере 3%. Если значение метрики приближается к 100%, замените ее другой метрикой, которая, по вашему мнению, снизилась на несколько пунктов.

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

 

Инструктирование

 

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

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

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

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

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

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

• объяснять процесс разработки менеджерам высшего звена.

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

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

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

Роб Мии (Rob Мее) пишет.

 

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

Роб Мии (Rob Мее)

 

 

Слежение

 

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

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

Ведение игры в планирование – это часть слежения. Ревизор должен отлично знать правила игры и быть готовым применить их в различных эмоциональных ситуациях (планирование всегда эмоционально).

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

 

Интервенция

 

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

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

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

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

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

 

Глава 13.