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

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

Что было бы, если бы сразу применялась более эффективная коммуникация? Как бы изменился продукт, если бы вместо развернутых требований команда с самого начала написала минимальное количество документов, необходимых для работы?

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

Давайте представим, что так и случилось с проектом «Электронная книга». Благодаря возможности самостоятельно писать документацию наша команда стала счастливее, потому что сократилась нагрузка. Участники группы полагали, что смогут сэкономить время за счет повышения качества общения и отказа от ненужной документации. Но что если, несмотря ни на что, проект по-прежнему отстает от графика?

Почему-то эта экономия времени никогда не реализуется на практике. Похоже, что члены команды, пытаясь включить в ограниченные по времени итерации все те функции, которые захотел владелец продукта, потратили больше ночей и выходных, чем когда-либо. Выходит, что, став более гибкими, они вынуждены работать еще интенсивнее! Какое же это улучшение? Можно ли как-нибудь исправить эту ситуацию, прежде чем команда навсегда разочаруется в Agile?

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

Наиболее эффективное общение между членами agile-команды происходит тогда, когда они сосредоточены на разговоре лицом к лицу и опираются на минимальное количество документации, необходимой для реализации проекта (принцип № 4).

Для достижения наибольшей ценности программного продукта разработчики ежедневно общаются с бизнес-пользователями (принцип № 5).

Каждый член agile-команды чувствует свою ответственность за проект и отвечает за успех (принцип № 6).

Выполнение проекта – перемещение по проекту

Эффективное общение и доверие между членами команды – это отличное начало. После того как все наладили отношения и узнали, как им настроиться на проект, можно задуматься о главной проблеме – ежедневной работе. Как agile-команда продолжает трудиться над проектом?

Хорошая работа команды определяется тем, что все участники – члены команды, менеджеры, стейкхолдеры и клиенты – в любой момент знают, как продвигается работа над проектом. Но как вы сообщаете о его статусе? Эта проблема гораздо сложнее, чем может показаться на первый взгляд.