Книга: Постигая Agile

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

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

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

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

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

Ответ кроется в самом программном продукте. Вы можете мгновенно увидеть реально работающее программное обеспечение, оно перед вами, вы «получаете» его. Вы сразу видите, что этот продукт делает (или не делает). Если менеджер обещал предоставить то, чего данное ПО не в состоянии выполнить, то может возникнуть неловкая ситуация. Но скрыть это невозможно, потому что программа говорит сама за себя.

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

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

Команда проекта «Электронная книга» – далеко не первая из тех, кто напряженно работает, чтобы уложиться в нереальный срок. Жесткие рамки сдачи проекта – основной инструмент в командно-административном наборе. Всякий раз, когда приближается дедлайн, все первым делом думают о работе по ночам и в выходные дни. Невыполнимый срок – это коварный инструмент, заставляющий команду работать на пределе и сокращающий еженедельные сроки.

Кроме того, в долгосрочной перспективе это не дает желаемого результата. Хорошо известно: команда может работать в напряженном режиме в течение нескольких недель, но после этого ее производительность резко снижается. Это объяснимо: люди переутомились, демотивированы, начинает сказываться усталость. Все незавершенные и повседневные дела, от которых они старались уйти, так или иначе возвращаются и начинают оказывать давление. В самом деле, команды, много работающие сверхурочно, фактически выполняют меньше работы, чем те, кто трудится согласно нормативам. Кроме того, результаты сверхурочных работ, как правило, более низкого качества.

Именно поэтому agile-команды стремятся к сохранению устойчивого темпа. Они планируют выполнение задания, которое действительно можно сделать за выделенное для него время. Итеративная разработка позволяет добиваться этого. Намного проще оценить, сколько программных продуктов можно разработать в течение двух, четырех или шести недель, чем за год-полтора. Давая реальные обещания, команда создает среду, в которой работа по ночам – это исключение из правил[22].

Принцип № 9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта

Недостаточно подробная оценка проделанной работы – это причина не только сверхурочных работ. Большинство разработчиков признают: ощущение, что ты тонешь, приходит с осознанием того, что, казалось бы, пустяковое изменение в коде оборачивается кошмаром для разработки. Затем подряд следуют три рабочих выходных, потраченных на исправление ошибок и латание кода.

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

Последние два десятилетия были революционными в разработке программного обеспечения. Объектно-ориентированное проектирование и анализ, паттерны проектирования, независимая и сервис-ориентированная архитектура и другие инновации дали разработчикам шаблоны и инструменты для технического совершенствования в каждом проекте.

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

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

Еще хуже то, что в самом начале проекта команда заложила дизайн программного обеспечения и архитектуру для поддержания очень подробной спецификации. В итоге получился крайне сложный код, который трудно расширить. Это привело к большому количеству изменений в коде и к такому же числу «заплаток», которые запутывают код. Если бы команда придерживалась итеративного подхода и поставляла рабочее ПО на протяжении всего проекта, то могла бы планировать каждую итерацию для сохранения стабильного темпа работы. Упрощенный подход just-in-time («точно вовремя») к архитектуре позволил бы создать более гибкий и расширяемый дизайн.

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

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

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

Оглавление книги