План управления проектом

Привет всем.

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

Введение 2

Краткое описание проекта 2

Контекст, цели и задачи проекта 2

Список артефактов, которые будут получены в процессе работы над проектом 2

Организационная структура проекта 3

Участники проекта и их ответственность 3

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

Стартовые активности 3

Оценка 3

Выбор персонала 3

Ресурсы 4

Обучение персонала 4

Планирование работ 4

Предварительное расписание 4

Распределение персонала и ресурсов 4

Планируемый бюджет 4

Контроль проекта 4

Управление требованиями 4

Управление расписанием и бюджетом 5

Управление качеством 5

Управление коммуникациями 5

Управление метриками 7

Управление рисками 7

Закрытие проекта 8

Процесс разработки 8

Жизненный цикл проекта 8

Технические средства разработки 8

Инфраструктура 8

Процесс приемки продукта 9

Служебные процессы 9

Управление конфигурациями 9

План тестирования 9

Документирование 9

Процессы обеспечения качества 10

Процесс аудита кода проекта 10

Процесс работы с проблемами 10

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

Процесс улучшения процессов 11

Версии документа 12



Введение

ООО «Заказчик», именуемое в дальнейшем «Заказчик», в лице директора Иванова Ивана Ивановича, действующего на основании Устава, с одной стороны, и ООО «Софтария» в лице директора, Кузьмина Романа Михайловича действующего на основании Устава, именуемое в дальнейшем « Исполнитель», с другой стороны, - в дальнейшем по отдельности или вместе именуемые «Сторона», «Стороны», -согласовали следующий план работы над проектом «Мегапроект».

Данный документ описывает план управления проектом «Мегапроект». Оперативное управление проектом осуществляется менеджерами Исполнителя.

Краткое описание проекта

Контекст, цели и задачи проекта

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

Список артефактов, которые будут получены в процессе работы над проектом

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

• Исходные коды программного обеспечения «Мегапроект» (Должны находиться в системе контроля версий SVN, установленной на территории Заказчика

• Дистрибутив программного обеспечения

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

• Инструкция по установке дистрибутива

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

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

• Техническое задание на разработку системы (SRS)
• Критерии приемки проекта
• Календарный план разработки
• Бюджет проекта
• Документ, описывающий архитектуру проекта (SAD)
• База данных учета изменений (это не документ, а база данных системы ISSUE Tracking JIRA)
• И данный документ — план управления проектом

Организационная структура проекта

Участники проекта и их ответственность

Со стороны Заказчика в проекте участвуют исполнители следующих ролей:

• Представитель заказчика — представитель Заказчика, ответственный за формулирование требований, принятие стратегических решений, одобрение или не одобрение изменений а также предоставление информации, необходимой разработчикам проекта. Обычно Представитель Заказчика является представителем группы лиц, осуществляющих стратегическое управление проектом, однако существование и состав этой группы лиц является внутренним делом компании Заказчика. При данном масштабе проекта предполагается один Представитель Заказчика.
• Главный заказчик — лицо, ответственное за разрешение проблем общего характера, в случае разногласий между менеджером проекта и представителем Заказчика.
• Администратор инфраструктуры — ответственен за предоставление доступа к системам, находящимся на стороне Заказчика (SVN, Jira итп) а также за обеспечение их бесперебойной работы.
• Приёмщики — лица, ответственные за проверку выполнения критериев приемки.

Со стороны Исполнителя в проекте участвуют

• Менеджер проекта — выстраивание процессов управления проектом, решение важных вопросов, контроль процесса, внесение корректив.

• Лидер команды — управление оперативной деятельностью проекта согласно заданным процессам.

• Аналитик — уточнение требований к проекту

• Разработчики проекта — разработка архитектуры, написание кода, тестирование результатов друг друга

• Эксперт - аудитор — выполнение независимого аудита кода

• Тестировщики — выполнение независимого тестирования

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

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

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

Оценка

Согласована с Заказчиком и определена в ТЗ

Выбор персонала

В выполнении данного проекта со стороны Исполнителя планируется участие следующих специалистов.

• Пелевин Дмитрий Олегович — Лидер команды, Старший разработчик

• Рудер Иван Давыдович — Аналитик, Разработчик

• Кузьмин Роман Михайлович — Менеджер проекта

• Чуркин Иван Валерьевич — Эксперт-аудитор

Тестировщики на этой стадии проекта не определены. Будут выбраны в зависимости от наличия свободного времени.

Ресурсы

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

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

Заказчик предоставляет доступ к системе Issue Tracking-a JIRA.

Заказчик предоставляет доступ к системе класса Team Collabortaion (возможно Confluence, коль скоро используем JIRA).

Исполнитель также предоставляет сервер для сборки версий системы и систему Continuum, в качестве системы непрерывной интеграции(CI)

Обучение персонала

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

Планирование работ

Предварительное расписание

Первый релиз проект должен выйти 20 августа 2010 года

Распределение персонала и ресурсов

См. выше.

Планируемый бюджет

Бюджет проекта составляет 3 миллиона долларов.

Контроль проекта

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

Изменение требований инициируется Представителем Заказчика в виде создания нового Issue в JIRA и назначения Аналитика ответственным за него.

Аналитик ответственен за выполнение оценки влияния каждого изменения на проект. Изменение может

• Увеличить бюджет проекта

• Увеличить календарный срок проекта

• Внести в проект новые риски

В обязанности аналитика входит написание комментария к Issue с указанием влияния изменения на проект и внесения одной из своих рекомендаций

• Внести изменение в текущую итерацию проекта

• Внести изменение в следующую итерацию проекта

• Не вносить изменение вообще

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

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

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

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

Управление расписанием и бюджетом

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

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

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

Управлять качеством — значит добиваться таких качественных показателей продукта, при которых он наиболее точно соответствует Business Case. (В отличие от процесса обеспечения качества, описанного в разделе «Служебные процессы», управление качеством не является синонимом повышения качества. Иногда, в процессе управления качеством, может быть принято решение, наоборот, понизить качество той или иной составляющей проекта, с целью сокращения времени выхода на рынок или уменьшения стоимости проекта)

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

Управление коммуникациями

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

• Система Issue Tracking — JIRA

• Система Team Collaboartion (Confluence или любая WIKI-based система)

• Электронная почта

• Телефон

JIRA используется для

• Управления требованиями (issue report) — см.управление требованиями.

• Создания и отслеживания состояния отчета об ошибке (bug-rpeort)

• Постановке задач разработчикам

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

Электронная почта используется как средство привлечь внимание участника проекта к дискуссии или Issue в системе Issue tracking либо когда необходимо решить административный или технический вопрос (например, у кого-то просрочен пароль в JIRA). Другое использование электронной почты — предоставление представителю заказчика еженедельных отчетов о состоянии дел в проекте. Вопросы по проекту, ответы на которые важны для дальнейшей разработки, никогда не задаются посредством электронной почты.

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

В таблице перечислены наиболее распространенные типы информации и способы их передачи.

Тип информации	Средство коммуникации	Источник информации	Адресат информации
Новое требование об изменении	JIRA	Представитель Заказчика	Аналитик
Отчет об ошибке	JIRA	Любой участник	Лидер команды
Подтвержденное требование об изменении	JIRA	Аналитик	Лидер команды
	Email		Менеджер проекта
Задача на исполнение	JIRA	Лидер команды	Разработчик, Тестировщик, Аудитор, Аналитик
Отчет об исполненной задаче	JIRA	Разработчик, Тестировщик, Аудитор, Аналитик	Лидер команды
Обсуждение вопросов, касающихся проекта	Confluence	все	все
Еженедельный отчет	Email	Лидер команды	Менеджер проекта, Представитель Заказчика
Запрос о доступе к инфраструктуре	Email	все	Администратор Инфраструктуры
Отчет о проблеме (эскалация)	Email	Участники проекта	Менеджер проекта, Лидер команды
Отчет о проблеме (эскалация)	Email	Менеджер проекта	Представитель Заказчика
Отчет о проблеме (эскалация)	Email	Закзачик	Менеджер проекта
Отчет о проблеме (эскалация)	Email, телефон	Представитель Заказчика, Менеджер проектов	Главный заказчик

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

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

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

Сравнение текущего плана и факта (с указанием, успеваем ли мы по графику)

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

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

На стадии планирования проекта определены следующие риски:

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

По данным рискам:

Риск	Вероятность	Важность	Вредный эффект	Стратегия предотвращения	Стратегия преодоления
Нарушения работы, вызванные неготовностью оборудования и сервисов	Низкая	Средняя	Календарные задержки и увеличение бюджета.	По возможности, подготовить резервный вариант для JIRA и Confluence	Временно использовать другие средства коммуникации. Временно прекратить делать commit-ы в SVN
Болезнь одного из ключевых членов проектной команды	Низкая	Средняя	Календарные задержки	Продумать возможные замены.	Заменить заболевшего.

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

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

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

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

Закрытие проекта

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

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

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

• Официальные представители обеих компаний должны подписать акт сдачи-приемки работ.

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

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

Процесс разработки

Жизненный цикл проекта

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

Работающие версии будут создаваться в результате относительно коротких итераций (в терминологии Scrum — спринтов). Длина одного спринта будет от недели до трех недель. Результат итерации — работающая версия с четко определенной функциональностью будет помечаться в SVN путём создания ветки (branch).

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

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

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

Технические средства разработки

Разработка ведется на Java 1.6 под ОС Windows XP с применением Eclipse IDE и Tortoise SVN в качестве Svn-клиента.

Для планирования итераций используется JIRA.

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

См Ресурсы

Процесс приемки продукта

Основным критерием приёмки продукта является его пригодность для решения бизнес-задач (соответствие Business Case).

Формальные критерии — соответствие функциональным и нефункциональным требованиям.

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

Служебные процессы

Управление конфигурациями

Процесс сборки дистрибутива проекта будет осуществляться при помощи системы maven.

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

• рабочая машина с выходом в интернет

• java 1.6

• maven

• СУБД Mysql

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

План тестирования

В процессе разработки, разработчики постоянно тестируют результаты друг друга, а также просматривают код друг друга (непосредственно после выполнения update из SVN).

Тестировщики тестируют только версии — результаты итераций. Результаты тестируются согласно плану итерации. Отдельный документ — тест план не создаётся.

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

Документирование

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

Из них создаются и согласуются единожды на стадии планирования проекта:

• Техническое задание на разработку системы (SRS) — (Дальнейшие изменения фиксируются лишь в JIRA.)

Могут пересматриваться в исключительных случаях

• Документ, описывающий архитектуру проекта (SAD)

• Данный документ (план управления проектом)

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

• Критерии приемки проекта

• Календарный план разработки

• Бюджет проекта

Изменяются ежедневно:

• База данных учета изменений (это не документ, а база данных системы ISSUE Tracking JIRA)

Создаются еженедельно:

• Отчеты о состоянии проекта.

Отчеты включают в себя —

• Список задач, над которыми работала команда

• Список законченных задач

• Потраченный за неделю бюджет

• Сравнение текущего и первоначального планов (календарного и бюджетного)

• Сравнение текущего плана и факта (успеваем ли вовремя)

• Список изменений, включенных в план за неделю и их влияние на проект

• Список произошедших за неделю рисков и их влияние на проект

• Список найденных за неделю потенциальных рисков и их влияние на проект

• Любую информацию, которую менеджер проекта сочтет нужным предоставить Заказчику в интересах успешности проекта.

Процессы обеспечения качества

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

• Правило не включения изменения в текущую итерацию. Направлено на исключение «несходимости» процесса.

• Согласование с Заказчиком всех решений, могущих повлиять на качество

• Периодический аудит бизнес целей проекта менеджером

• Периодический аудит кода экспертами

• Использование системы непрерывной интеграции

• Парное тестирование и независимое тестирование

• Жесткий процесс отбора персонала для участия в проекте

Процесс аудита кода проекта

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

Важно отметить, что в качестве критериев качества кода предполагается использовать критерии, выработанные нашей компанией совместно с немецким партнером (Brox IT Solutions) и используемые при разработке ПО для европейских корпораций (Siemens, Volkswagen, Дойче Телеком, Credit Suisse). Данные критерии доступны на английском языке в виде WIKI. По желанию Заказчика, к ним будет предоставлен доступ.

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

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

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

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

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

В данном проекте отсутствует

Процесс улучшения процессов

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



Версии документа

Дата	Версия	Описание	Автор
17.07.2008	1.0	Первая версия	Кузьмин Роман Михайлович
15.08.2008	1.1	Уточненная версия	Кузьмин Роман Михайлович
15.08.2008	1.2	Правки для большей юридической точности	Кузьмин Роман Михайлович

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

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

Привет, Все !

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

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

Что такое 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

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

Что такое 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.

Литература

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

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

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

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

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

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

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

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

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