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

Что должно учитываться, когда формируется команда: нестандартное время работы, выходные, сверхурочные, отпуска.

Нужно помнить, что не всегда все 24 часа в сутки разработчики доступны.

Следующие ресурсы – это оборудование, машинное время и ПО. Это те дополнительные ресурсы, которые в общем случае могут на самом деле являться узким местом проекта. Почему? Потому что речь может идти про специализированное оборудование и ПО. Специализированное оборудование и ПО тоже является разделяемым ресурсом, которым нужно управлять.

В общем случае, какие у нас могут быть варианты:

 

 

Это среды разработки, отладчики, какие-то профайлеры, либо специальное железо, на котором может проходить компиляция.

Например, какие-то специализированные стенды, или стенды, не которых установлено ПО с ограниченным количеством лицензий.

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

Это все нужно учитывать и это тоже является внешним ограничением задачи планирования.

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

Программные проекты

Проект-самостоятельно управляемый объект разработки. Результат программного проекта-программный продукт. Для того, чтобы добиться этой цели – создание этого самого продукта, программный проект проходит разные этапы ЖЦ и при этом разработчиками выполняются различные проектные активности.

Все разработчики выполняют различные работы.

Первое – это задачи или подпроекты(программного проекта, которые являются обособленными и с которыми связан определенный набор требований)

Вторая часть проектной активности – это изменения, которые происходят с требованиями. исправление дефектов.

Вот это три активности, которые обычно выполняются разработчиками.

Первая активность – это задачи (тот элемент программного проекта, который выдается на выполнение какому-то одному разработчику)

Активность – изменение проекта.

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

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

Т.е. для наблюдения за проектом кроме визуального наблюдения нам требуются еще какие-либо отчеты о разных аспектах состояния проекта.

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

Срез по сотрудникам

срез по дефектам.

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

Проектные активности

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

Все разработчики выполняют различные работы. Что это за работы?

Первое – это задачи или подпроекты, или просто работы. Это части программного проекта, которые являются обособленными и с которыми связан определенный набор требований. Обычно конкретные задачи выполняются какими-то конкретными разработчиками.

Вторая часть проектной активности – это изменения, которые происходят с требованиями.

И еще одна вещь, которой может заниматься разработчик – это исправление дефектов.

Вот это три активности, которые обычно выполняются разработчиками.

Это средства по деятельности. А какие есть средства по времени?

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

Второй тип: вехи – это меньшая временная сущность, которая формирует какую-то функциональность.

Первая активность – это задачи.

 

Обычно задача – это тот элемент программного проекта, который выдается на выполнение какому-то одному разработчику.

Какими свойствами характеризуется задача? Их м.б. много, но чаще всего интересуют временные характеристики.

Какие м.б. временные связи между задачами?

Когда весь граф последовательностей задач построен у нас не д.б. циклических связей.

 

Активность – изменение проекта.

 

Последняя активность – это исправление программных дефектов.

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

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

 

Теперь рассмотрим вторую группу сущностей – это временные сущности.

Обычно программный проект делят на этапы.

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

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

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

Т.е. этап – это крупныйвременной промежуток, состоящий в решении ограниченного круга задач, подчиненных какой-то цели.

Если говорить о более мелких других временных сущностях, то это в первую очередь веха проекта (milеstone – это придорожный камень на котором указывается расстояние до следующего камня, а в России это называлось верста или верстовой столб).

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

Сама веха не является отдельным задачным этапом проекта.

 

Временные сущности

Теперь рассмотрим вторую группу сущностей – это временные сущности.

Обычно программный проект делят на этапы.

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

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

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

 

Т.е. этап – это крупныйвременной промежуток, состоящий в решении ограниченного круга задач, подчиненных какой-то цели.

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

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

Два основных временных параметра, которые используются в разных проектах – веха и этап. Все это вместе с активностями и проектными ресурсами относится к выполнению проекта.