Очень знакомая картина для XP– и scrum-команд. Мы говорили со многими разработчиками, прошедшими через это. Люди, как правило, начинают обвинять методологию: «Мы прилагаем все усилия для написания тестов (парного программирования, ежедневных scrum-митингов и т. д.), но это не убеждает нас. Да такая методология и не способна работать».
Принципы помогают понять, почему это происходит. Принципы – это самоанализ. Они заставляют вас думать о том, как вы и ваша команда делаете свою работу. Когда вы тратите время, чтобы понять ценности и принципы, вы начинаете узнавать о проблемах команды. Такой опыт редко доставляет удовольствие. Например, вы можете взглянуть на принцип, касающийся неудач, и осознать, что культура вашей команды не признает права на ошибку. Не исключено, что вы сталкивались с проблемой, которая заставляла вашего руководителя накричать на вас. Члены команды могут перестать уважать вас как человека, который постоянно ошибается. Во многих компаниях факт признания собственной ошибки имеет серьезные последствия[54].
Вот почему люди во многих командах поступают вполне разумно, когда игнорируют ценности и принципы или поддерживают их на словах, ничего не меняя на деле. Поставьте себя на место тех, кто понимает, что культура их команды находится в противоречии с принципом XP, признающим право на ошибку. Что произойдет, если вы поднимете этот вопрос и попросите коллег изменить стиль работы?
Либо вы сможете изменить культуру команды, либо коллеги и руководитель так разозлятся на вас, что останется только уволиться. Причем последний вариант встречается намного чаще, чем первый. Это одна из причин, по которой люди считают, что Agile – это трудно.
Рис. 6.4. Scrum и XP похожи, но все-таки различаются
В зрелой XP-команде нет фиксированных ролей. Цель в том, чтобы каждый человек вносил в успех команды все лучшее, на что он способен. В начале освоения жесткое распределение ролей может помочь в изучении новых навыков, дав возможность технарям принимать технические решения, а менеджерам – бизнес-решения. После того как между членами команды установятся доверительные и уважительные отношения, фиксированные роли мешают каждому максимально проявить себя.
Неслучайно проблемы мышления, вытекающие из столкновения между командой и ценностями, влияют на 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-команда использовала бы эту историю: создала бы ее как часть бэклога, встроила бы в спринт и разместила на доске задач. А как бы использовала это ХР-команда? Она поступила бы аналогично, но применила бы еще и ХР-принципы, чтобы удачнее включить ее в проект.
Экономика
Клиенты подбирают следующие истории так, чтобы это помогало в разработке, что позволяет команде проекта сосредоточиться на создании только самых ценных историй.
Неудача
Истории небольшие и не связаны между собой. Команда может быстро создать историю и передать ее клиенту, поэтому, если программное обеспечение окажется неудачным, она в сотрудничестве с пользователями сможет внести необходимые изменения.
Принятие ответственности
Программист прочитал карточку задачи, оценил, сколько времени потребуется на выполнение работы, и тем самым взял всю ответственность на себя.
Коммуникация
Записывая историю на языке, понятном для пользователя, проще определить приоритеты в работе.
Качество
Обдумывая заранее, как вы будете тестировать историю, вы способствуете поставке продукта высокого качества.
Благодаря тому, что вы уже понимаете, как работают пользовательские истории и как применяют их проектные команды, вы сможете отталкиваться от них, чтобы лучше понять перечисленные принципы.
Обе методологии придают большое значение обратной связи. Мы уже видели, как Scrum использует петли обратной связи, чтобы получить непрерывную коммуникацию между командой и заказчиком. Команды, применяющие эти методологии, разделяют очень похожие ценности – открытость (Scrum) и коммуникацию (ХР). Они сходным образом воспринимают способы общения разработчиков в команде.
Но XP придает гораздо большее значение обратной связи. XP-команды нацелены на очень короткие итерации (недельный цикл) для улучшения качества обратной связи и укорочения петли. Изучая Scrum, мы узнали, что для эффективной итерации команда должна активно интересоваться потребностями пользователей и понимать, что для них ценно. Чтобы сделать петли обратной связи короче, программисты постоянно анализируют ход проекта.
Если возникает проблема, то команда будет ее обсуждать. Осмотическая коммуникация, происходящая тогда, когда люди сидят рядом, помогает распространять эту обратную связь внутри команды. Если совместить все эти приемы, то команда может достичь в своей работе состояния