Книга: Постигая Agile

Понимание слона

Понимание слона

Лисса Адкинс в своей книге Coaching Agile Teams[14] объясняет, как метафора может стать ценным инструментом для понимания концепции.

Существует полезная метафора, которая поможет получить представление о том, что значит сломанная перспектива и почему она ведет команду по наименее эффективному пути. Это история о слепых и слоне.

Команды, добивающиеся от гибких методологий результата «лучше-чем-ничего», зачастую способны получить достаточно хорошее программное обеспечение еще до начала применения Agile. Они надеются, что Agile поможет им сделать проект еще лучше. Суть в том, что до начала внедрения agile-методов команды уже испытывают проблемы (хотя это еще нельзя назвать серьезным кризисом программного обеспечения), которые причиняют вред проектам не сразу, но вызывают трения в команде. Это и есть «раздробленное видение»: разработчики думают только о разработке, проектные менеджеры – лишь об управлении проектом, они пишут код и не стараются разрушить стену непонимания, отделяющую их от клиента, который думает только о бизнесе.

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

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

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

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

Рис. 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 в своей книге «Быстрая разработка программного обеспечения»:

Для многих команд начало перехода к 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-ценности и разделяют некоторые ценности, идеи и методы друг с другом

Оглавление книги