ГРУППЫ ПРОЦЕССОВ УПРАВЛЕНИЯ ПРОЕКТОМ

ПРОЦЕССЫ УПРАВЛЕНИЯ ПРОЕКТОМ Управление проектами – это приложение знаний, навыков, инструментов и методов к работам проекта для удовлетворения требований, предъявляемых к проекту. Это приложение знаний требует эффективного управления соответствующими процессами.

ОПРЕДЕЛЕНИЕ ПРОЦЕССА Процесс – это набор взаимосвязанных действий и операций, осуществляемых для получения заранее определенного продукта, результата или услуги. Каждый процесс характеризуется своими входами, инструментами и методами, которые могут быть применены, а также конечными выходами.

УСПЕШНЫЕ ПРОЕКТЫ Для того чтобы проект оказался успешным, его команда должна: выбрать те процессы, которые необходимы для достижения целей проекта; использовать определенный подход, который может быть принят для удовлетворения требований проекта; исполнить требования, чтобы удовлетворить потребности и ожидания заинтересованных сторон проекта; и находить баланс между противоречивыми требованиями к содержанию, времени, стоимости, качеству, ресурсам и рискам, чтобы произвести заданный продукт, услугу или результат.

ПРОЦЕССЫ ПРОЕКТА Процессы управления проектом - обеспечивают результативное выполнение проекта в течение всего времени его существования. Процессы, ориентированные на продукт - определяют и создают продукт проекта. В данном курсе рассматриваются только процессы управления проектом

ГРУППЫ ПРОЦЕССОВ УПРАВЛЕНИЯ ПРОЕКТАМИ Группа процессов инициации. Группа процессов планирования. Группа процессов исполнения. Группа процессов мониторинга и управления. Группа процессов завершения.

ГРУППЫ ПРОЦЕССОВ УПРАВЛЕНИЯ ПРОЕКТАМИ

ВЗАИМОДЕЙСТВИЕ ГРУПП ПРОЦЕССОВ В РАМКАХ ПРОЕКТА

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

ГРУППА ПРОЦЕССОВ ПЛАНИРОВАНИЯ Группа процессов планирования состоит из процессов, осуществляемых для определения общего содержания работ, постановки и уточнения целей и разработки последовательности действий, требуемых для достижения данных целей. Процессы планирования разрабатывают план управления проектом и документацию проекта, которые будут использованы для выполнения проекта. По мере поступления и осмысления большего объема информации или характеристик проекта может потребоваться дополнительное планирование. Значительные изменения, происходящие на протяжении жизненного цикла проекта, приводят к необходимости вновь вернуться к одному или нескольким процессам планирования, а, возможно, и к процессам инициации.

ГРУППА ПРОЦЕССОВ ИСПОЛНЕНИЯ Группа процессов исполнения состоит из процессов, применяемых для выполнения работ, определенных в плане управления проектом для осуществления целей проекта. Эта группа процессов включает в себя координацию людей и ресурсов, а также интеграцию и выполнение операций проекта в соответствии с планом управления проектом

ГРУППА ПРОЦЕССОВ МОНИТОРИНГА И УПРАВЛЕНИЯ Группа процессов мониторинга и управления состоит из процессов, требуемых для отслеживания, анализа и регулирования хода и эффективности выполнения проекта, выявления тех областей, в которых требуется внесение изменений в план, и инициации соответствующих изменений. Основное назначение данной группы процессов состоит в том, что исполнение проекта контролируется и измеряется регулярно и тщательно, с тем чтобы выявить отклонения от плана управления проектом.

ГРУППА ПРОЦЕССОВ ЗАВЕРШЕНИЯ Группа процессов завершения состоит из процессов, выполняемых для завершения всех операций в рамках всех групп процессов управления проектом для формального завершения проекта, фазы или контрактных обязательств. Данная группа процессов подтверждает, что процессы, определенные в рамках всех групп процессов, выполнены необходимым образом для завершения проекта или фазы проекта, и формально устанавливает, что проект или фаза проекта завершена.

МЕТОДОЛОГИИ УПРАВЛЕНИЯ ПРОЕКТАМИ ПО РАЗРАБОТКЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Waterfall RUP MSF Agile: XP Lean Scrum TDD (Test-driven design) …..

WATERFALL (ВОДОПАД) Модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, внедрения и поддержки.

RUP (RATIONAL UNIFIED PROCESS) RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта.

НАЧАЛЬНАЯ ФАЗА (INCEPTION) В фазе Inception: Формируются видение и границы проекта. Создается экономическое обоснование (business case). Определяются основные требования, ограничения и ключевая функциональность продукта. Создается базовая версия модели прецедентов. Оцениваются риски. При завершении фазы Inception оценивается достижение вехи целей жизненного цикла (Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта.

УЛУЧШЕНИЕ (ELABORATION) В фазе Elaboration производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя: Документирование требований (включая детальное описание для большинства прецедентов). Спроектированную, реализованную и оттестированную исполняемую архитектуру. Обновленное экономическое обоснование и более точные оценки сроков и стоимости. Сниженные основные риски. Успешное выполнение фазы Elaboration означает достижение вехи архитектуры жизненного цикла (Lifecycle Architecture Milestone).

РАЗРАБОТКА (CONSTRUCTION) Во время этой фазы происходит реализация большей части функциональности продукта. Фаза Construction завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).

ВНЕДРЕНИЕ (TRANSITION) Во время фазы Transition создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Inception, фаза Transition повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.

MSF (MICROSOFT SOLUTION FRAMEWORK

AGILE Agile семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile Manifesto. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются успешные команды. Agile Manifesto разработан и принят февраля 2001 года. Agile Manifesto cодержит 4 основные идеи и 12 принципов. Примечательно что, Agile Manifesto не содержит практических советов

ОСНОВНЫЕ ИДЕИ AGILE Личности и их взаимодействия важнее, чем процессы и инструменты; Работающее программное обеспечение важнее, чем полная документация; Сотрудничество с заказчиком важнее, чем контрактные обязательства; Реакция на изменения важнее, чем следование плану

ОСНОВНЫЕ ПРИНЦИПЫ AGILE удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО; приветствие изменения требований, даже в конце разработки ( это может повысить конкурентоспособность полученного продукта); частая поставка рабочего ПО (каждый месяц или неделю или ещё чаще); тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта; проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием; рекомендуемый метод передачи информации личный разговор (лицом к лицу); работающее ПО лучший измеритель прогресса; спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок; постоянное внимание на улучшение технического мастерства и удобный дизайн; простота искусство НЕ делать лишней работы; лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды; постоянная адаптация к изменяющимся обстоятельствам

XP (EXTREME PROGRAMMING) 12 основных приёмов экстремального программирования: Короткий цикл обратной связи (Fine scale feedback) Разработка через тестирование (Test driven development) Игра в планирование (Planning game) Заказчик всегда рядом (Whole team, Onsite customer) Парное программирование (Pair programming) Непрерывный, а не пакетный процесс Непрерывная интеграция (Continuous Integration) Рефакторинг (Design Improvement, Refactor) Частые небольшие релизы (Small Releases) Понимание, разделяемое всеми Простота (Simple design) Метафора системы (System metaphor) Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership) Стандарт кодирования (Coding standard or Coding conventions) Социальная защищенность программиста (Programmer welfare): 40-часовая рабочая неделя (Sustainable pace, Forty hour week)

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

РЕЗУЛЬТАТЫ ОПРОСА ПО ПРИМЕНЯЕМЫМ МЕТОДОЛОГИЯМ РАЗРАБОТКИ (С САЙТА А.ОРЛОВА) Методология Scrum14%18% XP3%1% Agile-based (не Scrum и не XP)11%18% RUP-based5% CMM/CMMI2%1% Как получится21%18% Никак35%30% MSF1% Водопад/Waterfall-5% Другое8%3% Голосов122913