суббота, 5 июля 2008 г.

Технологии управления проектами

Привет, Все !

Недавно начали в своей компании серию семинаров, или точнее разговоров о различных методологиях управления проектами. Что-то вроде вводных курсов, стартовых точек, для тех, кто хочет понять какие конкретно 400-страничные документы ему действительно стоит изучать. Решил опубликовать конспекты для тех, кому интересно. А может кто-нибудь еще и прокомментирует, тогда будет совсем здорово.

На сегодня есть конспекты - про PMBOK, PRINCE2, CMMI, 6 сигм, MSF и Scrum (они уже опубликован ы ниже) Читать полностью...

пятница, 4 июля 2008 г.

Что такое Scrum

Очередной конспект семинара о методологии управления проектами. На этот раз рассматриваем Scrum - один из, так называемых, гибких (agile) методов.

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

Конспект семинара предоставлен моим коллегой Антоном Сальником

Оглавление

Введение

Концепция Scrum

Роли

Product Owner

Scrum Master (Скрам Мастер)

Scrum Team

Практики

Sprint

Daily Scrum Meeting

Sprint Review Meeting

Sprint Abnormal Termination

Артефакты

Product Backlog

Sprint Backlog

Burndown Chart

Выводы



Введение

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

Термин Scrum был впервые озвучен в работе Хиротаки Такеучи и Икуджиро Нонака, где авторы отметили успешность проектов, использующих небольшие команды без жесткой специализации. Такие команды чем-то напоминают конструкцию схватки (scrum) в регби, которая назначается при нарушении правил или остановке игры. Джеф Сазерленд использовал эту работу при создании методологии для корпорации Easel в 1993 году, которую по аналогии и назвал Scrum, а Кен Швабер формализовал процесс для использования в индустрии разработки программного обеспечения, представив в 1995 году работу на конференции Object-Oriented Programming Systems, Languages & Applications.

Основа Scrum — итеративная разработка. Scrum определяет:

  • правила, по которым должен планироваться и управляться список требований к продукту;

  • правила планирования итераций;

  • основные правила взаимодействия участников команды;

  • правила анализа и корректировки процесса разработки.

Каждую итерацию можно описать так: планируем — фиксируем — реализуем — анализируем. За счет фиксирования требований на время одной итерации и изменения длины итерации можно управлять балансом между гибкостью и планируемостью разработки.

Концепция Scrum

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

Роли

В методологии Scrum всего три роли.

  • Product Owner

  • Scrum Master

  • Team

Product Owner

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

Обязанности владельца продукта таковы:

  • Отвечает за формирование product vision

  • Управляет ожиданиями заказчиков и всех заинтересованных лиц

  • Координирует и приоритизирует Product backlog

  • Предоставляет понятные и тестируемые требования команде

  • Взаимодействует с командой и заказчиком

  • Отвечает за приемку кода в конце каждой итерации

Scrum Master (Скрам Мастер)

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

Основные обязанности Scrum Master-а таковы:

  • Создает атмосферу доверия,

  • Участвует в митингах в качестве фасилитатора

  • Устраняет препятствия

  • Делает проблемы и открытые вопросы видимыми

  • Отвечает за соблюдение практик и процесса в команде

Scrum Team

Scrum-команда (Scrum Team) — группа, состоящая из пяти–девяти самостоятельных, инициативных программистов. Первая задача этой команды — поставить реально достижимую, прогнозируемую, интересную и значимую цель для итерации. Вторая задача — сделать все для того, чтобы эта цель была достигнута в отведенные сроки и с заявленным качеством. Цель итерации считается достигнутой только в том случае, если все поставленные задачи реализованы, весь код написан по определенным проектом «стандартам кодирования» (coding guidelines), программа протестирована полностью, а все найденные дефекты устранены. Программисты этой команды должны уметь оценивать и планировать свою работу, работать в команде, постоянно анализировать и улучшать качество взаимодействия и работы.

Обязанности команды таковы:

  • Отвечает за оценку элементов баклога

  • Принимает решение по дизайну и имплементации

  • Разрабатывает софт и предоставляет его заказчику

  • Отслеживает собственный прогресс (вместе со Скрам Мастером).

  • Отвечает за результат перед Product Owner

Практики

Sprint

В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц (30 дней).

Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику (по крайней мере, система должна быть готова к показу заказчику).

Подготовка к первой итерации, называемой спринт (Sprint), начинается после того, как владелец продукта разработал план проекта, определил требования и отсортировал их в количестве, достаточном для наполнения одной итерации. Такой список требований называется журналом продукта (Product Backlog). При планировании итерации происходит детальная разработка сессий планирования спринта (Sprint Planning Meeting), который начинается с того, что владелец продукта, Scrum-команда и Scrum-мастер проверяют план развития продукта, план релизов и список требований. Scrum-команда проверяет оценки требований, убеждается, что они достаточно точны, чтобы начать работать, решает, какой объем работы она может успешно выполнить за спринт, основываясь на размере команды, доступном времени и производительности. Важно, чтобы Scrum-команда выбирала первые по приоритету требования из журнала продукта. После того как Scrum-команда обязуется реализовать выбранные требования, Scrum-мастер начинает планирование спринта. Scrum-команда разбивает выбранные требования на задачи, необходимые для его реализации. Эта активность в идеале не должна занимать больше четырех часов, и ее результатом служит список требований, разбитый на задачи, — журнал спринта (Sprint Backlog). Необходимо, чтобы все участники команды приняли на себя обязательство по реализации выбранной цели.

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

Scope спринта должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что Sprint Backlog не может быть изменен никем, кроме команды.

Daily Scrum Meeting

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

Скрам митинг проводит Скрам Мастер. Он по кругу задает вопросы каждому члену команды

  • Что сделано вчера?

  • Что будет сделано сегодня?

  • С какими проблемами столкнулся?

Скрам Мастер собирает все открытые для обсуждения вопросы в виде Action Items, например в формате что/кто/когда, например

  • Обсудить проблему с отрисовкой контрола

  • Петя и Вася

  • Сразу после скрама

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

Sprint Review Meeting

В конце каждого спринта проводится демонстрационный митинг (Sprint Review Meeting) продолжительностью не более четырех часов. Сначала Scrum-команда демонстрирует владельцу продукта сделанную в течение спринта работу, а тот в свою очередь ведет эту часть митинга и может пригласить к участию всех заинтересованных заказчиков. Владелец продукта определяет, какие требования из журнала спринта были выполнены, и обсуждает с командой и заказчиками, как лучше расставить приоритеты в журнале продукта для следующей итерации. Во второй части митинга производится анализ прошедшего спринта, который ведет Scrum-мастер. Scrum-команда ищет использованные в последнем спринте положительные и отрицательные способы совместной работы, анализирует их, делает выводы и принимает важные для дальнейшей работы решения.

Затем цикл замыкается, и начинается планирование следующего спринта

Sprint Abnormal Termination

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

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

Артефакты

Product Backlog

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

Sprint Backlog

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

Burndown Chart

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

Выводы

Плюсы:

  • Простота и легковестность;

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

  • Вовлеченность каждого члена команды (выставление оценок, полностью осведомлен о состоянии проекта, учавствует в принятии решений;

  • Плотная работа с закачиком, принимает непосредственное участие;

Product Backlog

Sprint Backlog

Sprint Burndown chart

Читать полностью...

четверг, 3 июля 2008 г.

Что такое MSF

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

Этот посвящен MSF. Автором семинара является мой коллега Антон Сальник. Конспект опубликован с его согласия.

Оглавление

Введение

Структура MSF

Модель проектной группы

Ролевые кластеры

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

Модель процессов

Вехи и фазы

Итеративный подход

Фазы и вехи модели процессов MSF

Фаза выработки концепци (Envisioning)

Фаза планирования (Planning)

Фаза разработки (Development)

Фаза стабилизации (Stabilizing)

Фаза внедрения(Deploying)

О чем еще рассказывается в модели процессов

Дисциплина управления проектами

Дисциплина управления рисками

Дисциплина управления подготовкой

Новые версии MSF

Литература

Масштабирование проектных групп

Таблица совместимости ролей



Введение

Microsoft Solutions Framework, далее MSF, представляет собой подход компании Microsoft к управлению IT-проектами. В данном обзоре будет рассмотрена версия 3.0 данной методологии, опубликованная в июне 2002 года.

Структура MSF

Технология MSF состоит из двух моделей:

  • Модель проектной группы;

  • Модель процессов.

И трех дисциплин:

  • Дисциплина управления проектами;

  • Дисциплина управления рисками;

  • Дисциплина управления подготовкой.

Все они довольно подробно описаны в 5 whitepapers [1]. Рассмотрим все эти части более детально.

Модель проектной группы

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

К основным принципам и ключевым концепциям, определяющих проектную группу MSF относятся:

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

  • Единое видение проекта. А именно единое четкое понимание целей и задач проекта.

  • Распределение ответственности при фиксации отчетности.

  • Нацеленность на необходимый заказчику конечный результат;

  • Наличие у сотрудников необходимых полномочий;

  • Открытое общение;

  • Установка на отсутствие дефектов;

  • Стремление к совершенствованию;

  • Гибкость и готовность к переменам;

  • Заинтересованность и энтузиазм.

Ролевые кластеры

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

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

Управление продуктом

Цель: Удовлетворенные заказчики.

Область компетенций:

  • Маркетинг;

  • Бизнес-отдача (бизнес-приоритеты);

  • Представление интересов заказчика;

  • Планирование продукта.

Управление программой

Цель: Достижение результата в рамках проектных ограничений.

Область компетенций:

  • Управление проектом;

  • Выработка архитектуры решения;

  • Контроль производственного процесса;

  • Административные службы.

Разработка

Цель: Создание продукта в соответствии со спецификацией.

Область компетенций:

  • Технологическое консультирование;

  • Проектирование и осуществление реализации;

  • Разработка приложений;

  • Разработка инфраструктуры.

Тестирование

Цель: Одобрение выпуска продукта только лишь после того, как все дефекты выявлены и улажены.

Область компетенций:

  • Планирование тестов;

  • Разработка тестов;

  • Отчетность по тестам.

Удовлетворение потребителя

Цель: Повышение эффективности пользователя, увеличение потребительской ценности продукта.

Область компетенций:

  • Обеспечение технической поддержки;

  • Обучение;

  • Эргономика;

  • Графический дизайн;

  • Интернационализация;

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

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

Цель: Беспроблемное внедрение и сопровождение продукта.

Область компетенций:

  • Инфраструктура;

  • Сопровождение;

  • Бизнес-процессы;

  • Управление выпуском готового продукта.


Принципы MSF формируют такой подход к управлению проектами, при котором:

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

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

Как следует из вышесказанного, одна из характерных особенностей MSF — отсутствие должности менеджера проекта!

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

Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия.

  • В одном ролевом кластере может быть много людей;

  • Один человек может взять на себя несколько ролей;

  • Большие коллективы:

    • создаем группы направлений;

    • создаем функциональные группы;

  • Малые коллективы:

    • смотрим таблицу совместимости ролей (из таблицы можно сделать вывод, что минимальный размер команды – 3 человека: удовлетворение потребителя, управление продуктом, Тестирование; Управление программой и выпуском; Разработка);

Модель процессов

Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT-решений, а именно описывает последовательность действий, осуществляемых в ходе реализации проекта.

Модель процессов MSF объединяет в себе принципы каскадной и спиральной моделей.

Тремя особенностями модели процессов MSF являются:

  • Подход, основанный на фазах и вехах.

  • Итеративный подход.

Вехи и фазы

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

MSF вводит два типа вех: главные (major) и промежуточные (interim). Они имеют следующие особенности:

  • Главные вехи служат точками перехода от одной фазы к другой. Они также определяют изменения в текущих задачах ролевых кластеров.

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

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

Итеративный подход

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

Фазы и вехи модели процессов MSF

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

Для каждой фазы модели процессов MSF определяет:

  • Что (какие артефакты) является результатом этой фазы;

  • Над чем работает каждый из ролевых кластеров на этой фазе;

Фаза выработки концепци (Envisioning)

Основными задачами фазы выработки концепции являются создание ядра проектной группы и подготовка документа общего описания и рамок проекта (vision/scope document).

Веха: Концепция утверждена.

Результаты:

  • Общее описание и рамки проекта (vision/scope document).

  • Документ оценки рисков (risk assessment document).

  • Описание структуры проекта (project structure document).

Рекомендуемые промежуточные вехи:

  • Ядро проектной группы сформировано

  • Черновой вариант концепции проекта составлен

Фаза планирования (Planning)

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

Веха: Планы проекта утверждены.

Результаты:

  • Функциональная спецификация;

  • План управления рисками;

  • Сводный план и сводный календарный график проекта.

Рекомендуемые промежуточные вехи:

  • Верификация технологий;

  • Базовая версия функциональной спецификации создана;

  • Базовая версия сводного плана проекта создана;

  • Базовая версия сводного календарного графика проекта создана;

  • Среды разработки и тестирования развернуты.

Фаза разработки (Development)

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

Веха: Разработка завершена.

Результаты:

  • Исходный и исполнимый код приложений;

  • Скрипты установки и конфигурирования;

  • Окончательная функциональная спецификация;

  • Материалы поддержки решения;

  • Спецификации и сценарии тестов.

Рекомендуемые промежуточные вехи:

  • Концепция подтверждена;

  • Билд 1 завершен;

  • Билд 2 завершен;

  • Билд n завершен.

Фаза стабилизации (Stabilizing)

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

Веха: Готовность решения утверждена

Результаты:

  • Окончательный продукт (golden release);

  • Документация выпуска (release notes);

  • Материалы поддержки решения;

  • Результаты и инструментарий тестирования;

  • Исходный и исполнимый код приложений;

  • Проектная документация;

  • Анализ пройденной фазы (milestone review).

Рекомендуемые промежуточные вехи:

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

  • Точка достижения нуля (Точка достижения нуля (zero-bug bounce) – это момент, когда впервые все выявленные ошибки оказываются устраненными.)

  • Версии-кандидаты

  • Контрольное тестирование завершено

  • Тестирование приемлемости для потребителей завершено

  • Пилотное внедрение завершено

Фаза внедрения(Deploying)

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

Веха: Внедрение завершено.

Результаты:

  • Информационные системы эксплуатации и поддержки;

  • Процедуры и процессы;

  • Базы знаний, отчеты, журналы протоколов (logbooks);

  • Версии проектных документов, массивы данных (load sets) и программный код, разработанные во время проекта;

  • Отчет о завершении проекта (project close-out report);

  • Окончательные версии всех проектных документов;

  • Показатели удовлетворенности заказчика и потребителей;

  • Описание последующих шагов.

Рекомендуемые промежуточные вехи:

  • Ключевые компоненты развернуты;

  • Внедрение на местах завершено;

  • Внедренное решение стабилизировано.

О чем еще рассказывается в модели процессов

  • Вскольз упоминается про Управление конфигурацией (протоколирование и контроль состояний элементов проекта), Управление изменениями и Управление рисками. Говорится что нужно не забывать про них и дается несколько вариантов в поверхностным описанием как это можно делать;

  • Дается множество определений.

Дисциплина управления проектами

Носителем профессиональных управленческих навыков и организатором работы команды в MSF является ролевой кластер “Управление программой”. Однако типовые управленческие обязанности при этом распределяются среди лидеров всех ролевых кластеров проектной группы.

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

  • Ответственность за управление проектом распределена среди лидеров ролевых кластеров внутри команды.

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

Распределение ответственности по управлению проектом среди лидеров групп

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

Дисциплина управления рисками

Дисциплина управления рисками MSF заимствует хорошо известную модель процесса непрерывного управления рисками, разработанную Software Engineering Institute (SEI). При этом интерпретация этой модели дается в контексте опыта Microsoft. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием шестишагового процесса для успешного активного управления рисками. Этот процесс включает в себя:

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

  • Анализ рисков (risk analysis) – это фаза преобразования накопленных во время предыдущего шага оценок и данных в форму, позволяющую осуществить приоритезацию рисков. Приоритизация рисков (risk prioritization) позволяет проектной группе управлять наиболее важными из них, выделяя для этого необходимые ресурсы.

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

  • Мониторинг рисков (risk tracking) выполняется для наблюдения за конкретными рисками и прогрессом в осуществлении составленных планов.

  • Корректирование ситуации (risk control) представляет собой процесс исполнения принятых в отношении рисков планов и контроля за ходом их исполнения.

  • Извлечение уроков (risk learning) формализует процесс усвоения накопленного за время работы над проектом опыта в форме, доступной для использования как внутри проектной группы, так и на уровне всего предприятия.

Дисциплина управления подготовкой

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

  • Определение

  1. Проектные сценарии (scenarios).

  2. Квалификационные требования (competencies).

  3. Профессиональные навыки (proficiencies).

  • Оценивание

    1. Измерение знаний, умений, способностей (measure knowledge, skills, abilities).

    2. Анализ несоответствий (analyze gaps).

    3. Создание учебных планов (create learning plans).

  • Корректировка

    1. Обучение (train).

    2. Мониторинг прогресса (track progress).

  • Осмысление

    1. Анализ результатов (review results).

    2. Управление знаниями (manage knowledge).

Новые версии MSF

Новая версия MSF 4.0 была представлена в 2005 году. В данной версии произошло разделение методологии на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement. MSF for Agile Software Development в определенной степени отражает тенденции последнего времени, связанные с появлением методологий, предлагающих максимально облегченный и гибкий подход к процессу разработки. MSF for CMMI Process Improvement - это строгий, документированный процесс, рассчитанный на большие команды и длительный процесс разработки, что предполагает больше верификации, больше планирования, процедуры утверждения, отслеживание потраченных ресурсов и т.д. Данная версия выглядит, как облегченный вариант 3.0 и ориентирована на продукты Microsoft, а именно Visual Studio 2005 Team System и MS Project.

Литература

  1. Модель процессов MSF, версия 3.1;

  2. Модель проектной группы MSF, версия 3.1;

  3. Дисциплина управления рисками MSF, версия 1.1;

  4. Дисциплина управления проектами MSF, версия 1.1;

  5. Дисциплина управления подготовкой MSF, версия 1.1.

Ресурс: http://www.microsoft.com/rus/msf

Масштабирование проектных групп

Таблица совместимости ролей

Читать полностью...

среда, 2 июля 2008 г.

Что такое CMMI

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

Хотя этот семинар не о методологии, он о CMMI, а эта модель является скорее набором критериев, чем методологией.

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

Я благодарю Алену Федосееву за разрешение опубликовать этот материал в моём блоге.

Оглавление

Что такое СММ

Что такое CMMI

Поэтапный подход

Непрерывный подход

Пример применения CMMI

Определения

Процессные области (Process Area)



Что такое СММ

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

То есть:

  1. проблемы с качеством результата

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

Результатом работы SEI (Института системного инжиниринга при Университете Карнеги-Меллона) стало появление модели CMM (Capability Maturity Model) для разработки программного обеспечения (версия 0.6 была опубликована в 1990 г., версия 1.0 – в 1991 г., версия 2 – в 1997 году).

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

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

Что такое CMMI

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

- модель зрелости процессов разработки программного обеспечения (Capability Maturity Model for Software – SW-CMM)
- модель зрелости процессов для системного реинжиниринга (Electronic Industries Alliance Interim Standard – EIA/IS 731)
- модель зрелости процессов интегрированной разработки продуктов (Integrated Product Development Capability Maturity Model – IPD-CMM)

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

Поэтапный подход


В CMM на соответствие уровню зрелости оценивались ВСЕ процессы организации. Если представлять это диаграммой, то это выглядит следующим образом:

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

Модель зрелости процессов выглядит следующим образом:


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

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

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

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

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

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

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

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

Непрерывный подход

CMMI предоставляет 2 подхода – 2 модели:

  1. поэтапная репрезентация, унаследованная от CMM

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

На диаграмме это выглядит следующим образом:




При внедрении CMMI на непрерывной основе порядок улучшения процессных областей не фиксирован. Качество процессов в каждой процессной области может быть оценено на один из шести (0-5) уровней устойчивости (capability level).


Уровень устойчивости

Название уровня

0

Незавершенный уровень

1

Выполненный уровень

2

Управляемый уровень

3

Определенный уровень

4

Количественно-управляемый уровень

5

Оптимизированный уровень



Разумеется, большинство крупных IT-компаний выбирают именно поэтапное представление. Получив уровень повыше, можно аргументированно объяснять клиенту почему эта компания предпочтительнее, чем компания-конкурент. Однако трудоемкость на проекте, который использует CMMI модель, как минимум увеличивается на 10%-20%.

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

Пример применения CMMI

Определения

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

В CMMI области процессов одинаковы для непрерывной и поэтапной репрезентации.

Практики (practices) – это действия, производимые для достижения поставленных целей в данной области процессов.

Практики являются основным конструктивным элементом на основе, которого построена модель CMMI.

Специфические цели (specific goals) – цели, конкретизирующие основную (общую) цель

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

Специфические практики (specific practices) – практики, выполнение которых способствует достижению специфических целей.

Общие практики (generic practices) – практики, выполнение которых способствует достижению общих целей.

Субпрактики (subpractices) – представляют собой детализированные описания, поясняющие специфические и общие практики.




Процессные области (Process Area)

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

Уровень

Описание

Процессные области

5 Оптимизирующий

Continuous Process Improvement

Organizational Innovation and Deployment

Causal Analysis and Resolution

4 Количественно управляемый (измеримый)

Quantitative Management

Organizational Process Performance

Quantitative Project Management

3 Определенный

Process Standardization

Requirements Development

Technical Solution

Product Integration

Verification

Validation

Organizational Process Focus

Organizational Process Definition

Organizational Training

Integrated Project Management for IPPD

Risk Management

Integrated Teaming

Integrated Supplier Management

Decision Analysis and Resolution

Organizational Environment for Integration

2 Управляемый

Basic Project Management

Requirements Management

Project Planning

Project Monitoring and Control

Supplier Agreement Management

Measurement and Analysis

Process and Product Quality Assurance

Configuration Management

1 Начальный



Вот типичный пример описания специальной цели для процессной области Requirements Management:

SG 1: Requirements are managed and inconsistencies with project plans and work products are identified.

А вот описание специальной практики:

SP 1.3: Manage Requirements Changes. Manage changes to the requirements as they evolve during the project.

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

GG2: The process is institutionalized as a managed process.

Что здесь подразумевается под управляемым процессом? Если вкратце, то это такой процесс, который планируется и выполняется согласно существующей стратегии компании; для выполнения данного процесса нанимаются люди с соответствующими навыками и у которых есть все необходимое для успешного выполнения данного процесса. Кроме того, этот процесс контролируется, проверяется и оценивается согласно своему описанию.

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

GP 2.1: Establish an Organizational Policy

Establish and maintain an organizational policy for planning and performing appropriate process.

GP 2.2: Plan the Process

Establish and maintain the plan for performing appropriate process.

GP 2.3: Provide Resources

Provide adequate resources for performing appropriate process, developing the work products, and providing the services of the process.

GP 2.4: Assign Responsibility

Assign responsibility and authority for performing the process, developing the work products, and providing the services of appropriate process.

GP 2.5: Train People

Train the people performing or supporting appropriate process as needed.

GP 2.6: Manage Configurations

Place designated work products of appropriate process under appropriate levels of configuration management.

GP 2.7: Identify and Involve Relevant Stakeholders

Identify and involve the relevant stakeholders of appropriate process as planned.

GP 2.8: Monitor and Control the Process

Monitor and control appropriate process against the plan for performing the process and take appropriate corrective action.

GP 2.9: Objectively Evaluate Adherence

Objectively evaluate adherence of appropriate process against its process description, standards, and procedures, and address non-compliance.

GP 2.10: Review Status with Higher Level Management

Review the activities, status, and results of appropriate process with higher level management and resolve issues.


Читать полностью...