Ознакомительная версия.
Наиболее сложный вывод, который я сделал, исполняя роль инструктора, – это то, что вы работаете лучше, если вы работаете не напрямую. Если вы видите ошибку в дизайне, прежде всего вы должны решить, является ли это настолько важным, что требуется ваше вмешательство. Каждый раз, когда вы начинаете влиять на поведение команды, вы делаете ее участников менее самостоятельными. Если вы будете руководить ими в большой степени, они потеряют возможность работать без вас. В результате снизится производительность, ухудшится качество и ослабеет моральный дух. Таким образом, прежде всего вы должны определить, стоит ли обнаруженная вами проблема того риска, который вы принимаете, решая вмешаться в обычный ход дела.
Если все же вы приняли решение, что ваше мнение в данной ситуации весомее, чем мнение команды, то вы должны сделать ваше вмешательство как можно менее разрушительным. Например, вместо того, чтобы самостоятельно изменять дизайн системы, будет лучше, если вы предложите такой тестовый случай, удовлетворить который можно, только изменив дизайн. Это великое искусство – не говорить напрямую, что вы видите, а говорить об этом так, что вся остальная команда тоже начинает видеть это. Однако в некоторых ситуациях вы должны действовать прямо, прямо до грубости. Уверенные в себе, агрессивные программисты ценны именно тем, что они уверены в себе и агрессивны. Однако при этом они становятся беззащитными перед определенного рода недальновидностью, и единственным лекарством в подобных ситуациях является прямой разговор. Когда вы позволили ситуации ухудшиться до той степени, что нежная рука на загривке не дает желаемых результатов, вы должны быть готовыми схватить удила в обе руки и прикрикнуть: А ну, п-шо-о-ол! направляя кого надо в нужную сторону. Но делать это надо только до того момента, пока команда не выедет на нужную дорогу. После этого вы должны вновь ослабить свое влияние.
Здесь я хочу еще кое-что рассказать о роли инструктора. Как инструктор я постоянно обучаю мою команду навыкам ХР – простому дизайну, переработке кода, тестированию. Однако я не считаю, что все это должно входить в определение роли инструктора. Если у вас есть команда, которая в достаточной степени технически самодостаточна, однако нуждается в помощи для организации процесса, вы можете быть инструктором и при этом не быть техническим волшебником. В этом случае вы по-прежнему должны добиваться от всех членов команды, чтобы они слушались вас. Однако когда все уже обладают необходимыми навыками, ваша задача будет заключаться в том, чтобы напоминать им о тех методиках, которые они собрались применять в тех или иных ситуациях.
Роль инструктора теряет свою значимость по мере того, как команда взрослеет и совершенствуется. В соответствии с принципами распределенного управления и принимаемой ответственности сам процесс ХР становится общей ответственностью. На ранних стадиях перехода к ХР просить программистов приходится о многих вещах.
Консультант
В рамках проекта ХР, как правило, не возникает каких-либо специализаций. Каждый член команды работает в паре с любым из других членов, партнеры в парах часто меняются, пары меняют свой фокус в рамках системы с высокой частотой, и каждый член команды при желании может взять на себя ответственность за выполнение любой задачи. По этим причинам в проекте не возникает черных дыр, связанных с тем, что только один или два человека обладают доскональным знанием о той или иной части системы или обо всей системе в целом.
Это является существенным преимуществом, так как команда становится чрезвычайно гибкой. Однако это является также и слабым местом, потому что время от времени команда нуждается в глубоких технических знаниях. Благодаря тому что ХР концентрируется на простоте дизайна, редко когда в процессе разработки возникает надобность в помощи со стороны специалистов, однако время от времени такое случается.
Когда это происходит, команда нуждается в помощи консультанта. Если вы консультант, значит, вы не привыкли работать в рамках ХР. Скорее всего, вы смотрите на то, что делает команда, с некоторым скептицизмом. Однако команда должна обладать четким представлением о том, какую проблему ей требуется решить. Команда должна снабдить вас тестами, которые подскажут вам, когда проблему можно считать решенной (в действительности они будут настаивать на тестах).
Однако при этом они не дадут вам просто уйти и решить проблему самостоятельно. Если команде потребовались глубокие технические знания в некоторой области, значит, скорее всего, это не в последний раз. Теперь задача команды состоит в том, чтобы получить от вас все необходимые знания для того, чтобы решить свою собственную проблему своими силами. Для этой цели один или двое членов команды будут сидеть рядом с вами, когда вы будете решать проблему. Скорее всего, они будут задавать вам множество вопросов. Они будут внимательно оценивать предлагаемый вами дизайн и сделанные вами предположения, при этом они будут стараться понять, нельзя ли сделать что-либо более простое и при этом добиться решения проблемы.
И когда вы наконец решите поставленную перед вами задачу, они, скорее всего, выбросят все, что вы сделали, и попытаются заново решить проблему своими собственными силами. Не переживайте и не расстраивайтесь. В определенной мере они занимаются этим каждый день и, возможно, раз в месяц им приходится выкидывать на свалку результаты дневной работы.
Большой босс
Если вы – большой начальник, значит, команда больше всего желает видеть в вас храбрость, уверенность и время от времени возникающее желание убедиться в том, что команда делает именно то, что она обещала сделать. Поначалу работать с командой для вас будет совсем несложно. Они будут предлагать вам проверять их почаще. В любой ситуации они будут объяснять вам последствия любых изменений. Например, если вы не выделите им нового тестера, о котором они просят, они вам доступно объяснят, как именно и почему сместится график работ и насколько отдалится дата выпуска очередной версии. Если вам не понравится их ответ, они предложат вам уменьшить объем работ по проекту.
Команда ХР стремится к откровенной и правдивой коммуникации. Они не хнычут и не плачутся. Они просто хотят, чтобы вы как можно раньше узнали о том, что реальность начинает отличаться от заранее сформированного плана, благодаря чему у вас будет больше времени, чтобы среагировать должным образом.
Команда желает, чтобы у вас было достаточно храбрости, потому что то, чем они занимаются, иногда выглядит для вас полным безумством, особенно если ранее вы уже работали в области разработки программного обеспечения. Некоторые идеи покажутся вам вполне резонными и оправданными, например ориентация на постоянное и надежное тестирование. Другие методики поначалу покажутся бессмысленными. Например, вам покажутся подозрительными утверждения о том, что программирование в парах является более эффективным методом разработки кода и что постоянный пересмотр и переделка дизайна – это менее рискованный метод проектирования программных систем. Но посмотрите, что выходит из рук этих ребят. Если это не срабатывает, вы можете вмешаться. Однако если у них получается, значит вы в выигрыше, так как у вас есть команда, которая работает с высокой продуктивностью, которая делает заказчиков счастливыми и которая делает все от нее зависящее для того, чтобы у вас никогда не было неприятных сюрпризов.
Это не означает, что у команды никогда не будет сбоев. Время от времени затруднительные ситуации, конечно же, будут возникать. Но вы будете смотреть на то, что у них получается, и для вас не будет иметь значения, что именно они делают для того, чтобы добиться результата. Вы просите у них объяснить вам это, и само по себе объяснение тоже не будет иметь значения, так как именно в такие моменты команда благодаря вам получает возможность остановиться и взглянуть на свою деятельность. Вы находитесь на своем месте не просто так. Команда использует это для своих собственных целей тогда, когда ей это нужно. А когда ей это не нужно, откровенно говоря, команда обходит это.
Глава 23.
Правило 20 на 80
Полная отдача от ХР получается только тогда, когда в силу вступают все методики. Многие практики можно вводить в силу постепенно, однако если все они введены в действие, общий эффект от их использования равен произведению между ними.
Разработчики программного обеспечения привыкли иметь дело с правилом 20 на 80, которое утверждает, что 80% пользы исходит из 20% работы.
Чтобы правило 20 на 80 работало, рассматриваемая система должна обладать элементами управления, в достаточной степени независимыми друг от друга. Например, когда я занимаюсь оптимизацией производительности программы, я могу вносить изменения в несколько разных мест, при этом желательно, чтобы при внесении изменения в одно место это изменение не оказывало бы существенного влияния на все остальные места, в которых я могу повлиять на систему. Я никогда не должен попадать в ситуацию, в которой при изменении одного элемента системы, оказывающего наибольшее влияние на время исполнения программы, я обнаруживаю, что после внесения этого изменения я уже не могу воздействовать на второй по важности элемент системы.
Ознакомительная версия.
