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

Scrum можно сформулировать (но не применять) очень просто:

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

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