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