Планирование проекта (CMMI)
Требуемый результат планирования проекта — план, включающий в себя область, расписание, бюджет, план управления рисками, а также обязательства всех заинтересованных лиц и одобрение всеми заинтересованными лицами.При наличии согласованного плана проекта можно перейти к анализу и затем выполнить проектирование, разработку, тестирование и в конечном счете поставку.
Снизить риск можно, используя метод последовательной разработки.Этот метод позволяет демонстрировать частично работающий продукт в конце каждой итерации и действовать в соответствии с отзывами на такую демонстрацию.Таким образом, план обеспечивает общий шаблон и до начала каждой итерации анализируется и уточняется.
Содержание раздела
Сбор и моделирование требований
Создание добавочных требований к продукту
Ввод и изменение требований к продукту
Оценка требований к продукту
Назначение требований к продукту итерациям
Планирование тестов
Пересмотр требований к продукту
Сбор и моделирование требований
На этом этапе необходимые функции системы обсуждаются с заинтересованными лицами из сферы бизнеса, предполагаемыми пользователями и экспертами.Важно понять контекст бизнеса.Если поступил запрос на создание приложения для милиционеров, этот этап помогает понять их профессиональную лексику, процедуры и правила.
Модели UML — полезное средство для представления сложных отношений и размышления о них.Эти модели можно получать в Visual Studio и связывать с другими документами и рабочими элементами Team Foundation.Дополнительные сведения см. в разделе Моделирование требований пользователей.
На протяжении всего проекта модели требований следует обновлять и уточнять.По мере приближения очередной итерации добавляйте дополнительные сведения в аспекты модели, соответствующие данной итерации.Из модели можно получить проверочные тесты.
Дополнительные сведения см. в разделах Developing Customer Requirements и Разработка тестов из модели.
Создание добавочных требований к продукту
Требования, собранные от клиентов, непосредственно не подходят для планирования последовательной разработки.Например, для точного определения процедуры покупки пользователем какого-либо товара на веб-сайте, возможно, была подробна записана последовательность действий: клиент просматривает каталог, добавляет элемент в корзину, проверяет корзину, указывает адрес и производит оплату; склад планирует доставку и т. д.Эти действия или эквивалентная схема деятельности не являются добавочными требованиями.
Вместо этого на первом этапе разработки системы может быть предложен только один элемент для продажи, доставка только по одному адресу и выполнение только тестовой транзакции со службой платежей.На втором этапе можно предоставить каталог, состоящий из простого списка.На последующих этапах можно добавить возможность упаковки купленного товара или запроса каталогов, предоставляемых различными поставщиками.Некоторые этапы могут быть посвящены повышению качества обслуживания, например, обеспечению возможности обслуживания 1000 клиентов, а не только одного.
Другими словами, на ранних этапах следует полностью реализовать основные варианты использования и затем постепенно добавлять функциональные возможности.
При работе с существующим продуктом данный принцип сохраняется, но разработка начинается с учетом существующих функций.Если внутренняя структура продукта неизвестна, оценка стоимости обновлений может быть затруднена.Рекомендуется оценивать ранние изменения с запасом.
Дополнительные сведения см. в разделе Разработка требований.
Ввод и изменение требований к продукту
Зарегистрируйте добавочные требования к продукту в виде рабочих элементов требований в Team Foundation и типу требований присвойте значение "Функция".Можно создать рабочие элементы требований в Team Explorer. При наличии нескольких рабочих элементов, которые нужно создать в то же время можно использовать представление Office Excel запроса требований к продукту.Дополнительные сведения см. в разделах Работа в приложениях Microsoft Excel и Microsoft Project, подключенных к серверу Team Foundation Server и Выполнение планирования сверху вниз при помощи списка дерева рабочих элементов (в программе Excel).
Оценка требований к продукту
Команда разработки должна оценить работу, необходимую для разработки каждого требования к продукту.Оценку следует ввести в часах в поле "Исходная оценка" рабочего элемента.
В начале проекта требуется только грубая оценка.
Большие требования к продукту следует разделить на меньшие.Идеально разработка каждого требования к продукту должна занимать несколько дней.
Назначение требований к продукту итерациям
Представители заинтересованных лиц из сферы бизнеса и команда разработки должны сотрудничать в вопросе назначения требований к продукту итерациям.Обычно такое сотрудничество проходит в форме совещаний, где совместно используется или демонстрируется представление Office Excel запроса требований к продукту.
Ниже перечислены сведения, на основе которых выполняется назначение.
Приоритет требования.См. примечания в следующем подразделе.
Расчетные затраты.С учетом заданного числа участников команды и длительности итерации на каждую итерацию выделяется только фиксированное время разработки (в часах).Кроме того, значительная часть этого времени используется для планирования итерации и других задач, в которые разработка непосредственно не входит.
Зависимости между требованиями к продукту.Сначала следует выполнить самые простые требования набора добавочных требований и только затем вводить улучшения в той же области.
Требование можно определить в рабочем элементе, задав множество сведений, как показано на следующих рисунках.
.png "Форма рабочего элемента для требования")
.gif "Ee461521.collapse_all(ru-ru,VS.110).gif")
Некоторые правила назначения приоритетов
Существует много детальных схем назначения приоритетов.Некоторые из них будут рассмотрены при описании планирования итерации.Сейчас, на уровне проекта, рассмотрим некоторые правила, которые могут быть полезны для управления рисками и оптимизации добавленной стоимости.
Назначение приоритета минимальным сквозным сценариям.
Цель — получение простого сквозного сценария как можно раньше в проекте.Позже следует добавить дополнительные функции в различные части сценария.Это обеспечит раннюю проверку основных функций платформы и основных целей требований.
Не делите расписание в соответствии с архитектурой.Расписание, согласно которому обрабатывается база данных, затем бизнес-логика и затем пользовательский интерфейс, вероятно, потребует большой переработки для объединения отдельных частей в конце.Не рекомендуется также использовать горизонтальную границу, например {компонент продаж; компонент склада; компонент платежа}.Это, вероятно, привело бы к созданию замечательной системы для продаж в Интернете, но для обеспечения предприятия средствами получения денег от клиентов не хватило бы времени.Завершение компонентов можно запланировать на более поздние итерации, только если эти компоненты действительно являются дополнительными.
Назначение приоритета технически рискованным задачам.
Если сценарий содержит технически рискованный элемент, его следует разработать в начале расписания.Для рисков применяйте подход раннего обнаружения неудачи.Если что-то выполнить не удается, выяснить это лучше на раннем этапе проекта, чтобы можно было отменить такую задачу или заменить ее альтернативным подходом.Таким образом, технически рискованные требования следует выполнять на ранних итерациях.
Назначение приоритета уменьшению неопределенности.
У заинтересованных лиц из сферы бизнеса не будет уверенности в отношении некоторых требований.Трудно предсказать, какое поведение продукта будет наилучшим в определенном контексте бизнеса.Уделите первостепенное внимание работе, выполнение которой должно, вероятно, привести к уменьшению неопределенности.Этой цели часто можно достичь путем разработки более простой версии сценария, с которой пользователи могут провести эксперименты.Отложите реализацию всего сценария на более позднюю итерацию, когда можно будет учесть результаты этих экспериментов.
Назначение приоритета очень важным требованиям.
По возможности попытайтесь определить для каждого сценария стоимость задержки реализации возможности.Используйте полученные данные для определения требований, выполнение которых позволит раньше предоставить клиентам дополнительные преимущества.Обеспечьте приоритетное выполнение этих требований на ранних итерациях.В этом случае может появиться возможность выпустить частично реализованный продукт раньше.
Групповые сценарии, являющиеся общими для множества пользователей.
Если имеются сценарии, подходящие для двух или более пользователей, объедините их.Классифицируйте сценарии по количеству пользователей, которым они требуются.Обеспечьте приоритетную реализацию сценариев, применимых для большого числа пользователей, на ранних итерациях.
Классификация пользователей.
Пользователи представляют сегменты рынка или группы пользователей.Специалисты по маркетингу и владельцы предприятий должны быть способны четко определять приоритет таких сегментов или групп на основе обеспечиваемой выгоды или значения сегмента.Если сегменты или группы пользователей можно классифицировать по приоритету, покажите это, перечислив пользователей для каждого сегмента по категориям.Определите сценарии для наиболее важных пользователей и обеспечьте приоритетную реализацию этих сценариев на ранних итерациях расписания.
Таким образом, необходимо уделить первостепенное внимание снижению риска из-за возможной неудачи.Кроме того, нужно уделить первостепенное внимание общим функциям, поскольку они, скорее всего, будут обязательными и вряд ли изменяться.Следует также уделить первостепенное внимание наиболее важным требованиям.Требуется обеспечить возможность раннего выпуска продукта для ряда пользователей, обеспечив приоритетную реализацию всех сценариев, необходимых для удовлетворения потребностей любого пользователя.
Планирование тестов
В оценке работы по каждому требованию должны быть учтены усилия, необходимые для проверки требования вручную или путем создания автоматического теста.
Перед тем как каждое требование к продукту можно будет считать выполненным, его необходимо связать с рядом рабочих элементов тестовых случаев, которые вместе демонстрируют, удовлетворено ли требование; тесты должны пройти.
При создании или пересмотре требований к продукту необходимо обновить соответствующий план тестирования.
Пересмотр требований к продукту
Пересмотрите это действие перед тем как считать каждую итерацию пересмотренной, а также пересмотрите новые требования, пересмотренные приоритеты и пересмотренные оценки.На нескольких первых итерациях будет больше исправлений.
После нескольких первых итераций участники команды разработки будут больше уверены в оценках.Они должны проверить оценки на одной или двух следующих итерациях и пересмотреть значения полей исходных оценок требований, назначенных этим итерациям.