Глава 19 Изменения случаются

«Как продвигается разработка, Гленн?» — спросил Дейв, менеджер проекта Chemical Tracking System на совещании, посвященному состоянию проекта.

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

Дейв был озадачен. «Я не помню, чтобы мы обсуждали новую функцию запроса каталога на недавней встрече совета по управлению изменениями. Шэрон подала этот запрос через процесс контроля изменений?»

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

Большинство разработчиков сталкивались с простыми на первый взгляд изменениями, которые оказывались более сложными, чем они ожидали. Разработчики иногда не выполняют — или не могут выполнить — реалистичные расчеты затрат и других последствий предложенного изменения ПО. И когда разработчик, который хочет быть любезным, соглашается добавить улучшение, запрашиваемое пользователем, требования изменяются через «заднюю дверь», а не утверждаются заинтересованными лицами, которые имеют на это право. Такие неконтролируемые изменения — повсеместный источник хаоса в проекте, нарушения графика и проблем с качеством, особенно если работа ведется на нескольких участках или проект выполняет сторонняя организация. Организация, серьезно относящаяся к управлению своими проектами по разработке ПО, должна убедиться, что:

· предложенные изменения требований тщательно оценены до их ввода в дело;

· соответствующие лица принимают бизнес-решения, будучи хорошо информированными о запрошенных изменениях; одобренные изменения доведены до сведения всех участников проекта;

· изменения требований, внесенные в проект, согласованы друг с другом.

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

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

Обязанность аналитика требований — включить утвержденные изменения в проектную документацию требований. Принцип все тот же: документация требований должна точно описывать поставляемый продукт. Если вы не будете обновлять спецификацию требований по мере разработки продукта, его ценность будет снижаться, и команде придется работать таким образом, как будто бы у нее вообще нет никакой спецификации.

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

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

Управление незапланированным ростом объема

Capers Jones (1994) сообщает, что незапланированный рост объема ставит под удар:

· 80% проектов по разработке систем управления информацией;

· 70% проектов по разработке военных систем ПО;

· 45% проектов по созданию ПО, выполняемых по контракту.

Незапланированным изменением требований считается предложение новой функциональности и существенной модификации после утверждения базовой версии требований к проекту. Чем дольше продолжается работа над проектами, тем больше их объем. Требования к системе управления информацией, как правило, увеличиваются на 1% в месяц (Jones, 1996b). Темп прироста может составлять до 3,5% в месяц для коммерческого ПО, при этом темпы роста других типов проектов входят в этот показатель. Проблема заключается не в изменении требований, а в том, что запоздалые изменения значительно влияют на уже выполненную работу. Если каждое предложенное изменение одобряется, то тем кто финансирует проект, его участникам и клиентам, может казаться, что проект никогда не будет завершен — и действительно такая возможность существует,

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

Первый шаг при управлении незапланированным ростом объема — документирование образа, границ и ограничений новой системы, как части бизнес-требований (см. главу 5). Оценивайте каждое предложенное требование или функцию, соотносясь с бизнес-целями, образом продукта и границами проекта. Если задействовать клиентов всборе информации, то снижается количество требований, упущенных из внимания, которые приходится добавлять к задачам команды после того, как обязательства приняты, а ресурсы распределены (Jones, 1996а). Составление прототипов - это еще один эффективный прием управления незапланированным ростом объема (Jones, 1994). Прототип позволяет предварительно реализовать продукт, что помогает разработчикам и пользователям прийти к общему пониманию нужд пользователей и необходимых решений. Короткие циклы разработки при инкрементальной разработке системы позволяют вносить изменение часто, это особенно полезно, когда требования неясные или быстро изменяются (Beck, 2000).

Наиболее эффективный прием для управления незапланированным ростом объема - это умение сказать: «Нет» (Weinberg, 1995). Люди в принципе не любят отказывать, а разработчиков могут прессинговать по поводу каждого предложенного требования. Такие принципы, как «Клиент всегда прав» и «Мы сделаем все, чтобы клиент остался доволен» звучат прекрасно в теории, однако за их выполнение нужно платить. Игнорируя это, вы никак не измените тот факт, что коррективы не могут произойти просто так. Президент одной компании, специализирующейся на поставке программного обеспечения, привык слышать от менеджера по разработке в ответ на предложение новой функции: «Не сейчас». «Не сейчас», — звучит более привлекательно, чем простой отказ. В этом слышится обещание включить функцию в следующие версии. Включение каждой функции, запрашиваемой клиентами, специалистами отдела маркетинга, менеджерами продукта и разработчиками, приводит к размыванию обязательств, снижению качества, истощению разработчиков и созданию ПО с избыточной функциональностью. Клиенты не всегда правы, но в их высказываниях всегда есть смысл, поэтому фиксируйте их идеи — возможно, их стоит включить в последующие версии.

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