Заметки консультанта

Шамрай Александр Владимирович

Руководство по управлению требованиями VS TFS 2010 – Управление изменениями и утверждение требований

Posted by Шамрай Александр на Апрель 14, 2010

<<Содержание

«Базовая линия – это набор спецификаций или рабочих элементов, который был формально рассмотрен и согласован и впоследствии служит основой для дальнейшей разработки, и который может быть изменен только с использованием процедур контроля изменений. Базовая линия представляет собой назначенный идентификатор для элементов конфигурации и связанных с ней сущностей. «- CMMI, Guidelines for Process Integration and Product Improvement, Chrissis, Konrad, Shrum.

Управление изменениями требований осуществляется для:

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

Управление изменениями требований и утверждение описывает, как участник процесса формально получает утверждение для новых требований или изменений/расширений существующих требований. Фокус в этом разделе будет сделан на описании действий процесса изменения требований, управления базовыми линиями требований и разрешения на продолжение работ по реализации требования. Также будет уделяться большое внимание к соблюдению промышленных стандартов таких, как CMMI и ITIL, соответствие отраслевым нормам такие, как FDA CFR-21, Часть 11 и закона Сарбейнса-Оксли, тоже может рассматриваться.

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

Примечание: Этот раздел руководства по управлению изменениями и утверждения предполагает, что требование на уровне бизнеса, реализовано с использованием рабочего элемента «Возможность» (Feature) Team Foundation Server. Авторы не настаивают на использовании рабочего элемента «Возможность» (Feature) для этой цели и признают, что это добавляет элемент формальности, который можно легко избежать для небольших и более гибких команд.

Управление изменениями и утверждения — Общие сценарии

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

Новые требования

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

Запрос на расширение

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

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

Дефекты требований

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

  • Элементы Запрос на изменение – эти запросы на изменение должны включать в себя данные, необходимые для проведения анализа влияния изменений, а также обеспечивать оценки затрат и утверждение. Эти вопросы можно отнести к неверному пониманию требований определенными заинтересованными лицами в проекте. Как правило, они обеспечивают изменения в первоначальные требования, но также могут быть введены новые требования или открыты требование, которые были помечены как устаревшие и на удаление.
  • Последовательность работ — каждый запрос на изменение должен обеспечить механизмы для обследования, утверждения, назначения, анализа, разработки и проверки нового запроса в ходе жизненного цикла. Этот процесс более строгий для традиционного водопадного проекта и менее формален для гибкого проекта, для гибкой команды существуют правила для внедрения новых требований.
  • Утверждение — этап утверждения необходим для каждого состояния (или «Ворот») рабочего процесса для традиционного проекта. Утверждение на окончании этапа или окончании цикла релиза необходимо для контроля для всех проектов. Релиз для традиционного проекта означает развертывание в конце проекта, а релиз для гибкого проекта выполняется в конце каждой итерации на протяжении всего проекта.

Обнаруженные «на лету»

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

Управление изменениями и утверждение – Поддержка сценариев в Team Foundation Server

Изменения для требований в гибком проекте, в смысле манифеста»Agile Manifesto», очень просты для управления, поскольку они определены и хранятся до начала новой итерации и не отличаются от определения расширений к проекту, который завершен.

Изменения требований в традиционной водопадной модели также просты, но только в механизмах создания, сравнения и утверждения базовой линии. Управление изменениями требований на лету немного сложнее, потому что методика водопада требует не только оценки изменений в требованиях, но и изменения в контексте ВСЕХ других проектных артефактов, плана проекта, последовательности выполнения, проектных зависимостей, качества обслуживания и т.д. Таким образом, управление изменениями и утверждение для традиционного проекта требует дополнительных работ и жесткой привязки к его «воротам» (условиям окончания). Даже при такой политике, предсказуемость гораздо труднее обеспечить для традиционных проектов.

Подготовка управления базовой линии

Требования описаны с помощью конкретных типов рабочих элементов в Team Foundation Server (например, типы рабочего элемента сценарий или пользовательское описание функциональности). Документация (технические характеристики и прототипы) хранятся на SharePoint-сайте проекта. Рабочие элементы связываются с документами сайта проекта с помощью гиперссылок. Эти гиперссылки могут быть размещены и в рабочих элементах, которые задают определенную часть работы в области разработки для разработчика.

Библиотека документов командного сайта построена так, чтобы отражать гибкость подхода, которая соблюдается. В библиотеке Requirements создаются папки как система записей. Это хорошая практика, когда различные виды активов организованы в их собственные папки. Например, требования описания (Stories) должны быть в одной папке, а нефункциональные (Quality of Service) требования должны быть в другой. Документы общие для всего проекта, такие как видение продукта, ограничения продукта или дополнительные характеристики нефункциональных требований, должны быть сохранены в корне папки требований.

Для того чтобы обеспечить трассировку, рабочие элементы история и QoS должны быть связаны с соответствующими документами в папках Stories и QoS.

Рисунок 1. Представление документов в Team Explorer и WSS

На скриншоте выше слева в Team Explorer открыта папка библиотеки документов, отображающая требования и описания. Те же документы отражены в правой части в двух представлениях портала Windows SharePoint Services (WSS). Это сравнение показывает, что члены команды Team Foundation Server могут использовать документы в любом приложении, в зависимости от того, где они больше работают. Разработчики и аналитики, например, могут работать в Team Explorer, в то время как менеджеры и бизнес-аналитики могут использовать портал.

Рисунок 2. Установка связи между рабочими элментами и документами

Документы, хранящиеся на командном сайте также доступны прямо из Visual Studio IDE. Team Foundation Server предоставляет мощный механизм для связывания документов и других артефактов на основе файлов с рабочими элементами. Если документы размещены в библиотеке документации с включенным пунктом «Versioning» в портале для изменений в документах, то связанный рабочий элемент с типом связи «гиперссылка» всегда будет ссылаться на последнюю версию.

Участники проекта могут сравнивать последнюю версию документа с его предшественниками помощью функциональности сравнения в Word, которая осуществляется с помощью возможности «Revision Tracking» версионного хранения портала SharePoint.

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

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

Продвижение базовой линии

Для любой базовой линии требований, может быть единственный набор требований, который относится к релизу. Особенно в тех случаях, когда важно управление и соблюдение требованиям таких, как контроль пищевых продуктов и медикаментов (Food and Drug Administration), для изменений, которые вносятся в требования в течение всего цикла разработки (вставка требований в поставку релиза), имеют значение только утвержденные наборы требований. С точки зрения базовых линий, окончательный набор, привязанный к сборке, поставляемой в релиз, является исходной записью о любых запросах на расширение или дефектах, определенных в поставку.

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

Это руководство описывает оба типа базовых линий в следующих двух подразделах.

Управление внутрифазовыми базовыми линиями

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

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

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

В целях создания базовой линии, все важные артефакты должны быть получены и сохранены в местах, отведенных для базовой линии. Рекомендуется создать библиотеку документов «Project Milestones» с отдельными директориями для каждого этапа. Тут «Iteration 0», «Iteration 1», «Iteration 2» и т.д. Важные артефакты, находящиеся здесь, демонстрируют полною трассировку иерархии от требований бизнеса до кода и результатов тестов, созданных в этой вехе:

  • Выбранные Бизнес-требования – используя запросы для рабочих элементов с фильтром для рабочих элементов «Возможность» (Feature) со всеми атрибутами, которые способствуют решению для разработки приложений, можно выбрать весь набор в Excel таблицу и сохранить в каталоге вехи.
  • Выбранные Сценарии – используя запрос для рабочих элементов с фильтром по рабочим элементам «Сценарий» (Scenario), связанные только с вехой (например, «Iteration Path = Iteration 0»), со всеми их атрибутами, можно извлечь весь набор в Excel таблицу и сохранить в каталог вехи.
  • Выбранные Задачи – то же, что сценарии, но только фильтр по рабочим элементам «Задача» (Task) для итерации.
  • Описания – каждый документ, который представляет собой фрагмент сценария итерации, должен быть скопирован в каталог вехи. Хотя ревизия истории в SharePoint позволяет сравнивать документы от версии к версии, эта копия позволит легче сравнивать принятую «базовую версию» и текущие изменения. Без этой копии будет трудно понять, какой документ нужно сравнивать.
  • Другие документы — любые другие документы такие, как спецификация проектирования, документ видение, архитектура и характеристика инфраструктуры и т.д., должны быть скопированы в каталог вехи.
  • Отчет сборки — снимок окончательной сборки позволит установить связь между документацией (рабочими элементами и файлами) для базовой линии и исходными файлами, тестами и результатами тестов для той же базовой линии. Отчет по сборке – это отчет, который поставляется как стандарт с шаблонами процессов «MSF for Agile» «и «MSF for CMMI». Это список всех сборок, хранящихся в системе. Только одна имеет значение, которая является окончательной сборкой для итерации, представляющую базовую линию. Эта информация должна храниться в виде файла в папке вехи итерации.

Рисунок 3. Файлы для базовой линии итерации

Рисунок 4. Финальный отчет для сборки итерации

В отчете сборки выше отображается сборка, шаги сборки по компиляции и шаги создания связей, результаты тестов сборки, включая статусы «тест прошел / не прошел», а также (хотя и не показано на рисунке) рабочие элементы и наборы изменений, которые вошли в сборку (как отчетный материал).

Утверждение базовой линии

Многие методики, особенно которые используют отраслевые стандарты (CMMI) или государственные регулирования (FDA, закон Сарбейнса-Оксли), требуют пересмотра и утверждения базовых линий. При создании базовых линий, как описано выше, WSS может поддерживать такой цикл утверждения.

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

Рисунок 5. Группа управления запросами на изменение

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

Рисунок 6. Утверждение базовой линии

Методы сравнения 2-х базовых линий

Для сравнения двух базовых линий должны быть выполнены основные условия: важная веха должна быть достигнута и утверждена. Это может быть либо завершение итерации для гибкого проекта, «ворота», достигнутые в рамках процесса водопада, или продукт был успешно выпущен. В любом случае, существует ряд рабочих элементов, которые отражают это событие. Из-за различий типов требований и трассировки иерархии используется множество различных методик, мы будем использовать методы министерство обороны для нашего примера. В процессе проекта DoD применялись следующие этапы и связанные с ними рабочие элементы:

  • Веха документирования бизнес-требований (BRD) – бизнес-требования были утверждены и приняты за основу.
  • Веха документирования функциональных требований (FRD) – функциональные требования были утверждены и приняты за основу.
  • Веха документирования технических требований (TRD) – технические требования были утверждены и приняты за основу.

В проекте Agile утверждаются и принимаются за основу журнал продукта и журнал итерации.

Каждый тип требования (представленный в виде типа рабочего элемента в Team Foundation Server) должен быть выгружен из Team Foundation Server в электронную таблицу Excel. Структура всех трассируемых атрибутов для рабочих элементов должна быть задана в запросе по рабочим элементам перед началом процедуры экспорта:

На рисунке выше показан результат запроса Требования к продукту и все применимые атрибуты. Это будет служить в качестве основы для базовой линии Требований к продукту. Подобный список с задачами по проекту может быть экспортирован в дополнение к требованиям.

На следующем шаге создание Excel таблицы на основе этого списка. Функция, которая это делает, выделена красным цветом на рисунке выше. Результат будет выглядеть следующим образом:

Эта таблица должна быть сохранена с именем соответствующей вехи. Например, может называться «Итерация 1– Базовая линия требований к продукту». Дополнительный лист книги может называться «Итерация 1 – Базовая линия задач».

Храниться каждый файлов, относящийся к базовой линии, в папке вехи проекта в библиотеки документов, созданной для хранения базовой линии. ВСЕ файлы, связанные с требованиями, которые входят в базовую линию, должны храниться в той же библиотеке документов в качестве базовой линии требований. Из-за особенностей этой базовой линии, такой механизм обеспечит хранение всех документов в SharePoint с фиксированием времени и идентификации пользователя, который сохранил их там. Если организация требует соблюдения правил, таких как FDA CFR-21, часть 11, то документ для подписи можно создать и хранить в общем комплекте или он может быть сгруппирован в пакет, который будет поставлен в средство, поддерживающее цифровую подпись пакета документов.

Если анализ должен проводиться для определения изменчивости требований или просто для понимания изменений от одной вехи к следующей, то можно использовать инструменты сравнения такие как Excel Compare от Formula Software, Inc. (http://www.formulasoft.com), которые позволят сравнить однотипные требования базовой линии от одной вехи к другой (Т. е. Iteration 0 Feature Baseline.xlsx и Iteration 1 Feature Baseline.xlsx).

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

Для традиционных проектов контроль не как естественное. Изменения требуют рабочего процесса, который включает в себя принятие незапланированного времени в процессе разработки для анализа влияния изменений, оценки рабочих затрат, а затем постановка и получение утверждения для внесения изменений в проект. Более формальные организации используют системы управления изменениями для поддержки их циклов изменений и утверждения. С помощью Team Foundation Server тип рабочего элемента Запрос на изменение может реализовывать процесс управления изменениями, где он может иметь жизненный цикл на основании состояний, что позволяет организовать переходы для анализа, оценки, постановки и утверждения. После утверждения команда может включать изменения в свою разработку. Рабочий элемент Запрос на изменение может быть связан, используя тех же механизмы ссылок, описанные выше для трассировки к требованиям или требований, которые добавляются или обновляются на основании запроса.

Важно иметь возможность сравнить набор требования от одного изменения к следующему в целях оценки «Изменчивости требований», эта оценка используется для отслеживания низкой зрелости и качества разработки приложений команды и их релизов. Чем выше изменчивость, тем выше вероятность того, что дефекты будут найдены в конце жизненного цикла или даже после выпуска релиза. В следующем разделе будет показано, как использовать Team Foundation Server для поддержки контроля изменчивости или контроля изменений и утверждения.

Описанный выше процесс для сравнения набора требований в базовых линиях определяет различия на макроуровне между базовыми линиями. Если различия будут найдены, то дальнейший анализ для развернутого сравнения можно выполнять на уровне документов. Используя Word, включенную возможность управления ревизиями и управления версиями WSS, аналитик может сравнивать и утверждать различия между отдельными версиями документа. Основным сценарием использования подхода может использоваться для управления изменениями «на лету».

На рисунке ниже показано сравнение документа Word c ранней версией. Обратите внимание, что текущая версия доступна для просмотра в одном окне панели, предыдущая версия в другом, а исходный документ в третьем. Слева открывается окно для просмотра различий ожидающих одобрения или отклонения.

Процесс управления изменениями

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

Рисунок 7. Процесс управления изменениями для гибких проектов

Бизнес требует изменение

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

Новое требование

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

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

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

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

Изменение для текущего требования в журнале

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

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

Требование в журнале будет иметь статус утверждения Черновик и младший номер версии.

Рисунок 8. Требование в журнале

Рисунок 9. Регистрация требования с младшим номером

Изменение текущих разрабатываемых требований

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

Если изменение касается требования, которое в настоящее время разрабатывается, изменение должно быть обговорено со SCRUM мастером или руководителем проекта, ведущим разработчиком и с разработчиком, на которого рабочий элемент назначается.

Должны быть определены следующие параметры:

Может ли этот запрос на изменение рассматриваться просто в качестве уточнения по требованию?

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

Рисунок 10. Версионная история документа для уточнения

Рисунок 11. Комментарий должен быть добавлен на вкладке истории рабочего документа

Требование остается полезным без изменений?

Если изменение в требовании является настолько важным, что требование в его первоначальном виде (утвержденной форме!) оказывается бесполезным без изменения, то требование должно быть выведено из итерации и перемещено в журнал с запросом на изменение внесенного в Пользовательскую историю. Это решение должно быть согласовано с бизнесом. Запрос на изменение никогда не должен влиять на возможность команды выполнить итерацию.

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

Рисунок 12. Задача, запланированная на итерацию 1

Рисунок 13. Задача более не назначена и находится в журнале

Процесс управления изменениями, характерный для традиционных проектов

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

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

Для того чтобы эти изменения были эффективно доведены до менеджера команды или команды, можно включить нотификацию в WSS для отправки уведомлений пользователям или команде об изменении. Уведомления по рабочим элементам, в частности в начале проекта, могут иметь «спам» эффект, что уменьшит положительное влияние от уведомлений.

Рисунок 14. Подробное описание в истории об изменениях очень важно

Процесс утверждения

Процесс утверждения, который представлен ниже, важен даже для гибких проектов.

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

Для гибких проектов этот процесс может быть применен также в «Паре» к неофициальному процессу между 2 членами команды, но всегда должны быть объединены в конце итерации со всеми артефактам, завершенным в итерации.

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

Рисунок 15. «Легкий» процесс утверждения

Настройка сайта команды для поддержки процесса утверждения

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

Рисунок 16. Включение управления версиями и утверждения

Рисунок 17. Настройка библиотеки документов

Рисунок 18. Рекомендуемые настройки

Рисунок 19. Автор документа публикует документ с основной версией – состояние утверждения «Черновик»

Рисунок 20. Утверждение документа

Рисунок 21. Состояние утверждения документа

Заключение

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

В соответствии с данным руководством, использование командой Team Foundation Server в качестве хранилища для всех данных проекта дает преимущества для более эффективной, предсказуемой и надежной работы. Вот некоторые из них:

  • Уменьшение «Изменчивости границ»
  • Улучшение Анализа влияния
  • Всесторонний охват тестирования требований
  • Совершенствование и повышение эффективности командной коммуникации

<<Содержание

Advertisements

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: