Существует полезная метафора, которая поможет получить представление о том, что значит сломанная перспектива и почему она ведет команду по наименее эффективному пути. Это история о слепых и слоне.
Чтобы определить, как выглядит слон, шестерых слепых попросили ощупать разные части тела слона и описать свои ощущения. Слепец, ощупывающий ногу, сказал, что слон похож на столб. Тот, кто ощупывал хвост, утверждал, что слон похож на веревку. Ощупывавший хобот предположил, что слон похож на дерево. А тот, кто трогал ухо, был уверен, что слон шершавый, как веер. Слепец, который трогал живот, сказал, что слон похож на стену. Трогавший бивень утверждал, что слон похож на твердую трубу.
Король объяснил им: «Все вы правы. Причина, по которой ваши мнения не совпадают, в том, что каждый ощупывал разные части слона. На самом деле слон имеет все свойства, которые вы описали»[16].
Команды, добивающиеся от гибких методологий результата «лучше-чем-ничего», зачастую способны получить достаточно хорошее программное обеспечение еще до начала применения Agile. Они надеются, что Agile поможет им сделать проект еще лучше. Суть в том, что до начала внедрения agile-методов команды уже испытывают проблемы (хотя это еще нельзя назвать серьезным кризисом программного обеспечения), которые причиняют вред проектам не сразу, но вызывают трения в команде. Это и есть «раздробленное видение»: разработчики думают только о разработке, проектные менеджеры – лишь об управлении проектом, они пишут код и не стараются разрушить стену непонимания, отделяющую их от клиента, который думает только о бизнесе.
Все заняты мыслями о собственной работе над проектом настолько сильно, что используют такую фразу, как «перебросить соседу через забор», которая явно разделяет команду и уничтожает сотрудничество. Если каждый думает исключительно о собственной задаче и мало коммуницирует с другими членами команды, то все работают по отдельности, а не как единое целое.
В этой ситуации очень подходит история «Слепые и слон». В раздробленном agile-видении человек использует только те методы, которые влияют на его работу (так же как каждый из слепых ощущает только одну часть слона). Например, разработчики концентрируются на разработке через тестирование, рефакторинге и автоматической сборке. Руководители проекта – на доске задач, скорости реализации проектов и выполнении графика. Бизнес-пользователи применяют планирование выпуска и пользовательские истории, чтобы получить более точное представление о том, что делает команда. Руководители используют ежедневные встречи и ретроспективы для управления и улучшения команды. Каждый хочет чем-то отличиться в проекте и видит несколько методов, позволяющих делать что-то конкретное, чтобы помочь ему в работе. (Мы рассмотрим каждый из этих методов чуть позже, так что не беспокойтесь, если вы еще не знакомы с ними.)
Внедряя эти методы по отдельности, вы, безусловно, улучшите положение вещей, потому что agile-практики действительно очень полезны. Проблема в том, что все – разработчики, менеджеры проектов, бизнес-пользователи и лидеры команды – видят проект с разных точек зрения и концентрируются только на тех методах, с которыми непосредственно связаны. Существует парадоксальный эффект («Именно я был прав!»), когда каждый человек видит лишь ту часть agile-методологий, которая влияет на его непосредственную задачу, и приходит к выводу, что Agile нужен для того, чтобы остальные придерживались его точки зрения.
Таким образом, хотя agile-«слон» и состоит из множества потрясающих практик, все же он существенно больше, чем простая сумма всех частей. И если вы отмечаете лишь отдельные методы – особенно те, которые влияют исключительно на вашу работу в проекте, – то будете видеть только небольшой кусок Agile. «Слон» Agile состоит из повседневных практик, но это гораздо больше, чем просто agile-практики.
Рис. 2.4. Agile-«слон» больше, чем сумма гибких практик
Команда, члены которой видят только практики и не думают о принципах, упускает из виду важные моменты взаимодействия между людьми. Их видение останется раздробленным, члены команды будут действовать по отдельности, а не как эффективно функционирующее целое. Они, безусловно, продолжат выполнять свою часть работы, но без усиления командного взаимодействия и сотрудничества, которые делают agile-методологии действительно мощными.
Это то, из чего состоит Agile. Вспомним еще раз первый постулат из Agile-манифеста.
16
Страница из англоязычного варианта «Википедии» (Blind Men and the Elephant, проверено 25 июня 2014 года).