каждый разработчик по-настоящему верит в проектирование кода и принятие решений в последний ответственный момент. Любой член команды должен быть убежден, что быстрее создать небольшую несвязанную часть системы сегодня и доверить команде внесение в будущем исправлений, если они понадобятся.
Рис. 7.11. Инкрементальная архитектура приводит к более надежной и пригодной к обслуживанию системе
Речь идет не только о том, как программисты проектируют и собирают код. Имеет значение и атмосфера внутри команды: как люди взаимодействуют, в какой обстановке работают и, главное, как относятся друг к другу.
Многие команды испытывают дефицит времени. Еще хуже, когда они понимают, что он искусственно создан руководством, которое думает, что невыполнимые сроки – этот лучший мотиватор. Команда с таким мировоззрением воспринимает любую работу, не добавляющую строки в код, как избыточную.
Когда вы чувствуете, что вам не хватает времени выполнять работу как следует, почти не имеет значения, насколько хороши ваши навыки. Чем сильнее сроки и план давят на вас, тем вероятнее, что вы откажетесь от таких полезных практик, как рефакторинг, разработка через тестирование и непрерывная интеграция. Например, вы не будете заниматься рефакторингом, потому что код и так работает, а у вас нет времени улучшать его. Ваш код будет выполняться и с модульными тестами, и без них, поэтому каждая минута, потраченная на их написание, расценивается как недобавленная новая функция. Умом мы понимаем, что эти практики помогают писать код быстрее, но, находясь под сильным давлением, мы подсознательно начинаем считать, что на них не хватает времени.
Рассмотрим случай, когда команда находится под прессингом руководителя. Возможно, он пообещал пользователям законченный продукт, но согласился на нереальные сроки и хочет уложиться в них. Поэтому он требует от разработчиков отказаться от модульного тестирования, рефакторинга и всего того, что напрямую не связано с добавлением новых функций. В такой команде обычное явление, когда программисты, сталкиваясь с кодом «с душком», думают: «У меня нет времени разбираться! Мне нужно как можно скорее закончить эту новую функцию и перейти к следующей». Конечно, они будут создавать сильно связанный код (потому что затрата нескольких минут, чтобы развязать его, расценивается как избыточная работа, ведь у них просто нет времени на обдумывание!). Руководитель такой команды фактически мешает ей эффективно внедрять ХР, и в результате появляется код «с душком», который трудно изменять и поддерживать. Их проекты практически всегда выполняются с опозданием, а некоторые полностью проваливаются[65].
В ХР есть действенное средство против этого, поэтому поговорим о двух оставшихся целостных практиках: энергичной работе и единой команде.
Разработка программного обеспечения – это игра на понимание, и прозрение приходит к подготовленному, отдохнувшему, расслабленному разуму.
Энергичная работа означает создание среды, в которой каждый член команды имеет достаточно времени и свободы делать свою работу. Это поддерживает в них ментальное состояние, в котором они способны вырабатывать и использовать хорошие привычки, ведущие к лучшему, естественно изменяемому коду. В таком состоянии они могут производить гораздо больше кода и поставлять более ценные функции потребителям за меньшие отрезки времени.
Разработка программного обеспечения – это преимущественно умственная деятельность[66]. Любой хороший разработчик тратит часы, размышляя над проблемой. Озарение может прийти внезапно – во время обеда, принятия душа, катания на велосипеде и т. д. Каждый программный проект опирается на ряд небольших инноваций, следующих одна за другой.
Чтобы разработчик вошел в состояние «потока», включающее в себя высокую концентрацию и максимальную продуктивность[67], требуется время (обычно от 15 до 45 минут). Перерывы и отвлекающие факторы могут вывести его из этого состояния. Но когда он находится под давлением необходимости поставить код в немыслимые сроки, войти в «поток» невозможно. Он так стремится поскорее разделаться с кодом, что ему некогда думать.
Неуважение, установка нереальных сроков и другое негативное поведение руководителя может вызвать состояние пассивности, при котором люди не имеют возможности принимать решения или внедрять инновации.
Когда менеджеры создают атмосферу постоянного отставания от сроков, назначаемых произвольно, они неизбежно будут халтурить, создавая код. Обычно это сопровождается отказом от многих полезных ХР-практик. Кроме того, в такой ситуации разработчики с трудом входят в состояние «потока», необходимое для использования в проекте более простых решений.
XP-команды стремятся создать совсем иную рабочую среду, наполненную энергией, означающую, что каждый член команды ощущает свою автономность.
Каждый сам решает, как выполнять свою работу, и понимает, что имеет право вносить изменения не только в код, но и в план проекта. ХР-команды делают это путем применения практик, ориентированных на планирование: используя недельные циклы. Поэтому они не принимают заранее конкретных решений, если есть возможность сделать это позже. Кроме того, они используют временной резерв, добавляя работы с низким приоритетом, которые легко перенести в следующий цикл. Эти практики повышают чувство командной автономии, предоставляя больше гибкости при планировании. Автономия может исходить от самого кода: избегая антипаттернов и собирая легко изменяемый код, команда открывает для себя возможность выбора в будущем.
В главе 3 мы узнали об agile-принципе устойчивого темпа: гибкие процессы способствуют такой же разработке. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп в течение неопределенного времени. Считаете ли вы, что мужество как ХР-принцип также требуется для того, чтобы поддерживать устойчивый темп?
Многие ХР-практики используют термины «энергичная работа», «40-часовая рабочая неделя» и «устойчивый темп» как синонимы, поэтому XP-команды создают среду, где они могут энергично работать путем выделения разумного количества рабочих часов. Идее 40-часовой рабочей недели много лет – в свое время профсоюзы требовали «восемь часов на работу, восемь часов на отдых и восемь часов на сон»[68]. К 1950-м годам после бесчисленных исследований производительности и изучения диаграмм, показывающих ее снижение и увеличение проблем качества при рабочей неделе, превышающей 40 часов, многие отрасли приняли этот принцип. ХР-команды знают: при устойчивом темпе работы и возможности жить полноценной жизнью вне офиса люди трудятся качественнее и испытывают чувство удовлетворенности.
Людям нужно чувство команды, мы принадлежим к ней. Мы вместе делаем одно дело. Мы поддерживаем друг друга в работе, развитии и обучении.
Хорошие команды вместе могут сделать гораздо больше, чем те же самые люди, работая по отдельности. Почему? Приглашая специалистов, обладающих необходимыми навыками и взглядами, и создавая для них среду, поощряющую открытое общение и взаимное уважение, вы помогаете рождению инноваций. Члены команды делятся своими идеями, а это создает еще больше новых идей.
Практика единой команды помогает отдельным ее членам объединяться. Когда они сталкиваются с препятствиями, то преодолевают их совместно. Важные решения, влияющие на направление развития проекта, также принимаются совместно. Все члены команды учатся доверять друг другу и определять, какие решения можно принимать самостоятельно, а какие – командой в целом.
В единой команде каждый принимает участие в обсуждении того, какие функции ценны для пользователей, какую работу команда возьмет на себя и как будет создано программное обеспечение. Если команда доверяет любому своему участнику принимать решения о кодировании, которое будет поставлять наибольшую ценность, то риск, что некоторые программисты начнут тратить время на дополнительный код, невелик.
Обратная сторона доверия – это понимание того, что каждый может ошибиться. Когда «единая команда» работает динамично, ее члены не боятся совершить оплошность, потому что знают: коллеги их поймут. Ведь единственный способ продвинуться вперед – вместе учиться на неизбежных ошибках.
Единая команда, имеющая энергичную рабочую среду, проектирует лучше, чем разобщенная, в которой царит атмосфера подавленности.
Инновации могут казаться высокими ценностями, но для эффективной ХР-команды это ежедневная реальность. Разработчики, регулярно достигающие состояния «потока» и работающие в информационном пространстве, которое стимулирует осмотическую коммуникацию, часто подпитывают друг друга идеями. А инкрементальное проектирование ПО дает каждому программисту свободу писать новый код с меньшим числом ограничений. Хорошие привычки, выработанные командой, помогают ей избегать антипаттернов, поэтому, когда она наращивает исходный код постепенно, она не накладывает на себя ограничений, который могут сказаться в будущем.
Если менеджер такой команды доверяет ей, то работа идет лучше. Он помогает команде понять ценность, которую она поставляет, не устанавливает нереальных сроков и создает атмосферу, в которой можно сосредоточиться на создании лучшего продукта. Команда с таким менеджером работает быстрее и имеет больше шансов создать продукт, соответствующий требованиям пользователей, в который легко вносить изменения.