Рис. 2.4. Agile-«слон» больше, чем сумма гибких практик
Команда, члены которой видят только практики и не думают о принципах, упускает из виду важные моменты взаимодействия между людьми. Их видение останется раздробленным, члены команды будут действовать по отдельности, а не как эффективно функционирующее целое. Они, безусловно, продолжат выполнять свою часть работы, но без усиления командного взаимодействия и сотрудничества, которые делают agile-методологии действительно мощными.
Это то, из чего состоит Agile. Вспомним еще раз первый постулат из Agile-манифеста.
Процессы, методологии и инструменты по-прежнему значимы (поэтому манифест заканчивается словами «…не отрицая важности того, что справа, мы все-таки больше ценим то, что слева»). Но еще важнее люди и их взаимодействие между собой. Именно эти ценности (наряду с 12 принципами, о которых вы узнаете в главе 3) демонстрируют нам, как практики работают вместе и служат руководством для команд, желающих принять их.
Существует большой разрыв между пониманием ценностей Agile-манифеста (и стоящих за ними принципов) и фактическим изменением способа создания программного обеспечения вашей командой. К счастью, есть еще один важный аспект гибкой разработки, помогающий уменьшить этот разрыв, – agile-методологии, которые предназначены помочь командам принять Agile и улучшить свои проекты.
Agile-методологии ценны, потому что помогают увидеть методы в контексте. Они особенно полезны для команд, незнакомых с гибкими методами. Каждая методология на протяжении многих лет разрабатывалась и совершенствовалась agile-экспертами, ориентированными на различные части «слона». Принятие методологии означает, что вы будете следовать надежным решениям, которые нужно соблюдать от начала и до конца проекта без судебных разбирательств и ошибок, ведущих к раздробленному видению.
Agile – это набор методов в сочетании с идеями, советами, а зачастую и совокупностью знаний и богатого опыта agile-практиков. Гибкие методологии будут подчеркивать разницу ролей и обязанностей для каждого участника проекта и рекомендовать определенные методы для каждого из них на различных этапах.
Результаты опроса о гибкой разработке, проведенного в 2013 году компанией VersionOne, содержат список самых популярных методик. Первое место занимает Scrum, затем идет сочетание Scrum и XP. Респонденты также сообщили об использовании Lean и Канбана. Это не гибкие методологии (о них вы узнаете в главе 8 и главе 9), но они по-прежнему составляют основу Agile.
Алистер Коберн так описывает Scrum в своей книге «Быстрая разработка программного обеспечения»:
Scrum можно сформулировать (но не применять) очень просто:
• Команда и спонсоры проекта создают упорядоченный список всего, что нужно сделать. Это могут быть задачи или функции. Перечень обозначается как невыполненный бэклог продукта.
• Каждый месяц команда вытягивает верхнюю часть списка, которую она оценивает как часть работы на месяц. Расширяет и детализирует перечень задач и называет его бэклогом спринта. Команда обещает спонсорам продемонстрировать или предоставить результаты работы в конце месяца.
• Каждый день члены команды собираются вместе на пять – десять минут, чтобы сообщить друг другу о состоянии дел и любых препятствиях, которые тормозят их. Это называется ежедневным митингом.
• Кто-то один назначается scrum-мастером. Задача этого человека – самому или с чужой помощью устранить любые проблемы, о которых говорится на ежедневных совещаниях[17].
Для многих команд начало перехода к Agile означает применение конкретных методов (которые мы выделили жирным шрифтом и объясним более подробно в главе 4):
• Владелец продукта создает и поддерживает бэклог продукта (невыполненные работы по продукту), перечень требований для программного обеспечения.
• Команда выполняет сгруппированные по времени месячные спринты (короткие фиксированные итерации в работе над проектом), в рамках которых они готовят месячный объем требований продуктового бэклога по созданию, тестированию и демонстрации продукта. Требования для текущего спринта называют бэклогом спринта (списки невыполненных работ спринта). (Некоторые scrum-команды используют спринты, продолжительность которых составляет две или четыре недели.)
• Команда встречается на ежедневных митингах, во время которых каждый рассказывает о работе, которую он делал накануне, планах на сегодня и обо всех возникших проблемах.
Scrum-мастер выступает в качестве лидера и коуча, он поддерживает команду в рамках проекта.
Но внедрение Scrum требует большего, чем простое принятие этих серьезных практик. Каждый из перечисленных методов в принципе может быть использован таким образом, что не будет отражать ценности Agile. Ежедневные митинги, например, очень полезны, если команда использует их, чтобы сотрудничать и двигать проект вперед. Но эти же совещания могут попросту использоваться руководителем проекта для информирования команды об индивидуальных заданиях и получения от каждого данных о текущем состоянии дел. Также каждый разработчик не упустит случая, чтобы на встрече сообщить менеджеру проекта: «Вот несколько препятствий на моем пути – давай, разберись с ними». Если каждый цепляется за свою роль, а о других думает примерно так: «Занимайся своими проблемами сам!», то он начинает воспринимать любую новую проблему как чужую. Собрание превращается в говорильню, а не в место для сотрудничества. Команда, попадающая в эту ловушку, может внедрять scrum-методы, но не использовать их.
(В дальнейшем вы больше узнаете о том, как работает Scrum и его методы.)
Вторая методология – экстремальное программирование (или XP). В книге Джеймса Шора и Шейна Уордена The Art of Agile Development так описывается XP: «Используя параллельные фазы, команда XP производит развертывание программного обеспечения каждую неделю. В каждой итерации команда анализирует, проектирует, кодирует, тестирует и разворачивает подмножество функций». (Многие XP-команды используют итерации, продолжающиеся одну неделю, а некоторые – две недели или месяц. Кроме того, XP может быть адаптирован для использования при различных продолжительностях итераций. Дальше в нашей книге вы узнаете больше об адаптации гибких методологий.) ХР устанавливает конкретные методы разработки, направленные на улучшение сотрудничества с пользователями, планирования и тестирования. Но XP выходит за рамки, применяя эти методы, чтобы помочь команде собирать простые, гибкие конструкции программного обеспечения, которые команда может поддерживать и расширять.
Scrum и XP имеют много общего, включая тот факт, что они итерационные. Это означает, что проект делится на итерации, в которых команда выполняет все активности полного проекта, необходимые, чтобы произвести развертывание программного обеспечения в конце каждой итерации. Некоторые XP-команды используют итерации, длящиеся неделю, а scrum-команды – длиною в месяц. Установка ограничений на продолжительность итераций называется таймбоксинг (timeboxing), и это помогает пользователям узнавать, когда они могут ожидать появления дополнительных функций у ПО.
Многие команды считают, что внедрение методологий – особенно Scrum и XP – плодотворнее, чем простое использование индивидуальных практик. Хотя последнее позволяет каждому участнику команды выбирать методы, характерные именно для его работы, внедрение единой методологии собирает всех членов команды вместе, чтобы выяснить, как выбранные по отдельности практики будут укладываться в рамки одной методологии. Чтобы сделать это, нужно изменить способ мышления. Методологии строятся вокруг agile-ценностей и принципов, поэтому перемены, как правило, касаются сотрудничества и взаимодействия, разработки программного обеспечения и реагирования на изменения. Переход облегчают книги и знания, собранные другими agile-практиками, а также поддержка со стороны уже существующих сообществ, формирующихся вокруг этих методологий.
Lean – это не методология, а скорее образ мышления. Он имеет собственный набор ценностей и инструментов мышления, помогающих принять его. Lean так же важен для мира Agile, как XP и Scrum, и вы сможете многое узнать о том, что значит быть гибким, если разглядите общее между ними. Канбан – это agile-метод, помогающий командам улучшать сборку программного обеспечения. Он строится на ценностях Lean и включает собственные методы, помогающие команде лучше работать и развиваться.
Если приглядеться повнимательнее, то методы и приоритеты в XP отличаются от методов и приоритетов в Scrum. Lean и Канбан имеют различный подход к выбору практик и основных направлений. Почему эти непохожие друг на друга подходы к Agile, имеющие абсолютно разную направленность и практики, все еще считаются гибкими? Дело в том, что все гибкие методологии основываются на одних и тех же принципах, опираются на членов команды и на совместную работу над каждым аспектом проекта. Ценности и принципы Agile-манифеста – это то, что объединяет все методологии.
Рис. 2.5. Scrum, XP и Lean все в своей основе имеют agile-ценности и разделяют некоторые ценности, идеи и методы друг с другом
С чего начинать при работе с новой методологией
Приняв решение о цели внедрения методологии, каждый член команды начинает обсуждать с остальными методы, идеи и перспективы. Это противоположность раздробленного видения. Глядя на ситуацию в