Гибкая методология разработки программного обеспечения

Описатели

Показывать лекцию целиком

Дефект

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

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

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

  • Переход: От нового к активному: Новый описатель дефекта создается в узле Work Items (Описатели) Проводника команды.
  • Основание: Новый: Дефект считается новым, когда создается впервые. Указывайте основание для создания всех описателей дефектов как "New" (Новый), если они не являются сбоями при сборке продукта.
  • Основание: Сбой при сборке: Основанием для создания описателя дефекта считается сбой при сборке, если выявленная проблема является прямым следствием безуспешной сборки продукта.
    •

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

  • Переход: От активного к решенному: Чтобы перевести проблему в состояние решенной, ее надо назначить или лицу, создавшему описатель дефекта, или тестировщику чтобы они смогли проверить, устранен ли дефект.
  • Основание: Исправлен: Дефект считается исправленным ("Fixed") после внесения изменений в соответствующий код и его регистрации в системе управления версиями. Свяжите дефект с набором изменений ( changeset ) после регистрации исправленного кода.
  • Основание: Так задумано: Основание решения проблемы "As Designed" (Так задумано) указывается, если кажущийся дефект соответствует ожидаемому состоянию или поведению системы.
  • Основание: Отложен: Основание "Deferred" (Отложен) устанавливается для дефекта, который не будет исправляться в данной итерации. Его исправление откладывается до следующих итераций или версий.
  • Основание: Повтор: Основание разрешения проблемы "Duplicate" (Повтор) устанавливается для дефектов, которые уже имели место. Добавьте ссылку на повторяющийся дефект, чтобы автору записи о дефекте было проще подтвердить повторение ошибки, прежде чем закрыть запись.
  • Основание: Неактуален: Основание "Obsolete" (Неактуален) устанавливается для дефектов, которые уже неприменимы к продукту. Например, если речь идет о проблеме, связанной с функцией, от которой отказались.
  • Основание: Невозможно воспроизвести: Основание "Unable to Reproduce" (Невозможно воспроизвести) устанавливается для ошибок, которые разработчик не может заново воссоздать на своем компьютере.
    •

    Состояние: Решен: Дефект находится в состоянии решенного, когда он отработан разработчиком или во время классификации. Основанием для перехода в это состояние может быть "Fixed" (Исправлен) или "As Designed" (Так задумано).

  • Переход: От решенного к закрытому: Дефект считается закрытым, когда его решение проверено инициатором создания описателя дефекта или тестировщиком.
  • Основание: Исправлен: Дефект закрывается с основанием "Fixed" (Исправлен), когда автор описателя дефекта убеждается, что сборка продукта содержит исправления.
  • Основание: Так задумано: Дефект закрывается с основанием "As Designed" (Так задумано), когда автор описателя дефекта соглашается с тем, что дефект соответствует запланированному поведению системы.
  • Основание: Отложен: Дефект закрывается с основанием "Deferred" (Отложен), если автор описателя дефекта согласен, что исправление дефекта нужно отложить.
  • Основание: Повтор: Дефект закрывается с основанием "Duplicate" (Повтор), если автор описателя дефекта подтверждает, что этот описатель соответствует уже зафиксированной проблеме.
  • Основание: Неактуален: Дефект закрывается с основанием "Obsolete" (Неактуален), если автор описателя дефекта согласен, что описанная проблема больше не может иметь отношения к продукту.
  • Основание: Невозможно воспроизвести: Дефект закрывается с ос нованием "Unable to Reproduce" (Невозможно воспроизвести), если автор описателя дефекта не может воссоздать ситуацию возникновения зафиксированной проблемы или дать более подробные инструкции для ее повторной инициации.
    •
  • Переход: От решенного к активному: Если решение не может быть проверено, состояние описателя дефекта возвращается к активному ("Active"). Например, если при работе исправленного кода снова повторяется та же проблема, тестировщик может вернуть дефект в состояние активного. При возврате дефекта в активное состояние не забудьте переназначить дефект соответствующему специалисту для классификации или исправления.
  • Основание: Решение запрещено: Дефект возвращается в состояние активного, если решение проблемы недопустимо. Чтобы упростить работу другим людям, которые будут заниматься этой проблемой, предоставьте конкретную информацию о причинах запрета.
  • Основание: Неверное исправление: Дефект возвращается в состояние активного, если исправление было некорректным. Подробно опишите, как и почему исправленная версия работала неверно.
  • Основание: Тест не проходит: Дефект возвращается в состояние активного, если тесты показывают, что ошибка не исправлена. Подробно опишите, какой тест и в какой сборке (build) не прошел.

    • Состояние: Закрыт: Дефект в состоянии "закрыт" не требует дальнейших действий в текущей версии продукта. Дефект закрывается после проверки его решения.

  • Переход: От закрытого к активному: Закрытый дефект может быть переведен в состояние активного, если регрессионное тестирование показывает повторное возникновение проблемы.
  • Основание: Рецидив: Если при регрессионном тестировании дефект обнаруживается вновь, переведите его в активное состояние и классифицируйте. В поле "Reason" (Основание) установите значение "Regression" (Рецидив).
    •
    Поля
    НазваниеОбязательное. В поле "Title" (Название) кратко описывается решаемая проблема. Название должно быть достаточно информативным, чтобы специалисты, осуществляющие классификацию, могли понять, на какую часть системы влияет проблема и каким образом
    ОбластьПоле "Area" (Область) применяется для группировки дефектов по функциям или проектным группам в иерархии проекта. Область должна быть допустимым узлом в иерархии проекта
    Итерация В поле "Iteration" (Итерация) указывается итерация, в которой дефект исправлен
    Кому назначен В этом поле ("Assigned To") указывается специалист, который в данный момент отвечает за обработку дефекта. Если для устранения дефекта требуется несколько различных исправлений, он может рассматриваться как сценарий и может быть назначен следующему в иерархической цепочке лицу. После интеграции всех частей исправления отчет о дефекте назначается тестировщику
    ПриоритетОбязательное. Приоритет ("Priority") - это субъективная оценка важности. Приоритет 1 указывает, что продукт не готов к поставке и должен быть исправлен как можно скорее. Приоритет 2 указывает на важный дефект, который нет необходимости исправлять немедленно, но необходимо устранить до поставки продукта. Приоритет 3 указывает на дефект, который можно исправлять или нет, в зависимости от ресурсов, времени и рисков
    СостояниеОбязательное. В поле "State" (Состояние) указывает одно из возможных состояний дефекта: "Active" (Активный), "Resolved" (Решенный) или "Closed" (Закрытый)
    ОснованиеОбязательное. В поле "Reason" (Основание) указывается, на каком основании дефект переведен в его текущее состояние. Например, "Fixed" (Исправлен) - одно из возможных оснований перевода дефекта в состояние решенного
    Описание Поле "Description" (Описание) служит для описания проблемы и шагов для ее воспроизведения
    Архив По мере обработки ошибки в поле "History" (Архив) накапливаются записи. При каждом изменении, связанном с дефектом, в это поле добавляется запись со сведениями о том, какие сделаны изменения, почему, а также другими подробностями
    Препятствие В поле "Issue" значения "Yes" (Да) и "No" (Нет) указывают на наличие или отсутствие проблем, каким-то образом препятствующих исправлению дефекта. Если в поле указано "Yes" (Да), в отчете о проблемах менеджера проекта будут содержаться сведения о соответствующем дефекте
    Найдено в сборке В этом поле ("Found in Build") указывается номер сборки, в которой был обнаружен дефект
    Решено в сборке В этом поле ("Resolved in Build") хранится номер сборки, в которой проблема была решена
    Название теста В этом поле ("Test Name") указывается название теста, связанного с данным дефектом
    Идентификатор теста В этом поле ("Test ID") указывается идентификатор теста, связанного с данным дефектом
    Расположение теста В этом поле ("Test Path") указывается путь, по которому расположен тест, связанный с данным дефектом
    Ссылки Ссылки ("Links") на связанные с данным описателем другие описатели, гиперссылки, наборы изменений или файлы с исходным кодом
    Вложения В этом поле ("File Attachments") указываются файлы, содержащие дополнительные сведения о дефекте
    Ранг Относительный приоритет с учетом других описателей ("Rank")
    Классификация Содержит результаты совещания по классификации ("Triage"). Если поле не заполнено, значит дефект не классифицирован

    Требования к качеству

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

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

    Состояние: Новое: Требования к качеству добавляются в список, который находится в папке требований библиотеки документов, или с помощью описателя в Team Explorer (Проводник команды).

  • Переход: От нового к активному
  • Основание: Новое: Требование к качеству активируется как новое припервом создании.
    •

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

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

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

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

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

  • Переход: От закрытого к активному
  • Основание: Повторная активация: Отложенное требование к качеству активируется заново, когда начинается итерация, на которую назначена его реализация. Если требование все еще нужно задокументировать, назначьте его бизнес-аналитику Если же требование готово к реализации, назначьте его ведущему разработчику. При повторной активации удаленных требований, следуйте той же процедуре, что и для отложенных требований.
    •
    Название Обязательное. Название должно быть максимально информативным
    Область Поле "Area" (Область) применяется для группировки требований к качеству по функциям или проектным группам. Область должна быть допустимым узлом в иерархии проекта
    Итерация В поле "Iteration" (Итерация) указывается итерация, в которой требование к качеству реализовано в коде
    Тип Имеется пять типов требований к качеству: "Load" (Нагрузка), "Stress" (Стресс), "Performance" (Производительность), "Platform" (Платформа), "Other" (Прочее) и "Security" (Безопасность)
    Кому назначено В данном поле ("Assigned To") указывается специалист, который в данный момент отвечает за реализацию требования
    Состояние Обязательное. В поле "State" (Состояние) указывается одно из возможных состояний требования: "Active" (Активное), "Resolved" (Обработанное) или "Closed" (Закрытое)
    Основание В поле "Reason" (Основание) указывается, на каком основании требование к качеству переведено в его текущее состояние. Например, "Completed" (Завершено) - одно из возможных оснований перевода требования в состояние закрытого
    Описание Поле "Description" (Описание) служит для описания требования к качеству. Опишите требование как можно подробнее, чтобы разработчику было проще его реализовать, а тестировщику - проверить
    Архив По мере обработки ошибки в поле "History" (Архив) накапливаются записи. При каждом изменении требования в это поле добавляется запись со сведениями о том, какие сделаны изменения, почему, а также другие подробности
    Препятствие В поле "Issue" значения "Yes" (Да) или "No" (Нет) указывают на наличие или отсутствие проблем, каким-то образом препятствующих реализации требования. Если в поле указано "Yes" (Да) в отчете о проблемах, который получает менеджер проекта, будут сведения о данном требовании
    Условия завершения В поле "Exit Criteria" значения "Yes" (Да) или "No" (Нет) указывают, входит ли реализация данного требования в список обязательных работ (backlog) для текущей итерации. Это поле применяется для синхронизации различных представлений списка обязательных работ (список сценариев, набор требований к качеству и план итерации). Если условия завершения установлены в "Yes" (Да), данное требование к качеству отображается в контрольном списке проекта и одном из конечных продуктов. Данное поле в следующей версии будет переименовано в "Iteration Backlog" (Список обязательных работ в итерации)
    РангЗначение в этом поле ("Rank") указывает важность данного требования к качеству относительно всех прочих требований к программному продукту
    Сборка с реализациейВ поле "Integration Build" хранится номер сборки (build), в которой содержится реализация данного требования
    Идентификатор В поле "ID" хранится уникальный идентификационный номер требования к качеству
    Приблизительный порядок величины Приблизительный порядок величины ("Rough order of magnitude") - это способ оценки трудозатрат на реализацию сценария или требования к качеству. Если требуется выполнить не более шести заданий, требующих 1-2 дня, в этом поле указывается значение 1. Если требуется выполнить от 6 до 12 заданий, требующих 1-2 дня, в этом поле указывается значение 2. Если трудозатраты больше, в данном поле указывается значение 3 и рассматривается возможность разбиения на части задачи реализации сценария или требования к качеству

    Сценарий

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

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

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

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

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

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

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

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

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

  • Переход: От закрытого к активному
  • Основание: Повторная активация: Сценарий может быть заново переведен в активное состояние при изменении функциональности.
    •
    Название Обязательное. Название должно отражать цель выполнения сценария. Название должно быть максимально информативным
    Область Поле "Area" (Область) применяется для группировки сценариев по функциям или проектным группам. Область должна быть допустимым узлом в иерархии проекта
    Итерация Итерация, в которой реализован сценарий
    Кому назначено Ответственный за работу со сценарием
    СостояниeОбязательное. В поле "State" (Состояние) указывается одно из возможных состояний сценария: "Active" (Активный), "Resolved" (Обработанный) или "Closed" (Закрытый)
    Основание В поле "Reason" (Основание) указывается, на каком основании сценарий переведен в его текущее состояние. Например, "Completed" (Завершен) - одно из возможных оснований перевода сценария в состояние закрытого
    Описание Описание сценария на достаточно общем уровне. Подробное описание сценария должно быть в одном из конечных продуктов
    Архив По мере обработки сценария в поле "History" (Архив) накапливаются записи. При каждом изменении, связанном со сценарием, в это поле добавляется запись со сведениями о том, какие сделаны изменения, почему, а также другие подробности
    Препятствие В поле "Issue" значения "Yes" (Да) или "No" (Нет) указывают на наличие или отсутствие проблем, каким-то образом препятствующих реализации сценария. Если в поле указано "Yes" (Да), в отчете о проблемах менеджера проекта будет присутствовать соответствующий сценари й
    Условия завершения В поле "Exit Criteria" значения "Yes" (Да) или "No" (Нет) указывают, входит ли данный сценарий в список обязательных работ (backlog) для текущей итерации. Это поле применяется для синхронизации различных представлений списка обязательных работ (список сценариев, набор требований к качеству и план итерации). Если условия завершения установлены в "Yes" (Да), данный сценарий отображается в контрольном списке проекта и одном из конечных продуктов. Данное поле в следующей версии будет переименовано в "Iteration Backlog" (Список обязательных работ в итерации)
    Ранг Значение в этом поле ("Rank") указывает важность данного сценария относительно всех прочих сценариев
    Сборка с реализацией В поле "Integration Build" хранится номер сборки ("Build"), в которой содержится реализация данного сценария
    ИдентификаторВ поле "ID" хранится уникальный идентификационный номер сценария
    Приблизительный порядок величины Если требуется выполнить от 6 до 12 заданий, требую щих 1-2 дня, в этом поле указывается значение 2. Приблизительный порядок величины ("Rough order of mag-nitude") - это способ оценки трудозатрат на реализацию сценария или требования к качеству. Если трудозатраты больше, в данном поле указывается значение 3 и рассматривается возможность разбиения на части задачи реализации сценария или требования к качеству. Если требуется выполнить не более шести заданий, требующих 1-2 дня, в этом поле указывается значение 1.

    Риск

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

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

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

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

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

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

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

  • Переход: От закрытого к активному
  • Основание: Повторная активация: Риск может возникнуть снова и при этом повторно активируется. Его состояние при этом меняется с "Closed" (Закрытый) на "Active" (Активный).
    •
    Название Обязательное. В поле "Title" (Название) кратко описывается потенциальный риск. Название должно быть достаточно информативным, чтобы участникам команды было понятно, с чем связан риск
    Область Поле "Area" (Область) применяется для группировки рисков по функциям или проектным группам. Область должна быть допустимым узлом в иерархии проекта
    Кому назначено Ответственный за отслеживание риска. Обычно это менеджер проекта или архитектор, но ответственным может быть и любой другой член проектной группы
    СерьезностьСерьезность ("Severity") содержит оценку влияния неблагоприятного эффекта, уровень потерь или возможных затрат на устранение риска ("Low" - низкая, "Medium" - средняя, "High" - высокая или "Critical" - критическая)
    Основание В поле "Reason" (Основание) указывается, на каком основании риск переведен в его текущее состояние. Например, "Avoided" (Аннулирован) - одно из возможных оснований перевода риска в состояние закрытого
    Состояние Обязательное. В поле "State" (Состояние) указывается одно из возможных состояний риска: "Active" (Активный) или "Closed" (Закрытый)
    Итерация Итерация, в которой может произойти рискованное событие
    Приоритет Приоритет описывает важность риска по отношению к другим рискам; удобен для определения последовательности, в которой следует снижать риски
    Ссылки Ссылки ("Links") на связанные с данным описателем другие описатели, гиперссылки, наборы изменений или файлы с исходным кодом
    Вложения В этом поле ("File Attachments") указываются файлы, содержащие дополнительные сведения о риске
    Препятствие В поле "Issue" значения "Yes" (Да) или "No" (Нет) указывают на наличие или отсутствие проблем, каким-то образом препятствующих обработке риска. Если в поле указано "Yes" (Да), в отчете о проблемах менеджера проекта будет присутствовать соответствующий сценарий
    Условия завершенияВ поле "Exit Criteria" значения "Yes" (Да) или "No" (Нет) указывают, входит ли обработка данного риска в список обязательных работ (backlog) для текущей итерации. Это поле применяется для синхронизации различных представлений списка обязательных работ (список сценариев, набор требований к качеству и план итерации). Если условия завершения установлены в "Yes" (Да), данный риск отображается в контрольном списке проекта и одном из конечных продуктов. Данное поле в следующей версии будет переименовано в "Iteration Backlog" (Список обязательных работ в итерации)
    Описание В данном поле содержится описание риска, его воздействие на проект и возможные варианты его уменьшения
    Архив В данном поле фиксируются все изменения, происходящие с описателем

    Задача

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

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

    Состояние: Новый: Новый описатель задачи может быть создан в любой момент, когда обнаруживается потребность в выполнении той или иной работы. Существуют три типа задач. Задачи по разработке связаны с выработками архитектурных решений, а также с реализацией сценариев или требований к качеству. Тестовые задачи соответствуют необходимым тестам. Третий тип относится к работам, выходящим за рамки этих двух областей. Для создания описателя задачи используется Team Explorer (Проводник команды).

  • Переход: От новой к активной
  • Основание: Новая: Задача считается новой, если создается впервые.
    •

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

  • Переход: От активного к закрытому
  • Основание: Завершена: Задача закрывается как завершенная ("Completed"), если проделаны все составляющие ее работы.
  • Основание: Отложена: Основание "Deferred" (Отложена) устанавливается для задачи, которая не будет выполнена в данной итерации. Выполнение задачи может быть отложено из-за нехватки времени у разработчиков или обнаружения проблем, блокирующих работу. В поле "Iteration" (Итерация) нужно указать правильный номер итерации, в которой задача будет выполнена.
  • Основание: Неактуальна: Задача закрывается с основанием "Obsolete" (Неактуальна), если ее описатель представляет работу, которая больше не нужна для реализации продукта.
  • Основание: Вырезана: Задача закрывается с основанием "Cut" (Вырезана), если реализуемые ею функции удалены из продукта.
    •

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

  • Переход: От закрытого к активному
  • Основание: Повторная активация: Задача по разработке или тестированию может быть заново переведена в активное состояние при изменении функциональности.
    •
    Название Обязательное. В поле "Title" (Название) кратко описывается решаемая задача. Название должно быть достаточно информативным, чтобы специалисты, осуществляющие классификацию, могли понять, на какую часть системы влияет решаемая задача и каким образом
    Дисциплина Указывает тип задачи: разработка, тестирование или прочее. Задачи по разработке и тестированию предполагают определенное состояние работ при закрытии задачи
    Область Поле "Area" (Область) применяется для группировки задач по функциям или проектным группам. Область должна быть допустимым узлом в иерархии проекта
    Итерация Запланированная итерация, в которой произошло исправление дефекта
    Кому назначена Ответственный за выполнение задачи
    Состояние Обязательное. В поле "State" (Состояние) указывается одно из возможных состояний задачи: "Active" (Активная) или "Closed" (Закрытая)
    Основание Обязательное. В поле "Reason" (Основание) указывается, на каком основании задача переведена в ее текущее состояние. Задача может быть закрыта, потому что она завершена, отложена, вырезана или неактуальна
    РангОбязательное. Ранг (поле "Rank") - это субъективная оценка важности. Значение "1" указывает на высокую важность задачи - ее необходимо выполнить как можно раньше. Значение "2" присваивается достаточно важным задачам, которые должны быть выполнены после задач с рангом 1. Ранг 3 имеют задачи, выполняемые после задач с рангом 1 и 2
    Краткое описание Краткое описание задачи
    Подробное описание и архив Подробное описание задачи и набор всех предыдущих записей о задаче
    Вложения Ссылки на файлы или другие описатели. Для задач по разработке указываются ссылки на соответствующие сценарии или требования к качеству. Также указываются файлы с поясняющими текстами и другие вспомогательные данные
    Препятствие В поле "Issue" значения "Yes" (Да) или "No" (Нет) указывают на наличие или отсутствие проблем, каким-то образом препятствующих решению задачи. Если в поле указано "Yes" (Да), задача будет отображена в отчете о проблемах менеджера проекта
    Условия завершения В поле "Exit Criteria" значения "Yes" (Да) или "No" (Нет) указывают, является ли данная задача одной из обязательных работ ("Backlog") для текущей итерации. Это поле применяется для синхронизации различных представлений списка обязательных работ (список сценариев, набор требований к качеству и план итерации). Если условия завершения установлены в "Yes" (Да), данная задача отображается в контрольном списке проекта и одном из конечных продуктов. Данное поле в следующей версии будет переименовано в "Iteration Backlog" (Список обязательных работ в итерации)
    Сборка с реализацией Номер сборки, содержащей реализованные функции
    Оставшаяся Объем работ, оставшихся до завершения задачи. Данное работа (в часах) поле синхронизируется с Microsoft Project и может использоваться при применении последнего
    Проделанная работа (в часах)Объем проделанной для решения задачи работы. Данное поле синхронизируется с Microsoft Project и может использоваться при применении последнего
    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^