Для достижения наибольшей ценности программного продукта разработчики ежедневно общаются с бизнес-пользователями (принцип № 5).
Каждый член agile-команды чувствует свою ответственность за проект и отвечает за успех (принцип № 6).
Выполнение проекта – перемещение по проекту
Эффективное общение и доверие между членами команды – это отличное начало. После того как все наладили отношения и узнали, как им настроиться на проект, можно задуматься о главной проблеме – ежедневной работе. Как agile-команда продолжает трудиться над проектом?
Хорошая работа команды определяется тем, что все участники – члены команды, менеджеры, стейкхолдеры и клиенты – в любой момент знают, как продвигается работа над проектом. Но как вы сообщаете о его статусе? Эта проблема гораздо сложнее, чем может показаться на первый взгляд.
Типичный командно-административный менеджер старается сохранить верное направление проекта и подробно информировать всех о содержании планов и отчетов о состоянии дел. Но из отчета порой трудно понять реальный статус проекта, потому что это несовершенный инструмент коммуникации. Зачастую разные люди, читая один и тот же отчет, получают абсолютно несовпадающие впечатления о статусе проекта. Менеджеры проекта порой используют отчеты о статусе для своих целей. Почти каждый менеджер проекта, оказавшись в сложной ситуации, старается не вносить в документ какие-нибудь неудобные для него сведения, предоставленные менеджером или руководителем команды. И чаще всего это именно та информация, которая необходима для принятия решения. Так как же можно говорить о прогрессе, если отчеты недостаточно полны?
Ответ кроется в самом программном продукте. Вы можете мгновенно увидеть реально работающее программное обеспечение, оно перед вами, вы «получаете» его. Вы сразу видите, что этот продукт делает (или не делает). Если менеджер обещал предоставить то, чего данное ПО не в состоянии выполнить, то может возникнуть неловкая ситуация. Но скрыть это невозможно, потому что программа говорит сама за себя.
Рис. 3.6. Работающее программное обеспечение лучше, чем последние отчеты о ходе работ, предоставляющие обновленную информацию о статусе проекта. Потому что это наиболее эффективный способ сообщить, чего достигла команда
Это одна из причин, почему agile-команды используют итеративную разработку. Предоставляя работающие программные продукты по окончании каждой итерации и демонстрируя, что именно сделала команда, они держат всех в курсе того, на каком этапе находится проект. Поэтому практически невозможно неправильно истолковать ситуацию.
Команда проекта «Электронная книга» – далеко не первая из тех, кто напряженно работает, чтобы уложиться в нереальный срок. Жесткие рамки сдачи проекта – основной инструмент в командно-административном наборе. Всякий раз, когда приближается дедлайн, все первым делом думают о работе по ночам и в выходные дни. Невыполнимый срок – это коварный инструмент, заставляющий команду работать на пределе и сокращающий еженедельные сроки.
Кроме того, в долгосрочной перспективе это не дает желаемого результата. Хорошо известно: команда может работать в напряженном режиме в течение нескольких недель, но после этого ее производительность резко снижается. Это объяснимо: люди переутомились, демотивированы, начинает сказываться усталость. Все незавершенные и повседневные дела, от которых они старались уйти, так или иначе возвращаются и начинают оказывать давление. В самом деле, команды, много работающие сверхурочно, фактически выполняют меньше работы, чем те, кто трудится согласно нормативам. Кроме того, результаты сверхурочных работ, как правило, более низкого качества.
Именно поэтому agile-команды стремятся к сохранению устойчивого темпа. Они планируют выполнение задания, которое действительно можно сделать за выделенное для него время. Итеративная разработка позволяет добиваться этого. Намного проще оценить, сколько программных продуктов можно разработать в течение двух, четырех или шести недель, чем за год-полтора. Давая реальные обещания, команда создает среду, в которой работа по ночам – это исключение из правил[22].
22
Это хороший пример упрощения, о котором говорилось в главе 1. Правда, сейчас мы будем говорить о том, что «устойчивый темп» означает следующее: команда имеет достаточно времени для создания ПО, поэтому ей не нужно работать по ночам и в выходные. Далее мы подробно расскажем о важности устойчивых темпов для рабочей среды в команде и для культуры компании в целом, а также о том, что она оказывает влияние на качество производимого ПО.