Глава 12.
Стратегия менеджмента
Мы будем осуществлять управление всем проектом, используя при этом базовые приемы бизнес-менеджмента, – поэтапная поставка, быстрая и надежная обратная связь, ясная взаимосвязь бизнес-требований к системе, а также использование специалистов для решения специализированных задач.
Дилемма менеджмента состоит в следующем. С одной стороны, было бы неплохо, если бы все решения принимал менеджер. При этом не приходится тратить ресурсы на коммуникацию, так как существует только один человек. Существует один человек, который отвечает за высший менеджмент. Существует один человек, который обладает видением. Никому больше не надо ничего знать, так как все решения принимает только один человек.
Мы знаем, что эта стратегия не срабатывает, так как ни один человек в мире не знает достаточно для того, чтобы принимать качественные решения во всех областях. Стратегии управления, сбалансированные в сторону централизованного контроля, также сложно реализовывать, так как при этом возникает чрезмерная нагрузка на тех, в отношении которых выполняется управление.
С другой стороны, прямо противоположная стратегия также не срабатывает. Вы не можете позволить кому угодно делать, что ему вздумается, без какого-либо надзора. Люди начнут действовать в разнобой. Требуется кто-то, кто обладал бы более общим взглядом на проект и мог бы повлиять на его развитие в случае, если работа команды отклоняется от намеченного курса.
И вновь мы должны вернуться к принципам, которые помогут нам проложить путь между двумя крайностями.
• Принимаемая ответственность, – в соответствии с этим принципом обязанность менеджера состоит не в том, чтобы назначить ту или иную работу, тому или иному человеку, а в том, чтобы указать команде на необходимость выполнения этой работы.
• Качественная работа – предполагает, что взаимодействие между менеджерами и программистами должно основываться на доверии, так как программисты хотят делать свою работу хорошо. С другой стороны, это не означает, что менеджер может вообще ничего не делать. Однако необходимо понимать разницу между фразами: Я стараюсь заставить этих ребят делать свою работу хорошо и Я должен помочь этим ребятам делать свою работу еще лучше.
• Постепенное изменение – предполагает, что менеджеры не выдают программистам в самом начале работы над проектом толстое описание внутренней политики, в рамках которой следует выполнять работу, а управляют процессом разработки в течение всего времени работы над проектом.
• Локальная адаптация – предполагает, что менеджеры должны взять на себя адаптацию ХР к локальным условиям, анализируя моменты, в которых культура ХР конфликтует с культурой компании, и формируя решения проблем в случае несоответствия.
• Путешествие налегке – предполагает, что менеджер не создает чрезмерной лишней нагрузки на проект (например, длительные совещания с обязательным присутствием всех членов команды или бесконечные продолжительные доклады о текущем состоянии проекта). Любая просьба, которую менеджер может адресовать программисту, должна требовать не очень много времени для исполнения.
• Откровенные оценки – предполагает, что любые метрики, собираемые менеджером, должны находится на реалистичном уровне точности. Не пытайтесь определять время с точностью до секунды, если у ваших часов есть только часовая и минутная стрелки.
Стратегия, которую можно сформировать на основании всего перечисленного, ближе к децентрализованному принятию решений, чем к централизованному контролю. Работа менеджера – вести игру в планирование (Planing Game) для того, чтобы собирать метрики, делать так, чтобы эти метрики были наблюдаемыми для тех, чья работа подвергается анализу и оценке, и время от времени вмешиваться в ситуации, в которых принятие решения распределенным образом невозможно.
Средой отражения состояния метрик является большая наглядная диаграмма (Big Visible Chart). Вместо того чтобы посылать всем членам команды электронное письмо (которое зачастую будет ими игнорироваться), менеджер должен периодически (не реже чем раз в неделю) обновлять видимую для всех диаграмму. Зачастую подобное вмешательство просто необходимо. Вы полагаете, что написано недостаточное количество тестов? Покажите это на диаграмме и обновляйте этот показатель каждый день.
Не следует включать в состав диаграммы чрезмерно большое количество метрик. Будьте готовы убрать с диаграммы метрики, которые уже отслужили свою службу. Как правило, команда в состоянии следить одновременно за тремя-четырьмя показателями.
Со временем метрики теряют актуальность. На практике любая метрика, значение которой приблизилось к отметке 100%, перестает быть полезной. Это замечание, конечно же, не относится к показателю тестов модулей. Этот показатель всегда должен равняться 100%. Однако показатель тестов модулей – в большей степени предположение, а не метрика. Вы не можете отметить на диаграмме, что показатель функциональных тестов равен 97%, имея в виду, что осталось приложить усилия в размере 3%. Если значение метрики приближается к 100%, замените ее другой метрикой, которая, по вашему мнению, снизилась на несколько пунктов.
Все это не означает, что вы можете управлять проектом ХР при помощи чисел. Напротив, числа в данном случае – это способ мягко и непринужденно сообщить людям о необходимости изменений. Для менеджера ХР наиболее чувствительным барометром необходимости изменений является внимательное слежение за его собственными ощущениями: физическими и эмоциональными. Если утром, когда вы садитесь в свою машину, ваш желудок завязывается узлом, это значит, что с вашим проектом происходит что-то неправильное и ваша работа состоит в том, чтобы что-то изменить.
Термины ведущий программист или системный архитектор рождают в голове видение изолированного гения, который принимает важные решения о проекте. Инструктор ХР – это прямо противоположное понятие. Инструктор ХР тем лучше, чем меньше он делает технических решений: его работа состоит в том, чтобы помогать другим людям принимать хорошие решения.
Инструктор не принимает на себя ответственность за множество технических задач. Скорее, его обязанности заключаются в следующем:
• быть доступным в качестве партнера по разработке, особенно для новичков, которые только начинают брать на себя ответственность за решение сложных технических задач;
• видеть долгосрочные цели переработки кода и стимулировать мелкомасштабную переработку для того, чтобы частично способствовать достижению этих целей;
• помогать программистам индивидуальными техническими навыками, например тестированием, форматированием и переработкой;
• объяснять процесс разработки менеджерам высшего звена.
Однако, наверное, самой главной обязанностью инструктора является покупка игрушек и еды. Проекты ХР похоже притягивают к себе игрушки. Консультанты часто рекомендуют использовать обычные головоломки для стимулирования побочных мыслительных процессов. Однако в ХР игрушка необязательно должна быть головоломкой. Инструктор использует игрушки для того, чтобы глубоко и продуктивно воздействовать на процесс разработки. Например, во время работы над проектом Chrysler СЗ совещания о проектировании зачастую тянулись в течение многих часов и их участники все никак не могли прийти к приемлемому решению.
Чтобы решить проблему, я купил обычный кухонный будильник и заявил, что ни одно совещание не может тянуться более 10 минут. Я не уверен в том, что этот будильник был когда-либо использован по прямому назначению, однако его видимое присутствие напоминало всем о том, что надо внимательно следить за ходом дискуссии. Если обсуждение переставало быть результативным, все глядели на будильник и понимали, что пора пойти и написать какой-либо код для того, чтобы проверить свои доводы на деле.
Еда также является отличительным признаком всех проектов ХР. Есть нечто значительное в том, что вы преломляете хлеб в компании со своими соратниками. Если во время разговора вы что-то жуете, дискуссия начинает идти совсем по-другому. Поэтому в ХР-проектах еда постоянно разложена повсюду. Лично я рекомендую шоколадные батончики Frigor Noir, если конечно, вы сможете их раздобыть, однако я наблюдал, что некоторые проекты вполне сносно выживают на палочках из лакрицы Twizzler. Полагаю, что вы в состоянии разработать свое собственное локальное меню.
Роб Мии (Rob Мее) пишет.
Слежение за ходом дел в ХР осуществляет ревизор (tracker). Ревизор собирает сведения о состоянии метрик, которые отслеживаются в данный момент, кроме того, он следит за тем, чтобы все члены команды знали о том, какие метрики в данный момент отслеживаются (также он напоминает о ранее сделанных предположениях и оценках).
Ведение игры в планирование – это часть слежения. Ревизор должен отлично знать правила игры и быть готовым применить их в различных эмоциональных ситуациях (планирование всегда эмоционально).
Слежение должно осуществляться без лишних трудозатрат и неудобств. Если ответственное лицо по два раза на дню будет спрашивать у программистов о текущем состоянии их дел, в скором времени программисты начнут уклоняться от такого контроля. Напротив, ревизор должен экспериментировать, чтобы выяснить, какой минимальный объем измерений необходимо выполнить для того, чтобы при этом не утратить эффективности и актуальности этих измерений. Сбор реальных данных о разработке дважды в неделю – этого вполне достаточно. При более интенсивных измерениях вы вряд ли получите лучшие результаты.
Прежде всего менеджер должен внимательно проанализировать ситуацию, пытаясь понять, существовало ли что-либо, о чем необходимо было знать ранее или что необходимо было бы сделать ранее для того, чтобы полностью избежать возникновения проблемы. Время, когда требуется вмешательство менеджера, это не время надевать белые доспехи и вскакивать на боевого коня. Скорее, это время, когда надо прийти к команде и сказать: Я не могу понять, как я позволил этому произойти, но сейчас я вынужден сделать то-то и то-то. Смирение – основное правило для интервенции.
Одной из причин, достаточно серьезных для того, чтобы вмешаться в процесс разработки, является изменение в составе команды. Если член команды не справляется со своими обязанностями, менеджер вынужден попросить его уйти. Подобные решения лучше принимать раньше, чем позже. Как только вы не можете представить себе ситуацию, в которой изучаемый вами субъект мог бы оказать поддержку и не был бы обузой, вы должны сделать свой ход. Дальнейшее ожидание только лишь усугубит проблему.
Несколько более приятной обязанностью менеджера является вмешательство в момент, когда работа команды требует изменений. Как правило, менеджер не должен приказывать, что именно требует изменений и какими должны быть эти изменения. Менеджер должен всего лишь указать на необходимость изменений. Команда должна придумать и провести один или несколько экспериментов, после чего менеджер докладывает команде о том, как изменились показатели в результате проведения эксперимента.
Наконец, еще одной причиной для интервенции является закрытие проекта. В большинстве ситуаций команда не сможет отказаться от продолжения работы над проектом по собственной воле. Однако приходит день, когда дальнейшие инвестиции в текущую систему становятся менее привлекательными, чем какая-либо другая альтернатива, например начало работы над новой системой, которая должна прийти на смену устаревшей. Менеджер обязан быть в курсе, когда именно происходит переход через эту пограничную черту. Он также обязан известить более высокое руководство о необходимости изменений.
Дилемма менеджмента состоит в следующем. С одной стороны, было бы неплохо, если бы все решения принимал менеджер. При этом не приходится тратить ресурсы на коммуникацию, так как существует только один человек. Существует один человек, который отвечает за высший менеджмент. Существует один человек, который обладает видением. Никому больше не надо ничего знать, так как все решения принимает только один человек.
Мы знаем, что эта стратегия не срабатывает, так как ни один человек в мире не знает достаточно для того, чтобы принимать качественные решения во всех областях. Стратегии управления, сбалансированные в сторону централизованного контроля, также сложно реализовывать, так как при этом возникает чрезмерная нагрузка на тех, в отношении которых выполняется управление.
С другой стороны, прямо противоположная стратегия также не срабатывает. Вы не можете позволить кому угодно делать, что ему вздумается, без какого-либо надзора. Люди начнут действовать в разнобой. Требуется кто-то, кто обладал бы более общим взглядом на проект и мог бы повлиять на его развитие в случае, если работа команды отклоняется от намеченного курса.
И вновь мы должны вернуться к принципам, которые помогут нам проложить путь между двумя крайностями.
• Принимаемая ответственность, – в соответствии с этим принципом обязанность менеджера состоит не в том, чтобы назначить ту или иную работу, тому или иному человеку, а в том, чтобы указать команде на необходимость выполнения этой работы.
• Качественная работа – предполагает, что взаимодействие между менеджерами и программистами должно основываться на доверии, так как программисты хотят делать свою работу хорошо. С другой стороны, это не означает, что менеджер может вообще ничего не делать. Однако необходимо понимать разницу между фразами: Я стараюсь заставить этих ребят делать свою работу хорошо и Я должен помочь этим ребятам делать свою работу еще лучше.
• Постепенное изменение – предполагает, что менеджеры не выдают программистам в самом начале работы над проектом толстое описание внутренней политики, в рамках которой следует выполнять работу, а управляют процессом разработки в течение всего времени работы над проектом.
• Локальная адаптация – предполагает, что менеджеры должны взять на себя адаптацию ХР к локальным условиям, анализируя моменты, в которых культура ХР конфликтует с культурой компании, и формируя решения проблем в случае несоответствия.
• Путешествие налегке – предполагает, что менеджер не создает чрезмерной лишней нагрузки на проект (например, длительные совещания с обязательным присутствием всех членов команды или бесконечные продолжительные доклады о текущем состоянии проекта). Любая просьба, которую менеджер может адресовать программисту, должна требовать не очень много времени для исполнения.
• Откровенные оценки – предполагает, что любые метрики, собираемые менеджером, должны находится на реалистичном уровне точности. Не пытайтесь определять время с точностью до секунды, если у ваших часов есть только часовая и минутная стрелки.
Стратегия, которую можно сформировать на основании всего перечисленного, ближе к децентрализованному принятию решений, чем к централизованному контролю. Работа менеджера – вести игру в планирование (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.
Стратегия организации рабочего места
Мы создадим для нашей команды открытое рабочее место с небольшими индивидуальными пространствами по периферии и общей областью программирования в середине.
Рон Джеффрис (Ron Jeffries) писал о фотографии, показанной на рис. 5.
Рис. 5. Рабочее помещение команды DaimlerChrysler СЗ
Если у вас нет подходящего места для работы, ваш проект не сможет стать успешным. Различие между хорошим местом для команды и плохим местом для команды значительно и подчас критично.
В моей карьере консультанта был момент, когда я особенно остро ощутил значимость правильной организации рабочего места. Я был приглашен в одну организацию для того, чтобы пересмотреть объектно-ориентированный дизайн для некоторого проекта. Я взглянул на систему и, конечно же, обнаружил, что она была спроектирована из рук вон плохо. После этого я обратил внимание на то, кто где сидит. Команда состояла из четырех старших программистов. Каждый из них работал в своем собственном кабинете, а каждый из этих кабинетов располагался в одном из четырех углов здания средних размеров. Я посоветовал им переселиться так, чтобы их кабинеты располагались рядом друг с другом. Я был приглашен из-за того, что обладал значительным опытом в области Smalltalk и объектно-ориентированного дизайна, однако, на мой взгляд, наиболее ценным советом, который я им дал, было предложение переставить мебель.
Правильная организация рабочих помещений – это в любом случае непростая работа. В этой области существует большое количество конфликтующих ограничений. Планировщики рабочих помещений стараются потратить как можно меньше денег и при этом обеспечить как можно большую гибкость. Люди, использующие эти помещения, желают работать в тесной связке с остальной командой. В то же время они нуждаются в некотором отделенном от остальных людей индивидуальном пространстве, из которого они могли бы (например) звонить в приемную своей поликлиники.
В рамках ХР существует сильная склонность к огромным публичным пространствам. ХР – это коммунальная дисциплина разработки программного обеспечения. Члены команды должны видеть друг друга, слышать изредка выкрикиваемые вопросы, случайно подслушивать сторонние переговоры, в которые они могли бы внести жизненно важные замечания.
ХР преображает структуру рабочих помещений. Общепринятая структура офисов плохо соответствует идеологии ХР. Например, если вы поставите свой компьютер в угол, это будет не самым удачным решением, так как двум людям будет неудобно работать с таким компьютером. Часто рабочее помещение – это огромный зал, поделенный перегородками на небольшие индивидуальные рабочие ячейки, однако такая структура тоже не работает в рамках ХР. Для повышения эффективности ХР необходимо снизить высоту стен по крайней мере на половину, а лучше вообще от них избавиться. В то же время команда должна быть отделена от остальных команд.
Лучшим является план помещения, в котором центральное обширное общее пространство обрамлено по периметру небольшими отгороженными ячейками. Члены команды могут хранить в этих ячейках свои личные вещи, делать в них телефонные звонки, или проводить в них время в одиночестве, когда они не хотят, чтобы их отвлекали. Вся остальная команда должна с уважением относиться к виртуальному одиночеству человека, сидящего в собственной ячейке. Самые большие, самые быстрые компьютеры следует разместить в середине центрального общего пространства (индивидуальные ячейки могут быть как с компьютерами, так и без компьютеров). В этом случае, если кто-то хочет приступить к программированию, он будет вынужден выйти на открытое общее пространство. Здесь каждый может увидеть, что происходит; формирование пар осуществляется без затруднений и каждая пара получает дополнительную энергетику от других пар, которые также занимаются программированием поблизости.
Если у вас есть возможность, вы можете зарезервировать наиболее уютный кусочек помещения рядом с общим рабочим пространством, разместить там кофейный комбайн, пирожки, несколько игрушек, нечто, что будет притягивать туда людей. Очень часто для того, чтобы выйти из тупика, который возник в процессе разработки, достаточно отойти ненадолго в сторону и отвлечься. Если при этом у команды будет специально предназначенное место, люди с большей вероятностью воспользуются этим в случае необходимости.
Одна из рассмотренных ранее ценностей – храбрость – находит свое воплощение в тяге ХР к рабочим помещениям. Если корпоративный взгляд на планировку рабочего пространства конфликтует со взглядом команды, команда, как правило, побеждает. Если компьютеры размещены в неправильных местах, они перемещаются в новые места. Если помещение разделено перегородками неправильно, перегородки исчезают.
Если освещение слишком яркое, оно приглушается. Если телефоны звонят слишком громко, однажды обнаруживается, что в звонке каждого из них набита вата.
Однажды мы работали для банка, и когда я в самый первый день пришел на работу, я обнаружил, что для работы нам выделили отвратительные старые столы, за каждым из которых мог разместиться только один человек. По обе стороны от каждого стола были смонтированы металлические выдвижные ящики, таким образом, столы даже нельзя было сдвинуть вместе. Между выдвижными ящиками умещались ноги только одного человека. Очевидно, что с этим невозможно было работать. Мы посмотрели вокруг и обнаружили электрическую отвертку с достаточно мощным двигателем. После этого мы отвинтили у одного из столов один набор выдвижных ящиков. В результате за этим столом теперь могли разместиться не один, а два человека. Аналогичным образом мы обработали все остальные столы.
Вся подобная возня с мебелью может стать для вас причиной дополнительных административных проблем. Люди, в обязанности которых входит следить за состоянием рабочих помещений и инвентаря, могут прийти в негодование от того, что кто-то без их ведома передвигает столы (не думая о том, что если обратиться к ним с этой просьбой, то ее исполнение может потребовать несколько недель или даже месяцев). На это я отвечу: Очень плохо. Я должен разработать программную систему, и если я избавлюсь от этих дурацких перегородок, я смогу справиться с моей задачей лучше и быстрее, поэтому я иду и убираю то, что мешает мне работать. Если организация, для которой я работаю, не может вытерпеть столь смелую инициативу, значит, я просто не хочу для нее работать.
Если вам удается установить контроль над физическим окружением, это значит, что ваша команда получает чрезвычайно важное сообщение: никто не собирается смиряться с какими бы то ни было иррациональными интересами организации, которые встают на пути к успеху. Установление контроля над физической средой – это первый шаг в направлении установления контроля над общим стилем работы команды.
Мебель и рабочие помещения могут быть предметом постоянного экспериментирования (еще одна ценность – обратная связь – в действии).
В конце концов, организация потратила кучу денег на приобретение всего этого гибкого офисного инвентаря. Все эти деньги будут потрачены впустую, если вы не воспользуетесь этой гибкостью и не перенастроите свой офис так, как вам это нужно. Что, если сделать индивидуальные ячейки ближе друг к другу? А что, если их немножко удалить? Может, поставить компьютер, предназначенный для интеграции, в центре зала? А может, лучше в углу? Попробуйте это. То, что оказывается удобным, остается. Тем, что не работает, жертвуют в процессе следующего эксперимента.
Рон Джеффрис (Ron Jeffries) писал о фотографии, показанной на рис. 5.
На этой фотографии показано рабочее помещение команды DaimlerChrysler C3, работающей над проектом Payroll. В помещении находятся два больших стола, на каждом из которых установлено по шесть программистских компьютеров. Пары программистов располагаются за любыми доступными для этого компьютерами. На картинке ничего не срежиссировано специально: программисты действительно работают за одним компьютером в паре, именно так, как показано. Тот, кто фотографировал, на самом деле работает в паре с Четом – программистом, который сидит за дальним столом спиной к фотокамере.
На двух видимых на фотографии стенах размещаются белые доски, на которых показаны функциональные тесты, требующие внимания, запланированные сеансы CRC, а также план итераций на задней доске. Листки бумаги, которые можно заметить в верхней части доски слева, – это небольшие заметки, в которых отмечены используемые группой правила ХР.
Вдоль правой стены располагаются небольшие отгороженные от остального помещения индивидуальные ячейки, в которых можно поставить телефон или использовать их для того, чтобы написать что-нибудь на бумаге, не отвлекаясь на других людей.
В дальней части помещения, между компьютерным столом и белой доской, располагается стандартный стол, вокруг которого команда собирается для CRC-сеансов. Как правило, стол завален карточками CRC и едой (одно из используемых командой правил гласит: здесь должна быть еда).
Помещение было спроектировано командой: мы действительно РЕШИЛИ работать в этом помещении. Люди говорят негромко, поэтому уровень шума на удивление низкий. Однако если вы нуждаетесь в помощи, вы можете немножко повысить голос, чтобы получить эту помощь. Помощь придет незамедлительно: обратите внимание, что на полу отсутствует ковер. Это значит, что стулья, на которых мы сидим, могут перемещаться по комнате без каких-либо затруднений.
Рон Джеффрис (Ron Jeffries)
Если у вас нет подходящего места для работы, ваш проект не сможет стать успешным. Различие между хорошим местом для команды и плохим местом для команды значительно и подчас критично.
В моей карьере консультанта был момент, когда я особенно остро ощутил значимость правильной организации рабочего места. Я был приглашен в одну организацию для того, чтобы пересмотреть объектно-ориентированный дизайн для некоторого проекта. Я взглянул на систему и, конечно же, обнаружил, что она была спроектирована из рук вон плохо. После этого я обратил внимание на то, кто где сидит. Команда состояла из четырех старших программистов. Каждый из них работал в своем собственном кабинете, а каждый из этих кабинетов располагался в одном из четырех углов здания средних размеров. Я посоветовал им переселиться так, чтобы их кабинеты располагались рядом друг с другом. Я был приглашен из-за того, что обладал значительным опытом в области Smalltalk и объектно-ориентированного дизайна, однако, на мой взгляд, наиболее ценным советом, который я им дал, было предложение переставить мебель.
Правильная организация рабочих помещений – это в любом случае непростая работа. В этой области существует большое количество конфликтующих ограничений. Планировщики рабочих помещений стараются потратить как можно меньше денег и при этом обеспечить как можно большую гибкость. Люди, использующие эти помещения, желают работать в тесной связке с остальной командой. В то же время они нуждаются в некотором отделенном от остальных людей индивидуальном пространстве, из которого они могли бы (например) звонить в приемную своей поликлиники.
В рамках ХР существует сильная склонность к огромным публичным пространствам. ХР – это коммунальная дисциплина разработки программного обеспечения. Члены команды должны видеть друг друга, слышать изредка выкрикиваемые вопросы, случайно подслушивать сторонние переговоры, в которые они могли бы внести жизненно важные замечания.
ХР преображает структуру рабочих помещений. Общепринятая структура офисов плохо соответствует идеологии ХР. Например, если вы поставите свой компьютер в угол, это будет не самым удачным решением, так как двум людям будет неудобно работать с таким компьютером. Часто рабочее помещение – это огромный зал, поделенный перегородками на небольшие индивидуальные рабочие ячейки, однако такая структура тоже не работает в рамках ХР. Для повышения эффективности ХР необходимо снизить высоту стен по крайней мере на половину, а лучше вообще от них избавиться. В то же время команда должна быть отделена от остальных команд.
Лучшим является план помещения, в котором центральное обширное общее пространство обрамлено по периметру небольшими отгороженными ячейками. Члены команды могут хранить в этих ячейках свои личные вещи, делать в них телефонные звонки, или проводить в них время в одиночестве, когда они не хотят, чтобы их отвлекали. Вся остальная команда должна с уважением относиться к виртуальному одиночеству человека, сидящего в собственной ячейке. Самые большие, самые быстрые компьютеры следует разместить в середине центрального общего пространства (индивидуальные ячейки могут быть как с компьютерами, так и без компьютеров). В этом случае, если кто-то хочет приступить к программированию, он будет вынужден выйти на открытое общее пространство. Здесь каждый может увидеть, что происходит; формирование пар осуществляется без затруднений и каждая пара получает дополнительную энергетику от других пар, которые также занимаются программированием поблизости.
Если у вас есть возможность, вы можете зарезервировать наиболее уютный кусочек помещения рядом с общим рабочим пространством, разместить там кофейный комбайн, пирожки, несколько игрушек, нечто, что будет притягивать туда людей. Очень часто для того, чтобы выйти из тупика, который возник в процессе разработки, достаточно отойти ненадолго в сторону и отвлечься. Если при этом у команды будет специально предназначенное место, люди с большей вероятностью воспользуются этим в случае необходимости.
Одна из рассмотренных ранее ценностей – храбрость – находит свое воплощение в тяге ХР к рабочим помещениям. Если корпоративный взгляд на планировку рабочего пространства конфликтует со взглядом команды, команда, как правило, побеждает. Если компьютеры размещены в неправильных местах, они перемещаются в новые места. Если помещение разделено перегородками неправильно, перегородки исчезают.
Если освещение слишком яркое, оно приглушается. Если телефоны звонят слишком громко, однажды обнаруживается, что в звонке каждого из них набита вата.
Однажды мы работали для банка, и когда я в самый первый день пришел на работу, я обнаружил, что для работы нам выделили отвратительные старые столы, за каждым из которых мог разместиться только один человек. По обе стороны от каждого стола были смонтированы металлические выдвижные ящики, таким образом, столы даже нельзя было сдвинуть вместе. Между выдвижными ящиками умещались ноги только одного человека. Очевидно, что с этим невозможно было работать. Мы посмотрели вокруг и обнаружили электрическую отвертку с достаточно мощным двигателем. После этого мы отвинтили у одного из столов один набор выдвижных ящиков. В результате за этим столом теперь могли разместиться не один, а два человека. Аналогичным образом мы обработали все остальные столы.
Вся подобная возня с мебелью может стать для вас причиной дополнительных административных проблем. Люди, в обязанности которых входит следить за состоянием рабочих помещений и инвентаря, могут прийти в негодование от того, что кто-то без их ведома передвигает столы (не думая о том, что если обратиться к ним с этой просьбой, то ее исполнение может потребовать несколько недель или даже месяцев). На это я отвечу: Очень плохо. Я должен разработать программную систему, и если я избавлюсь от этих дурацких перегородок, я смогу справиться с моей задачей лучше и быстрее, поэтому я иду и убираю то, что мешает мне работать. Если организация, для которой я работаю, не может вытерпеть столь смелую инициативу, значит, я просто не хочу для нее работать.
Если вам удается установить контроль над физическим окружением, это значит, что ваша команда получает чрезвычайно важное сообщение: никто не собирается смиряться с какими бы то ни было иррациональными интересами организации, которые встают на пути к успеху. Установление контроля над физической средой – это первый шаг в направлении установления контроля над общим стилем работы команды.
Мебель и рабочие помещения могут быть предметом постоянного экспериментирования (еще одна ценность – обратная связь – в действии).
В конце концов, организация потратила кучу денег на приобретение всего этого гибкого офисного инвентаря. Все эти деньги будут потрачены впустую, если вы не воспользуетесь этой гибкостью и не перенастроите свой офис так, как вам это нужно. Что, если сделать индивидуальные ячейки ближе друг к другу? А что, если их немножко удалить? Может, поставить компьютер, предназначенный для интеграции, в центре зала? А может, лучше в углу? Попробуйте это. То, что оказывается удобным, остается. Тем, что не работает, жертвуют в процессе следующего эксперимента.
Глава 14.
Разделение полномочий между технарями и бизнесменами
Одним из основополагающих правил нашей стратегии является то, что технари концентрируются на решении технических проблем, а бизнесмены – на решении бизнес-проблем. Проект должен управляться бизнес-решениями, однако для принятия бизнес-решений должна использоваться информация о затратах и риске, предоставляемая техническими специалистами. Эта информация является результатом технических решений.
Существуют два широко распространенных неправильных режима взаимоотношений между бизнесом и разработчиками: когда либо бизнес, либо разработчики получают слишком большую власть над проектом, проект начинает страдать.
Существуют два широко распространенных неправильных режима взаимоотношений между бизнесом и разработчиками: когда либо бизнес, либо разработчики получают слишком большую власть над проектом, проект начинает страдать.