Постигая Agile

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

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

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

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

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

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

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

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

Лучшая рабочая среда для команды проекта «Электронная книга»

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

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

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