Руководство по Agile · Основы Agile
Что такое гибкое управление проектами? Руководство для менеджера проектов
Agile-управление проектами — это практика ведения проектов короткими итеративными циклами, при которой планы, бюджеты и ожидания заинтересованных сторон строятся вокруг частых поставок, а не одного фиксированного предварительного плана. Если наше Руководство по методологии Agile объясняет, что такое Agile и как работают его ценности и фреймворки, то это руководство смотрит на него со стороны руководителя проекта: что меняется в вашей роли, как планировать и составлять бюджет, когда объём заведомо будет меняться, как сообщать о прогрессе и управлять рисками и как Agile сочетается с традиционной системой управления.
Главное
- Agile-управление проектами ведёт проекты короткими циклами, при этом время и стоимость обычно фиксированы, а объём гибок.
- Руководители проектов переходят от распределения задач к управлению бюджетами, заинтересованными сторонами, зависимостями, рисками и системой управления.
- Планы существуют на нескольких уровнях: видение, дорожная карта, релиз, итерация и день.
- Отчётность основана на работающих результатах, диаграммах сгорания вверх и диапазонах прогноза, а не на проценте выполнения.
- Гибридные подходы позволяют сочетать предиктивное планирование и Agile-реализацию там, где каждый из них подходит лучше всего.
Что означает Agile-управление проектами на практике
В традиционном проекте руководитель составляет детальный план, получает его утверждение, а затем контролирует работу относительно этого базового плана. В Agile-управлении проектами проект по-прежнему планируется, финансируется, управляется и отражается в отчётности, но меняется единица контроля. Вместо отслеживания прогресса относительно фиксированного объёма вы отслеживаете ценность, полученную в каждом цикле, и направляете оставшуюся работу на основе реальных фактов.
Три вещи остаются прежними: проекту по-прежнему нужны чёткая цель, спонсор, отвечающий за бизнес-обоснование, и способ показать заинтересованным сторонам текущее положение дел. Три вещи меняются: объём становится главной переменной, детальное планирование приближается к работе, а принятие решений смещается к команде, которая выполняет работу. В остальной части руководства рассматривается, что это означает для каждой части работы руководителя проектов.
Как меняется роль руководителя проекта
В чистом Scrum нет роли руководителя проекта. Три зоны ответственности в нём — Владелец продукта, Scrum-мастер и разработчиков. На практике во многих организациях руководители проектов по-прежнему участвуют в Agile-работе, особенно когда проекты охватывают несколько команд, поставщиков или отделов. Их внимание смещается с распределения задач на создание условий, в которых команда может достигать результатов.
Полезный способ увидеть изменение — спросить, кто теперь отвечает за каждую классическую обязанность в управлении проектами:
| Традиционная обязанность РП | Кто обычно отвечает в Agile |
|---|---|
| Определение и приоритизация объёма | Владелец продукта, через упорядоченный бэклог |
| Назначение задач и составление графика | Команда, которая сама планирует свою работу в каждом цикле |
| Устранение препятствий и улучшение процесса | Scrum-мастер или Agile-коуч |
| Бюджет, контракты и управление поставщиками | Руководитель проекта или руководитель реализации |
| Межкомандные зависимости и координация релизов | Руководитель проекта, руководитель реализации или инженер поезда релизов (RTE) |
| Управление, соответствие требованиям и отчётность перед советом | Руководитель проекта, часто с Agile PMO |
| Управление рисками и проблемами | Совместно: команда отвечает за риски реализации; РП эскалирует организационные риски |
Важнейшими навыками становятся фасилитация, управление заинтересованными сторонами, коммерческое мышление и умение защищать команду от помех — подход, который часто называют служащее лидерство.
Планирование Agile-проекта
Agile-проекты планируются на нескольких уровнях, у каждого из которых свой горизонт и уровень детализации. Детальные планы составляются только на ближайшую перспективу, когда команда знает достаточно, чтобы сделать их точными.
- Видение и бизнес-обоснование: зачем существует проект, кому он приносит пользу и как будет измеряться успех. Это меняется редко.
- Дорожная карта: основные темы или возможности, ожидаемые в ближайшие кварталы, сформулированные как результаты, а не как даты для каждой функции.
- План релизов: какие группы функций ожидаются в каждом релизе, по прогнозу на основе измеренного темпа команды.
- План итерации: детальная работа на ближайшие одну–четыре недели, за которую отвечает команда.
- План на день: как команда координирует сегодняшнюю работу.
Задача руководителя проекта — поддерживать связь между этими уровнями: следить, чтобы работа итерации по-прежнему служила дорожной карте, а дорожная карта — бизнес-обоснованию. Традиционный план проекта по-прежнему играет роль для фиксированных элементов, таких как контракты, мероприятия по запуску, подача документов регуляторам и вехи поставщиков. Некоторые команды также ведут высокоуровневую Представление Ганта для заинтересованных сторон, которым нужны даты, а сама команда работает по бэклогу.
Бюджеты, объём и сроки
Главное изменение для руководителей проектов — какое ограничение становится гибким. Традиционные проекты обычно фиксируют объём и оценивают время и стоимость. Agile-проекты обычно фиксируют время и стоимость, например команду из семи человек на шесть месяцев, и позволяют объёму меняться, реализуя самые ценные элементы в первую очередь.
Именно это делает фиксированный бюджет или срок работоспособными в Agile: команда обязуется реализовать самый ценный объём, который помещается в рамки, а не все когда-либо придуманные элементы. Методы приоритизации, такие как MoSCoW (Must, Should, Could, Won't have this time — обязательно, желательно, возможно, не в этот раз), делают компромиссы явными, и спонсор может остановить проект, как только получено достаточно ценности.
Прогнозирование опирается на факты, а не на ранние оценки. После нескольких итераций измеренный темп команды (скорость или пропускная способность) даёт реалистичный диапазон того, какую часть бэклога можно завершить к заданной дате. Прогнозы следует давать в виде диапазонов и обновлять каждую итерацию, а не обещать одну дату. планирование мощностей в Agile описывает механику.
Договоры требуют такого же подхода. Договоры с фиксированной ценой и фиксированным объёмом плохо сочетаются с Agile. Распространённые альтернативы: «время и материалы» с ограничением бюджета, фиксированная цена за итерацию и фиксированная цена с гибким объёмом, при которой заказчик может заменять элементы бэклога аналогичного размера. На уровне организации многие компании переходят от финансирования проектов к финансированию долгосрочных команд и продуктов; см. Agile-управление портфелем.
Управление заинтересованными сторонами и отчётность о прогрессе
Agile заменяет значительную часть отчётности о статусе прямыми доказательствами. Самый убедительный отчёт — работающая демонстрация: заинтересованные стороны видят продукт на каждом обзоре, а не читают, что он «готов на 80%». Руководитель проекта следит за тем, чтобы нужные заинтересованные стороны присутствовали, а их обратная связь попадала в бэклог.
Спонсорам и советам по-прежнему нужны регулярные сводки. Полезная Agile-отчётность включает:
- Диаграммы сгорания вверх (burn-up) по релизу, показывающая выполненный объём относительно общего объёма во времени, чтобы рост объёма был виден, а не скрыт.
- Диапазоны прогноза для ключевых вех, обновляемые каждую итерацию.
- Показатели результатов, такие как внедрение пользователями или сокращение времени обработки, наряду с показателями реализации.
- Краткий журнал рисков и решений, с указанием того, что команде нужно от руководства.
- Расходование бюджета относительно полученной ценности, чтобы спонсор мог решить, продолжать, менять курс или остановиться.
Выберите небольшой набор показателей и сохраняйте его неизменным.
Риски и управление в Agile-проектах
Короткие циклы по своей природе снижают многие риски: технические проблемы, неверно понятые требования и низкий интерес пользователей проявляются в течение недель, а не в конце. Agile-команды также работают с риском напрямую: выполняют самую рискованную работу в первую очередь, проводят короткие исследовательские задачи (часто называемые спайками) для ответа на открытые вопросы и добавляют меры реагирования на риски в бэклог, как любую другую работу.
Некоторые риски находятся вне контроля команды: задержки поставщиков, решения о финансировании, регуляторные одобрения, зависимости от других проектов. Их выявление, эскалация и отслеживание остаются задачей руководителя проекта, и облегчённый реестр рисков по-прежнему полезен.
Система управления адаптируется, а не исчезает. Вместо утверждения детальных планов на контрольных точках этапов органы управления регулярно рассматривают работающие результаты и данные об итоговых показателях и принимают решения о финансировании исходя из полученной ценности. Agile PMO может поддержать это, устанавливая лёгкие стандарты отчётности, инструментов и прав принятия решений для всех команд.
Гибридные подходы: сочетание Agile и традиционных методов
Многие реальные проекты сочетают подходы. В строительной программе может использоваться традиционное планирование для строительства и Agile-реализация для цифровых систем. ИТ-проект может включать предиктивную фазу закупок и заключения контракта, за которой следует Agile-реализация. Это часто называют гибридным управлением проектами.
Это поддерживают признанные фреймворки. PRINCE2 Agile сочетает систему управления PRINCE2 с Agile-реализацией; см. PRINCE2 и Agile. PMBOK Guide от PMI призывает руководителей проектов адаптировать подход к разработке — от предиктивного до адаптивного — к конкретной работе. Навык состоит в том, чтобы решить, каким частям проекта нужна предсказуемость, а каким гибкость, а не выбирать один подход для всего. Наше сравнение Agile или Waterfall объясняет, где уместен каждый из них.
Инструменты для Agile-управления проектами
Инструменты Agile-управления проектами обычно сочетают бэклог, доску задач, представления итераций или потока, простую отчётность, а для крупных инициатив — дорожные карты и отслеживание зависимостей. Небольшие команды могут начать с общей доски; проектам с несколькими командами обычно нужен инструмент, связывающий командные доски с представлениями портфеля и отчётами.
Наш рейтинг лучших инструментов управления проектами сравнивает такие варианты, как Jira, Wrike, monday.com, Asana и ClickUp. Если вы не готовы к ПО, бесплатные шаблоны покрывают основы: Шаблон Agile-плана проекта, a шаблоне бэклога продукта и шаблон плана релизов.
Первые шаги в профессии руководителя проектов
- Сначала изучите основы. Прочитайте Руководство по методологии Agile и Agile Manifesto , чтобы понимать, зачем это нужно, а не только церемонии.
- Согласуйте распределение ролей. Договоритесь со спонсором, владельцем продукта и командой о том, кто отвечает за приоритеты, реализацию, бюджет и отчётность.
- Настройте уровни планирования. До первой итерации напишите краткое видение, черновую дорожную карту и упорядоченный бэклог.
- Согласуйте, как будет сообщаться о прогрессе. Замените подробные отчёты о статусе обзорами, диаграммой сгорания вверх (burn-up) и кратким журналом рисков и решений.
- Защищайте ритм. Проводите обзоры и ретроспективы в регулярном ритме и защищайте команду от изменений посреди цикла.
- Инспектируйте и адаптируйте собственный подход. Через несколько циклов спросите команду и заинтересованные стороны, что работает, и внесите корректировки.
Пошаговый разбор проекта см. в как вести Agile-проект. Если вы хотите получить квалификацию, как изучить Agile и получить сертификацию сравнивает основные варианты.
Бесплатные шаблоны по этой теме
Частые вопросы
Есть ли руководитель проекта в Agile-управлении проектами?
В самом Scrum нет роли руководителя проекта; его зоны ответственности — владелец продукта, Scrum-мастер и разработчики. На практике многие организации сохраняют руководителей проектов или руководителей реализации в Agile-работе для управления бюджетами, контрактами, межкомандными зависимостями, системой управления и отчётностью перед заинтересованными сторонами, а команда сама планирует свою повседневную работу.
Чем занимается Agile-руководитель проекта?
Agile-руководитель проекта создаёт условия, в которых команда может достигать результатов. Типичные обязанности: управление бюджетами и поставщиками, координация зависимостей между командами, отчётность перед спонсорами, эскалация рисков, которые команда не может решить, защита команды от помех и поддержание соответствия дорожной карты бизнес-обоснованию. Распределение задач переходит к самой команде.
Чем Agile-управление проектами отличается от традиционного?
Традиционное управление проектами рано фиксирует объём, детально планирует заранее и контролирует работу относительно этого базового плана. Agile-управление проектами обычно фиксирует время и стоимость, позволяет объёму меняться, детально планирует только следующий цикл и измеряет прогресс работающими результатами. Роль руководителя проекта смещается от распределения задач к фасилитации, координации и управлению заинтересованными сторонами.
Как составить бюджет Agile-проекта?
Большинство Agile-бюджетов основаны на мощности команды: стоимости стабильной команды за определённый период. Спонсор финансирует эту мощность, команда в первую очередь реализует объём с наибольшей ценностью, а прогресс пересматривается каждые несколько недель. Когда у команды появляется измеренный темп, прогнозы становятся надёжнее, и финансирование можно продолжить, увеличить или прекратить в зависимости от полученной ценности.
Работает ли Agile при фиксированном бюджете или сроке?
Да. В Agile время и стоимость обычно фиксированы, а объём гибок, поэтому фиксированный бюджет или срок вполне подходят, если заинтересованные стороны принимают, что элементы с наименьшим приоритетом могут быть не реализованы. Приоритизация по MoSCoW и прогнозирование по измеренному темпу команды заранее делают компромиссы видимыми.
Как сообщать о прогрессе заинтересованным сторонам в Agile-управлении проектами?
В первую очередь через регулярные обзоры, на которых заинтересованные стороны видят работающие результаты. Для спонсоров и советов добавьте диаграмму сгорания вверх по релизу, диапазоны прогноза для ключевых вех, несколько показателей результатов, израсходованный бюджет относительно полученной ценности и краткий журнал рисков и решений. Держите набор показателей небольшим и неизменным.
Как управляются риски в Agile-управлении проектами?
Короткие циклы рано выявляют многие риски. Команды начинают с самой рискованной работы, используют короткие исследовательские задачи для ответа на открытые вопросы и добавляют меры реагирования на риски в бэклог. Руководитель проекта отслеживает и эскалирует риски вне контроля команды, такие как задержки поставщиков, решения о финансировании или регуляторные одобрения, часто в облегчённом реестре рисков.
Что такое гибридное управление проектами?
Гибридное управление проектами сочетает предиктивный и Agile-подходы в одном проекте, например традиционное планирование для закупок, контрактов или строительства и Agile-реализацию для разработки ПО или дизайна. Это поддерживают такие фреймворки, как PRINCE2 Agile, и рекомендации по адаптации в PMBOK Guide от PMI. Цель — применять каждый подход там, где он подходит лучше всего.
Какие сертификации полезны Agile-руководителям проектов?
Распространённые варианты — PMI Agile Certified Practitioner (PMI-ACP), PRINCE2 Agile и сертификации по Scrum, такие как Professional Scrum Master (PSM) или Certified ScrumMaster (CSM). Правильный выбор зависит от вашей организации и роли. Наше руководство по изучению Agile и получению сертификации сравнивает их.
Какие инструменты используются для Agile-управления проектами?
Команды используют инструменты, сочетающие бэклоги, доски, представления итераций или потока и отчётность, такие как Jira, Wrike, monday.com, Asana и ClickUp. Крупным программам нужны представления портфеля и отслеживание зависимостей. См. наш рейтинг лучших инструментов управления проектамиили начните с бесплатных шаблонов электронных таблиц.
Работает ли Agile-управление проектами для крупных проектов?
Да, но крупным проектам нужна дополнительная координация: согласованное планирование между командами, управление зависимостями и общие процессы интеграции и выпуска. Фреймворки масштабирования, такие как SAFe дают для этого структуру, и многие организации сочетают Agile-команды с управлением на уровне программы. Начните с одной-двух команд и масштабируйте только тогда, когда это работает.
Сложно ли освоить Agile-управление проектами?
Основные идеи можно освоить за несколько дней, но хорошо применять их — дело практики, особенно для опытных руководителей проектов, привыкших к детальным предварительным планам. Самое сложное обычно — позволить объёму меняться, разделить принятие решений с командой и убедить заинтересованные стороны оценивать прогресс по работающим результатам.