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

Лекция 4 Методологии и стандарты управления проектами Основными разработчиками стандартов управления проектами являются Институт управления проектами США — PMI (Project Management Institute), Международная ассоциация управления проектами — IPMA (International Project Management Association), Японская ассоциация управления проектами — PMAJ (Project Management Association of Japan), Международная организация по стандартизации — ISO (International Standard Organization), Агентство по ИТ и телекоммуникациям Великобритании — ССТА (Central Computer and Telecommunication Agency). Существующие стандарты можно классифицировать следующим образом: • стандарты управления монопроектами (РМВОК (PMI), ISO 10006 (ISO), PRINCE2 (ССТА), Р2М (PMAJ)); • стандарты управления программами (Standard for Program Management (PMI), P2M (PMAJ)); • стандарт управления портфелем проектов (Standard for Portfolio Management – (SPfM) (PMI)); • стандарты описания компетенций менеджера проекта (PMCDF (PMI), ICB Version 3.0 (IPMA), НТК (Российская ассоциация управления проектами СОВНЕТ), GAPPS); • стандарты организационного управления проектами (ОРМЗ (PMI)). Пирамида стандартов управления проектами, программами и портфелями проектов Представление основных стандартов относительно шкалы «Водопад»-«Гибкость» Для понимания общего ландшафта управления проектами важно знать разные подходы к управлению проектами. Наиболее полно они описаны в следующих документах: ​ PMBoK — свод знаний по управлению проектами (англ. Project Management Body of Knowledge, PMBoK), используется в качестве основного методологического документа организацией Project Management Institute (PMI (США); Институт управления проектами), международной некоммерческой профессиональной организацией по управлению проектами, наиболее значимой и авторитетной международной организации в области управления проектами. Является стандартом de facto (хотя по своей сути это не стандарт, а фреймворк) по классическому управлению проектами. В последней версии стандарта добавлена рекомендация по использованию гибких подходов в управлении проектами. Рекомендации PMBoK применяются в ряде проектов в государственном секторе РФ. В 2021 году вышла 7-я версия документа. ​ PRINCE2 — метод управления проектами в рамках четко определенной структуры, популярный в госуправлении Великобритании и Австралии. PRINCE2 описывает процедуры для координации деятельности команды проекта при разработке, контроль над проектом, а также процедуры, которые используются при изменении проекта или при отклонениях от первоначального плана. Для каждого процесса определяются основные входы и выходы, конкретные цели и мероприятия, которые будут осуществлены, что обеспечивает автоматический контроль любых отклонений. За счет разделения процессов на управляемые этапы метод дает возможность эффективно управлять ресурсами. Данный стандарт также получил расширение PRINCE2Agile, предусматривающее использование гибких подходов. IPMA ICB4 — международный стандарт, развиваемый международной организацией IPMA, определяющий элементы компетентности, которыми должны обладать профессионалы в управления проектами, программами и портфелями проектов и программ. В IPMA ICB4 представлены основные достижения, знание которых необходимо для успешного управления современными проектами, программами и портфелями проектов и программ. В IPMA ICB4 каждый из 29 элементов компетентности относится к одной из трех сфер компетентности (Люди, People; Практика, Practice; Контекст, Context). (см.: https://clck.ru/Yvt3P) PMBOK 7 - отказ от процессов в пользу принципов Институт управления проектами (PMI) в 2021 году выпустил 7-ую редакцию Руководства к своду знаний по управлению проектами (PMBOK Guide). Новое издание предлагает взглянуть на управление проектом с другой точки зрения: проект — это система поставки ценности для заинтересованных сторон. Каждый проект уникален, поэтому описать такую систему в виде набора шагов (процессов) не получится. Более универсальным представляется определение общих принципов, которыми участники проекта должны руководствоваться при работе над проектом. Сам проект – совокупность связанных между собой тематических областей (доменов). Для соблюдения баланса между стабильностью и изменчивостью выделена переменная часть PMIstandard+ в отдельную платформу для размещения новых практик, кейсов и т.д. 7-е издание содержит две основные части — стандарт ANSI и руководство PMBOK Guide. 1Однако структура каждой части значительно изменилась. В стандарте ANSI в шестом издании стандарт описывал управленческий цикл как общую структуру для всех действий. Структура задавала логичную последовательность: 1. Инициация — по сути целеполагание; 2. Планирование — ответ на вопрос, как добраться до цели; 3. Исполнение — путь к цели; 4. Мониторинг и контроль — наблюдение за тем, как проходит путь к цели; 5. Закрытие — подведение итогов, насколько удалось достигнуть цель. В седьмом стандарте описывается система поставки ценности. Для описания системы нужно определить цель, элементы и взаимосвязи между элементами. Цель проектов по новому стандарту не в производстве результатов, а в поставке ценности. Новая цель означает, что проектная команда должна смотреть дальше во времени, думать о пользе создаваемых продуктов. При изменении цели проектов, меняется и система управления. Новая система управления содержит объекты управления: портфели, программы проектов и проекты. Предлагается 12 базовых принципов, которые направляют поведение участников проектной команды: 1. Будьте прилежным, уважительным и заботливым управляющим 2. Создавайте среду сотрудничества проектной команды 3. Вовлекайте заинтересованные стороны 4. Фокусируйтесь на ценности 5. Используйте системное мышление 6. Поощряйте лидерство на всех уровнях 7. Адаптируйте систему управления проектом к конкретной ситуации 8. Встраивайте качество в процесс и конечные продукты 9. Учитывайте сложность проекта на протяжении всего проекта 10. Учитывайте угрозы и возможности 11. Встраивайте адаптируемость и устойчивость в систему управления проектом 12. Управляйте изменениями в организации В PMBOK Guide шестого издания нужно было определить жизненный цикл проекта. На каждом этапе жизненного цикла выполнялись три слоя активности: слой управления, слой создания продукта и слой обеспечения. Слой управления – это проход управленческого цикла по десяти областям знаний проекта. В новой редакции компоненты системы управления – 8 доменов проекта. 1. Заинтересованные стороны. 2. Команда (теперь выделена отдельно). 3. Неопределенность. Была область «управление рисками». 4. Поставка результатов. Были две области знаний «Содержание» и «Качество». 5. Жизненный цикл. 6. Планирование. Раньше был управленческий цикл из 5 шагов, теперь остались только три самых наполненных действиями шага – планирование, выполнение и мониторинг. 7. Выполнение. 8. Измерение прогресса. Был шаг управленческого цикла «мониторинг и контроль», теперь отдельный домен. Платформа PMIstandards+ представляет собой хранилище полезных дополнений к основным стандартам. На данный момент здесь представлены 4 руководства (шестое издание PMBOK Guide с приложением по Agile, руководство по иерархическим структурам и руководство по бизнес-анализу), шаблоны, видео, аудио и текстовые материалы по различным отдельным темам. Основные изменения в стандартах ИСО В начале 2021 года были обновлены и расширены два основных стандарта ИСО, связанных с управлением проектами. На смену ИСО 21500:2012 пришли два стандарта, в которых можно найти еще более полные рекомендации по данной теме2: 1. ИСО 21500:2021 «Управление проектами и программами, портфельный менеджмент – Контекст и концепции» – основополагающий профильный стандарт, который является всеобъемлющим руководством по использованию серии стандартов ИСО 21500. Он определяет организационный контекст и основные концепции для управления проектами, программами и портфелями, предлагая общую информацию и помогая заинтересованным сторонам обрести понимание используемых инструментов. Документ применим к большинству организаций, включая государственные и частные, при этом размер и тип организации не имеет значения, к любому проекту, программе и портфелю независимо от их сложности, размера или продолжительности. Основные изменения по сравнению с предыдущей редакцией: представлен обзор среды для управления проектами, программами и портфелями, а также общие факторы, влияющие на среду; обеспечивает общий обзор взаимосвязей между стандартами по управлению проектами, программами и портфелями, подготовленными ИСО/ТК 258, в то время как руководство по управлению проектами теперь дано в стандарте ИСО 21502. 2. ИСО 21502:20203 «Управление проектами и программами, портфельный менеджмент – Руководящие указания в части управления проектами». Стандарт содержит целый ряд существенных изменений в описании подходов к управлению проектом, отражающих современную практику. В его разработке принимали участие представители разных стран, что позволило обобщить в документе лучшие современные международные практики проектного управления. От России в его подготовке принимали участие эксперты ТК205 «Проектный менеджмент», включая Алексея Полковникова, Председателя ТК205, Председателя Правления СОВНЕТ, управляющего партнера Группы компаний «Проектная ПРАКТИКА». Документ предлагает руководящие указания и описание базовых принципов управления проектами с акцентом на выгоды и результаты, включая надзор за проектами, не дает указаний по управлению программами или портфелями. Темы, относящиеся к общему менеджменту, рассматриваются только в контексте управления проектами. Представлены описания лучших практик, которые считаются хорошо работающими и приносящими хорошие результаты в контексте управления проектами. Документ применим к любой организации, включая государственные, частные и благотворительные, а также к любому типу проекта независимо от цели, подходов к реализации, используемой модели жизненного цикла, сложности, размера, стоимости или продолжительности. Основные изменения по сравнению с ISO 21500:2012 заключаются в следующем: • концепция управления проектом расширена и включает в себя надзор за проектами и руководство деятельностью спонсирующей организации; • добавлена информация о том, каким образом проекты могут повышать результативность и обеспечивать реализацию выгод; • добавлен учет организационного контекста проектов; • добавлены описания дополнительных ролей и обязанностей в проекте; • добавлены новые темы, такие как создание среды проекта, которая способствует успеху, жизненные циклы проекта, точки принятия решений, а также дополнительные методы: управление выгодами и контроль изменений; • добавлены пред- и постпроектные мероприятия; • произошла смена формата с процессного на практический и описательный. Методологии (Модели) управления проектами Методология (Модель) — это совокупность методов и принципов управления проектами4. Классификаций на сегодняшний день существует очень много, приведем одну из них, охватывающую достаточно большую совокупность применяемых не практике методологий: • Традиционные последовательные методологии5 • Каскадная методология управления проектами (Waterfall) • Метод критического пути (CPM) • Метод критической цепи (CCPM) • Группа Agile-методологий • Методология управления проектами Agile • Scrum • Канбан • Экстремальное программирование (XP) • Адаптивный проектный менеджмент (APF) • Методологии управления изменениями • Методология моделирования событий (ECM) • Экстремальное управление проектами (XPM) • Процессно-ориентированные методологии • Бережливое производство • Шесть сигм • Процессно-ориентированное управление проектами • Прочие методологии • PRINCE2 • PRiSM Популярных широко известных моделей управления проектами две: каскадная (водопадная) – Waterfall и гибкая – Agile. Методика — это уже готовый алгоритм применения методов, часто их называют фреймворки. К ним относятся Scrum, Kanban, Lean, Scramban, XP, Six Sigma и т.д. Каскадная модель — Waterfall Название появилось в 1970 году в статье «Managing the development of large software systems» Винстона Уолкера Ройса6, директора Lockheed Software Technology Center. Разработана как ответ на потребность управления все более усложняющимся процессом разработки программного обеспечения. Особенность этого подхода заключается в том, что все этапы идут друг за другом: на следующий этап проекта переходят только после того, как сделаны все работы на предыдущем. После завершения этапа вернуться к нему нельзя. Классический пример такого проекта – строительство дома. Когда в начале проекта составляется проектная документация, согласовывается бюджет проекта и срок реализации. Когда дом начинает строиться, он строится в соответствии с проектом, а если заказчик захочет достроить, например, ещё несколько балконов, то это сделать будет нельзя в рамках данного проекта, и весь процесс начиная с планирования проекта придется переделывать. Точно также при строительстве дома не получится переделать фундамент, если в нем нашли проблемы на стадии возведения стен и крыши. Подход сравнивают с каскадом и иногда называют водопадной моделью или waterfall-методологией. Так как вернуться на предыдущую фазу проекта невозможно, перед переходом на следующий этапа результат должен пройти проверку и приемку. Этот момент в проекте называют гейтом. Оригинальная модель состояла из пяти этапов. Часто она описывается как линейно-последовательная модель жизненного цикла. Это означает, что он следует простой структуре фаз, где результаты каждой фазы переходят на следующий уровень развития. Первый этап – ключевой. Чем четче заказчик опишет желаемый результат, тем лучше получится готовый продукт. Дело в том, что каскадная модель не такая гибкая, поэтому подходит для продуктов, которые понятны самому заказчику. Разработка происходит последовательно, но промежуточные результаты не демонстрируются клиенту. При этом выявлять и исправлять ошибки допустимо только на этапе тестирования. Основные этапы – это: 1. Сбор требований и создание документации. Команда собирает требования к будущему продукту. Потом пишет подробное техническое задание, планирует график работ и возможные риски. Переходит к следующему этапу, только когда все требования прописаны и есть план. А в плане — инструкции, что и когда делать. 2. Дизайн и проектирование системы. Команда создаёт прототип и готовит дизайн-макеты. Когда это готово, подключаются разработчики 3. Реализация. На этом этапе пишут код продукта согласно плану, макетам и требованиям. Четко по ТЗ, без изменений. 4. Тестирование и развертывание. Здесь проверяют продукт на соответствие техническому заданию, ищут и исправляют ошибки. 5. Эксплуатация и поддержка. Проект передают заказчику и следят заранее определённое время, чтобы всё работало. 7 Сведем вместе основные принципы водопадной модели разработки: • Документы и инструкции – это важно, всё должно быть зафиксировано. • Следующий этап работы не начинается, пока не закончится предыдущий. • Пропускать этапы нельзя. • Если требования к продукту изменились после согласования – переписывается Техническое задание. • Нельзя возвращаться на предыдущий этап, чтобы что-то изменить. • Нет итераций, есть один общий процесс создания продукта. • Выявлять и исправлять ошибки можно – только на этапе тестирования. • Клиент не участвует в создании продукта после постановки ТЗ. Водопадная модель подходит проектам, в которых: • разрабатываемый продукт технически сложный или не имеет аналогов; • исполнители имеют опыт подобных проектов и их процессы стандартизированы; • требования, технологии и инструменты заранее известны и не меняются; • влияние внешней среды минимально; • нельзя сдать продукт по частям; • главный критерий проекта – качество и соответствие требованиям; • заказчик не участвует в проекте, а только получает готовый продукт. Преимущества каскадной модели Недостатки каскадной модели Чтобы быстрее выявлять проблемы в проекте, используют гибридные каскадные модели, а для сокращения времени меняют последовательность работ на параллельный или поточный метод. Гибридные модели сложнее, чем классическая модель, поэтому в них выше риски не уложиться в бюджет или во время, определяемое для реализации. Выделяют каскадную модель с обратными связями, которые срабатывают, когда во время работ или в гейтах находят ошибки, что позволяет их исправлять, не дожидаясь проверки и итеративную каскадную модель, согласно которой на следующий этап передают не весь результат, а рабочую часть. Когда проект выдает часть работоспособного продукта, начинается новый (другой) проект, в котором делают другую часть.  В параллельном методе выполнения работ работы разных этапов делают одновременно, что значительно ускоряет выполнение проекта, но и увеличивает бюджет. Поточный метод выполнения работ соблюдает баланс между последовательным и параллельным методом. В нем команда передает часть работы на следующий этап и сразу начинает делать следующую часть. Например, построив фундамент для первого дома, команда начинает строить фундамент для второго, а первый дом передает команде, которая строит стены. Так проект идет быстрее, а затраты на команду не увеличиваются. Гибкая модель — Agile Концепция Agile не нова, поскольку гибкое управление проектами широко использовалось еще 60-х годов 20 века. Формально методология появилась лишь в 2001 году, когда 17 разработчиков, экспертов-практиков в сфере создания ПО организовали встречу в штате Юта (США), где сформулировали ценности и принципы Agile Manifesto (можно ознакомиться по ссылке: https://agilemanifesto.org/iso/ru/manifesto.html). Термин Agile в настоящий момент употребляют в двух основных значениях: система ценностей или философия, которой придерживаются многие разработчики и стартапы; собирательное название для гибких подходов и методик, которые, так или иначе, пересекаются с основными ценностями Agile.8 Agile полностью противоположен методологии Waterfall по подходу и идеологии. Само название с английского языка переводится как «Гибкий», а это значит, что в управлении используется быстрый и гибкий подход. Этот подход характеризуется итеративностью разработки. Когда сам проект реализуется небольшими интервалами, после которых можно показывать промежуточный результат заказчику и получить обратную связь. В Agile происходит постоянная коммуникация с клиентом, поэтому легко может изменяться направление движения проекта. Agile — это методология управления проектами, состоящая из коротких циклов инкрементальной разработки, называемых спринтами. На самом деле можно сказать, что Agile — это семейство гибких методологий управления проектами. Циклы (итерации, спринты) имеют одинаковую длительность на протяжении всего проекта и в среднем составляют две недели. В рамках отдельной итерации выполняется конкретная задача, главным свойством которой является то, что ее решение должно обновлять продукт до новой версии или увеличивать его эффективность. Именно по этому признаку такие задачи и отбираются. Гибкость данного похода обеспечивается благодаря тому, что отдельные процессы могут идти параллельно и независимо друг от друга. Цикличность доработок позволяет добиться куда лучшей проработки таких функций и возможностей, до которых при плановой работе руки бы не дошли никогда. В Agile существует: четыре ценности: 1. Люди важнее инструментов: 2. Качество продукции важнее документации; 3. Взаимодействие с заказчиком важнее контракта; 4. Готовность к изменениям важнее установленного плана. и 12 принципов, сформировали на основе ценностей: 1. Работающий продукт — это главный индикатор прогресса. 2. Важное условие — необходимость поддерживать один и тот же темп работы на протяжении всего периода разработки и вне зависимости от этапа. 3. Простота, то есть не надо делать ненужную работу. 4. Регулярные обновления: продукт должен быть конкурентоспособным. 5. Необходимость удовлетворения требований заказчика по проекту на любом этапе работы. 6. Тесное взаимодействие с заказчиком на протяжении всего периода разработки. 7. Постоянное удовлетворение его потребностей за счёт регулярного предоставления продукта (раз в 7 дней или раз в месяц по договорённости). 8. Обсуждение проекта в личном разговоре, чтобы убрать любые барьеры. 9. Самоконтроль членов команды. 10. Повышение их мотивации, для этого создаются оптимальные условия работы, обеспечивается поддержка. 11. Постоянное усовершенствование навыков и знаний членов команды. 12. Регулярный анализ работы команды и каждого её члена и поиск способов её оптимизации. Когда Agile только появился, его использовали, в основном, разработчики ПО, игр и интерфейсов. Среди них — Google, Netflix, Microsoft, Spotify, Ericsson, Dell, Adobe, Accenture, WordPress, Riot Games, CH Robinson, Magna International, Scrum Alliance, Intronis. Теперь же сфера применения расширилась: Agile используют, например, Saab для производства новых истребителей, General Electric и John Deere — ведущий американский производитель сельхозтехники9. Некоторые компании идут дальше и разрабатывают на основе идей и принципов Agile свои подходы, которые помогают им в их работе. Так, к примеру, поступили в «Spotify». Использовали Agile, чтобы организовать 30 команд, работавших в 3-х разных городах, и разработать услуги, увеличившие количество потребителей компании и качество сервиса10. Преимущества Agile-методологии Недостатки Agile-методологии оперативность выявления неправильных подходов и быстрое принятие решения, касающееся изменения ситуации краткосрочный подход, из-за которого могут возникнуть сложности с масштабированием продукта; Необходимость прислушиваться к заказчику, всё время с ним взаимодействовать, оперативно вносить изменения в технические задания отказ от регламентирующей документации, которая может быть важна при работе над продуктом; Затраты меньшего времени на подготовку документации скорость, на которую ориентируются разработчики (иногда, чтобы успеть в срок, они могут упускать важные нюансы). В 2020 году компания ScrumTrek провела исследование Agile среди российских организаций, где они выяснили, от чего зависит успех этой модели и какие эффекты следует ожидать от внедрения гибких подходов11. Главным эффектом участники исследования отметили ускорение поставки продуктов на рынок: • 56% – на этапе пилотирования Agile (в 2019 было 47%); • 62% – на этапе становления / масштабирования Agile (в 2019 было 60%); • 80% – на этапе зрелости Agile во всей организации (в 2019 было 75%). Кроме того, согласно отчёту «Agile в России 2020. Трансформируйте свою компанию, не наступая на чужие грабли» гибкие практики управления командами помогли компаниям в период массового перевода сотрудников на удаленную работу в связи с кризисом пандемии COVID-19. Однако есть 2 эффекта, которые в реальности не превосходят ожидания: влияние Agile на качество в России практически незаметно, а на затраты Agile зачастую влияет в сторону ухудшения. Распространение модель получила в IT и финансах, однако она начинает всё чаще применяться и в телекоммуникациях, промышленности и торговле. Например, ПО-разработчик First Line Software, гипермаркет электроники «М.Видео», служба доставки Dostаевский, онлайн-кинотеатр ivi, бренд одежды 12 Storeez. Общемировые12 данные по целям и достижениям Agile — примерно такие же, как и в России: • по достижению цели ускорения поставки в этом году Россия выровнялась с мировыми показателями: 60% в мире, 61% в России, причем в России – это превышение ожиданий (цель повышения скорости в мире ставят 71% респондентов, в России – 55%); • в списке реально достигнутых выгод первые 2 места в мире занимают те же показатели, что в России: управление меняющимися приоритетами (70% в мире, 78% в России) и прозрачность ведения проектов (65% в мире, 75% в России); • «качество» является значимой целью (пятой по популярности в мире), но эта цель – как и в России – реализуется редко относительно ожиданий. Переход от каскадной разработки к гибким методам работы над проектами может быть довольно болезненным13. Во-первых, предстоит упразднить иерархичность и при этом добиться того, чтобы все участники процессов смогли на равных разделить ответственность за результат. Во-вторых, переход к итеративной разработке заставит сосредоточиться на том, чтобы каждый из этапов гарантированно привносил в продукт что-то новое. Это непросто, инерция плановой разработки будет преследовать вас первые несколько месяцев. В третьих, если вы ведёте заказную разработку, будет непросто объяснить клиентам принципы работы, а если входите в состав крупной организации, та же проблема может возникнуть при обосновании перехода на Agile перед вышестоящими руководителями. Проиллюстрируем различия в ценностях и жизненном цикле продукта в Agile и Waterfall. Если взять классический подход и спросить: «Вы сделали этот проект успешно или нет? Как это понять?». Я должен его сделать вовремя, не превысив бюджет, и полностью сделать содержание. Если мы смотрим с позиции Agile, то наш проект тем успешнее, чем больше мы поставили ценностей заказчику. Статистика исследования Standish Group в 2019 г.14 показала, что эффективность Agile выше, чем у каскадных моделей управления. Agile-проекты имеют примерно в 2 раза больше шансов на успех, и на 1/3 меньше вероятность неудачи. В заключении ознакомимся с кейсом «Гибрид Agile и Waterfall в компании GanttPRO» 15 С.Пукита, Project manager в GanttPRO — компании, разрабатывающей онлайн-инструмент для управления проектами на основе диаграммы Ганта, делится опытом работы над продуктом с использованием гибридного подхода:«При разработке и развитии продукта наши команды должны опираться на долгосрочные цели, но при этом все стратегии по их достижению должны быть разбиты на задачи, а задачи упакованы в итерации. Потребности наших пользователей и потребности нашей команды в частности сформировались на стыке предсказуемости традиционных подходов и гибкости современных. Проще говоря, нам понадобилось взять и совместить лучшее из подходов Waterfall и Agile. Мы отбираем задачи из бэклога и генерируем новые гипотезы, которые, по нашему мнению, будут способствовать достижению поставленных перед нами целей. Далее следует приоритизация задач и провалидированных гипотез. Затем мы формируем спринты (в нашем случае — это релизы), и у нас складывается каскадная модель из этих спринтов. Мы можем менять или корректировать наши стратегии на ходу, что сказывается на наполнении спринтов и на сроках соответственно. Но при любых изменениях у нас всегда есть четкий план. Благодаря такому подходу у нас получилось создать единый источник хранения долгосрочных целей, а также стратегий по их достижению. Каждый видит, в каком направлении мы движемся. Команды маркетинга и разработки синхронизируют свои действия. Команды продаж и поддержки имеют доступ к планам и могут своевременно предоставлять информацию пользователям о планируемых сроках и релизах.» Литература: 1. Что нового в PMBOK 7-й редакции https://sergeysharpak.ru/news/pmbok-7/ 2. Управление проектами: основные изменения в стандартах ИСО https://clck.ru/YvtNg 3. А не бревно ли ты? Сравниваем классический и гибкий подходы к управлению проектами https://clck.ru/YvtSE 4. Методологии управления проектами https://clck.ru/YvtU4 5. Каскадная модель жизненного цикла: преимущества и недостатки https://clck.ru/YvtbX 6. Классическая (каскадная) модель управление проектами “водопад” (waterfall) https://clck.ru/YvtdT 7. Как устроена каскадная модель управления проектами https://clck.ru/YvtkQ 8. Что такое Agile и подойдет ли он вашей компании https://clck.ru/YvtrY 9. Agile-методология управления проектами https ://clck.ru/Yvtsu 10. Agile в России 2020 https://scrumtrek.ru/userfiles/reports/AgileSurvey20.pdf 11. Что такое Agile: методология, команда, оценка эффективности https://skillbox.ru/media/management/chto_takoe_agile/ 12. Как команда GanttPRO использует гибрид Agile и Waterfall https://clck.ru/Yvty9 Практическое задание Самостоятельно ознакомьтесь со статьёй «Как понять, какая модель жизненного цикла проекта даст наибольший эффект для конкретного проекта?» https://project-management.zis.by/agile/kakaja-model-zhiznennogo-cikla-proekta-dast-naibol.html Входные условия для реализации проекта: в команде 5 человек, необходимо разработать экстремальный геокэшинг-квест, спонсор не уверен, что Scrum нам поможет быстро и качественно разработать наш продукт, порядка 30% требований из первоначально сформулированных требований к продукту проекта может измениться по ходу реализации проекта, потери, которые могут возникнуть из-за дефектов – может погибнуть 1 человек, команда на 70 % уверена, что письменное ТЗ не нужно, будет достаточно пользовательских историй, владелец продукта отдаст принятие технических решений по поводу реализации требований команде, в команде есть опытный Product Owner, реализовавший 3 проекта в этой роли, Scrum master с опытом работы – 2 проекта в этой роли, среди участников 1 из команды не участвовал в подобных проектах,2 имеют опыт реализации 2-х проектов, использовавших Scrum, Product owner сможет отвечать день в день на вопросы команды разработки; продукт можно разрабатывать по частям и предъявлять заказчику. Постройте диаграмму «Профиль проекта «Экстремальный геокэшинг-квест»». Примите решение: какую модель жизненного цикла выбрать – Agile, гибридную или предиктивную (водопадную) Пример диаграммы: