Работа над Chemical Tracking System продвигалась просто замечательно. Но спонсор проекта Жерар и сторонник продукта от персонала, работающего на складе, Роксана, сомневались, стоит ли тратить много времени на определение требований, Тем не менее они присоединились к разработчикам и другим сторонникам продукта, которые проводили однодневный тренинг, посвященный работе над требованиями к ПО. На этом тренинге подчеркивалась важность достижения общего понимания всеми заинтересованными в проекте лицами бизнес-целей и нужд пользователей. Кроме того, всех участников ознакомили с терминологией, касающейся требований, концепциями и приемами, которые будут использоваться в работе. А также призвали применять лучшие приемы для работы с требованиями на практике.
По мере развития проекта Жерар получил отличные отзывы от представителей пользователей о том, насколько хорошо прошла разработка требований. Он даже организовал ланч для аналитиков и апологетов продукта, чтобы отпраздновать создание основной версии требований для первого выпуска системы. На ланче Жерар поблагодарил тех, кто занимался сбором информации для создания требований, за их вклад и коллективную работу. А затем сказал: «Теперь, когда с требованиями все в порядке, я с нетерпением ожидаю скорого появления готового кода».
«Мы еще не готовы писать код продукта, — ответил менеджер проекта, — Мы планируем выпускать систему поэтапно, поэтому ее необходимо разрабатывать, сообразуясь с будущими дополнениями. С помощью прототипов мы получили четкое представление о технической стороне и смогли понять характеристики интерфейса, который предпочитают пользователи. Если на этой стадии мы потратим еще немного времени на проектирование, то сможем избежать проблем в течение следующих нескольких месяцев, когда придет время добавлять функциональность к системе».
Жерар расстроился. Все выглядело так, как будто разработчики сознательно медлили, вместо того чтобы прямо приступить к работе. Однако не делал ли он преждевременных выводов?
Опытные менеджеры проекта и разработчики понимают ценность преобразования требований к ПО в надежный дизайн и рациональные планы. Они необходимы в тех случаях, когда следующая версия представляет 1 или 100% всего конечного продукта. В этой главе мы рассмотрим, как преодолеть пропасть, которая отделяет разработку требований от успешного выпуска продукта: несколько вариантов влияния требований на планы проекта, проектирование, написание кода и тестирование, как показано на рис. 17-1.
Рис. 17-1. Влияние требований на планирование проекта, дизайн, написание кода и тестирование
От требований к планам проекта
Поскольку именно требования определяют предполагаемый исход (результат) проекта, планы, сметы и графики следует разрабатывать на основе требований. Однако необходимо помнить, что наиболее важный результат проекта — это та система, которая соответствует бизнес-целям, а не обязательно та, в которой реализованы все первоначально требования согласно первоначальному плану проекта.
В требованиях и планах указана первоначальная оценка затрат на проект, определенная членами команды. Однако границы проекты могут выйти за первоначальные рамки, да и планы могут оказаться невыполнимыми. Кроме того, бизнес-потребности, бизнес-правила и ограничения проекта могут измениться. Успех проекта сомнителен, если вы не будете обновлять ваши планы в соответствии с изменяющимися целями и обстоятельствами.
· Менеджеров проекта часто интересует, сколько времени и усилий понадобится для разработки требований. Для небольших проектов, которыми обычно занималась наша команда, этот этап обычно стоил от 12 до 15% всех затрат (Wiegers, 1996а), однако показатель зависит от объема и сложности проекта. Несмотря на опасения, что работа над требованиями замедлит создание продукта, доказано, что понятные требования ускоряют процесс разработки, что и показывают следующие примеры;
· изучение 15 проектов в сфере телекоммуникаций и банковской сферы показало, что в наиболее успешных проектах примерно 28% ресурсов тратилось на разработку требований (Hofmann и Lehner 2001): 11% — на сбор информации по требованиям, 10% — на моделирование, а 7% — на проверку и утверждение. На разработку требований для среднего проекта необходимо 15,7% всех ресурсов и 38,6% времени;
· в проектах NASA, в которых затрачивалось более 10% всех ресурсов на разработку требований, затраты и отклонения от графика оказались существенно ниже, чем в проектах, где на требования затрачивалось меньше ресурсов (Hooks и Farry, 2001);
· исследования, проведенные в Европе, показали, что команды, разрабатывающие продукты более быстро, посвятили больше времени и усилий требованиям, чем более медленные команды (табл. 17-1) (Blackburn, ScuddernVanWassenhove, 1996).
Не все ресурсы на разработку требований должны расходоваться в начале проекта, как в модели «водопада» или последовательной модели жизненного цикла. В итеративных моделях определенное время на требования будет тратиться в каждом повторном цикле разработки. Цель таких проектов — реализовывать функциональность каждые несколько недель, поэтому требованиями придется заниматься часто, но мало. На рис. 17-2показано, как в разных моделях жизненного цикла в период разработки продукта распределяются усилия на требования.
Таблица 17-1. Затраты на требования ускоряют разработку
| Усилия, затраченные на требования | Время, затраченное на требования | |
| Более быстрые проекты | 14% | 17% |
| Более медленные проекты | 7% | 9% |
Рис. 17-2. Распределение затрат на требования по времени различается для проектов, разрабатываемых на основе различных моделей жизненного цикла
| Ловушка Старайтесь избегать паралича аналитического процесса. Если в самом начале проекта масса усилий тратится на разработку совершенных и полных; требований — «раз и навсегда», то зачастую мало полезной функциональности удается реализовать в срок. С другой стороны, не следует избегать разработки требований вообще только из-за боязни паралича аналитического процесса. |
Требования и расчеты
Первый шаг при оценке проекта — прикинуть объем продукта ПО. Это делают исходя из текстовых требований, моделей анализа, прототипов или элементов пользовательского интерфейса. Хотя не существует идеального мерила размера ПО, чаще всего используются следующие:
· количество отдельно тестируемых требований (Wilson, 1995);
· функциональные точки и характерные точки (Jones, 1996b) или трехмерные функциональные точки, включающие в себя данные, функции и элементы управления (Whitmire, 1995);
· количество, тип и сложность элементов графического пользовательского интерфейса (graphical user interface, GUI);
· оценка строк кода, необходимого для реализации специальных требований;
· количество классов объектов или других объектно-ориентированных метрик (Whitmire, 1997).
Все эти методы годятся для расчета размера. Выбирайте любой, учитывая собственный опыт и природу разрабатываемого ПО. Понимание того, что команда добилась успеха при разработке схожих проектов, используя аналогичные технологии, поможет вам оценить результативность работы команды. Как только вы получите данные о размере, вы сможете воспользоваться коммерческим инструментом для расчета, который предлагает допустимые комбинации затрат на разработку и сроков. Эти средства позволят вам привести в порядок расчеты, выполненные на основе таких факторов, как квалификация разработчиков, сложность проекта, а также опыт команды в данной предметной области. Информация о некоторых доступных средствах оценки ПО опубликована на https://www.laatuk.com/tools/effort_estimation_tools.html. (Сайт закрыт прим. Редактора)
Если вы не сравните ваши расчеты с действительными результатами проекта и не улучшите методы расчета, то ваша оценка вечно будет оставаться всего лишь предположением. Чтобы собрать достаточно данных для корреляции размера ПО с усилиями на его разработку, потребуется время. Ваша цель — вывести уравнения, которое позволит с уверенностью оценить размер завершенного ПО на основании требований к нему.
Однако даже самые лучшие методики не сработают, если клиенты, менеджеры или юристы будут часто менять требования. Если изменения настолько велики, что аналитик и разработчики не успевают их учитывать, команда может впасть в ступор, не имея возможности продолжать проект. В этом случае, возможно, стоит приостановить работу, пока потребности клиентов не прояснятся.
Определенные крайние сроки поставки — головная боль для менеджеров большинства проектов. Каждый раз, когда заданные сроки и тщательно просчитанный график не совпадают, необходимы переговоры. Менеджер проекта, который может аргументировать расчеты, тщательно выполненные и основанные на фактах, выглядит при переговорах гораздо лучше, чем оперирующий предположениями. Если лица, заинтересованные в проекте, не могут разрешить конфликт, разгоревшийся вокруг графика, стоит обратить внимание на бизнес-цели проекта: они будут определять, стоит ли уменьшить объем, добавить ресурсы или согласиться на некоторое снижение качества. Такие решения принимать нелегко, однако это единственный способ максимально повысить ценность подлежащего сдаче продукта.
| Есть час? Как-то клиент попросил наших разработчиков адаптировать небольшую программу, которую он написал для себя, к нашей общей компьютерной сети, чтобы и его коллеги могли ее использовать. «Есть час?» - спросил меня наш менеджер, передавая мне поверхностную оценку размера проекта. Когда я порасспросил клиента и его коллег, чтобы понять, что же им требуется, оказалось, что проблем несколько больше. Я потратил 100 часов только на написание программы, которая им была нужна, без наведения лоска. Тот факт, я потратил в 100 раз больше времени, чем рассчитывал менеджер, говорит о том, что его расчеты были несколько поспешными и основывались на неполной информации. Аналитик должен изучить требования, оценить масштаб и составить представление о размере до того, как кто-нибудь приступит к расчетам или возьмет на себя определенные обязательства. |
Неясно сформулированные требования неизбежно приводят к неточным расчетам размера, затрат и графика. Поскольку определенные неясности в требованиях на ранних стадиях проекта неизбежны, заложите в график и бюджет резерв для непредвиденных обстоятельств, чтобы учесть некоторое разрастание требований (Wiegers, 2002d). Оно происходит из-за изменения ситуации в бизнесе, смещения приоритетов пользователей и рынка, а также того, что со временем заинтересованные в проекте лица лучше начинают понимать, что же продукт может и должен делать. Однако значительное увеличение требований, как правило, указывает на то, что масса положений была упущена в ходе сбора информации.
Отведите время на выбор соответствующих измерений для тех типов проектов, над которыми работает ваша команда. Между размером продукта, затратами, сроком разработки, производительностью и временем становления команды существуют сложные нелинейные взаимоотношения (Putnam и Myers, 1997). Если вы разберетесь в них, вы сможете избежать «области невозможного», то есть такой комбинации факторов, зависящих от размера продукта, графика и сотрудников, при которой еще не один продукт не был успешно разработан.
| Ловушка Не позволяйте, чтобы на ваши расчеты влияли желания других. Ваши прогнозы не должны меняться только потому, что кому-то они не нравятся. Слишком большое несоответствие в прогнозах указывает на необходимость переговоров. |
Требования и график
В некоторых проектах применяется график «справа - налево»: сначала устанавливают дату поставки продукта, а затем определяют требования. В таком случае разработчики зачастую часто не успевают закончить работу в указанные сроки, включив в ПО всю необходимую функциональность соответствующего уровня. Более реалистично определить требования к ПО до составления подробных планов и принятия определенных обязательств. Тем не менее стратегия «проектирования по расписанию» может сработать, если менеджеру проекта удастся договориться с заказчиком, какая часть желаемой функциональности удовлетворит его в указанные сроки. Как и всегда, расстановка приоритетов требований — ключевой фактор для успеха проекта.
Для сложных систем, в которых ПО является лишь частью конечного продукта, детальные графики, как правило, составляются после разработки требований на уровне продукта (системы) и предварительного определения архитектуры. На этом этапе ключевые даты поставки могут быть определены и согласованы на основе информации из таких источников, как отдел маркетинга, отдел продаж, отдел по работе с клиентами и разработчики.
Рассмотрите возможность поэтапного планирования и финансирования проекта. На стадии первоначального изучения требований вы получите достаточно информации, чтобы составить реалистичные планы и расчеты для одного или более этапов сборки. Проекты, требования к которым сформулированы нечетко, выиграют в случае поэтапного цикла разработки. Эта модель позволит разработчикам приступить к созданию качественного ПО задолго до полного выяснения требований. Расставив приоритеты требований, вы сможете определить очередность включения функциональности на каждом этапе.
Часто причина неудачи проекта по разработке ПО кроется в том, что разработчики и другие участники проекта плохо составляют планы, а не в том, что они плохие специалисты. К главным ошибкам планирования относятся пропуск стандартных задач, недооценка затрат или сроков, а также проектных рисков, необоснованный оптимизм. Кроме того, не забудьте учесть возможные переделки. Эффективное планирование проекта предполагает наличие следующих элементов:
· оценку размера продукта;
· информацию о производительности специалистов, основанную на прошлом опыте;
· список задач, которые необходимы для полной реализации или проверки функции или варианта использования;
· требования с приемлемым уровнем стабильности;
· опыт, который позволит менеджеру проекта учесть нематериальные факторы и индивидуальные особенности каждого проекта.
| Ловушка Не поддавайтесь давлению и не принимайте на себя невыполнимых обязательств. Это верный путь к неудаче. |