Программирование
Как непрерывная интеграция помогает выявлять изменения? Мы создали набор модульных тестов, которые запускаем каждый раз при выполнении интеграции кода. Поэтому, когда один из членов команды добавляет изменения, он запускает все тесты, в том числе и для той части кода, над которой работают все остальные ее участники. Если один из этих тестов терпит неудачу, то мы сможем работать вместе – и даже парами, – чтобы решить эту проблему в обеих конфликтующих частях кода.
Когда все эти практики работают вместе, то изменения – даже крупные – испытывают меньшее негативное влияние. Это помогает команде понять, что с изменениями можно справляться легче.
Когда XP-команды используют разработку через тестирование, первым делом они создают модульные тесты, выражающие поведение будущего кода, а затем пишут код, который сможет их пройти. Это создает петлю обратной связи, помогающую предотвратить появление дефектов.
Команды создают десятиминутную сборку, или автоматизированную сборку, которая выполняется не более чем за 10 минут.
Отдельные разработчики используют непрерывную интеграцию, чтобы постоянно учитывать изменения коллег, поэтому у каждого из них «песочницы» соответствуют текущему состоянию проекта.
XP-команды применяют итерации с циклами в неделю и квартал, а также истории так, как это делают scrum-команды.
Команды добавляют незначительные, с низким приоритетом задачи в каждый недельный цикл, чтобы создать временной запас.
Когда XP-команды сидят вместе, они периодически впитывают информацию о проекте через осмотическую коммуникацию.
XP-команды работают в информационном рабочем пространстве, которое использует излучатели информации, такие как настенные диаграммы выгорания, автоматически передающие ее людям, находящимся поблизости.
Джастин – первый разработчик
Даниэль – второй разработчик
Бриджит – менеджер проекта
Акт II. План игры изменился, но мы все равно проигрываем
Шесть недель назад Джастин решил, что дела пошли в гору. Команда только что закончила шлифовку первого альфа-релиза фантазийного баскетбольного сайта, включающего NBA и европейские лиги. Но возникли проблемы.
Он вспомнил слова Даниэль: «Проблемы – это мягко сказано. Там столько ошибок, что черт ногу сломит». Все члены команды были расстроены, поэтому провели большое совещание, чтобы обсудить качество кода. Бриджит сказала: «Надо срочно что-то предпринять!» От участников встречи посыпались предложения: «нужно проводить больше оценок кода и самого проекта», «давайте устроим масштабное тестирование, для которого привлечем на несколько часов всех менеджеров продукта, чтобы разом улучшить все программное обеспечение», «нужно нанять тестера на полную ставку».
И тогда Даниэль рассказала им об XP.
– Нам нужно начать ее использовать, – сказала она. – Эта методика позволит решить наши проблемы с кодом.
Казалось, что все члены команды согласились, и Бриджит договорилась о выделении некоторых ресурсов, чтобы внедрить ХР. Она получила задание дать команде несколько недель на апробирование новой практики, начиная с недельной разработки модульных тестов. Поскольку никаких модульных тестов у них не было, вся команда целую неделю писала множество тестов для разных частей программы, чтобы успеть сделать как можно больше.
К сожалению, Бриджит не смогла убедить офис-менеджера позволить им сидеть вместе. Но возле кофейного автомата была пустая стена, и Даниэль вывесила на ней описания основных практик XP, напечатанных крупным шрифтом на большом листе бумаги. Достав контрольный лист, она поставила галочку против пункта «информационное пространство». И после недели разработки модульных тестов отметила как выполненный пункт «разработка через тестирование». Джастин установил сборочный сервер и запустил на нем ежечасный контроль изменений кодовой базы, сборку кода и выполнение модульных тестов с рассылкой результатов всем членам команды. Появилась отметка о выполнении пункта «непрерывная интеграция».
Это было шесть недель назад. С тех пор был проделан большой объем работы. Так почему же Джастин считает, что ничего не изменилось?
Он и Даниэль только что вышли от Бриджит. Встреча не удалась, Бриджит очень разозлило, что исправление ошибок в базе данных управления игрой заняло больше времени, чем ожидалось.
Незадолго до этого Джастин и Даниэль поговорили и пришли к выводу, что не успеют закончить работу в срок. Но на общей встрече всей команды они заверили Бриджит, что закончат все вовремя, и совершенно ее успокоили. «Ничего, мы потом извинимся», – сказала Даниэль. Джастин знал, что им приходилось халтурить, чтобы уложиться в срок, но и этого было недостаточно. Они все равно не успевали. Но он был согласен с Даниэль, что пока не время посвящать в это Бриджит. Это только усугубит ситуацию и еще сильнее задержит проект. Он не был уверен, что всему виной именно XP-практика, но и пользы от нее не было заметно.
Был перерыв, они с Даниэль пили кофе, и Джастин колебался, стоит ли выносить эти проблемы на общее обсуждение. Кроме того, он хотел знать ее мнение на этот счет.
– Что ты думаешь о том, как у нас внедряется XP? – спросил он.
Даниэль с грустью сказала:
– Я не знаю, в какой момент мы сбились с пути. Эти практики должны были исправить наш код, но я только что потратила четыре часа на поиск ошибок в совершенно новом коде, который мы писали уже после внедрения ХР. Мне кажется, что мы повторяем прежние ошибки. Ничего не меняется!
– Так в чем же мы ошибаемся? – воскликнул Джастин.
Даниэль немного подумала и сказала: «Ну, например, мы больше не работаем парами. Первое время мы активно использовали этот метод, но спустя несколько недель он стал казаться неэффективным. Я не думаю, что кто-то распорядился перестать так работать. Просто один человек ушел в отпуск, и поэтому пара распалась».
Даниэль была права, но, похоже, никто из команды «слона-то и не приметил». Хотя никто не говорил о прекращении парного программирования, оно почему-то остановилось. То же самое произошло и с разработкой через тестирование: Джастин написал лишь несколько модульных тестов, а Даниэль поняла, что у нее на это вообще нет времени.
Несколько дней назад Даниэль все же начала переживать из-за отказа от парного программирования, поэтому решила взглянуть на код Джастина. Это был тихий ужас, все оказалось завалено закомментированными блоками кода – настоящая мешанина. Даниэль не побоялась спросить его прямо:
– Куда делся тот аккуратный код, который ты писал прежде?
Джастин вздохнул:
– Я бы с удовольствием писал сейчас хороший код, но сроки поджимают. У меня просто нет времени подумать.
И Даниэль поняла, что ему действительно не хватает времени – важна каждая минута. Да и Бриджит была уверена, что они считают недопустимым потерю хотя бы одного дня из-за ошибок. Так что, хотя они оба знали, что могли сделать работу лучше, но срок сдачи приближался слишком быстро.
– Знаешь, почему так случилось? Потому что мы перестали использовать парное программирование. Ты и я работали в паре до тех пор, пока не обнаружилась серьезная ошибка в работающей части программы, – сказал Джастин. – Мне пришлось заняться ее исправлением, а ты не могла ждать. Поэтому код базы данных, над которым мы работали вместе, ты дописывала в одиночку. У нас просто не хватило времени на работу в паре. Нам вообще некогда заниматься всеми этими новшествами!
Даниэль сказала:
– Может да, а может нет. – Немного помолчав, она добавила: – Скажу честно, я никогда не писала модульные тесты перед основным кодом. Я программировала, как обычно, и добавляла их после завершения каждого объекта. Ведь не должно быть никакой разницы, правда?
Джастин задумался на минуту, а затем произнес:
– Значит, мы работаем так же, как и до начала внедрения ХР.
ХР-ценности помогают команде изменить мышление
Сами по себе практики непродуктивны. Вне связи с поставленными целями они становятся пустым звуком. Например, парное программирование не имеет смысла, если делать его для галочки. Работать парами ради того, чтобы угодить руководителю, означает просто разочароваться в этом методе. Парное программирование ради общения, получения обратной связи, упрощения системы, поиска ошибок и поддержания вашего мужества имеет гораздо больше смысла.
В главах, посвященных Scrum, была приведена цитата Кена Швабера, объясняющая, что без коллективной ответственности и самоорганизации вы не сможете внедрить этот подход. Теперь вы знаете, как команда, не выполнившая этих требований, идет по пути применения отдельных scrum-практик, но не занимается самоорганизацией, – в итоге получает результат «лучше-чем-ничего».
Почти то же самое происходит с XP. Если ваша команда сопротивляется переменам, отстраняется от пользователей, которым нужна программа, непохожая на ту, что вы написали, и не верит в реальность создания продукта, который легко (или хотя бы возможно) изменить, то у вас не будет ХР. И если вы не добьетесь простоты – в архитектуре и коде, корпоративной культуре и командной атмосфере, которые влияют на способность создавать простой код и предотвращать ошибки, – то вы также не получите ХР. Оставшаяся часть этой главы посвящена важной теме – как научиться принимать изменения. В главе 7 будет рассказано о простоте и о том, как она поможет разработать программное обеспечение, которое проще изменить. Но чтобы лучше понять это, разберемся сначала, откуда берутся ошибки.