Управление разработкой ПО

Управление ресурсами

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

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

При разработке графика проекта нужно выполнить следующие действия:

• Уточнить имеющуюся структуру работ проекта для того, чтобы использовать ее в рамках выбранного процесса разработки. Например, структура работ может соответствовать набору функций, которые должны иметься в результирующем продукте. Использование процесса XP может потребовать составить план поставок не в соответствии с наборами поставляемых функций, а в соответствии с понедельным планом поставок. В этом случае тяжело предвидеть наборы функций, которые будет иметь очередная поставляемая версия продукта, но можно спланировать еженедельные поставки, их обкатку у пользователей, анализ результатов и доработки по его итогам.
• Установить зависимости между отдельными работами, присутствующими в уточненной структуре работ проекта. Зависимости могут иметь разный характер: "финиш-старт" (работа может быть начата только после конца другой), "старт-старт" (работа может быть начата только с началом другой), "старт-финиш" и "финиш-финиш". Если вы встречаете более сложную зависимость типа "работу можно начать, только если сделана некоторая часть другой", это признак того, что работы декомпозированы недостаточно детально и нужно разбить вторую работу на части.

  Вставив фиктивные работы, не требующие ресурсов и времени, можно все зависимости привести к виду "финиш-старт".

  

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

  Таблица 16.1. Работы проекта, сетевая диаграмма которого показана на рис. 16.5

  Код	Название	Трудоемкость, ч*мес	Время, мес
  T1	Формулировка целей и содержания проекта	0,6	0,3
  T2	Сбор и анализ требований	3,0	1,0
  T3	Разработка архитектуры	6,0	2,0
  T4	Первичное планирование	0,6	0,3
  T5	Разработка маркетинговых документов	0,3	0,3
  T6	Реализация прототипа	3,0	1,0
  T7	Детальное проектирование	6,0	2,0
  T8	Испытания прототипа	0,6	0,3
  T9	Анализ результатов испытаний и изменения проекта	1,0	0,3
  T10	Детальное планирование	1,0	0,3
  T11	Разработка и отладка пользовательского интерфейса	3,0	1,0
  T12	Разработка пользовательской документации	2,0	1,0
  T13	Реализация	8,0	2,0
  T14	Тестирование	4,0	1,0
  T15	Доработка по результатам тестирования	4,0	1,0
  T16	Развертывание	1,5	0,5
  T17	Обучение пользователей	2,0	0,5

  Если связи между работами в сетевой диаграмме превратить в вершины, а вершины-работы в связи (и добавить две новых вершины — начало и конец проекта), то получится так называемая PERT-диаграмма (PERT — program evaluation and review technique, техника оценки и обзора программ). PERT-диаграмма, соответствующая приведенной ранее сетевой, показана на Рис. 87. Часто различий между этими двумя видами диаграмм не делают, называя обе и сетевыми, и PERT-диаграммами.

  

  
  увеличить изображение
  Рис. 16.6. PERT-диаграмма для рассматриваемого примера проекта

  Сетевые и PERT-диаграммы используются для планирования продолжительности проекта и выделения критических путей — последовательностей работ от начала до конца проекта, сумма длительностей которых максимальна среди таких последовательностей. В примере, представленном на рис. 16.6, критических путей несколько — работы, лежащие на них, изображены жирными стрелками. Выполнить проект быстрее, чем за время, требующееся для прохождения по критическому пути, нельзя. Поэтому критические пути используют для планирования основных поставок в ходе проекта. В нашем примере длительность проекта не может быть меньше, чем 10,7 месяцев. Кроме того, любая задержка в одной из работ, попавшей на критический путь, обязательно вызовет задержку проекта в целом, а значит, такие работы требуют повышенного внимания во время проекта.

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

  

  
  увеличить изображение
  Рис. 16.7. Диаграмма Ганта для рассматриваемого примера проекта

  Расписание работ удобно изображать с помощью диаграмм Ганта (Gantt chart). Эта диаграмма показывает и связи между работами, и их длительность во времени. Диаграмма Ганта для рассмотренного примера показана на рис. 16.7.

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

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

  

  
  увеличить изображение
  Рис. 16.8. График рассматриваемого проекта, построенный с учетом доступных ресурсов

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

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

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