Постигая Agile. Дженнифер Грин

Чтение книги онлайн.

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

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

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

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