Постигая Agile

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

В ходе посиделок Брюс расслабился и рассказал еще об одной проблеме, которая не давала ему покоя: многие команды в компании имели большие проблемы с созданием ПО. Даже если пользователь прислал письменные требования (что случалось редко) и команда, прочитав их, смогла в них разобраться (чего вообще никогда не случалось), то они часто применяли неподходящие инструменты и имели трудности с дизайном и архитектурой программ. Это приводило к тому, что команды Брюса неоднократно создавали программные продукты с множеством ошибок, которые невозможно было исправить.

Обе эти проблемы привели к массе неудавшихся проектов, особенно с учетом тех случаев, когда им приходилось работать по 90 часов в неделю, если код давал сбои. Джоанна объяснила, что главная причина этих неудач – неспособность водопадного подхода, принятого в компании, справляться с изменениями. В идеальном мире водопадный подход работал бы прекрасно, потому что на старте проекта известно, что нужно получить в конце. Таким образом, можно было бы записать все в виде аккуратной спецификации и передать команде разработчиков. Но в реальных проектах так не бывает.

Захмелевшие Дэн и Брюс подпали под влияние Джоанны, которая усилила напор. Дэн рассказал, что практически каждый проект, над которым они работали, обрывался на полпути, потому что заказчики неожиданно сообщали, что им нужно что-то другое, отличающееся от первоначального замысла. Затем всем приходилось возвращаться к началу водопада. В соответствии со строгими процессами этой методологии их действия были следующими: создать совершенно новые спецификации, другой дизайн и новый план. Но в реальности этого почти никогда не случалось, крайне редко удавалось урвать время, чтобы переписать весь код заново. Вместо того чтобы следовать методикам водопадного программирования, принималось решение о срочной переделке существующего кода. Это влекло за собой ошибки, потому что ситуация, когда программное обеспечение сначала разрабатывается для одних целей, а затем спешно модифицируется для других, часто приводит к беспорядочному, запутанному коду (особенно когда команда находится под посторонним давлением). Адаптация кода к новым задачам отнимала драгоценное время, так что они завершали проект обходными способами и создавали нестойкий код.

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

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

Серебряной пули не существует

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

(По иронии судьбы одна из самых цитируемых работ в области программной инженерии – это эссе Фреда Брукса No Silver Bullet («Серебряной пули не существует», 1986). В нем он убедительно доказывает, что эта задача невыполнима. Что еще нужно, чтобы остановить бесплодные попытки найти загадочную панацею?)