Инфраструктура эффективного управления проектами по разработке ПО. Понятие инфраструктуры по CMMI и по ГОСТ Р ИСО 9001-2008 (ГОСТ Р ИСО 9001-2011)

Жизненный цикл проекта, основные артифакты, роли участников

 

Методология SCRUM: этапы, роли, артифакты, коммуникации, метрики

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

Роли

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

· ScrumMaster

· ProductOwner

· Team

Скрам Мастер (ScrumMaster) – самая важная роль в методологии. Скрам Мастер отвечает за успех Scrum в проекте. По сути, Скрам Мастер является интерфейсом между менеджментом и командой. Как правило, эту роль в проекте играет менеджер проекта или тимлид. Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды. В Agile команда является самоорганизующейся и самоуправлямой. Основные обязанности Скрам Мастера:

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

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

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

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

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

Скрам Мастер ведет DailyScrumMeeting и отслеживает прогресс команды при помощи SprintBacklog, отмечая статус всех задач в спринте. ScrumMaster может также помогать ProductOwner создавать Backlog для команды.

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

· Отвечает за формирование productvision

· УправляетROI

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

· Координирует и приоритизируетProductbacklog

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

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

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

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

Команда (Team).В методологии Scrum команда является самоорганизующейся и самоуправляемой. Команда берет на себя обязательства по выполнению объема работ на спринт перед ProductOwner. Работа команды оценивается как работа единой группы. В Scrum вклад отдельных членов проектной команды не оценивается, так как это разваливает самоорганизацию команды. Обязанности команды таковы:

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

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

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

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

· Отвечает за результат перед ProductOwner

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

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

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

Артефакты

ProductBacklog – это приоритезированный список имеющихся на данный момент бизнес требований и технических требований к системе. Product Backlog включаетвсебя use cases, defects, enhancements, technologies, stories, features, issues, ит.д..Productbacklog также включает задачи, важные для команды, например «провести тренинг», «добить всем памяти»

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

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

Пример SprintBacklog

Сумма оценок оставшейся работы может быть построена как график зависимости от времени. Такой график называется SprintBurndownchart. Он демонстрирует прогресс команды по ходу спринта.

В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц (30 дней). Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику (по крайней мере, система должна быть готова к показу заказчику). Короткие спринты обеспечивают быстрый feedback проектной команде от заказчика. Заказчик получает возможность гибко управлять scope системы, оценивая результат спринта и предлагая улучшения к созданной функциональности.

Такие улучшения попадают в ProductBacklog, приоритезируются наравне с прочими требованиями и могут быть запланированы на следующий (или на один из следующих) спринтов. Каждый спринт представляет собой маленький «водопад». В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. Scope спринта должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что SprintBacklog не может быть изменен никем, кроме команды.

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

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

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

Планирование спринта, митинг первый. Участники: команда, ProductOnwer, SxrumMaster, пользователи, менеджемент Цель: Определить цель спринта (SprintGoal) и SprintBacklog –функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта. Артефакт: SprintBacklog.

Планирование спринта, митинг второй. Участники: Скрам Мастер, команда Цель: определить, как именно будет разрабатываться определенная функциональность для того, чтобы достичь цели спринта. Для каждого элемента SprintBacklog определяется список задач и оценивается их продолжительность. Артефакт: в SprintBacklog появляются задачи Если в ходе спринта выясняется, что команда не может успеть сделать запланированное на спринт, то Скрам Мастер, ProductOwner и команда встречаются и выясняют, как можно сократить scope работ и при этом достичь цели спринта.

DailyScrumMeeting

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

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

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

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

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

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

· Петя и Вася

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

12. Аналитик: сбор, анализ и управление требованиями

Системы версионного контроля. Локальные, централизованные и децентрализованные. Управление изменениями и версиями. Ветвления (branches), метки (labels, tags) и объединение (merge). Пример использования в курсовом проекте

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

Такие системы наиболее широко используются при разработке программного обеспечения для хранения исходных кодов разрабатываемой программы. Однако они могут с успехом применяться и в других областях, в которых ведётся работа с большим количеством непрерывно изменяющихся электронных документов. В частности, системы управления версиями применяются в САПР, обычно в составе систем управления данными об изделии (PDM). Управление версиями используется в инструментах конфигурационного управления (SoftwareConfigurationManagementTools).

Ветвления

Делать мелкие исправления в проекте можно путём непосредственной правки рабочей копии и последующей фиксации изменений прямо в главной ветви (в стволе) на сервере. Однако при выполнении объёмных работ такой порядок становится неудобным: отсутствие фиксации промежуточных изменений на сервере не позволяет работать над чем-либо в групповом режиме, кроме того, повышается риск потери изменений при локальных авариях и теряется возможность анализа и возврата к предыдущим вариантам кода в пределах данной работы. Поэтому для таких изменений обычной практикой является создание ветвей (branch), то есть «отпочковывание» от ствола в какой-то версии нового варианта проекта или его части, разработка в котором ведётся параллельно с изменениями в основной версии. Ветвь создаётся специальной командой. Рабочая копия ветви может быть создана заново обычным образом (командой извлечения рабочей копии, с указанием адреса или идентификатора ветви), либо путём переключения имеющейся рабочей копии на заданную ветвь.

Рис 1-3

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

Версии проекта, теги

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

Одни системы поддерживают версионность файлов. Это означает, что любой файл, появляющийся в проекте, получает собственный номер версии (обычно — номер 1, условной «нулевой» версией файла считается пустой файл с тем же именем). При каждой фиксации разработчиком изменений, затрагивающих файл, соответствующая часть фиксируемых изменений применяется к файлу и файл получает новый, обычно следующий по порядку, номер версии. Поскольку фиксации обычно затрагивают только часть файлов в репозитории, номера версий файлов, имеющиеся на один и тот же момент времени, со временем расходятся, и проект в целом (то есть весь набор файлов репозитория), фактически, никакого «номера версии» не имеет, поскольку состоит из множества файлов с различными номерами версий. Подобным образом работает, например, система управления версиями CVS.

Для других систем понятие «версия» относится не к отдельному файлу, а к репозиторию целиком. Вновь созданный пустой репозиторий имеет версию 1 или 0, любая фиксация изменений приводит к увеличению этого номера (то есть даже при изменении одного файла на один байт весь репозиторий считается изменённым и получает новый номер версии). Таким способом трактует номера версий, например, система Subversion. Номера версии отдельного файла здесь, фактически, не существует, условно можно считать таковым текущий номер версии репозитория (то есть считать, что при каждом изменении, внесённом в репозиторий, все его файлы меняют номер версии, даже те, которые не менялись). Иногда, говоря о «версии файла» в таких системах, имеют в виду ту версию репозитория, в которой файл был последний раз (до интересующего нас момента) изменён.

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

Тег (tag) — это символическая метка, которая может быть связана с определённой версией файла и/или каталога в репозитории. С помощью соответствующей команды всем или части файлов проекта, отвечающим определённым условиям (например, входящим в головную версию главной ветви проекта на определённый момент времени) может быть присвоена заданная метка. Таким образом можно идентифицировать версию проекта (версия «XX.XXX.XXX» — это набор версий файлов репозитория, имеющих тег «XX.XXX.XXX»), зафиксировав таким образом его состояние на некоторый желаемый момент. Как правило, система тегов достаточно гибкая и позволяет пометить одним тегом и не одновременные версии файлов и каталогов. Это позволяет собрать «версию проекта» любым произвольным образом. С точки зрения пользователя системы пометка тегами может выглядеть по-разному. В некоторых системах она изображается именно как пометка (тег можно создать, применить к определённым версиям файлов и каталогов, снять). В других системах (например, Subversion) тег представляет собой просто отдельный каталог на файловом дереве репозитория, куда из ствола и ветвей проекта с помощью команды копирования делаются копии нужных версий файлов. Так что визуально тег — это просто вынесенная в отдельный каталог копия определённых версий файлов репозитория. По соглашению в дерево каталогов, соответствующее тегу, запрещена фиксация изменений (то есть версия проекта, представляемая тегом, является неизменной).

Tag, label

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

Пример использования в курсовом проекте? (Открытый вопрос)

 

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

 

Более универсальный способ- Apacheant.

Что может быть лучше? - Maven.

Пример использования в курсовом проекте? (открыты вопрос)

 

Тестирование кода разработчиками: модульное тестирование (unittesting, TestDrivenDevelopment - TDD). Использование Mock-объектов. Покрытие кода тестами. Пример использования в курсовом проекте

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

· фпродемонстрировать разработчикам и заказчикам, что программа соответствует требованиям;

· выявить ситуации, в которых поведение программы является неправильным, нежелательным или не соответствующим спецификации^[1].

·

Разработка через тестирование (англ. test-drivendevelopment, TDD) — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам. Кент Бек, считающийся изобретателем этой техники, утверждал в 2003 году, что разработка через тестирование поощряет простой дизайн и внушает уверенность (англ. inspires confidence)^[1].

 

Модульное тестирование, или юнит-тестирование (англ. unittesting) — процесс в программировании, позволяющий проверить на корректность отдельные модулиисходного кода программы.

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

Mock-объект (от англ. mockobject, буквально: объект-пародия, объект-имитация) — в ООП —тип объектов, реализующих заданные аспекты моделируемого программного окружения.

Mock-объект представляет собой конкретную фиктивную реализацию интерфейса, предназначенную исключительно для тестирования.

В процедурном программировании аналогичная конструкция называется «dummy» (англ. — заглушка). Функция, выдающая константу, или случайную величину из допустимого диапазона значений.

Mock-объекты активно используются в разработке через тестирование.

 

Пример использования в курсовом проекте?(открытый вопрос)

 

 

17. Непрерывная интеграция (Continuousintegration): примеры программых средств, преимущества и недостатки. Средства проверки кода (codecheckers). Пример использования в курсовом проекте

Непрерывная интеграция (CI, англ. ContinuousIntegration) — это практика разработки программного обеспечения, которая заключается в слиянии рабочих копий в общую основную ветвь разработки несколько раз в день и выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий. Впервые названа и предложена ГрадиБучем в 1991 г.[1]

Непрерывная интеграция является одним из основных приёмов экстремального программирования.

Требования к проекту

· Исходный код и всё, что необходимо для сборки и тестирования проекта, хранится в репозитории системы управления версиями;

· Операции копирования из репозитория, сборки и тестирования всего проекта автоматизированы и легко вызываются из внешней программы.

Организация

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

· получение исходного кода из репозитория;

· сборка проекта;

· выполнение тестов;

· развёртывание готового проекта;

· отправка отчетов.

Локальная сборка может осуществляться:

· по внешнему запросу,

· по расписанию,

· по факту обновления репозитория и по другим критериям.

В случае сборки по расписанию (англ. dailybuild — рус. ежедневная сборка), они, как правило, проводятся каждой ночью в автоматическом режиме — ночные сборки (чтобы к началу рабочего дня были готовы результаты тестирования). Для различия дополнительно вводится система нумерации сборок — обычно, каждая сборка нумеруется натуральным числом, которое увеличивается с каждой новой сборкой. Исходные тексты и другие исходные данные при взятии их из репозитория (хранилища) системы контроля версий помечаются номером сборки. Благодаря этому, точно такая же сборка может быть точно воспроизведена в будущем — достаточно взять исходные данные по нужной метке и запустить процесс снова. Это даёт возможность повторно выпускать даже очень старые версии программы с небольшими исправлениями.

Преимущества

· проблемы интеграции выявляются и исправляются быстро, что оказывается дешевле;

· немедленный прогон модульных тестов для свежих изменений;

· постоянное наличие текущей стабильной версии вместе с продуктами сборок — для тестирования, демонстрации, и т. п.

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

Недостатки

· затраты на поддержку работы непрерывной интеграции;

· потенциальная необходимость в выделенном сервере под нужды непрерывной интеграции;

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

· в случае использования системы управления версиями исходного кода с поддержкой ветвления, эта проблема может решаться созданием отдельной «ветки» (англ. branch) проекта для внесения крупных изменений (код, разработка которого до работоспособного варианта займет несколько дней, но желательно более частое резервное копирование в репозиторий). По окончании разработки и индивидуального тестирования такой ветки, она может быть объединена (англ. merge) с основным кодом или «стволом» (англ. trunk) проекта.

Виды и уровни тестирования. Процесс тестирования. Жизненный цикл дефекта. Пример использования в курсовом проекте

Управление качеством, метрики, управление проектом на основе KPI. Пример использования в курсовом проекте

Проект - это всегда:

· Структурированный, состав работ, которые:

· могут выполняться параллельно или

· должны исполняться строго последовательно

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

Масштаб проекта

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

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

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

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

· Время (сроки и фактическая длительность)

· Деньги (израсходованный бюджет)

· Качество реализованных работ

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

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

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

Степень неопределенности

Неопределенности хоть отбавляй в проектах НИОКР (научно-исследовательские и опытно-конструкторские работы). К категории этих проектов можно отнести, в том числе:

· проекты, связанные с модернизацией производства

· комплексные проекты организационного развития, которые также страдают отсутствием полной определенности,

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

· и список, уверена, Вы сможете продолжить.

Как это выглядит:

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

· есть общее понимание, что нужно делать, чтобы получить заданный результат

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

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

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

· и есть рекомендованный (совсем не повезло - утвержденный) бюджет создания проектного чуда

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

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

И теперь мы имеем краткое описание полной красоты:

· неопределенность процесса реализации, умноженная на

· желание верить в получение нужного результата, и все это возведено в

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

Требования к интеграции и консолидации.

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

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

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

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

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

Требование 1. К системе мониторинга реализации проектов - абсолютная интеграция с системой управления бизнесом в целом.

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

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

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

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

20. Управление рисками проекта. Источники рисков, идентификация и оценка рисков. Стратегии по управлению рисками. Пример использования в курсовом проекте

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

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

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

Выделяются негативные риски, позитивные риски и непредвиденные обстоятельства.

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

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

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

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

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

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

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

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

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

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

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

- соответствовать серьезности риска;

- быть экономически эффективными в решении проблемы;

- быть своевременными;

- быть реалистичными в контексте проекта;

- быть согласованными со всеми участниками.

 

Входные данные

Совокупность вариантов, в отношении которых необходим консенсус.

Процесс

Группу экспертов опрашивают с применением полу структ<