Описатели

Сценарий

Сценарий (scenario) - это разновидность описателя, в котором записывается один из возможных вариантов взаимодействия пользователя с системой. Сценарий содержит запись последовательности действий пользователя, которые он выполняет для достижения некоторой цели. В одних сценариях фиксируются успешные попытки, в других - безуспешные. При записи сценария нужно указывать, какой конкретный путь достижения цели описывается, поскольку таких путей множество.

Состояния и переходы

Состояние: Новый: Сценарии добавляются в список, который находится в папке сценариев библиотеки документов.

• Переход: От нового к активному
  • Основание: Новый: Сценарий считается новым, когда создается впервые.

Состояние: Активный: Начальное состояние сценария - активный. Бизнес-аналитик создает сценарий, указывая для него информативное название, и заполняет поле описания как можно более подробными сведениями о нем. После того как сценарий полностью описан, бизнес-аналитик назначает его ведущему разработчику. В поле "Specified" (Описан) устанавливается значение "Yes" (Да) и сценарий остается в активном состоянии на время его реализации. Ведущий разработчик координирует с другими разработчиками действия, необходимые для реализации данного сценария.

• Переход: От активного к обработанному
  • Основание: Завершен: Сценарий переводится в состояние обработанного на основании "Completed" (Завершен), если команда разработчиков закончила написание кода, реализующего данный сценарий. Ведущий разработчик назначает сценарий тестировщику
  • Основание: Разделен: Сценарий переводится в состояние обработанного на основании "Split" (Разделен), если выяснилось, что он слишком объемный или что требуется описание дополнительных деталей. При разбиении сценария создайте новые сценарии и свяжите их с начальным сценарием.
  • Основание: Отложен: Основание "Deferred" (Отложен) устанавливается для сценария, который не будет реализован в данной итерации. Реализация сценария может быть отложена из-за нехватки времени у разработчиков или обнаружения проблем, блокирующих работу. В поле "Iteration" (Итерация) нужно указать правильный номер итерации, в которой сценарий будет реализован. Если реализация сценария откладывается до следующей версии продукта, поле "Iteration" (Итерация) нужно оставить пустым. Не забудьте предоставить подробное описание причин, по которым отложена реализация сценария, и укажите планируемые сроки работы над ним.
  • Основание: Удален: Сценарий удаляется ("Removed"), если его реализация больше не считается целесообразной. При удалении сценария проверьте поля "Issue" (Препятствие) и "Exit Criteria" (Условия завершения). Обычно для удаленных сценариев в этих полях содержится "No" (Нет).

Состояние: Обработанный: После реализации сценария ведущий разработчик устанавливает его состояние в "Resolved" (Обработанный). Ведущий разработчик также назначает этот сценарий тестировщику после чего можно начинать его проверку.

• Переход: От обработанного к закрытому
  • Основание: Завершен: Сценарий закрывается как "Completed" (Завершен), когда тестировщик сообщает о прохождении тестов. При завершении работы со сценарием проверьте поля "Issue" (Препятствие) и "Exit Criteria" (Условия завершения). Обычно для завершенных сценариев в этих полях содержится "No" (Нет).
  • Основание: Разделен: Сценарий закрывается на основании "Split" (Разделен), если выяснилось, что он слишком объемный или требуется описание дополнительных деталей.
  • Основание: Отложен: Основание "Deferred" (Отложен) устанавливается для сценария, который не будет реализован в данной итерации.
  • Основание: Удален: Сценарий удаляется ("Removed"), если его реализация больше не считается целесообразной.
• Переход: От обработанного к активному
  • Основание: Тест не проходит: Если какие-либо тесты сценария не проходят, тестировщик должен вернуть сценарий в активное состояние и снова назначить его ведущему разработчику, создавшему данный сценарий. Тестировщик также должен создать соответствующий описатель дефекта для сбоя теста.

Состояние: Закрытый: Тестировщик закрывает сценарий при прохождении всех тестов. Сценарий также закрывается, если он откладывается, удаляется или разбивается на более мелкие.

• Переход: От закрытого к активному
  • Основание: Повторная активация: Сценарий может быть заново переведен в активное состояние при изменении функциональности.

Риск

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

Состояния и переходы

Состояние: Новый: Описатель нового риска создается в любой момент, когда определяется риск. Этот новый описатель должен содержать название и описание, которые четко определяют потенциальные последствия риска. Также должно быть указано возможное воздействие риска. Новый описатель риска может быть создан любым участником команды и должен быть назначен специалисту, который будет отслеживать этот риск до его закрытия или переназначения.

• Переход: От нового к активному: Описатель нового риска создается в любой момент, когда определяется риск. Для его создания используется меню в Team Explorer.
  • Основание: Новый: Описатель нового риска создается в любой момент, когда потенциальный риск может повлиять на проект. Для его создания используется меню в Team Explorer.

Состояние: Активный: Когда с помощью Team Explorer создается новый описатель риска, его состояние автоматически устанавливается в "Active" (Активный). Активное состояние риска указывает, что может произойти некоторое событие, способное повлиять на проект. Каждый риск должен быть назначен некоторому владельцу.

• Переход: От активного к закрытому
  • Основание: Снижен: Риск может быть закрыт с указанием основания "Mitigated" (Снижен), если были предприняты некоторые действия для предотвращения возникновения рискованного события и/или уменьшения воздействия риска до приемлемого уровня.
  • Основание: Неактивный: Риск может быть закрыт на основании "Inactive" (Неактивный), когда вероятность его возникновения можно игнорировать. Никаких действий предпринимать не требуется.
  • Основание: Переведен: Риск может быть закрыт на основании "Transferred", если его можно вынести за рамки проекта. При этом сам риск не исчезает. Он лишь не влияет на проект в его текущем состоянии. Примеры перевода рисков: перемещение риска на следующую версию, привлечение сторонних консультантов или покупка готового программного компонента вместо его разработки.
  • Основание: Принят: Некоторые события невозможно предотвратить или снизить их воздействие. В таких случаях члены команды принимают риск, осознавая его эффект. При этом указывается основание закрытия "Accepted" (Принят).
  • Основание: Аннулирован: Риска может больше не быть из-за изменений в проекте или изменений в самом риске. Отслеживать его в проекте больше нет оснований и он закрывается как "Avoided" (Аннулирован).

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

• Переход: От закрытого к активному
  • Основание: Повторная активация: Риск может возникнуть снова и при этом повторно активируется. Его состояние при этом меняется с "Closed" (Закрытый) на "Active" (Активный).