Заметки консультанта

Шамрай Александр Владимирович

Posts Tagged ‘planning’

Добавим немного автоматизации для планирования в TFS

Posted by Шамрай Александр на Сентябрь 2, 2013

Автоматизация процессов– задача, которую призваны решать системы такие как TFS. Автоматизация управления конфигурациями, сборки проектов, тестирования, сбора отчетной информации и т.д. Вендоры обычно закрывают все основные моменты, но зачастую остаются места для улучшения. Допустим автоматизация планирования реализации и тестирования. Рассмотрим ниже пример для планирования реализации требований на итерацию.

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

Рисунок 1. Список требований на итерацию

Первым делом добавим новые задачи в план. У задач в TFS есть отдельное поле Действие, которое имеет ввиду тип работ необходимых для выполнения. Собственно, набор этих действий и будет нам определять шаблон создаваемых задач. Кроме этого выберем те требования, для которых нам интересно добавить дочерние задачи и выполним генерирование.

Рисунок 2. Выбор требований для планирования

В результате будет создан шаблон, в который нам необходимо добавить из списка исполнителей по задачам. Напротив задач, которые нам не нужны в плане, убираем чек-бокс. Результат публикуем.

Рисунок 3. Создание новых задач и назначение исполнителей

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

Рисунок 4. Результат создания задач

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

Рисунок 5. Выбор требований для создания тестов

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

Рисунок 6. Выбор плана тестирования

Для новых тестов устанавливаем ответственных и публикуем в TFS.

Рисунок 7. Указание ответственных за тесты

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

Рисунок 8. Сгенерированные задачи и тесты

Кроме этого тесты будут отражаться в плане тестирования в нужной иерархии и с назначенными исполнителями.

Рисунок 9. Новый план тестирования в Test Manager

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

Рисунок 10. Отслеживание выполнения

Posted in Полезное, Разное, Разработка, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , | Leave a Comment »

CMMI DEV v1.3 – Планирование проекта

Posted by Шамрай Александр на Январь 11, 2011

Перевод Шамрай А.В.

Процессная область Управления Проектом уровня зрелости 2

Назначение

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

Вступительный комментарий

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

  • Разработка плана проекта
  • Взаимодействие с соответствующими заинтересованными сторонами на надлежащем уровне
  • Получение обязательств по реализации плана
  • Поддержка плана

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

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

Термин «план проекта» используется в этой процессной области как общий план для контроля проекта. План проекта может быть отдельным документом или быть распределенным между несколькими документами. В любом случае, он обеспечивает целостную картину о том, кто делает и что должно быть включено. Кроме того, мониторинг и управление может быть централизованным или распределенным до тех пор, пока на проектном уровне может быть сохранена целостность картины состояния проекта.

Для линейки продукта, существует различный набор мероприятий, которые выиграют от использования практик этой процессной области. Эти мероприятия включают в себя создание и поддержку основных активов, разработку продуктов с использованием основных активов и организацию общих трудозатрат для поддержки и координации операций взаимосвязанных рабочих групп и их деятельности. В Agile среде инкрементальная разработка включает в себя планирование, мониторинг, контроль и перепланировке чаще, чем в традиционной разработке. Хотя план на высоком уровне для всего проекта или трудозатрат обычно создается, команды оценивают, планируют и обеспечивают фактическое выполнение инкремента или итерации все время. Обычно команды не прогнозируют то, что вне проекта или итерации, за исключением прогнозирования рисков, основных событий и крупномасштабных воздействий и ограничений. Оценки отражают итерационные и командные факторы, которые влияют на время, трудозатраты, ресурсы и риски для выполнения итерации. Команда планирует, отслеживает и корректирует планы во время выполнения каждой итерации так часто, на сколько это требуется (например, ежедневно). Обязательства по выполнению в плане обеспечиваются, когда задачи назначены и приняты во время планирования итерации, пользовательские истории разработаны или оценены и итерации составлены из задач, содержащихся в журнале работ. (См. «CMMI при использовании Agile подходов» в части I.)

Связанные процессные области

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

См. процессную область Техническое Решение для получения дополнительной информации о выборе, проектировании и реализации решений для требований.

См. процессную область Измерения и Анализ для получения дополнительной информации о спецификации измерений.

См. процессную область Управление Требованиями для получения дополнительной информации о управлении требованиями.

См. процессную область Управление Рисками для получения дополнительной информации о выявлении и анализе рисков, смягчении рисков.

Перечень специфических целей и практик

  • СЦ 1 Сформировать Оценки
    • СП 1.1 Оценивайте Масштаб Проекта
    • СП 1.2 Формируйте Оценки Атрибутов Рабочих Продуктов и Задач
    • СП 1.3 Определяйте Фазы Жизненного Цикла Проекта
    • СП 1.4 Оценивайте Трудозатраты и Стоимость
  • СЦ 2 Разработать Плана Проекта
    • СП 2.1 Формируйте Бюджет и График
    • СП 2.2 Определяйте Риски Проекта
    • СП 2.3 Планируйте Управление Данными
    • СП 2.4 Планируйте Ресурсы Проекта
    • СП 2.5 Планируйте Необходимые Знания и Навыки
    • СП 2.6 Планируйте Участие Заинтересованных Сторон
    • СП 2.7 Создайте План Проекта
  • СЦ 3 Получить Обязательства Выполнения по Плану
    • СП 3.1 Пересматривайте Планы, Которые Затрагивают Проект
    • СП 3.2 Согласовывайте Объемы Работы и Ресурсы
    • СП 3.3 Получайте Обязательства Выполнения по Плану

Специфические практики по целям

СЦ 1 Сформировать Оценки

Оценки параметров планирования проекта сформированы и поддерживаются.

Параметры планирования проекта включают всю информацию, необходимую в проекте для выполнения планирования, организации, управления персоналом, направления, координации, отчетности и управления бюджетом.

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

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

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

СП 1.1 Оценивайте Масштаб Проекта

Создавайте структуру декомпозиции работ (СДР) верхнего уровня для оценки масштаба проекта.

СДР развивается вместе с проектом. СДР верхнего уровня может служить для структурирования начальной оценки. Разработка СДР делит весь проект на взаимосвязанное множество управляемых компонентов.

Как правило, СДР является ориентированной на продукт, рабочий продукт или задачу структурой, которая обеспечивает схему для выявления и организации логических единиц работы для управления, которые называются «рабочими пакетами». СДР обеспечивает ссылочный и организационный механизм для назначения работы, формирования графика и ответственности и используется в качестве базы для планирования, организации и контроля работ по проекту.

Некоторые проекты используют термин «контрактная СДР», т.е. часть СДР размещается в контракте (возможно, вся СДР). Не все проекты имеют контрактную СДР (например, внутренне финансируемые разработки).

Пример рабочих продуктов

1. Описания задач

2. Описания рабочего пакета

3. СДР

Подпрактики

1. Разрабатывайте СДР.

СДР обеспечивает схему для организации работ проекта. СДР должна обеспечивать идентификацию следующих пунктов:

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

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

СДР верхнего уровня предназначена для того, чтобы помочь оценить трудозатраты проектных работ для задач, организационных ролей и обязанностей. Уровень детализации СДР на этом уровне помогает разработке реалистичных рабочих графиков и тем самым сводит к минимуму необходимость выделения резерва.

3. Определяйте продукты и компонентов, необходимые для внешней закупки.

См. процессную область Управление Соглашениями с Поставщиками для получения дополнительной информации об управлении приобретением товаров и услуг.

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

СП 1.2 Формируйте Оценки Атрибутов Рабочих Продуктов и Задач

Обеспечивайте и поддерживайте оценивание атрибутов рабочих продуктов и задач.

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

Примеры атрибутов для оценки:

  • Количество и сложность требований
  • Количество и сложность интерфейсов
  • Объем данных
  • Количество функций
  • Функциональные единицы
  • Количество строк кода
  • Количество классов и объектов
  • Количество таблиц базы данных
  • Количество полей в таблицах данных
  • Архитектурные элементы
  • Опыт работы участников проекта
  • Объем кода, который необходим для обеспечения повторного использования вместо новой разработки
  • Командная производительность и сложность
  • Количество страниц
  • Количество входных и выходных элементов
  • Количество технических рисков
  • Количество логических соединений для интеграционных схем
  • Количество частей (например, печатных плат, компонентов, механических частей)
  • Физические ограничения (например, вес, объем)
  • Географическое распределение участников проекта
  • Близость клиентов, конечных пользователей и поставщиков
  • Как сложно или легко договориться с клиентом
  • Качество и «чистота» существующего кода

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

Пример рабочих продуктов

1. Размер и сложность задач и рабочих продуктов

2. Оценка моделей

3. Атрибут оценки

4. Технический подход

Подпрактики

1. Определяйте технический подход к проекту.

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

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

Методы определения размера и сложности должны быть основаны на утвержденных моделях или исторических данных.

Методы определения атрибутов развиваются с пониманием отношений характеристик продукта к его атрибутам.

3. Оценивайте атрибуты рабочих продуктов и задач.

Примеры рабочих продуктов, для которых выполняется оценка размера:

  • Поставляемые и непоставляемые рабочие продукты
  • Документы и файлы
  • Операционное и поддерживающее оборудование, микропрограммы и программное обеспечение

СП 1.3 Определяйте Фазы Жизненного Цикла Проекта

Определяйте фазы жизненного цикла проекта, которые обеспечат границы планирования.

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

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

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

В зависимости от стратегии разработки могут быть промежуточные фазы создания прототипов, инкрементирования возможностей или циклы спиральной модели. Кроме этого, могут быть явно включены фазы для «запуска проекта» и «закрытия проекта».

Пример рабочих продуктов

1. Фазы жизненного цикла проекта

СП 1.4 Оценивайте Трудозатраты и Стоимость

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

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

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

Пример рабочих продуктов

1. Обоснование оценки

2. Оценка трудозатрат проекта

3. Оценка стоимости проекта

Подпрактики

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

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

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

2. Включайте поддержку инфраструктурных потребностей при оценке трудозатрат и стоимости.

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

Необходимо рассмотреть потребности в инфраструктурных ресурсах в среде разработки, тестовой среде, среде выпуска, операционной среде или в любой комбинации этих сред при оценке трудозатрат и стоимости.

Примеры инфраструктурных ресурсов:

  • Критические ресурсы компьютера (например, память, диски и пропускная способность сети, периферия, каналы связи, возможности этих ресурсов)
  • Среды проектирования и инструменты (например, инструменты для создания прототипов, тестирования, интеграции, монтажа, системы автоматизированного проектирования [CAD], моделирование)
  • Средства, машины и оборудование (например, испытательные стенды, записывающие устройства)

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

Примеры рабочих продуктов, которые обычно используются для оценки трудозатрат и стоимости:

  • Оценки, выполняемые экспертом или группой экспертов (например, метод Дельфи, Игра по планированию в Экстремальном программировании)
  • Риски, в том числе, в какой степени трудозатраты являются беспрецедентным
  • Критические компетенции и роли, необходимые для выполнения работы
  • Перемещение
  • СДР
  • Выбранная модель жизненного цикла проекта и процессов
  • Оценки стоимости жизненного цикла
  • Уровень квалификации руководителей и сотрудников, необходимых для выполнения работы
  • Необходимые знания, навыки и обучение
  • Прямые трудовые затраты и накладные расходы
  • Соглашение об обслуживании для колл-центров и гарантийных работ
  • Уровень безопасности, необходимый для задач, рабочих продуктов, оборудования, программного обеспечения, персонала и рабочего окружения
  • Необходимые средства (например, офис, помещения для совещаний и рабочие станции)
  • Требования к продукту и компонентам продукта
  • Оценки размера рабочих продуктов, задач и ожидаемых изменений
  • Стоимость внешне приобретенных продуктов
  • Возможности производственных процессов
  • Потребности в инженерных средствах
  • Возможности инструментов, используемых в инженерной среде
  • Технический подход

СЦ 2 Разработать План Проекта

План проекта создан и поддерживается в качестве основы для управления проектом.

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

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

СП 2.1 Формируйте Бюджет и График

Формируйте и поддерживайте бюджет и график проекта.

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

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

Пример рабочих продуктов

1. Рабочие графики проекта

2. Графики зависимостей

3. Бюджет проекта

Подпрактики

1. Определяйте основные вехи.

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

2. Определяйте предположения по графику.

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

3. Определяйте ограничения.

Факторы, которые ограничивают гибкость вариантов управления, должны быть определены как можно раньше. Рассмотрение атрибутов рабочих продуктов и задач часто выносит эти вопросы на поверхность. Такие атрибуты могут включать длительности задачи, ресурсы, входные и выходные элементы.

4. Определяйте зависимости задачи.

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

Примеры инструментов и материалов, которые могут помочь определить оптимальный порядок задач:

  • Метод критического пути (CPM)
  • Техники оценки и анализа программы (PERT)
  • Планирование с ограниченными ресурсами
  • Приоритеты клиента
  • Рыночные возможности
  • Значение для конечных пользователей

5. Формируйте и поддерживайте бюджет и график.

Формирование и поддержка бюджета проекта и графика обычно включает в себя следующее:

  • Определение наличия подтвержденных или ожидаемых ресурсов и средств
  • Определение времени фаз мероприятий
  • Определение срывов подчиненных графиков
  • Определение зависимостей между различными видами деятельности (связи с предшественниками или последователями)
  • Определение рабочего графика мероприятий и вех для поддержки мониторинга и контроля проекта
  • Определение вех, релизов или инкрементов на поставку продуктов для клиентов
  • Определение мероприятий для соответствующей продолжительности
  • Определение вех для соответствующего разделения времени
  • Определение резерва в планировании на основе уровня достоверности в выполнении графика и бюджета
  • Использование соответствующих исторических данных для проверки графика
  • Определение потребности в инкрементном финансировании
  • Документирование проектных предположений и обоснований

6. Создавайте критерии корректирующих действий.

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

СП 2.2 Определяйте Риски Проекта

Выявляйте и анализируйте риски проекта.

См. специфические практики Мониторинг Рисков Проекта в процессной области Мониторинг и Контроль Проекта для получения дополнительной информации о мониторинге рисков.

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

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

Планирование идентификации и анализа рисков в проекте обычно включает в себя следующее:

  • Выявление рисков
  • Анализ рисков для определения воздействия, вероятности возникновения и временных рамок, в которые проблемы могут возникнуть
  • Приоритезация рисков

Пример рабочих продуктов

1. Выявленные риски

2. Воздействия риска и вероятности возникновения

3. Приоритеты рисков

Подпрактики

1. Выявляйте риски.

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

Примеры инструментов для выявления и анализа рисков:

  • Таксономия рисков
  • Оценка рисков
  • Контрольные списки
  • Структурированные интервью
  • Мозговой штурм
  • Процессные, проектные и модели эффективности продукта
  • Стоимостные модели
  • Сетевой анализ
  • Анализ факторов качества

2. Документируйте риски.

3. Анализируйте и согласовывайте с соответствующими заинтересованными сторонами документированные риски на полноту и правильность.

4. Пересматривайте риски по мере необходимости.

Примеры, когда выявленные риски, возможно, должны быть пересмотрены:

  • Когда выявлены новые риски
  • Когда риски станут проблемами
  • Когда риски удаляются
  • Когда обстоятельства проекта значительно изменились

СП 2.3 Планируйте Управление Данными

Планируйте управление данными проекта.

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

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

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

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

Пример рабочих продуктов

1. План управления данными

2. Главный список управляемых данных

3. Описание содержания и формата данных

4. Списки требований к данным для покупателей и поставщиков

5. Конфиденциальные требования

6. Требования к безопасности

7. Процедуры обеспечения безопасности

8. Механизмы для получения, воспроизведение и распространение данных

9. Расписание для сбора данных проекта

10. Список собираемых данных проекта

Подпрактики

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

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

2. Создавайте механизм для архивирования данных и доступа к архивным данным.

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

3. Определяйте данные проекта, которые будут выявляться, собираться и распространяться.

4. Определяйте требования для обеспечения доступа и распределения данных для соответствующих заинтересованных сторон.

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

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

СП 2.4 Планируйте Ресурсы Проекта

Планируйте ресурсы для выполнения проекта.

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

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

Каждому рабочему пакету в СДР должен быть присвоен уникальный идентификатор (например, номер) для обеспечения отслеживания. СДР может быть основано на требованиях, мероприятиях, рабочих продуктах, сервисах или сочетании этих элементов. Словарь, который описывает работу для каждого рабочего пакета в СДР, должен соответствовать структуре декомпозиции работ.

Пример рабочих продуктов

1. Рабочие пакеты

2. Словарь задач СДР

3. Требования к персоналу в зависимости от размера и масштаба проекта

4. Список критически важных средств и оборудования

5. Диаграммы и описания процессов и последовательности работ

6. Список требований администрирования проекта

7. Отчеты о состоянии

Подпрактики

1. Определяйте требования к процессу.

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

2. Определяйте требования к каналам связи.

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

3. Определяйте требования к персоналу.

Кадровое обеспечение проекта зависит от декомпозиции проектных требований на задачи, роли и обязанности для выполнения требований проекта, как указано в рабочих пакетах СДР.

Требования к персоналу должны включать уровень знаний и навыков, необходимых для каждой определенной позиции, как это описано в специфической практике Планирование Необходимых Знаний и Навыков.

4. Определяйте требования к средствам, оборудованиям и компонентам.

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

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

5. Определяйте другие постоянные потребности в ресурсах.

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

  • Расходные материалы (например, электричество, канцелярские товары)
  • Доступ к интеллектуальной собственности
  • Доступ к перевозке (для людей и оборудования)

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

СП 2.5 Планируйте Необходимые Знания и Навыки

Планируйте знания и навыки, необходимые для выполнения проекта.

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

Знания поставляются в проекты с помощью обучения персонала проекта и приобретения знаний из внешних источников.

Кадровые требования зависят от знания и навыков, необходимых для оказания поддержки реализации проекта.

Пример рабочих продуктов

1. Перечень необходимых навыков

2. Планы кадрового обеспечения и найма новых сотрудников

3. Базы данных (например, навыки, обучение)

4. Планы тренингов

Подпрактики

1. Определяйте знания и навыки, необходимые для выполнения проекта.

2. Оценивайте доступные знания и навыки.

3. Выбирайте механизмы для обеспечения необходимых знаний и навыков.

Примеры механизмов:

  • Внутреннее обучение (как организационное, так и проектное)
  • Внешнее обучение
  • Кадровое обеспечение и набор новых сотрудников
  • Внешнее приобретение навыков

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

4. Включайте выбранные механизмы в план проекта.

СП 2.6 Планируйте Участие Заинтересованных Сторон

Планируйте участие выявленных заинтересованных сторон.

Заинтересованные стороны определяются из всех фаз жизненного цикла проекта путем выявления людей и функции, которые должны быть представлены в проекте, и описания их актуальности и степени взаимодействия в проектной деятельности. Для идентификации можно использовать двумерную матрицу с заинтересованными сторонами по одной оси и проектной деятельностью вдоль другой оси. Актуальность заинтересованных лиц в деятельности в той или иной фазе проекта и объем взаимодействия будет отражена на пересечении оси фазы проектной деятельности и оси заинтересованных лиц.

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

Примеры материалов, которые должны быть включены в план участия заинтересованных сторон:

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

Реализация этой специфической практики основывается на общедоступной информации или информации общей с предыдущей специфической практикой Планирование Необходимых Знаний и Навыков.

Пример рабочих продуктов

1. План участия заинтересованных сторон

СП 2.7 Создайте Плана Проекта

Создайте и поддерживайте общий план проекта.

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

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

  • Решения по жизненному циклу проекта
  • Задачи проекта
  • Бюджеты и рабочие графики
  • Вехи
  • Управление данными
  • Выявление рисков
  • Требования к ресурсам и квалификации
  • Выявление и взаимодействие с заинтересованными лицами
  • Инфраструктурные решения

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

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

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

  • План разработки программного обеспечения
  • План проекта программного обеспечения
  • План программного обеспечения

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

Примеры планов, которые использовались в Министерстве обороны США:

  • Интегрированный Генеральный План – план на основе событий, который документирует значительные достижения с критериями «пройдено»/ «не пройдено» для бизнес и технических элементов проекта и который связывает каждое достижение с ключевым событием проекта.
  • Интегрированный Генеральный Рабочий График – интегрированный и сетевой многослойный график задач проекта, необходимых для завершения работы, описанной в соответствующем Интегрированном Генеральном Плане.
  • План Управления Системного Проектирования – план, который детализирует интегрированные технические задачи в рамках всего проекта.
  • Генеральный Рабочий График Управления Системного Проектирования – график на основе событий, который содержит подборку ключевых технических достижений, каждое из которых имеет измеряемые критерии, требующие успешного их достижения для того, чтоб пройти эти события.
  • Детальный Рабочий График Управления Системного Проектирования – подробный, основанный на времени и ориентированный на задачи график, который связывает даты и вехи с Генеральным Рабочим Графиком Управления Системного Проектирования.

Пример рабочих продуктов

1. Общий план проекта

СЦ 3 Получить Обязательства Выполнения по Плану

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

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

СП 3.1 Пересматривайте Планы, Которые Затрагивают Проект

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

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

Пример рабочих продуктов

1. Отчет по результатам пересмотра планов, которые влияют на проект

СП 3.2 Согласовывайте Объемы Работ и Ресурсов

Выполняйте регулирование плана проекта для согласования доступных и предполагаемых ресурсов.

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

Пример рабочих продуктов

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

2. Пересмотренные бюджеты

3. Пересмотренные рабочие графики

4. Пересмотренный список требований

5. Пересмотренные соглашения с заинтересованными сторонами

СП 3.3 Получите Обязательства Выполнения по Плану

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

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

Пример рабочих продуктов

1. Документированные запросы на подтверждение обязательств по выполнению

2. Документированные обязательства по выполнению

Подпрактики

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

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

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

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

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

3. Пересматривайте внутренние обязательств выполнения с руководством по мере необходимости.

4. Пересматривайте внешние обязательств выполнения с руководством по мере необходимости.

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

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

Четко определенные спецификации взаимодействия формируют основу для принятия обязательств выполнения.

Posted in CMMI, Стандарты и методологии | Отмечено: , , , , , | 2 комментария »

 
%d такие блоггеры, как: