 |
Оглавление. Контрольные вопросы. 4. Методология управления проектами. 4. 1. Понятие методологии управления проектами, ее структура
|
|
|
|
ОГЛАВЛЕНИЕ
4. МЕТОДОЛОГИЯ УПРАВЛЕНИЯ ПРОЕКТАМИ.. 1
4. 1. Понятие методологии управления проектами, ее структура. 1
4. 2. Каскадный подход к управлению проектами. 2
4. 3. Agile как философия управления проектами. 4
4. 4. Профессиональные организации управления проектами. 6
4. 4. 1. International Project Management Association (IPMA) (INTERNET) 7
4. 4. 2. СОВНЕТ (Россия) http: //www. sovnet. ru. 17
4. 4. 3. Институт управления проектами (PMI) https: //www. pmi. org. 19
4. 4. 4. Московское отделение PMI (https: //pmi. ru/about/) 21
4. 4. 5. Международная организация по стандартизации — ИСО.. 22
4. 5. Стандарты проектного управления. 22
4. 5. 1. Виды стандартов проектного управления. 22
4. 5. 2. Международные стандарты.. 24
4. 5. 3. Национальные стандарты.. 24
КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Основные международные и национальные организации проектного управления: название, страна, охват деятельностью (PMI, IPMA, СОВНЕТ).
2. Цели, задачи и направления деятельности профессиональных организаций проектного управления, возможности для студентов.
3. Цель проекта Excellence Award, российские участники.
4. Модель IPMA Delta, предназначение, уровни зрелости, российские участники, зачем им это нужно.
5. Стандарт P2M, страна, организация-разработчик, что включает, область применения.
6. Стандарт PRINCE2, страна, организация-разработчик, что включает, область применения.
7. Стандарт PMBok, страна, организация-разработчик, что включает, область применения.
8. Стандарт НТК, страна, организация-разработчик, что включает, область применения.
9. Стандарт ICB IPMA: цель, группы компетенций в версии 4 (последняя).
10. Стандарт ОРМ3 (Organizational Project Management Maturity Model), страна, организация-разработчик, что включает, область применения.
11. Что такое зрелось организации с точки зрения стандарта OPM3 PMI.
|
|
|
12. Участие Сбербанка в различных проектных конкурсах и сертификациях, примеры.
13. Организация ISO, деятельность, какое отношение имеет к проектному управлению.
14. Основные разработчики стандартов управления проектами
15. Типы стандартов проектного управления, пирамида стандартов.
16. Стандарты ISO, примеры.
17. Примеры известных международных и национальных стандартов.
4. МЕТОДОЛОГИЯ УПРАВЛЕНИЯ ПРОЕКТАМИ
4. 1. Понятие методологии управления проектами, ее структура
Методология – учение о структуре, логической организации, методах и средствах деятельности.
Методология − система практик, методов, процедур и правил, используемых в определенной сфере деятельности [PMBOK].
Методология управления проектами − совокупность подходов, методов и моделей управления проектами, программами и портфелями проектов, отраженных в профессиональных стандартах управления проектами глобального, международного, национального, отраслевого и корпоративного уровня, а также в различных научных и практических источниках, организующих теорию и практику управления проектами с целью достижения заданного результата.
Основные элементы структуры методологии УП
1. Методологические подходы к УП:
· классические: каскадный
· гибкий Agile.
2. Методы УП:
• структуризации;
• сетевого планирования (CPM, PERT, CPM-COST и др. );
• метод освоенного объема и многие другие методы, применяемые в различных областях знаний управления проектами.
3. Модели управления проектами:
• модели зрелости организационного управления проектами;
• сетевые и другие модели.
4. Стандарты управления проектами, программами и портфелями проектов различного уровня (глобального, международного, национального, отраслевого), управления по областям знаний (рисками и др. ).
5. Частные (корпоративные и отраслевые) методологии управления проектами.
|
|
|
4. 2. Каскадный подход к управлению проектами
Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах.
Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации.
Каскадная (водопадная) модель сей час представляет, скорее, исторический интерес, т. к. в современных проектах практически не применима. Она предполагает однократное выполнение каждой из фаз проекта, которые, в свою очередь, строго следуют друг за другом (рис. ). Очень упрощё нно можно сказать, что, в рамках этой модели, в любой момент времени команде «видна» лишь предыдущая и следующая фаза. В реальной же разработке ПО приходится «видеть весь проект целиком» и возвращаться к предыдущим фазам, чтобы исправить недоработки или что-то уточнить.
Рис. 4. 1. Каскадная (водопадная) модель
Особенности каскадной модели:
− высокий уровень формализации процессов;
− большое количество документации;
− жесткая последовательность этапов жизненного цикла без возможности возврата на предыдущий этап.
В каскадной модели нужно производить документацию в соответствии со стандартами, которые приняты по договоренности с заказчиком внутри компании как руководство к действию, как шаблоны для реализации документации, которая тоже является важной частью продукта.
Продукт – это не только код, но и огромное количество документации, необходимое, чтобы обеспечить его грамотное и стабильное сопровождение. Документация тем более полезна для чтения чужого кода, поскольку персонал сопровождения как раз и работает с чужим кодом, ища в нем ошибки.
Следует отметить, что документация критически важна для каскадной модели ещё и потому что, проверяя ее на адекватность и сопоставляя с ТЗ или другим вариантом требований к продукту, которые согласованы с заказчиком и утверждены как юридический документ, разработчики отчитываются по продукту и закрывают каждую стадию ЖЦ.
|
|
|
Минусы:
− Waterfall-проект должен постоянно иметь актуальную документацию, обязательная актуализация проектной документации, избыточная документация.
− Весь проект делается за один раз, нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена.
− У заказчика нет возможности ознакомиться с системой заранее и даже с «Пилотом» системы, нет возможности привыкать к продукту постепенно.
− Все требования должны быть известны в начале жизненного цикла проекта.
− Возникает необходимость в жёстком управлении и регулярном контроле, иначе проект быстро выбьется из графиков.
− Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта.
Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и требует дополнительных соглашений к контракту.
Плюсы:
− Высокая прозрачность разработки и фаз проекта.
− Чёткая последовательность.
− Стабильность требований.
− Строгий контроль менеджмента проекта.
− Облегчает работу по составлению плана проекта и сбора команды проекта.
− Хорошо определяет процедуру по контролю качества.
Большую систему сложно реализовать за один проход, хотя при правильной постановке задачи и хорошем подходе к документированию и проектированию это оказывается возможным, например, в проектах, которые реализуются по каскадной модели большей частью для госструктур, таких как министерства обороны (и в США, и в России).
|
|
|
