Создание сценария

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

Операция: Работа над сценариями методом "мозгового штурма"

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

Операция: Определение приоритетов в списке сценариев

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

Операция: Формулировка описания сценария

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

Операция: Раскадровка сценария

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

Ведение проекта

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

Операция: Оценка хода выполнения

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

Операция: Оценка пороговых значений показателей тестов

В документе с описанием подходов к тестированию указаны пороговые значения для показателей тестов. Необходимо периодически анализировать продвижение проекта в соответствии с этими показателями и при необходимости их корректировать. Эффективность тестов, число неисправностей, охват кода, подробные отчеты о выполненных тестах - все это поможет контролировать выполнение проекта. Затем, при необходимости, можно скорректировать курс.

Операция: Определение риска

Своевременно необнаруженный и неконтролируемый риск может отрицательно сказаться на выполнении проекта. Риски имеют место в различных областях. Например, в одном проекте риск может быть связан с эргономикой, поскольку эта область принципиально важна для заказчика, а в другом проекте риски могут быть связаны с производительностью. Важно четко определить и учесть наиболее опасные риски в первых же итерациях проекта. По мере появления дополнительных сведений о сценариях и требованиях к качеству в каждой последующей итерации уделите время поиску новых возможных рисков.

Операция: Обзор целей

После всех итераций, кроме нулевой, продукт должен быть в стабильном состоянии и готовым к поставке. Установите показатель минимального приемлемого уровня ( minimum acceptance level ), чтобы в дальнейшем сравнивать реализованные сценарии и требования к качеству с этим уровнем. Минимальный приемлемый уровень должен постоянно переоцениваться с учетом изменений потребностей заказчика, состояния рынка и т. д. Минимальный приемлемый уровень обновляется после каждой итерации.

Операция: Классификация дефектов

Классификация ( triage ) - процесс анализа вновь обнаруженных или заново обрабатываемых дефектов, назначения им приоритетов и привязки к определенным итерациям. Классификацию проводит менеджер проекта с участием других участников проектной группы.