Эта статья, состоящая из трех частей, представляет собой описание концепций и проектных задач готового решения для управления жизненным циклом приложений (application lifecycle management, ALM) для IBM Rational ClearQuest.
Управление заданиями
Проекты задают контекст для нашей работы, а мы должны выполнять задания, чтобы завершить работу над проектом. На всем протяжении разработки программного решения, чтобы обеспечить выполнение всех заданий по проекту, необходимо выполнять множество деятельностей. Рабочие записи в пакете ALMWork предоставляют способ мониторинга требований и задач, которые должна решать рабочая группа по ходу цикла разработки. В предыдущих версиях ClearQuest управление заданиями осуществлялось посредством создания типов записей для каждого элемента, нуждающегося в управлении (Дефект, Запрос на изменение и т.п.). Однако в ALM-схеме основное внимание уделяется распределению заданий между сотрудниками рабочей группы. AML-схема предоставляет основные типы записей для управления заданиями, а именно: Request (Запрос), Task (Задача) и Activity (Деятельность).
- Request (Запрос) - это новый тип записи, предназначенный для передачи рабочей группе различных ходатайств, например, запроса на новую функцию или отчета о дефектах. Однако запросы не ограничиваются только функциями или дефектами. Запрос может поступить на любой тип задания, определенный проектной группой.
- Task (Задача) - это запись, которая представляет собой поручение рабочей группе выполнить задание по запросу в контексте определенного проекта. С записью Request могут ассоциироваться несколько записей Task. В некоторых случаях для выполнения одного запроса может потребоваться много задач. И наоборот, один запрос может решаться в более чем одном проекте.
- Activity (Деятельность) - это единица работы, порученная отдельному исполнителю. Для выполнения всех заданий по одной задаче как правило требуется более одного исполнителя, следовательно, Деятельности совместно участвуют в выполнении Задачи. С одной Задачей могут быть ассоциированы несколько деятельностей. Хороший пример - задача тестирование. Одна задача Test может включать в себя обновление плана тестирования, создание контрольных примеров, создание тестовых скриптов и выполнение тестовых скриптов. Задача не выполнена до тех пор, пока не выполнены все деятельности.
Каждой из этих трех типов записей могут также быть присвоены "типы" (о которых рассказывается ниже), позволяющие дополнительно уточнить характер задания.
Кроме распределения заданий часто возникает вопрос о комментариях по поводу задания. Следовательно, предоставляется также запись Comment (Комментарий).
- Comment (Комментарий) - это инструмент взаимодействия с владельцем записи. Комментарии могут ассоциироваться с Запросами, Задачами и Деятельностями и использоваться для вопросов, комментариев и ответов. Они отличаются от существующего типа записей Notes в ClearQuest. Комментарий в данной модели - это, скорее, запись в ClearQuest, а не присоединенная строка в пакете notes.
На рисунке 1 показаны отношения между типами Requests (Запросы), Tasks (Задачи), Activity (Деятельность) и Work Types (Типы заданий).
Рисунок 1. Основные записи для заданий. Запросы определяют, какая "потребность" и где была "обнаружена". Задачи определяют, какие задания должны быть выполнены для удовлетворения запроса по проекту. Деятельности распределяются между отдельными исполнителями и совместно выполняют задачу. Запись Work Types определяет характер задания
Любое задание начинается с Запроса определенного вида. Запрос описывает идентифицированную потребность и принадлежит любому заинтересованному в проекте лицу, а Задачи и Деятельности представляют собой записи для мониторинга хода выполнения задания, которое было поручено исполнителям и должно быть выполнено для удовлетворения Запроса. Это позволяет сравнить количество запросов с количеством порученных задач. Кроме того, это позволяет проект-менеджеру оценить объем работы, связанный с каждым запросом, а также объем завершенных или незавершенных заданий. Возможны также ситуации, в которых один запрос оказывает влияние более чем на один проект. Такое разделение запросов на выполнение заданий и поручений на выполнение заданий позволяет управлять Задачами каждого проекта в отношении выполнения Запроса в специфическом для данного проекта контексте.
Рисунок 2. Использование записей для заданий. Сначала сортируются запросы и создаются задачи для проекта. Деятельности выполняют задачу, после чего выполненная работа анализируется, а запрос закрывается
На рисунке 2 показана схема потока для работы с этими новыми типами записей. Стрелки обозначают родительские/дочерние отношения между записями.
- Запрос описывает "потребность" и идентифицирует место обнаружения проблемы.
- Запросы сортируются, чтобы определить, должны ли они решаться и к какому сроку.
- После этого для проекта создаются Задачи, которые привязываются к Запросу.
- Затем определяются Деятельности, которые совместно выполняют Задачу.
- Состояние Деятельности отслеживается, чтобы иметь представление о ходе выполнения Задачи.
- Выполнение Задачи означает удовлетворение Запроса.
- Запрос принимается или отклоняется (если Задача выполнена неудовлетворительно).
Запись Request является исходной точкой для начала работы. Любое заинтересованное лицо, направившее Запрос, регулярно проверяет его состояние и отвечает на любые вопросы или комментарии. Полномочия пользователя схемы определяют, кто (т.е. какие пользователи, группы или роли) может передать новый Запрос (рисунок 3). Запись Request:
- Содержит всю информацию, имеющую отношение к тому, где и с какой целью был сгенерирован данный Запрос. Ассоциируется с одной из категорий, предназначенных для более точной локализации потребности (например, продукт, функция, компонент, сервис);
- Параметр Request Type (тип запроса) идентифицирует характер запроса. Распространенные примеры: Enhancement (запрос на усовершенствование), New Feature (запрос на новую функцию) и Defect (запрос на исправление дефекта). Однако набор типов запроса может быть расширен, чтобы можно было описать любой тип запроса на выполнение задания. Например, в Унифицированном процессе Rational IBM (Rational Unified Process® или RUP®) можно создать Запрос на "начало итерации";
- Выполняется на стороне подачи запроса;
- Принадлежит лицу, направившему Запрос;
- Может иметь присоединенные Комментарии (и вопросы);
- Содержит ссылки на все ассоциированные с ним Задачи.
Рисунок 3. Новая запись Request
Некоторые из показанных на рисунке 3 полей являются обязательными. Если указано значение в поле "project found in...", то в поле security context (контекст безопасности) на вкладке history автоматически выбирается этот проект. Остальные обязательные поля - это Headline, Type и Severity.
Переходы Запроса между состояниями очень просты, как показано ниже. Запрос может быть либо выполненным, либо невыполненным (рисунок 4).
Рисунок 4. Поток для запроса
Приемка запроса переводит его в состояние выполнен (completed)
Запрос может быть отозван (withdrawn) или отклонен (rejected). После перевода в состояние rejected или withdrawn запрос может быть снова открыт. Задачи выполняют запросы в контексте проекта.
 |
| |||||||||||||||
При категоризации Запроса указывается, какая рабочая группа будет им заниматься. Эта рабочая группа анализирует Запрос и решает, может ли он быть удовлетворен и к какому сроку. Если Запрос будет выполняться в рамках определенного проекта, то в этом проекте создается Задача, которая ассоциируется с Запросом, как показано на рисунке 5. Любой специалист, просматривающий Запрос, сразу увидит, какие Задачи необходимо выполнить для его удовлетворения. Любому специалисту или заинтересованному лицу при просмотре Задачи сразу видно, для удовлетворения какого Запроса она предназначена.
Запись Task:
- Содержит всю информацию, имеющую отношение к ассоциированному с ней Запросу, который должен быть удовлетворен, т.е. информацию о проекте, категории или релизе;
- Принадлежит одному из сотрудников рабочей группы;
- Представляет собой совокупность заданий, распределенных между несколькими сотрудниками рабочей группы;
- Содержит ссылки на все Деятельности, необходимые для выполнения данной Задачи;
- Ссылается на Запрос, для выполнения которого она предназначена.
Рисунок 5. Если Запрос будет выполняться в рамках определенного проекта, то в этом проекте создается Задача, которая ассоциируется с Запросом
Поля, выделенные красным шрифтом на рисунке 5, являются обязательными. Если указано значение в поле "project assigned...", то в полях security context (контекст безопасности) и roles (роли) на вкладке history автоматически выбирается этот проект. Остальные обязательные поля - это Headline, Type, Severity и related Request (на вкладке Related Records).
Рисунок 6. Поток задачи
Переходы между состояниями для Задачи очень просты (рисунок 6). Задача может быть Opened (Открыта), Activated (Активирована) или Completed (Выполнена). Когда Задача передается исполнителю, она переходит в состояние Open. Активация задачи означает начало ее выполнения. Задачу можно открыть повторно.
Руководители группы анализируют Задачу и определяют, какие Деятельности необходимы для ее выполнения. Часто для выполнения одной Задачи требуется труд нескольких пользователей. Деятельности создаются и распределяются таким образом, чтобы один сотрудник рабочей группы выполнял дискретную единицу работы, как показано на рисунке 7. Запись Activity:
- Принадлежит одному из сотрудников рабочей группы проекта;
- Представляет одну единицу работы;
- Ссылается на Задачу, в выполнении которой она участвует;
- Дополнительно может использоваться в системе унифицированного управления изменениями (Unified Change Management, UCM).
Рисунок 7. Деятельность создается и распределяется таким образом, чтобы один сотрудник коллектива выполнял дискретную единицу работы
Некоторые из показанных на рисунке 7 полей являются обязательными. Остальные обязательные поля - это Headline, Type, Severity и related Request (на вкладке Related Records). Поле Security Context на вкладке History наследует значение из поля related Task. Деятельности также характеризуются простыми переходами между состояниями, как показано на рисунке 8. В данном случае таких состояний четыре, как в UCM. Деятельности могут иметь состояния Submitted (Поручена), Opened (Открыта), Activated (Активирована) и Completed (Выполнена). Деятельность может перейти в состояние Activated из состояния Submitted.
Рисунок 8. Деятельности характеризуются простыми переходами между состояниями
Понятие "переключение контекста" заслуживает того, чтобы ему уделили немного внимания. В предыдущих версиях ClearQuest запись использовалась для документирования всей информации в полях, а переходы между состояниями - для "продвижения" записи по процессу. В ряде случаев переходы между состояниями также требовали переназначения владения записью другому сотруднику рабочей группы. В результате каждое состояние могло быть назначено для представления одной единицы работы, выполняемой отдельным сотрудником рабочей группы (это до сих пор работает в данных продуктах и поддерживается производителем).
ALM-решение предоставляет альтернативный подход. Чтобы проиллюстрировать переключение контекста, давайте возьмем для примера запись "Defect".
В предыдущих версиях ClearQuest запись Defect использовалась для управления всеми дефектами, обнаруженными в системе (рисунок 9). Она имела набор изменений состояния. Например, первым состоянием могло быть состояние "Develop" (Разработать), которое поручалось разработчику. Следующим состоянием могло быть "Validate" (Проверить), которое поручалось тестировщику.
Рисунок 9. Переходы состояний и существующие записи ClearQuest
После того как разработчик заканчивал свою работу, запись Defect переходила в следующее состояние, в результате чего владение записью переходило к тестировщику. Эта модель работает до тех пор, пока у вас не появятся две отдельные рабочие группы, для каждой из которых нужен свой набор переходов. Что делать в этом случае? У вас есть три варианта: создать новый тип записи для второй рабочей группы, изменить переходы между состояниями в существующем типе записи Defect и жестко привязать каждое состояние к одной из рабочих групп или полностью проигнорировать запрос. В схеме ALM используется другая модель (рисунок 10). Работа по новой модели начинается с Запроса типа Дефект. Этот тип записи могут использовать все рабочие группы. Он имеет простую модель перехода между состояниями и используется для сбора информации о дефекте и проекте, в котором он обнаружен.
Затем создается Задача и определяется Проект, в рамках которого она будет выполняться. Выбор проекта определяет, какие типы Задач будут доступны. Выбор типа Задачи определяет, какой набор деятельностей необходим для ее выполнения.
Рисунок 10. Замена перехода состояний при помощи деятельностей
В этом подходе вместо использования сложных диаграмм перехода состояний для перемещения отдельной записи через несколько наборов пользователей можно просто создать набор Деятельностей. Поскольку Задачи и Деятельности конфигурируются для каждого проекта в самом проекте, администраторам ClearQuest больше не придется изменять схему для каждого варианта процесса, необходимого рабочим группам проекта. Руководители проекта могут просто сконфигурировать набор Деятельностей, которые, по их мнению, необходимы для выполнения каждого типа задачи (информация о конфигурировании Задач и Деятельностей в соответствии с их типом приводится ниже).
О типах заданий (запись Work Types)
Как уже говорилось ранее, Запросы, Задачи и Деятельности можно дополнительно уточнить при помощи атрибута Type, идентифицирующего характер задания. Например, у вас может быть Запрос с типом "Дефект" Задача с типом "Исправить дефект" и Деятельность с типом "Реализовать" или "Протестировать".
Определения записи Work Type можно настраивать; они доступны в рамках всей системы. Для настройки типа задания достаточно просто создать новую запись ALMType:
- Сначала необходимо определить ALMTypeLabels для типов. Каждая запись ALMTypeLabel просто определяет "имя" типа, например, "Усовершенствование".
- Затем создается запись ALMType. Обратите внимание на то, что TypeLabels можно создавать непосредственно из записи ALMType, как показано на рисунке 11.
Рисунок 11. Запись ALMType
- В поле ALMType выберите Request (Запрос), Task (Задача) или Activity (Деятельность). Затем выберите метку для типа. Сохраните запись; теперь у вас есть новый тип, который можно использовать в любом проекте под управлением AML-системы.
После определения типов их нужно связать с проектом при помощи ALMWorkConfiguration; об этом мы поговорим чуть позже.
Атрибуты ALMType и TypeLabel позволяют создать весьма настраиваемую систему для вашей рабочей среды. Если ваша организация использует стандартный процесс, например, RUP или IT Infrastructure Library (ITIL®), то вы можете добавить в определения типа соответствующий глоссарий.
Но, скажем, вам необходим всего лишь подход к управлению заданиями в вашей рабочей группе. Или, может быть, вы пока не готовы использовать идею с трехуровневыми определениями, а просто хотите поручить людям работу и проследить за ее выполнением. Некоторые коллективы, практикующие принцип agile-разработки, работают именно так.
Вы можете осуществить такой минималистский подход, создав метки типа (Type Label) General и типы для Request, Task и Activity, присвоив всем им тип General. Если нужно различать Деятельности, то можно создать для них дополнительные типы:
- Сначала создайте проект и роли.
- Создайте Запрос, указав для атрибута типа значение "General," и ассоциируйте его с проектом.
- Создайте Задачу, указав для атрибута типа значение "General", и ассоциируйте ее с Проектом и Запросом, которые вы только что создали. Схема описанного подхода представлена на рисунке 12.
Рисунок 12. Деятельности, объединенные в рамках одной Задачи, создают модель для малых проектов или динамичных групп
- Откройте запись Project и перейдите на вкладку ALMWork Configurations. Добавьте записи Request и Task как записи по умолчанию для этого проекта (рисунок 13).
Рисунок 13. Добавление записей по умолчанию Request и Task в данный проект
- И, наконец, для каждой порции заданий, которая должна быть выполнена, создайте Деятельность (любого типа). Эта деятельность автоматически будет ассоциирована с Задачей, которая была задана как запись по умолчанию в данном проекте.
В данном примере всеми заданиями управляют Деятельности. Деятельности выполняются как очередь заданий, в которой каждое задание передается на выполнение, а затем выполняется. В проекте может быть много Деятельностей, но всего лишь одна Задача и один Запрос. Все пользователи этого проекта будут осведомлены лишь о Деятельностях и смогут взаимодействовать именно с ними, однако им не нужна информация о Задачах или Запросах.
Этот подход может использоваться в небольших динамичных рабочих группах или для небольших краткосрочных проектов, когда сотрудникам рабочей группы просто нужно знать, какое задание они должны выполнить. Но для крупных корпораций, которые связаны законодательными требованиями, эта модель может оказаться недостаточной, поскольку не дает возможности трассировать все задания к исходному запросу.
Эффективность "конфигурации заданий"
Описанное ранее разделение на Запросы, Задачи и Деятельности создает новую эффективную модель управления заданиями. Однако в предыдущей модели ClearQuest для определения особых переходов между состояниями использовалось несколько типов записей. В результате можно было управлять процессами при помощи типов записей и их состояний. Возникает следующий вопрос: как можно управлять такими процессами в новой модели? Придется ли для этого вручную создавать задачи и деятельности для каждого запроса? В первоначальной модели нужно было просто создать запись, а состояния были уже определены в этой записи. В новой модели одна деятельность представляет одно изменение состояния. Возможно, вам придется создать множество деятельностей; как можно гарантировать, что в каждом случае будет использоваться одна и та же деятельность?
Добавьте запись Work Configuration (Конфигурация задания), которая показана на рисунке 14. Именно здесь в полной мере проявляется гибкость новой модели. Чтобы адаптировать модель к рабочему потоку каждой рабочей группы, теперь можно назначить по умолчанию набор Деятельностей, необходимых для выполнения задач для каждого проекта. В понимании эффективности этой записи в наибольшей степени заинтересованы проект-менеджер и/или менеджер процессов. Другим пользователям в рабочей группе об этом знать необязательно.
Рисунок 14. Запись Work Types определяет характер задания; запись Work Configuration определяет рекомендуемый процесс
Для определения конфигурации задания (Work Configuration):
- Создайте метки типов заданий (Work Type Label);
- Создайте типы заданий (Work Types). Как уже говорилось ранее, атрибуты Work Type определяют для того чтобы описать характер задания;
- Ассоциируйте типы заданий (Work Type) с проектом при помощи записи Work Configuration. Запись Work Configuration определяет, какие типы заданий (Work Type) используются данным проектом. Кроме того, их можно использовать для добавления рекомендуемых процессов путем определения набора заданий для данного типа по умолчанию.
Записи Work Configuration позволяют проект-менеджеру наладить настраиваемый процесс управления заданиями по каждому проекту отдельно. Лучше всего показать это на примере, поэтому давайте вернемся к нашему примеру с записью Defect.
Проект 'A' имеет запрос типа "Проблема". Для этого проекта создана следующая конфигурация заданий (рисунок 15):
- Запись Work Configurations создана для каждого типа Деятельностей: это тип Develop и тип Validate;
- Еще одна запись Work Configuration определена для записи Task "Fix" (Исправить). Данная запись Work Configuration связывает запись Fix Task с проектом A и создает следующее правило: при создании записи Task типа Fix, как минимум, создается одна деятельность типа Develop и одна деятельность типа Validate;
- И наконец запись Work Configuration используется для установления следующего правила: при создании записи Request типа Problem также создается запись Task типа Fix.
Рисунок 15. Два Проекта - два процесса для решения проблемы. Здесь мы заменили одноразовые переходы состояний определенными для всего проекта наборами деятельностей
Как показано на рисунке 15, в проекте B можно сконфигурировать другой набор деятельностей для закрепления механизма работы этой рабочей группы. Конфигурация задания для этого проекта будет следующей:
- Запись Work Configuration для записи Task будет другой. Для Проекта B устанавливается правило о создании деятельностей типа Implement (Реализовать), Review (Проанализировать) или Test (Протестировать);
- Проект B также имеет Запрос типа Проблема, поэтому в его записи Work Configuration определено правило о создании Задачи типа Дефект.
Кроме того, обратите внимание, что на рисунке 15 проиллюстрирована возможность иметь один запрос, который удовлетворяется двумя разными задачами в двух разных проектах. Это делает возможной параллельную разработку, при которой каждой проектной группе поручается задание для удовлетворения данного запроса в контексте соответствующего проекта
На рисунке 16 показана конфигурация задания для рабочей группы проекта B.
Рисунок 16. Конфигурация задания для управления дефектом. Тип запроса может потребовать создания особого типа Задачи, которая может иметь собственный набор деятельностей. В записи Work configurations определяются все эти политики процесса для проекта
Мы показали только один пример, однако потенциал сценариев использования записи Work Configurations поистине безграничен. Например, можно создать Задачу "Начать работу по Проекту". Эта задача может иметь следующие Деятельности: "Определить роли", "Подобрать сотрудников для рабочей группы", "Определить итерации" и т.д. Еще одна задача может быть связана с уточнением требований и иметь отдельные деятельности для создания контрольных примеров, определения тестов производительности и т. д.
Запись Work Configuration позволяет проект-менеджерам наладить процессы для каждого проекта в отдельности. Пример AML-базы данных для "OpenUP" (который мы рассмотрим чуть позже) иллюстрирует использование записи Work Configurations для реализации процесса OpenUP.
После каждого изменения исходного кода приложение собирают и проверяют, имеет ли оно достаточное качество, позволяющее перейти к тестированию. После проверки выполняется "развертывание" сборки на тестовых серверах для тестирования. Эта последовательность сдачи изменений исходного кода, сборки и тестирования приложения выполняется независимо от охвата или размера релиза, будь то новое, создаваемое с нуля приложение или крупный пересмотр уже существующего приложения, исправление. При обнаружении ошибки регистрируются дефекты, а в исходный код вносятся изменения для исправления дефекта. После этого приложение снова должно быть собрано и развернуто на тестовых серверах для тестирования. Часто лишь отдельные специалисты в рабочей группе знают, какую сборку необходимо протестировать, поэтому проект-менеджер должен точно знать, кто эти люди.
ALM-схема поддерживает такую модель рабочих потоков, в которой имеет место параллельность разработки и тестирования. После того как разработчик сделает свою работу и выполнит деятельности по разработке, он сдает изменения в репозиторий. Инженер по релизам создает релизы (базовые линии), выполняет сборки, проверяет и передает сборки на тестирование. Тестировщик выполняет деятельности, связанные с тестированием.
В проектах разработки программного обеспечения сборки создаются непрерывно. Обычными вопросами к группе разработчиков являются вопросы типа "какие функции реализованы в сборке" и "что тестировать в сборке". ALM-решение предоставляет запись Build (Сборка), которая впервые появилась в пакетах Build и Deployment в ClearQuest 7.0.0.0. Эта запись позволяет рабочей группе документировать информацию о каждой сборке. Кроме того, ALM-решение использует запись Baseline (Релиз) чтобы отслеживать, какие деятельности сдаются в каждой сборке (рисунок 17). Благодаря записям Baseline, Build и Activity тестировщики знают, что необходимо тестировать, и могут отслеживать тесты, выполненные в данной сборке.
Рисунок 17. Интеграция записи Baseline с UCM-решением
Основной поток выглядит так: когда инженер по релизам проводит сборку, есть возможность зафиксировать, какие деятельности по разработке были выполнены. Для этого необходимо идентифицировать деятельности, которые были сданы с момента последней сборки. Запись Baseline (Релиз) используется для фиксации информации о состоянии деятельностей на данный момент времени. Тем, кто уже работал с системами UCM, знаком термин baseline (релиз) и его связь с фиксацией версии исходного кода в любой момент времени. В ALM-решении ClearQuest появилась запись Baseline, которую можно использовать для отображения на релизы UCM. При создании релиза в UCM, определив различия между деятельностями, можно понять, какие деятельности являются новыми. Этот список деятельностей можно заполнить в записи Baseline, как показано на рисунке 18. Для тех, кому раньше не приходилось работать с UCM, для идентификации списка деятельностей можно использовать запросы ClearQuest, которые можно вручную добавить в запись Baseline.
Рисунок 18. Запись Baseline с заполненной секцией Activities
После создания релиза выполняется сборка. Запись Build (рисунок 19) используется для фиксации состояния сборки. В этой записи можно создать ссылку на запись Baseline. Это связывает релиз и результат сборки. О состоянии сборки сообщает запись Build (сборка). Теперь остальные сотрудники рабочей группы могут использовать эту запись, чтобы определить дальнейшее направление работы. Для готовых сборок рабочая группа по тестированию может проанализировать запись Baseline и набор выполненных деятельностей. Каждая деятельность включает ссылку на исходную задачу, которая может включать и деятельности по тестированию. Благодаря этой новой наглядности контента сборки тестировщики могут более разумно сконцентрировать свои усилия.
Рисунок 19. Запись Build с новой вкладкой ALM
На первый взгляд может показаться, что для этого требуется слишком много усилий. Однако при помощи скриптов сборки и автоматизации сборки большая часть работы может быть автоматизирована в составе сборки. Можно использовать скрипт на языке Perl, который выявит различия между двумя релизами и заполнит запись Baseline. Существует и другой скрипт на Perl, который предназначен для создания и заполнения записи BTBuild. Рекомендуется использовать передовой метод, согласно которому создание записей Build и Baseline включается в скрипты сборки или в проект IBM Rational Build Forge®. В процессе выполнения сборки используйте предлагаемые Perl-скрипты для автоматического создания записи Baseline и определения деятельностей для создания записи Build в ClearQuest и заполнения полей соответствующей информацией.
Задачи могут быть распределены между итерациями проекта. Это позволит рабочей группе проекта равномерно распределить рабочую нагрузку между итерациями. Кроме того, можно создать диаграммы, аналогичные показанной на рисунке 20. Такие диаграммы позволяют проанализировать распределение заданий в рабочей группе. Это поможет проект-менеджеру равномерно распределить рабочую нагрузку между сотрудниками рабочей группы и избежать ситуаций "критического пути". Такие диаграммы также помогают проект-менеджеру убедиться в том, что распределены все задания.
Рисунок 20. Диаграмма для управления рабочей нагрузкой
Обратите внимание, что на рисунке 20 в столбце "No value" имеется пять Задач. Это означает, что они никому не поручены, и может служить для проект-менеджера сигналом о том, что часть заданий ускользнула от его внимания. Кроме того, обратите внимание, что в фазе конструирования рабочая нагрузка равномерно распределена между сотрудниками рабочей группы, тогда как в фазе передачи и сопровождения, как и следовало ожидать, имеется смещение рабочей нагрузки. Создавая подобные диаграммы, проект-менеджер сможет более эффективно управлять своим проектом, гарантируя выполнение всех заданий и активную работу всех своих сотрудников и предотвращая перегрузку отдельных членов рабочей группы большим количеством работы.