Учебник. Московский финансовопромышленный университет Синергия Кафедра Системного программирования
 Скачать 3.83 Mb.
|
|
Тема 5. Шаблоны процессов Процесс разработки ПО весьма сложен и включает в себя многочисленные операции на самых разнообразных уровнях. Перед группой разработчиков этот процесс предстает, как правило, в виде документации, но инструменты для реализации отсутствуют. Недостаток инструментария существенно усложняет изучение проекта группой разработчиков и его согласованное выполнение. Конечно, к услугам менеджера проекта различные средства для управления проектом, управления требованиями, отслеживания ошибок или управления обзорами, однако они редко хорошо взаимосвязаны. Несогласованность делает еще более трудной задачей соблюдение единой методологии в нескольких проектах. Усложняется также подготовка общего отчета, который позволил бы всей команде уяснить текущее состояние и успешность проекта. В результате анализ процесса становится ненадежным, а внесение улучшений в процесс - практически невозможным. Visual Studio Team System (VSTS) и TFS предоставляют вам интегрированную среду, в которой поддерживается большинство операций, включаемых в процесс разработки ПО. В TFS методологии цикла разработки реализованы в виде шаблонов процессов. Шаблон процесса (process template) - это набор XML-файлов со спецификациями процессов и артефактов, составляющих методологию разработки. В этой лекции объяснена архитектура шаблона процесса и ее компоненты. Если имеющиеся шаблоны не совсем соответствуют процессу разработки, принятому в вашей команде, создайте новый шаблон, отредактируйте существующий шаблон или выберите один из шаблонов, предлагаемых Microsoft Partners. Шаблоны процессов MSF Agile и MSF CMMI В комплект Team Foundation Server входят два шаблона процессов - MSF Agile и MSF CMMI, - описывающих два различных стиля разработки ПО. Используйте шаблон MSF Agile, если вы должны быстро разработать новое приложение. Он поможет реализовать MSF Agile разработку методом проб и ошибок и другие методики быстрой разработки. Опирайтесь на MSF CMMI, если следуете методологии Capability Maturity Model® Integration, предложенной Институтом разработки ПО (Software Engineering Institute, SEI). Это формальный процесс, направленный на усовершенствование существующих процессов. Возможности двух этих шаблонов различны. Например, в них по умолчанию создаются разные типы отчетов и рабочих элементов. Оба 62 шаблона допускают простую настройку согласно потребностям вашего проекта. Руководство по настройке процессов Создаваемый вами проект вовсе необязательно впишется в шаблоны процессов из комплекта VSTS: начиная с отсутствия нужного типа рабочего элемента и заканчивая совершенно иной методологией процессов. Допустим, если вы используете методологию SCRUM, а в текущем шаблоне процесса не упоминаются спринты (sprint), вам придется дополнить существующий шаблон или даже заменить его. Архитектура шаблона процесса В архитектуре шаблона процесса три основных компонента: Надстройки шаблона процесса. XML-файлы определения процессов. Мастер New Team Project. Надстройки шаблона процесса Надстройками шаблона процесса (process template plug-in) называются компоненты, запускаемые при создании нового проекта команды. Надстройка настраивает нужные файлы и конфигурирует данные в определенной области шаблона. В комплект TFS входят следующие надстройки: Classification. Определяет начальную итерацию и области. Groups and Permissions. Определяет начальные группы безопасности команды проекта и их разрешения. Windows SharePoint Services. Определяет портал проекта на базе шаблона сайта Microsoft Windows SharePoint®, а также файлы шаблонов и руководство процесса. Work Item Tracking Определяет начальные типы рабочих элементов, запросы и экземпляры рабочих элементов. Reports. Определяет начальные отчеты и настраивает сайт отчетов. Version Control. Определяет начальные разрешения безопасности по управлению версиями и заметки для возврата после правки. Для настройки шаблона процесса вы можете отредактировать любой файл определения надстройки. При необходимости в процессе настройки шаблона файлы определения надстроек можно даже удалять, за исключением надстройки Classification. 63 XML-файлы определения процессов XML-файлы определения процесса - это набор XML-файлов с описаниями задач, которые необходимо выполнить, чтобы правильно настроить новый проект для процесса. Если вы создаете проект при помощи мастера New Team Project, он сам запустит все необходимые надстройки. Каждая надстройка считывает из соответствующего XML- файла определения процесса список задач, которые она должна выполнить. При помощи XML-файлов определения процесса вы задаете настройки и параметры, которые должны применяться надстройками. Доступны следующие XML-файлы: XML-файл отслеживания рабочих элементов Файл Workitems. xml хранится в подпапке: Work Item Tracking. Иерархии папок шаблона процесса. В нем задаются типы рабочих элементов, запросы рабочих элементов и экземпляры рабочих элементов. Work Item Types. Определяют правила, поля, состояния и переходы для рабочего элемента (например, задача, ошибка, требование), который предполагается отслеживать в ходе выполнения проекта. Work Item Queries. Используются для поиска конкретных групп рабочих элементов, например, задач или активных ошибок. Запросы рабочих элементов задаются в файлах WIQ (work item query) в подпапке Queries папки Work Item Tracking иерархии папок шаблона процесса. Work Item Instances. Начальный набор экземпляров рабочих элементов, создаваемый по умолчанию одновременно с проектом. XML-файл классификации Файл Classification. xml хранится в подпапке Classification иерархии папок шаблона процесса. Он состоит из двух частей: итерации и области. Iterations. Здесь определяется, сколько раз команда проекта повторит некий набор базовых действий (например, планирование, разработку, тестирование). Итерации затрагивают запросы и отчеты рабочих элементов, поскольку рабочие элементы группируются по итерациям. Areas. Собственно организация работ в команде проекта. Например, команда может организовать свою деятельность, отталкиваясь от продукта или отдельного компонента и создав область интерфейса, область приложения и область базы данных. Области также используются, чтобы сгруппировать рабочие элементы для запросов и отчетов. XML-файл Windows SharePoint Services Файл WssTasks. xml хранится в подпапке Windows SharePoint Services иерархии папок 64 шаблона процесса. Здесь задаются три основные задачи: шаблон сайта, библиотеку документов, а также папки и файлы. Site Template. Шаблон сайта, на основе которого будет создан портал проекта. Шаблон также должен быть доступен на TFS SharePoint Portal. Шаблоны сайтов в шаблоны процессов не включаются. Document Libraries. После создания портала проекта вы можете так же создать дополнительные библиотеки документов. Folders and Files. После создания портала проекта вы можете задать создание дополнительных папок, а также указать конкретные файлы для копирования, например, файлы шаблона. XML-файл управления версиями Файл VersionControl. xml хранится в подпапке Version Control иерархии папок шаблона процесса. В нем задаются начальные разрешения безопасности по управлению версиями, заметки для возврата после правки, а также требуется или нет единоличное редактирование. Check-in Notes. Здесь задается использование заметок для возврата после правки (check-in note). В этих заметках разработчик, возвращая код после правки, указывает, как внесенные в код изменения соотносятся с общим процессом. Например, в заметке можно написать, что изменение было внесено как часть обзора безопасности, а также подробно описать его. Exclusive Check-out. Здесь задается возможность одновременного использования одного и того же файла несколькими пользователями. Permissions. Определяет, какие действия группам безопасности и отдельным пользователям разрешается выполнять в рамках управления версиями. XML-файл отчетов Файл ReportsTasks. xml хранится в подпапке Reports иерархии папок шаблона процесса. В нем определены начальные отчеты команды проекта. Reports Site. На сайт отчетов указывает ссылка Reports на домашней странице портала проекта. Folders. На сайте отчетов можно создавать папки. Созданная папка будет отображена на сайте проекта и в папке Reports обозревателя Team Explorer. Reports. Используется для добавления отчетов при помощи файлов. rdl. XML-файл групп и разрешений Файл GroupsandPermissions. xml хранится в подпапке Groups and Permissions иерархии папок шаблона процесса и используется для задания начальных групп безопасности в команде проекта. Groups. Здесь задается новая группа безопасности TFS. 65 Permissions. Здесь задаются разрешения для каждой созданной группы. Мастер New Team Project Мастер New Team Project используется для создания новых командных проектов при помощи надстроек и XML-файлов определения процесса. Способ настройки Чтобы настроить шаблон процесса, выполните следующие действия: 1. Изучите шаблоны процесса TFS и выберите тот, который максимально отвечает потребностям вашей организации. 2. Загрузите выбранный шаблон. 3. Настройте различные компоненты шаблона. 4. Выгрузите настроенный шаблон обратно в TFS. Убедитесь, что внесенные изменения соответствуют принятому процессу. Эта общая последовательность используется в составе следующих подходов к настройке шаблонов процесса: Редактор Process Template Editor Tool из комплекта Power Tools В последнюю версию комплекта усовершенствований, инструментов и утилит командной строки Visual Studio 2005 Team Foundation Server Power Tool входит программа с графическим интерфейсом для просмотра и редактирования шаблонов процесса. Подключившись к TFS, вы можете воспользоваться этим редактором для настройки определений типов рабочих элементов и глобальных списков активного проекта. Подробнее - в разделе "Как настроить шаблон процесса в Visual Studio Team Foundation Server". Основные настройки Здесь описаны основные компоненты, которые, как правило, редактируются при настройке процесса: Группы и разрешения. В стандартные шаблоны включен набор групп, которым уже назначены различные разрешения. Если группы по умолчанию и их разрешения не соответствуют требованиям вашего процесса, вы вольны их изменить или создать новые группы. Также можно добавить пользователя в группу, исключить пользователя из группы, назначить группе разрешение или отозвать его. Заметки и политики возврата исходного кода после правки. В стандартные шаблоны включен набор заметок и политик возврата после 66 правки. Если стандартные заметки не соответствуют требованиям вашего процесса, вы вправе добавить или удалить поля заметок, а также сделать некоторые из полей обязательными. Если вашим требованиям не соответствуют политики, создайте новые политики, а также отредактируйте или удалите имеющиеся. Области и итерации. В стандартных шаблонах нет структуры классификации ни для областей, ни для итераций. Вы можете настроить их согласно конкретным требованиям процесса. Рекомендуется использовать в качестве основы для областей компоненты или возможности проекта. Итерация - это цикл повтора конкретного набора базовых действий (например, планирования, разработки или тестирования). Портал команды. В стандартных шаблонах имеется портал команды по умолчанию, призванный стать средоточием коммуникаций между членами команды и другими сотрудниками организации. Вы можете изменить внешний облик портала, его действие и содержимое в согласии с требованиями процесса. Руководство по процессу. В стандартные шаблоны включено соответствующее руководство, в котором объясняются роли, формы, отчеты и организация работы в команде проекта. Настраивая шаблон процесса согласно собственным требованиям, обязательно отредактируйте руководство, отразив изменения в различных компонентах. Отчеты. В стандартных шаблонах имеется набор отчетов по умолчанию. Если они вам не подходят, создайте собственные отчеты на базе требований процесса. Типы и запросы рабочих элементов. В стандартные шаблоны включены набор типов рабочих элементов, экземпляры рабочих элементов по умолчанию и запросы. Если они не соответствуют требованиям вашего процесса, внесите в типы рабочих элементов необходимые изменения, например: Добавьте новые типы рабочих элементов. Удалите существующие типы рабочих элементов. Добавьте экземпляры по умолчанию для типов рабочих элементов. Удалите экземпляры по умолчанию для типов рабочих элементов. Создайте собственные открытые или закрытые запросы. Можно также вносить изменения в конкретный тип, например: 1. добавить поля; 2. переименовать поля; 3. задать допустимый диапазон значений поля; 4. изменить состояния и допустимые переходы состояний; 67 5. сделать поля обязательными или доступными только для чтения; 6. сделать одно поле зависимым от другого; 7. автоматически заполнять значения полей; 8. изменять способ представления информации на форме; 9. изменять соответствие между полем и столбцом Microsoft Office Project. Как происходит настройка? Процедура настройки шаблона разделяется на следующие этапы: 1. Пользователь запускает мастер New Team Project. Мастер запрашивает: 2. имя проекта; 3. название шаблона, который нужно использовать при создании проекта. Отображаемые окна мастера зависят от используемых надстроек. Например, если в шаблон процесса не включена надстройка Windows SharePoint Services, не будут отображаться окна для ввода информации о портале проекта. 4. Когда пользователь введет всю необходимую информацию и щелкнет Finish, мастер вызывает надстройки для выполнения действий по созданию проекта. Порядок вызова надстроек задается в XML-файлах определения процесса. Мастер считывает инструкции в шаблоне процесса, а затем создает и настраивает конкретные элементы. Пользователю не нужно задавать никакие сведения о создаваемых типах рабочих элементов, поскольку все необходимые указания уже содержатся в шаблоне процесса. Примечание Если в процессе создания проекта мастер столкнется с какими-либо осложнениями, вы увидите на экране сообщение с описанием проблемы и предложениями по ее устранению. Шаблон MSF Agile Процесс, определенный шаблоном MSF Agile, основан на идеях быстрой (Agile) разработки ПО, а также на принципах и методиках MSF. Стратегия быстрой разработки ПО, реализованная в шаблоне, основана на прохождении нескольких итераций и на сборке приложений на базе сценариев. В шаблон включены инструкции и средства автоматизации, необходимые для поддержки командной разработки, включая 68 управление конфигурацией, управление проектом, отслеживание рабочих элементов и портал проекта. Организация работы в проекте MSF Agile В шаблоне MSF Agile определен набор задач, которые выполняются в ходе итераций цикла разработки ПО различными ролями, например: бизнес-аналитиками, архитекторами, менеджерами проекта, разработчиками и специалистами по тестированию. Основные действия, связанные с каждой задачей, описаны ниже: Создание журнала проекта. Общее описание проекта. Создание архитектуры решения. Создание прототипа архитектуры. Определение интерфейсов. Создание архитектуры инфраструктуры. Создание сценариев использования. Разбиение на сценарии Внедрение сценариев в TFS Расстановка приоритетов сценариев. Планирование итераций. Распределение сценариев и требований по задачам разработки и тестирования. Оценка задач разработки и тестирования. Составление графика и назначение задач разработки и тестирования. Итерация разработки. Написание кода для задач разработки. Создание или обновление модульного теста для задачи разработки. Запуск модульного теста и анализ кода. Итерация тестирования. Создание проверочных тестов. Запуск тестовых сценариев, исследовательское тестирование. Оформление ошибок для выявленных проблем. Обзор результатов итерации. Анализ выполнения задач итерации. 69 Анализ выявленных ошибок. Сравнение полученных метрик с пороговыми значениями. Параметры MSF Agile по умолчанию Когда вы создаете новый командный проект на основе шаблона MSF Agile, в главном окне Microsoft Visual Studio® отображается страница с общим описанием процесса. Это ваше первое знакомство с процессом MSF Agile. Доступ к этой информации можно также получить с домашней страницы портала проекта. Разумеется, одним описанием дело не ограничивается. Вам доступна настройка рабочих элементов (например, сценариев, требований к качеству обслуживания, задач, ошибок и рисков), отчетов по проекту, ролей (групп и разрешений), а также портала проекта. Далее перечислены основные компоненты шаблона MSF Agile: рабочие элементы; группы и разрешения; контроль исходного кода; области и итерации; отчеты; портал. Далее компоненты шаблона MSF Agile описаны более подробно. Рабочие элементы В шаблон процесса MSF Agile включены следующие типы рабочих элементов: Bug. Реальная или потенциальная проблема в приложении. Risk. Возможное событие или условие, способное отрицательно сказаться на проекте. Scenario. Конкретная "траектория" взаимодействия пользователя с создаваемой вами системой. Task. Конкретный фрагмент работы, выполняемый членом команды. Quality of Service Requirement. Нефункциональное требование, относящееся, например, к безопасности, производительности или управляемости. При создании нового проекта на базе шаблона MSF Agile в нем для экономии вашего времени создаются следующие задачи, выполнить которые нужно при инициализации проекта. Set up: Set Permissions. Добавление членов команды в одну из четырех групп безопасности: Build Services, Project Administrators, Contributors и Readers. 70 Set up: Migration of Source Code. Перенос существующего исходного кода из Microsoft Visual SourceSafe® при переносе в Microsoft Visual Studio Team Foundation Server существующего проекта. Необходимо сначала завершить перенос исходного кода и лишь потом открывать членам команды доступ к проекту. Set up: Migration of Work Items. Перенося в TFS существующий проект, вы можете также перенести рабочие элементы (например, ошибки и задачи) из Clearquest или при помощи файла с разделителями-запятыми. Необходимо сначала завершить перенос рабочих элементов и лишь потом открывать членам команды доступ к проекту. Set up: Set Check-in Policies. Настройка бизнес-правил или политики, связанных с возвратом исходного кода после правки. Set up: Configure Build. Создание исходного дерева источников и настройка сборки на регулярной основе (как правило, ежедневно). Set up: Send Mail to Users for Installation and Getting Started. Отправка членам команды сообщений электронной почты с информацией о том, к какому TFS-серверу им подключаться и с каким проектом работать. Create Vision Statement. Создание общего описания проекта с указанием конечной цели, одобренной всеми заинтересованными лицами. Set up: Create Project Description on Team Project Portal. Изменение описания проекта по умолчанию в соответствии с решаемой задачей, например, включение в него описания целей и конечного результата проекта. Create Personas. Создание персон, символизирующих целевых пользователей системы. Их удобно применять, например, продумывая дизайн приложения. Define Iteration Length. Определение цикла итераций проекта. Зависит от объема и сложности проекта. Create Test Approach Worksheet including Test Thresholds. Цель этой задачи - разобраться в стратегии тестирования с самого начала итераций проекта. Это поможет вам составить более эффективное расписание тестирования и изначально более четко направить усилия разработчиков. Brainstorm and Prioritize Scenarios List. Выявление основных сценариев использования и оценка их приоритетности. Brainstorm and Prioritize Quality of Service Requirements List. Выявление нефункциональных QoS-требований, связанных, например, с безопасностью, производительностью и управляемостью. Set up: Create Project Structure. Создание структуры проекта с выделением основных областей, над которыми будет работать команда разработчиков. 71 Create Iteration Plan. Распределение задач разработки по итерациям. Отчеты По умолчанию в шаблоне MSF Agile доступны следующие отчеты: Bugs by Priority. Правильные ли найдены ошибки? В этом отчете сравниваются темпы выявления ошибок с высоким и низким приоритетом. Bug Rates. Насколько эффективно выявляются, исправляются и закрываются ошибки? На диаграмме иллюстрируются тенденции в появлении и исправлении старых новых ошибок, а также текущие ошибки. Builds. Каково качество сборки? В отчете приводится список доступных сборок, включая их качество и другие подробные сведения о них. Project Velocity. Насколько быстро команда завершает свою работу? Из этого отчета вы узнаете, насколько быстро команда справляется с плановыми заданиями, а также о том, как меняется темп работы. Quality Indicators. Каково качество ПО? В одном отчете собраны результаты испытаний, ошибки, покрытие кода и сведения о его изменчивости. Load Test Summary. Результаты практических испытаний приложения. Regressions. Список тестов, которые раньше выполнялись, а теперь - нет. Reactivations. Сколько рабочих элементов было повторно активировано? Из этого отчета вы узнаете, какие рабочие элементы были закрыты или помечены как разрешенные преждевременно. Related Work Items. Как рабочие элементы зависят друг от друга? В этом отчете приводится список рабочих элементов, связанных с другими рабочими элементами. Remaining Work. Сколько работы осталось сделать и когда она будет завершена? Из этого отчета вы узнаете объем оставшейся и выполненной работы. Проанализировав имеющиеся тенденции, вы предскажете примерный срок готовности кода. Unplanned Work. Сколько выполняется внеплановых работ? В этом отчете показаны полный объем работ и оставшийся объем работ с разделением на плановые и внеплановые операции. Triage. Какие рабочие элементы нуждаются в утверждении? В этом отчете показаны все рабочие элементы до сих пор имеющие статус предложения. 72 Work Items. Какие рабочие элементы активны? В отчете приводится список активных рабочих элементов. Work Items by Owner. Сколько работы назначено каждому члену команды? В отчете показаны рабочие элементы для каждого члена команды. Work Items by State. Сколько имеется активных, разрешенных и закрытых рабочих элементов? Ответ вы узнаете из этого отчета. Группы и разрешения По умолчанию в шаблоне MSF Agile доступны следующие группы: Readers Членам этой группы проект доступен только для чтения. Contributors Членам этой группу разрешается добавлять, изменять и удалять элементы проекта. Build Services Членам этой группы разрешается сборка проекта. Она предназначена только для учетных записей служб. Project Administrators Членам этой группы разрешается выполнять в проекте любые действия. Управление исходным кодом В MSF Agile по умолчанию используются следующие параметры управления исходным кодом: Коллективное редактирование. По умолчанию в MSF Agile разрешается одновременное редактирование одного и того же файла несколькими членами команды. Все возникающие при этом конфликты разрешаются при возвращении файла после правки. Разрешения. По умолчанию назначены следующие разрешения по контролю за исходным кодом: Project Administrators. Имеют все доступные права. Build Services. Имеют право читать, откладывать изменения, возвращать код после правки, помечать, начинать сборку, редактировать сборку. Contributors. Имеют право читать, откладывать изменения, брать код на редактирование, возвращать код после редактирования, помечать, начинать сборку. Readers. Имеют только право чтения исходного кода. Области и итерации В стандартных шаблонах нет структуры классификации ни для областей, ни для итераций. Вы можете настроить их согласно конкретным требованиям процесса. Рекомендуется использовать в 73 качестве основы для областей компоненты или возможности проекта. Итерация - это цикл повтора конкретного набора базовых действий (например, планирования, разработки или тестирования). Практические примеры использования MSF Agile В этом разделе приводятся практические примеры использования MSF for Agile Software Development командой Майкрософт patterns & practices и сторонней командой разработчиков. Пример 1: команда patterns & practices. В следующем примере показано, как процесс MSF Agile используется при выполнении типичного проекта команды patterns & practices. Новый проект с нулевой итерации. Менеджер продукта: Совместно с заказчиками и заинтересованными лицами формулирует требования к проекту. Они записываются в документ Microsoft Office Word с именем Project Back Log. Создает декларацию проекта при помощи Microsoft Office PowerPoint®. Совместно с заказчиками и заинтересованными лицами проводит совещание по выявлению основных сценариев использования продукта, выделяя ключевые требования к продукту и определяя его общий облик. Совместно с менеджером проекта и другими заинтересованными лицами определяет приоритеты сценариев. Менеджер проекта: Преобразует сценарии в рабочие элементы TFS. Принимает решение о продолжительности цикла итерации в зависимости от объема проекта и возможностей команды. Планирование до начала итераций Опираясь на приоритеты, менеджер проекта принимает решение, над какими сценариями будет вестись работа в ходе итерации. Менеджер продукта и менеджер проекта формулируют требования качества обслуживания (Quality of Service, QoS) для сценария. Требования QoS привязываются к сценариям. Планирование итераций Менеджер проекта: Совместно с разработчиками и другими членами команды разбивает сценарии на задачи для разработчиков: 74 Переносит задачи разработки в TFS и связывает их со сценариями. Определяет критерии завершения для каждой из задач разработки. Разделяет требования QoS на задачи тестирования. Переносит задачи тестирования в TFS и связывает их с QoS- требованиями. Определяет критерии завершения для каждой из задач тестирования. Составляет расписание выполнения задач и назначает их членам команды. Разработчик оценивает все задачи разработки. Важно! Если по предварительным расчетам на выполнение задачи разработки потребуется больше двух дней, ее следует разделить на меньшие задачи. Специалист по тестированию оценивает все задачи тестирования. Во время итерации Менеджер проекта руководит итерацией. Разработчик пишет код для задачи и закрывает задачу, если выполнены критерии ее завершения. Тестировщик выполняет назначенные ему задачи тестирования и для каждой выявленной проблемы создает новый рабочий элемент- ошибку. После итерации Менеджер проекта: Анализирует развитие проекта и заново расставляет приоритеты сценариев, которые не были завершены в ходе итерации. Предоставляет отчет о состоянии проекта заинтересованным лицам. На основании приоритетов решает, над какими сценариями будет вестись работа на следующей итерации. Менеджер продукта: Добавляет все вновь выявленные сценарии. Меняет приоритеты сценариев (при необходимости). Пример 2: сторонние разработчики. В следующем примере показано, как процесс MSF Agile используется одним из сторонних разработчиков. Новый проект с нулевой итерации Бизнес-аналитик: 75 Пишет краткую (на одну страницу) декларацию проекта. Находит представителя заказчика, с которым можно будет обсудить входные данные и создать персоны. Совместно с заказчиком идентифицирует сценарии. Совместно с заказчиком определяет приоритеты сценариев. Пишет сценарии для предстоящей итерации. Менеджер проекта: Собирает совещание разработчиков, на котором они делятся своими оценками, пока приблизительными, по порядку величины. Проверяет, не изменились ли приоритеты после подсчета затрат. Составляет расписание сценариев для предстоящей итерации. Архитектор разделяет сценарии на задачи архитектуры. Разработчик: Разделяет сценарии на задачи разработки. Определяет соответствующую стратегию сборки (по возможности, непрерывную интеграцию). Специалист по тестированию разделяет сценарий на задачи тестирования. Во время итерации Менеджер проекта: Руководит итерацией. Руководит проектом. Архитектор определяет архитектуру решения. Разработчик реализует задачу разработки. Тестировщик проводит тестирование сценария. После нулевой итерации На этом этапе задачи несколько меняются. Бизнес-аналитик: Обновляет персоны (при необходимости). Добавляет вновь обнаруженные сценарии. Изменяет приоритеты сценариев (при необходимости). Пишет сценарии для предстоящей итерации. Менеджер проекта: Оценивает новые сценарии. 76 Составляет расписание сценариев для предстоящей итерации. Архитектор разделяет сценарии на задачи архитектуры. Разработчик: Разделяет сценарии на задачи разработки. Обновляет процесс сборки (по возможности, непрерывную интеграцию). Специалист по тестированию разделяет сценарий на задачи тестирования. Настройка шаблона MSF Agile Есть два способа отредактировать шаблон MSF Agile согласно потребностям вашей организации: Ручная настройка XML-файлов Ручная настройка чревата ошибками, но с другой стороны позволяет управлять тонкими деталями настройки. Подробнее - в статье "Customizing Process Templates" по адресу http://msdn2. microsoft. com/en-us/library/ms243782(VS. 80). aspx. Process Template Editor. В последнюю версию комплекта усовершенствований, инструментов и утилит командной строки Visual Studio 2005 Team Foundation Server Power Tool входит программа с графическим интерфейсом для просмотра и редактирования шаблонов процесса. Подключившись к TFS, вы можете воспользоваться этим редактором для настройки определений типов рабочих элементов и глобальных списков активного проекта. Подробнее - в разделе "Как настроить шаблон процесса в Visual Studio Team Foundation Server". |