2015-05-10
322
При подготовке плана придерживаемся следующих рекомендаций:
1. Не используем суммарные задачи для декомпозиции.
Все задачи помещаем в один линейный список. Сначала это может показаться неудобным, но зато избавляет от многих проблем в дальнейшем. Для управления структурой задач используем настраиваемые поля (см.ниже).
2. Очень часто для управления зависимостями задач используют Drag&Drop. Когда задач много это быстро становится неудобно. Рекомендуется в этом случае не использовать перетаскивание, а явное указывать номера задач-предшественников. для этого можно добавить в таблицу столбец «предшественники» и вписывать номера задач вручную.
3. Срок каждой задачи не должен превышать двух недель. Если срок задачи превышает неделю — это уже повод задуматься о её декомпозиции. Существует простая методика оценки: примитивная задача — 2 дня, средней сложности — 1 неделя, сложная задача — 2 недели. При этом сложных задач не должно быть много. Такой подход дает возможность подготовить оценочный план довольно быстро. На больших проектах погрешности оценок отдельных задач обычно нивелируются, а на малых часто можно и нужно использовать и более точные оценки.
4. Всеми силами избегаем задач, у которых несколько исполнителей. Для каждой задачи должен быть назначен только один исполнитель. Двух исполнителей имеет смысл назначать только если они действительно работают вдвоем (например, вы практикуете парное программирование). В прочих случаях лучше декомпозировать задачу.
5. При назначении исполнителей руководствуемся их профессией и квалификацией, пока не беспокоясь о равномерности загрузки.
6. Используем суммарные задачи для разделения задач на этапы. Ставим зависимости между этапами, чтобы они шли последовательно. Разделение на этапы пока достаточно приблизительное.
Рис. 1 Список задач, разделенный на этапы
Балансировка проекта
Самым главным в методике является именно балансировка. Цель этого процесса — подготовить план, в котором работы достаточно равномерно разделены между исполнителями на всем протяжении.
После первичной подготовки плана обычно получается не оптимизированный проект. Поэтому начинаем приводить его в порядок. Приведение в порядок заключается в ручной балансировке назначений исполнителей и разделений на этапы. Для этого используем группировку задач по исполнителям, чтобы увидеть как разложились задачи. Для удобства просмотра рекомендую сортировать задачи по дате начала.
Рис. 2 Группировка задач по исполнителям
Примечание. Теоретически, для оценки загрузки полагается использовать графики
загрузки пользователей. Эти графики хороши для начальства, когда они оценивают готовый проект. Но они непригодны на этапе создания плана, так как показывают что все плохо, но совершенно не дают информации почему это так и что можно сделать.
Дальше начинается балансировка. Требуется минимизировать сроки выполнения каждого этапа путем обеспечения более-менее равномерной нагрузки на всех участников проекта.
Для этого мы выполняем следующие действия:
1. Сменить исполнителя задачи. Это имеет смысл сделать, если мы видим, что у одного исполнителя большой хвост задач, а у другого есть явные «дыры», причем он может взять на себя некоторые работы у первого.
2. Перенести задачу в другой этап. Задача, которая приводит у удлинению срока этапа, но при этом не является необходимой для получения результата этапа может быть перенесена на этап позже. И наоборот, если в этапе присутствуют «дыры» в загрузке исполнителей, а изменить исполнителей не получается, то можно попробовать взять задачи из следующего этапа.
Делать все это, приходится вручную, выполняя выравнивание загрузки ресурсов после каждого изменения. Несмотря на кажущуюся сложность, этот процесс обычно занимает конечное время.
Теперь еще раз внимательно смотрим на проект, убеждаемся, что связи между задачами расставлены правильно, что ничего не забыто, а назначения исполнителей соответствуют их специальностям и квалификации.
