Постигая Agile Грин Дженнифер

Акт II. План игры изменился, но мы все равно проигрываем

Шесть недель назад Джастин решил, что дела пошли в гору. Команда только что закончила шлифовку первого альфа-релиза фантазийного баскетбольного сайта, включающего NBA и европейские лиги. Но возникли проблемы.

Он вспомнил слова Даниэль: «Проблемы – это мягко сказано. Там столько ошибок, что черт ногу сломит». Все члены команды были расстроены, поэтому провели большое совещание, чтобы обсудить качество кода. Бриджит сказала: «Надо срочно что-то предпринять!» От участников встречи посыпались предложения: «нужно проводить больше оценок кода и самого проекта», «давайте устроим масштабное тестирование, для которого привлечем на несколько часов всех менеджеров продукта, чтобы разом улучшить все программное обеспечение», «нужно нанять тестера на полную ставку».

И тогда Даниэль рассказала им об XP.

– Нам нужно начать ее использовать, – сказала она. – Эта методика позволит решить наши проблемы с кодом.

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

К сожалению, Бриджит не смогла убедить офис-менеджера позволить им сидеть вместе. Но возле кофейного автомата была пустая стена, и Даниэль вывесила на ней описания основных практик XP, напечатанных крупным шрифтом на большом листе бумаги. Достав контрольный лист, она поставила галочку против пункта «информационное пространство». И после недели разработки модульных тестов отметила как выполненный пункт «разработка через тестирование». Джастин установил сборочный сервер и запустил на нем ежечасный контроль изменений кодовой базы, сборку кода и выполнение модульных тестов с рассылкой результатов всем членам команды. Появилась отметка о выполнении пункта «непрерывная интеграция».

Это было шесть недель назад. С тех пор был проделан большой объем работы. Так почему же Джастин считает, что ничего не изменилось?

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

Незадолго до этого Джастин и Даниэль поговорили и пришли к выводу, что не успеют закончить работу в срок. Но на общей встрече всей команды они заверили Бриджит, что закончат все вовремя, и совершенно ее успокоили. «Ничего, мы потом извинимся», – сказала Даниэль. Джастин знал, что им приходилось халтурить, чтобы уложиться в срок, но и этого было недостаточно. Они все равно не успевали. Но он был согласен с Даниэль, что пока не время посвящать в это Бриджит. Это только усугубит ситуацию и еще сильнее задержит проект. Он не был уверен, что всему виной именно XP-практика, но и пользы от нее не было заметно.

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

– Что ты думаешь о том, как у нас внедряется XP? – спросил он.

Даниэль с грустью сказала:

– Я не знаю, в какой момент мы сбились с пути. Эти практики должны были исправить наш код, но я только что потратила четыре часа на поиск ошибок в совершенно новом коде, который мы писали уже после внедрения ХР. Мне кажется, что мы повторяем прежние ошибки. Ничего не меняется!

– Так в чем же мы ошибаемся? – воскликнул Джастин.

Даниэль немного подумала и сказала: «Ну, например, мы больше не работаем парами. Первое время мы активно использовали этот метод, но спустя несколько недель он стал казаться неэффективным. Я не думаю, что кто-то распорядился перестать так работать. Просто один человек ушел в отпуск, и поэтому пара распалась».

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

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

– Куда делся тот аккуратный код, который ты писал прежде?

Джастин вздохнул:

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

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

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

Даниэль сказала:

– Может да, а может нет. – Немного помолчав, она добавила: – Скажу честно, я никогда не писала модульные тесты перед основным кодом. Я программировала, как обычно, и добавляла их после завершения каждого объекта. Ведь не должно быть никакой разницы, правда?

Джастин задумался на минуту, а затем произнес:

– Значит, мы работаем так же, как и до начала внедрения ХР.

ХР-ценности помогают команде изменить мышление

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

Кент Бек. Extreme Programming Explained: Embrace Change

В главах, посвященных Scrum, была приведена цитата Кена Швабера, объясняющая, что без коллективной ответственности и самоорганизации вы не сможете внедрить этот подход. Теперь вы знаете, как команда, не выполнившая этих требований, идет по пути применения отдельных scrum-практик, но не занимается самоорганизацией, – в итоге получает результат «лучше-чем-ничего».

Почти то же самое происходит с XP. Если ваша команда сопротивляется переменам, отстраняется от пользователей, которым нужна программа, непохожая на ту, что вы написали, и не верит в реальность создания продукта, который легко (или хотя бы возможно) изменить, то у вас не будет ХР. И если вы не добьетесь простоты – в архитектуре и коде, корпоративной культуре и командной атмосфере, которые влияют на способность создавать простой код и предотвращать ошибки, – то вы также не получите ХР. Оставшаяся часть этой главы посвящена важной теме – как научиться принимать изменения. В главе 7 будет рассказано о простоте и о том, как она поможет разработать программное обеспечение, которое проще изменить. Но чтобы лучше понять это, разберемся сначала, откуда берутся ошибки.

Так откуда же появляются ошибки?

Загляните в любой учебник по разработке программного обеспечения, и вы найдете ответ: переделка[51]. Источников ошибок много, но чаще всего дефекты привносятся в ПО (термин привнесение дефектов вы найдете во многих учебниках по разработке программного обеспечения) именно при переделке. Команда разрабатывает ПО для решения определенных задач, но потом кто-то приходит и говорит, что нужны изменения. Приходится все переделывать: вырезать старый код, вносить изменения в существующий и ставить заплатки нового кода. Именно так чаще всего ошибки попадают в программный продукт.

Но разве нельзя предотвратить такие изменения? Теоретически можно. В том же учебнике по разработке программ есть ответ: документируйте требования к программному обеспечению. Если вы добросовестно собираете требования, записываете их и оцениваете вместе с заказчиками, то можете предотвратить необходимость изменений. Команда способна разработать продукт, наиболее соответствующий всем требованиям пользователей, клиентов и заинтересованных сторон. Конечно, изменения будут, но минимальные!

Однако это в теории.

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

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

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

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

Программист: у меня есть отличная идея для кода!

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

Программист: но я могу изменить это за десять минут!

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

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

Команда, боящаяся вносить изменения, сама душит собственные инновации. Это не значит, что она не сможет создавать ПО, – она будет это делать, и порой даже качественно. Если вы используете метод BRUF, то сможете выполнить заявленные требования. И это хорошая цель для многих команд. Но данный путь, безусловно, имеет свои минусы.

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

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

Проблема в том, что, когда проект достигает второго, третьего и четвертого релиза, люди уже давно используют это ПО. А поставка работающего программного обеспечения – отличный способ получить обратную связь от пользователей (именно поэтому agile-команды отдают предпочтение работающему ПО перед всеобъемлющей документацией). Теперь от пользователей поступила полезная обратная связь, а в большинстве случаев учет их пожеланий требует переделок.

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

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

Но XP также изменяет представление каждого члена команды о качестве. Качество – не просто способ исключить ошибки. Это возможность предоставить пользователям такое программное обеспечение, которое отвечает их потребностям, даже если это не совсем то, о чем они изначально просили. Традиционные BRUF-команды отделяют проектирование функций (что делает программа) от разработки внутреннего устройства (как она устроена). Функциональность записывается в спецификации, которые затем передаются команде для реализации. Если программистам что-то непонятно или функциональность кажется неверной, они могут задать вопросы тому человеку, который подготовил спецификацию. Затем начинается «игра в испорченный телефон» – автор спецификаций опрашивает пользователей, менеджеров и тех, с кем еще не говорил, и переводит их требования на язык, понятный программистам. BRUF-команды считают это очень эффективным способом, потому что разработчики «не убивают» время на разговоры с клиентами. (Всем известно, что у программистов слабо развиты навыки общения, не так ли?)

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

XP также позволяет избежать ситуации, присущей спецификациям, в которых каждый просто спасает свою шкуру. Разработчикам легче реализовывать то, что прописано в спецификации, не задумываясь о реальных потребностях пользователя. Но если он привык перед началом работы над кодом задаваться вопросом «Что должна делать программа?», то начинает с выявления проблем и будет чувствовать себя комфортно, требуя ответов, потому что они нужны для написания тестов. Программист не будет спихивать ответственность на того, кто подготовил и передал ему спецификацию. Когда все в XP-команде поступают именно так, они постоянно обращаются за разъяснениями к пользователям и стараются выяснить, что им нужно от ПО, чтобы выполнять свою работу. Коммуникация происходит непосредственно, без промежуточных звеньев, что экономит массу времени.

Другими словами, BRUF позволяет создавать то, что вы задумали, а XP – то, что действительно нужно пользователям. И все счастливы: члены команды – потому что могут тратить время на решение реальных проблем, а не бороться с кодом, внося в него правки, а пользователи – потому что получают то, что им действительно нужно (а не то, что они хотели полгода назад). В результате формируется команда, включающая пользователей, клиентов и стейкхолдеров. Им не нужно предугадывать, что потребуется через полгода, а можно сосредоточиться на создании ПО, соответствующего текущим нуждам.

Так как же XP добивается этого?

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

Это новый способ мышления для многих технических специалистов и даже высококвалифицированных разработчиков. Обычно несложно переключить технарей на Scrum, особенно на версию «лучше-чем-ничего», если они чувствуют, что плохое планирование приводит к проблемам в проекте. Scrum действительно помогает командам лучше планировать. Но что произойдет, когда разработчик, изучая практики XP, обнаружит, что они вынуждают его изменить методы своей работы?

Рис. 6.3. Очень распространенная реакция на внедрение XP заключается в том, что, хотя в теории это звучит хорошо, на практике парное программирование и разработка через тестирование «непригодны для нашей команды». Это не обязательно аргумент против данных практик, а скорее предчувствие сложности их реализации

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

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

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

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

Если команды отстают от графика, то они стремятся делать только то, что крайне необходимо, отбросив всякие «украшательства». Обычно они говорят: «Мы опаздываем, поэтому у нас нет времени писать модульные тесты» или «Было бы здорово, если бы мы могли назначить на каждую задачу по два программиста, но тогда мы сорвем сроки сдачи проекта».

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

Именно поэтому вредно, когда команды трактуют ХР-практики как список мероприятий. Еще хуже, если они начинают оценивать, на сколько процентов внедрили ХР, которая в этом случае рассматривается как результат, а не как средство достижения цели. Это надо рассматривать как красный сигнал светофора, показывающий, что люди не готовы к применению XP.

Команда, неправильно воспринимающая ХР, должна изменить образ мышления. Смена мышления может показаться серьезным достижением, особенно если команда не допускает мысли, что этот метод оправдывает затраченное на него время. Так что же заставляет команду трактовать ХР-практики как «первоклассные» и жизненно важные для создания отличного ПО, а не в качестве необязательного дополнения?

Эффективное мышление начинается с ценностей ХР

Команды, имеющие правильное мышление, всегда с готовностью используют отличные практики, потому что точно знают, что они приведут к улучшениям. Так же как Scrum, XP имеет пять ценностей. И так же они помогают команде правильно внедрять ХР и избегать результата «лучше-чем-ничего». Эти ценности позволяют разработчикам изменить мышление, чтобы XP-практики казались естественным путем создания хорошего программного обеспечения. И наоборот, правильное ХР-мышление означает понимание того, что эти практики обеспечивают создание отличного кода.

Коммуникация

Каждый член команды знает, что делают остальные.

Простота

Разработчики стараются создать максимально простое и прямое решение.

Обратная связь

Постоянное тестирование и обратная связь держат качество продукта под контролем.

Мужество

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

Уважение

Каждый член команды ценен для проекта.

Все это абстрактные азбучные истины. Разве можно с ними не соглашаться?

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

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

Потом приходит реальность. Нам кажется излишеством, когда кто-то сидит рядом с нами, пока мы обдумываем и пишем код. Если единственная польза от парного программирования – дополнительная пара глаз, высматривающая ошибки, то для нее есть более эффективное применение. Анализ кода после его написания позволяет отлавливать ошибки с такой же вероятностью (точно такой же анализ можно провести после сессии парного программирования). Но если у вас мало времени из-за приближающегося срока сдачи, то легко убедить себя в том, что обзор кода почти так же хорош, как и парное программирование. «Это разновидность парного программирования, потому что я подключаю кого-то еще!»

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

Все эти утверждения справедливы. Но в каждом случае это означает делать «лучше-чем-ничего» и, соответственно, получать такие же результаты.

Вернемся к цитате Кента Бека, приведенной выше: «Сами по себе практики непродуктивны. Вне связи с поставленными целями они становятся пустым звуком». Примерно то же самое Кен Швабер сказал о Scrum, самоорганизации и коллективной ответственности: каждая ХР-практика делает гораздо больше, чем просто обеспечивает лишний взгляд на код, заставляет людей сидеть в одной комнате или добавлять тесты в базу кода. Они помогают команде привнести XP-ценности в проект.

Вот почему упрощения, которые делают, казалось бы, то же самое, что XP-практики, дадут лишь результат «лучше-чем-ничего». Они меняют методику работы команды, но не влияют на ее намерения и образ мышления.

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

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

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

Для XP в этом нет ничего особенного. Это же относится и к Scrum. Для вводных курсов по Scrum типично показать ценности на паре слайдов и рассказать о них в двух словах, а затем сразу перейти к «сути» тренинга – практикам. Но не стоит слишком многого требовать от тренеров. Гораздо проще обучать применению отдельных практик XP или Scrum, чем пытаться изменить мировоззрение слушателей. Большинство тренеров знают, что, если они уделяют много внимания ценностям, то слышат от разработчиков такие упреки: «слишком много теории» и «это не дает им информации, которую мы можем применить в своих проектах». Эта реакция вполне объяснима: трудно понять, почему ценности имеют практическое значение, пока вы их не усвоите. И невозможно сразу понять, почему практики не работают по-настоящему без ценностей, так что разработчики попадают в ловушку.

Вернемся к Джастину, Даниэль и их фантазийному баскетбольному проекту. Они сразу занялись внедрением ХР-практик, не найдя времени разобраться с ценностями. Даже если вы не знаете деталей их ежедневной работы, попробуйте установить, что они делали неправильно, пытаясь внедрить ХР.

Вот несколько примеров.

Коммуникация

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

Простота

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

Обратная связь

Когда Джастин и Даниэль перестали работать в паре, они почти прекратили общаться. Если бы Даниэль продолжала просматривать его код и давала ему обратную связь, то, возможно, не было бы такого беспорядка. И несмотря на то, что рабочее пространство дает больше информации, она не помогала людям принимать более обоснованные решения. Выяснение, «насколько глубоко команда освоила ХР», не делает программное обеспечение лучше.

Мужество

Если команда не надеется закончить проект вовремя и понимает это, то требуется много мужества, чтобы рассказать правду, – особенно если за это грозит увольнение. У Даниэль и Джастина не хватило мужества.

Уважение

Требовать от команды выполнить проект в заведомо нереальные сроки – это верх неуважения к ней[53]. Бриджит неоднократно устанавливала невероятно жесткие сроки. Хуже то, что она не чувствовала потребности быть рядом с людьми и знать, чем они живут. Например, как в случае, когда она назначила встречу вечером в пятницу и потребовала от команды внести множество исправлений к утру понедельника. И пока разработчики все выходные трудились в поте лица, она отдыхала. (Это не вошло в главу, но нам доподлинно известно, что так все и было.)

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

Если у XP-команды правильный настрой, то она действительно принимает эти ценности. И когда она так поступает, происходит изменение в восприятии XP: практики начинают обретать смысл.

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

Как это помогает команде познакомиться с XP-ценностями?

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

Вот как использование ХР-практик помогает формировать мышление команды.

Но вам не обязательно приступать к внедрению практик, чтобы узнать, совместимо ли мышление команды с ХР. Для этого достаточно ответить на несколько вопросов.

• Как воспримет команда ситуацию, когда часть написанного кода придется выбросить, потому что он не работает? Как отнесется к этому руководство?

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

• Если младший программист получает задачу, то дает ли ему команда полномочия довести ее до конца? Что если она не согласна с его подходом или кто-то считает, что он выполнит ее быстрее? Допустимо ли, что разработчик может не справиться с заданием, но извлечет из этого урок?

Так что же вы предпринимаете, когда ваша команда не до конца освоила ХР-ценности?

Описание: команда занимается разработкой фантазийного баскетбольного сайта

Джастин – первый разработчик

Даниэль – второй разработчик

Бриджит – менеджер проекта

Акт III. Динамика изменений

– Джастин, произошло что-то очень странное.

Джастин полностью погрузился в работу, занимаясь алгоритмом ранжирования игроков по нескольким характеристикам, но отвлекся и взглянул на Даниэль.

– Помнишь, парное программирование нам не очень помогло?

– Да, – сказал Джастин. – Сначала ты смотрела, а я писал код, потом мы менялись. Работы было много, а толку мало. Я посчитал количество строк, которые мы писали за час, и оказалось, что наша производительность падала примерно вдвое. Думаю, именно поэтому мы постепенно перестали им заниматься.

– Вообще-то сейчас мы очень хорошо поработали в паре с Тайлером, – сказала Даниэль.

– Тайлер? Этот новичок? Прошло чуть больше месяца, как он окончил колледж. Неужели из вашей затеи вышло что-то интересное?

Даниэль кивнула:

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

Джастин перебил:

– О боже! Это был тяжкий труд.

– Я помню. А знаешь, он поинтересовался, почему мы не стали хранить ключи и хэши вместе с объектами игрока.

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

– Постой, так значит, у нас в кэше будут неверные данные!

– Да, – сказала Даниэль.

– И Тайлер, этот желторотик, во всем разобрался?

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

У Джастина была копия списка ценностей ХР, которую он в свое время распечатал, прикрепил на стену рядом с собой и благополучно забыл о ней. Теперь он перечитал ее и сказал:

– Знаешь, я действительно не уделял этому внимания. Думаю, что сейчас я кое-что узнал о коммуникации.

– И об уважении, – добавила Даниэль. – В дальнейшем я обязательно буду интересоваться мнением Тайлера. И думаю, что продолжу работать с ним в паре.

Понимание принципов ХР поможет вам принять изменения

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

К счастью, XP имеет ряд принципов, которые сориентируют вас, как применять практики в реальных проектах. Эти принципы подсказывают не только как организовать жизнь в команде, но и как довести проект до конца.

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

Гуманизм

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

Экономика

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

Взаимная выгода

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

Сходство

Месячный, недельный и дневной циклы строятся по одному шаблону.

Улучшение

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

Разнообразие

Объединяйте различные мнения и взгляды, чтобы получить наилучший результат.

Рефлексия

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

Поток

Непрерывная поставка означает постоянную доставку результатов труда разработчиков, не разделяемую на этапы.

Возможность

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

Избыточность

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

Неудача

Неудачи могут многому научить. Нет ничего предосудительного в том, чтобы пробовать подходы, которые не работают.

Качество

Нельзя обеспечивать скорость поставки за счет снижения качества продукта.

Принятие ответственности

Если кто-то берет на себя ответственность, то он должен иметь полномочия для выполнения обещанного.

Маленькие шаги

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

Эти принципы полезны, чтобы понять некоторые конкретные практики, которые использует ХР. А когда вы начинаете изучать практики, они помогают разобраться в принципах.

Так же как в случае с ценностями, у тех, кто впервые сталкивается с ХР, возникает стремление перейти сразу к практике, минуя принципы. По ряду причин это оказывается путем наименьшего сопротивления. Вы можете добавить практику, не осознавая, что с проектом что-то не так. («Мы все делаем отлично, но можем сделать еще лучше!») Миновав изучение ценностей и принципов и сразу перейдя к практикам, вы можете просто составить их список и отмечать галочкой принятие каждой из них. Если ваша цель – «полное» внедрение всех ХР-практик, то этот подход сработает отлично. Но если вы хотите помочь команде создать лучшее программное обеспечение, то «списочный» подход к ХР закончится провалом. Как максимум вы получите результат «лучше-чем-ничего», а со временем практики начнут исчезать и команда вернется к старому способу работы.

Очень знакомая картина для XP– и scrum-команд. Мы говорили со многими разработчиками, прошедшими через это. Люди, как правило, начинают обвинять методологию: «Мы прилагаем все усилия для написания тестов (парного программирования, ежедневных scrum-митингов и т. д.), но это не убеждает нас. Да такая методология и не способна работать».

Принципы помогают понять, почему это происходит. Принципы – это самоанализ. Они заставляют вас думать о том, как вы и ваша команда делаете свою работу. Когда вы тратите время, чтобы понять ценности и принципы, вы начинаете узнавать о проблемах команды. Такой опыт редко доставляет удовольствие. Например, вы можете взглянуть на принцип, касающийся неудач, и осознать, что культура вашей команды не признает права на ошибку. Не исключено, что вы сталкивались с проблемой, которая заставляла вашего руководителя накричать на вас. Члены команды могут перестать уважать вас как человека, который постоянно ошибается. Во многих компаниях факт признания собственной ошибки имеет серьезные последствия[54].

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

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

Рис. 6.4. Scrum и XP похожи, но все-таки различаются

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

Кент Бек. Extreme Programming Explained: Embrace Change

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

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

Но планирование и отслеживание XP-проекта отличается от этих же действий в проекте Scrum, и принципы помогают нам понять почему. Отчего XP-проект не имеет конкретных ролей? Это тот случай, когда ХР-команды очень серьезно относятся к принципам «возможность» и «разнообразие». Бывает, хотя и редко, что в scrum-команде владелец продукта или scrum-мастер переключаются на разработку программной архитектуры и проектирование, а член команды берет на себя руководство работой с пользователями или занимается бэклогом. ХР-команды отвергают разделение ролей по двум причинам. Первая заключается в том, что люди, ограниченные одной ролью, упускают возможность расширить свой вклад. А вторая – в том, что каждый в команде может взглянуть на проблему с неожиданной стороны, что может стать ключом к ее решению. Иногда высококвалифицированный разработчик предлагает хорошую идею по работе с пользователями или руководитель вносит ценный вклад в создание архитектуры именно потому, что они смотрят на проект иначе, чем те, кто непосредственно занимается этими вопросами.

Такое понимание принципов меняет практику. Занимаясь фантазийным баскетбольным проектом, Даниэль узнала, что парная работа с новым программистом, который никогда не видел код, может дать совершенно иное видение. Это вносит в работу разнообразие: хорошие идеи приходят отовсюду, даже от новых членов команды. Вот почему многие XP-команды чередуют партнеров во время парного программирования, вместо того чтобы назначать постоянные пары. Это также вносит разнообразие и в работу пар, помогает взглянуть на код свежим взглядом, выявлять больше проблем и стимулировать инновации. Принцип гуманизма тоже играет свою роль. Привлечение разных людей и их совместная работа помогают создавать среду, где все дают друг другу обратную связь, что помогает каждому научиться принимать мнение коллег и даже их критику, сохраняя при этом взаимное уважение. Это дает мужество молодым членам команды высказывать свое мнение о проблемах, даже если они работают в паре с опытными программистами. Такие принципы, как разнообразие и гуманизм, в сочетании с такими ценностями, как коммуникация, уважение и мужество, помогают команде превратить парное программирование в эффективный инструмент.

Принципы также помогают понять, почему XP не имеет конкретной практики, позволяющей проанализировать сделанную работу, как при ретроспективах в Scrum. ХР опирается на такие ценности, как улучшение и рефлексия, и ХР-команды постоянно обсуждают то, как они делают работу, и способы ее улучшения. Но они склонны к самокопанию, углубляясь в рефлексию и отвлекаясь от непрерывного выполнения задач. Это тот случай, когда парное программирование способствует тому, чтобы люди в процессе работы обсуждали свои действия.

Принцип маленьких шагов очень полезен: вместо того чтобы сразу устанавливать глобальную цель («давайте внедрим все XP-практики»), команда может сделать к ней небольшой шажок («давайте начнем парную разработку, и тогда каждый день мы будем становиться лучше»).

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

На рисунке 6.5 показана типичная история, которую XP-команда может использовать в проекте. ХР, так же как Scrum, не вводит универсального формата для пользовательских историй. В данном случае команда решила применить свободную форму предложений (а не стандартный повествовательный формат) и писать на лицевой стороне карточки такое количество часов, какое они посчитали необходимым для реализации истории.

Рис. 6.5. XP-команды используют те же истории, что и scrum-команды, но применяют к ним свои ценности и принципы

Вы уже знаете, как scrum-команда использовала бы эту историю: создала бы ее как часть бэклога, встроила бы в спринт и разместила на доске задач. А как бы использовала это ХР-команда? Она поступила бы аналогично, но применила бы еще и ХР-принципы, чтобы удачнее включить ее в проект.

Экономика

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

Неудача