Programmnaya_inzheneria

Обзор существующих шаблонов

На данный момент существует достаточно широкий выбор свободно распространяемых шаблонов процесса разработки, которые можно было бы использовать

вкачестве основы19. Наиболее известными являются следующие шаблоны.

MSF for Agile Software Development – один из двух шаблонов, входящих в поставку TFS. Описывает достаточно простой вариант методологии MSF, используемый для разработки небольших проектов. Входит в стандартную комплектацию TFS.

MSF for CMMI – шаблон, используемый для более компаний, подразумевающий большее число типов элементов работы, а также больше формальных процедур разработки. Входит в стандартную комплектацию TFS.

Conchango SCRUM – шаблон, описывающий широко известную гибкую методологию SCRUM. Не входит в стандартную комплектацию TFS.

MSF for Agile Software Development

В этом шаблоне используются стандартные роли MSF, которые подробно обсуждались выше. В рамках поддержки процесса MSF for Agile соответствующий шаблон объявляет следующие основные типы элементов работы.

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

Требование к качеству сервиса (Quality of Service Requirement, QoS) – описание нефункционального требования к системе (то есть требования, которое, которое не может быть выражено в терминах сценария взаимодействия), например, быстродействие и эффективность использования памяти.

Задача (Task) – задание на выполнение некоторой ограниченной по объему работы в проекте. Для каждой роли задачи могут иметь свою специфику: для разработчика это написание кода, реализующего часть сценария или направленного на достижение определенного качества, а для тестера – написание тестовых сценариев.

Ошибка (Bug) – элемент работы, использующийся для того, чтобы отслеживать и устранять проблемы и ошибки, обнаруженные в системе.

Риск (Risk) – некоторый аспект управления проектом, который может оказать влияние на ход проекта (как правило, негативное).

По умолчанию вместе с активацией этого шаблона на портале Share Point разворачиваются следующие документы.

План разработки в Microsoft Project, настроенный на импорт элементов работы, относящихся к области работы «Разработка». Используется для планирования работы разработчиков.

План разработки тестов – то же самое, только направленно на планирования работы тестеров.

Список проблем – список выявленных проблем, которые необходимо отслеживать (элементов работы с проставленным флагом «Is Issue»).

Список (Check List) основных требований к проекту и их текущий статус.

Cписок неупорядоченных элементов работы, которые нужно приоретизировать и запланировать.

19 http://msdn.microsoft.com/ru-ru/teamsystem/aa718801(en-us).aspx

151

Кроме того, для поддержки процесса используются следующие отчеты.

Ошибки по приоритету – показывает процентное соотношение в проекте ошибок разной степени серьезности и, таким образом, позволяет оценить степень эффективности тестирования.

Рейтинг ошибок – показывает соотношение вновь открытых ошибок к закрытым и оставшихся открытых. Позволяет судить о «здоровье» продукта.

Сборки – позволяет оценивать изменение качества сборок.

Скорость проекта – отчет, демонстрирующий насколько активно закрываются элементы работы, т.е. насколько быстро команда решает поставленные перед ней задачи.

Индикаторы качества – объединяет несколько индикаторов, включая количество дефектов, уровень тестового покрытия и т.д.

Отчет о нагрузочном тестировании – показывает результаты нагрузочного тестирования.

Регрессия – показывает тесты, которые проходили раньше, но теперь стали падать.

Реактивация – показывает то, сколько элементов работы заново переходит в активное состояния после исправления.

Связанные элементы работы – еще один способ просмотра связей элементов работы друг с другом.

Оставшаяся работа – показывает количество элементов работы, которые закрываются, а которые остаются и появляются с течением времени.

Незапланированная работа – показывает соотношение сделанного к запланированному и к незапланированному.

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

Scrum

Шаблон для работы в методологии Scrum был разработан сообществом разработчиков, в настоящий момент поддерживается компанией Conchagp и доступен здесь http://scrumforteamsystem.com. В этом шаблоне используются стандартные роли Scrum, которые подробно обсуждались выше. Определяются следующие элементы работы.

Product Backlog Item – высокоуровневое описание определенной функционального или нефункционального требования. Содержит описание, приоритет, установленный Produсt Owner, а также предварительную оценку трудоемкости. Во многом аналогичен сценарию MSF for Agile.

Sprint – содержит информацию о текущем или запланированном Sprint, включая текущее состояние и объем доступных для спринта ресурсов.

Sprint Backlog Item – более низкоуровневое описание задачи, сформированное самое командой. Аналогична задаче MSF.

Bug – ошибка, обнаруженная при тестировании. Ошибки становятся частью Product Backlog и получают приоритеты от Product Owner.

Sprint Retrospective – описание некоторого элемента (например, проблемы, удачного нововведения), идентифицированного в рамках Sprint Review Meeting и требующего дальнейшего изучения или выполнения некоторых действий.

Impediment – нечто, реально или потенциально мешающее эффективной работе команды. Во многом аналогично риску из MSF.

152

Следует отметить, что описание элементов работы в шаблоне Scrum выгодно отличается от MSF отсутствием большого количества дополнительных, в большинстве случаев ненужных реквизитов, что позволяет сконцентрироваться на наиболее важной информации. Но, с другой стороны, в шаблоне для Scrum фактически не используются ни причины переходов (для каждого перехода определена ровно одна причина), ни правила, ограничивающие переходы. Таким образом, этот шаблон использует лишь часть возможностей, предоставленных TFS.

Среди поставляемых с шаблоном отчетов следует выделить следующие.

Bugs Count – показывает количество ошибок, отсортированных по состоянию и степени влияния на процесс тестирования.

Bugs Fixed and Found – соотношение найденных ошибок к закрытым.

Bug History – показывает количество открытых ошибок в соответствии с их влиянием на процесс тестирования, а также изменение этого количества со временем.

Bug Priority – показывает распределение ошибок по отношению их влияния на процесс тестирования.

Bug Resolution Time – показывает насколько быстро исправляются найденные ошибки.

Development To Test cycle time – демонстрирует, сколько проходит времени между выполнением работы и началом тестирования по этой работе.

Product Burndown – отчет, демонстрирующий, как быстро снижается количество работы, которую нужно сделать в контексте Product Backlog. Может показывать прогресс по дням или спринтам, а также позволяет увидеть общую тенденцию и предсказать дату завершения работ.

Product Cumulative Flow – показывает общее состояние Product Backlog в виде соотношения открытых и закрытых элементов, а также их изменения со временем.

Sprint Burndown и Сumulative Flow – тоже самое, только для Sprint Backlog.

Отдельного упоминания заслуживает система Task Board for Team System, которая позволяет визуализировать представления основного средства управления и мониторинга в Scrum – доски с задачами. Эта система получает информацию о всех элементах Sprint Backlog с сервера и визуализирует их в виде стикеров на доске, позволяя изменять их состояния путем перетаскивания, смю рис. 15.3. Этот продукт можно бесплатно скачать по ссылке http://www.scrumforteamsystem.com/en/TaskBoard/default.aspx.

153