То, что создают люди, часто зависит от того, на чем они сосредоточены. Чем больше люди сосредоточены на своих личных целях, а не на целях команды, тем меньше шансов, что они будут иметь реальную ценность для компании.

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

Рис. 2.2. Отдельные члены команды стремятся добавить agile-практики в те области проекта, где уже есть успехи, поэтому улучшения происходят только в этих местах. Вот почему раздробленное видение приводит к результату «лучше-чем-ничего»

Вот почему команды, которые внедряют отдельные элементы Agile, часто становятся успешнее, чем были до этого. Они применили лучшие методы к тому, что уже умеют делать на отлично, поэтому и добились заметного прогресса. Но они еще не затронули некоторые области проекта, поскольку методы, влияющие на них, пока не привлекли внимания кого-либо из разработчиков, поэтому часть проблем, влияющих на эти области, не была устранена. А ведь именно эти области зачастую мешают команде быть гиперпродуктивной и достигать высоких результатов.

Как же решить эту проблему?

Манифест гибкой разработки программного обеспечения, более известный как Agile-манифест, написан в 2001 году группой из 17 единомышленников, которые собрались на горнолыжном курорте Snowbird Retreat неподалеку от Солт-Лейк-Сити, чтобы придумать решение, способное помочь избежать проблем при разработке программного обеспечения, с которыми они сталкивались на протяжении всей своей карьеры. После нескольких дней обсуждения был принят основной набор идей и принципов (а также придумано название Agile). Собравшиеся объединили их в один документ, меняющий образ мышления в мире разработки программного обеспечения.

Agile-манифест содержит четыре простые идеи. Приведем полный текст.

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

Это особенно полезно для тех, кто нуждается в улучшении работы команды. Вот почему agile-команды ценят людей и взаимодействие больше процессов и инструментов, которых явно недостаточно, чтобы иметь «правильные» процессы или «лучшие» методы. Если люди, которые должны использовать процесс или инструмент, не примут его, то он окажется отброшен в сторону. Еще хуже, когда члены команды следуют букве процесса, даже если это заканчивается неправильными результатами. Прежде чем реализовать даже самый логичный и осмысленный процесс, необходимо, чтобы люди, работающие с вами, приняли его. Если они не понимают смысла ваших действий, то будут считать, что вы просите о необоснованных изменениях.

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

Есть много agile-практик, которые поддерживают этот принцип, так же как и множество различных способов мышления. Поэтому в книге описаны ежедневные митинги и ретроспективы (где каждый рассказывает, как прошел день или итерация и какие уроки можно извлечь). И пользовательские истории важны в том числе и потому, что они помогают команде вести разговор о том, что означает каждая конкретная история.

Во всем мире существуют целые тома подробной и всеобъемлющей программной документации, стоящие на закрытых полках. Их так много, что трудно предсказать, какой документ пригодится, а какой будет бесконечно пылиться на полке. Из-за этого многие команды и особенно их руководители принимают комплексный подход, при котором каждая мелочь должна быть задокументирована независимо от того, понадобится ли это в будущем.

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

Приоритет работающего ПО над всеобъемлющей документацией не означает, что документы не нужны вовсе. Среди них очень много полезных для команды. Но важно иметь в виду, что документацию и программное обеспечение зачастую пишут одни и те же люди. Документация, помогающая им заранее, прежде чем они соберут ПО, понять проблему, общаться с пользователями и исправлять недостатки, экономит больше времени и усилий, чем нужно на ее создание. Часто также мы имеем дело с документацией такого рода, как каркасная визуализация или диаграммы последовательности, которые программисты вовсе не отказываются писать.