Фреймворк предлагающий пошаговый план по управлению проектом

Обновлено: 03.07.2024

В этой, восемнадцатой статье из серии «Менеджмент цифрового мира» (оглавление) я буду рассказывать о фреймворках масштабирования Agile на большие подразделения или компанию в целом. Эту тему я уже начал в прошлой статье «Kanban и Lean - эволюция вместо революции»: Kanban также позволяет оркестровать работу в рамках компании, но он нем я здесь говорить больше не буду.

Отмечу, что ячейкой организации в любом случае является автономная самоорганизующаяся Agile-команда, поэтому совместимость способов управления с Agile-культурой является принципиальным требованием. Опыт показывает, что многие подходы менеджмента, основанные на уважении авторитета руководителя, полагаемого безусловным, или следовании за непогрешимым лидером не выдерживают столкновения с Agile-культурой: сотрудники могут просто уйти целой командой. И если руководство привыкло к такому стилю управления, то в Agile нет никакого смысла. С другой стороны, как я говорил в статьях «Три вызова цифрового мира» и «Цифровой мир: от физического труда — к умственному» методы регулярного менеджмента в цифровом мире перестают работать, а Agile-методы являются одной из работающих альтернатив, что подробно рассмотрено в статье «Agile – ответ IT на вызовы цифрового мира».

Фреймворки имеют разную сложность и рассчитаны на компании или подразделения разного размера. При этом большинство из них рассчитано на короткие цепочки создания ценности, когда одна кроссфункциональная команда делает продукт, поставляемый потребителям. Как я писал в статье «Место Agile-команд в компании», в условиях неопределенности и быстрого изменения условий работы компании в VUCA-мире короткие цепочки являются естественным способом организации труда, способным быстро реагировать на изменения, в отличие от стабильных условий функционирования, которые ведут к специализации и образованию длинных цепочек из функциональных подразделений.

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

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

И перед тем, как перейти к обзору фреймворков я хочу порекомендовать доклад Асхата Уразбаева «Фреймворки масштабирования Agile» на SECR-2017 со сравнением разных фреймворков.

Начну я с наиболее простого Scrum of Scrums, который появился раньше других. Он применяется в случае, если у вам в компании есть независимые Scrum-команды, каждая из которых делает свой продукт. Тогда для работы надо общими вопросами достаточно собрать команду Product Owner для обсуждения стратегии развития продуктов и координации усилий, и команду Scrum Master для обсуждения и координации вопросов организации. Если в командах есть Tech Lead, отвечающий за технологии и обучение им сотрудников, то добавляется еще координирующая команда из них.

Однако, бывают ситуации, когда одна команда не может обеспечить развитие продукта в требуемой темпе, ее мощности не хватает. Ведь размер команды ограничен, эффективно работает команда в 7-9 человек, а если их становится сильно больше, то необходимо дополнительное структурирование. Есть относительно простой способ нарастить команду до 15-20 человек, представленный на схеме. Это конструкция из мини-команд, каждая из которых состоит из опытного сотрудника и 1-2 стажеров, для которых опытный является наставником для стажеров. При этом операционные вопросы взаимодействия решаются командой из руководителей мини-команд.

Другой относительно простой способ – это собрать Integration Team из представителей отдельный команд, которая будет решать вопросы координации и зависимостей. Это предлагает Nexus и достаточно в случае, когда зависимости являются достаточно слабыми.

Более сложный фреймворк – Large Scaled Scrum (LeSS) (русское описание) – несколько команд на одном продукте с общим Product Owner, BackLog, спринтами, планированием, демо и поставкой, это позволяет объединить до 8 команд. У фреймворка есть huge вариант, применяемый для больших компаний и рассчитанный на работу 1000+ человек.

Ответственность команды не ограничивается выполнением основных производственных задач, она имеет много планов и фокусов, и логично, когда это реализуется через отдельные организационные структуры. Это мы видели на примере Scrum of Scrum, который организует две структуры управления – продуктовую и организационную, иногда дополняемую третьей, технологической. Более сложной конструкцией является Spotify фреймворк, который заслуживает отдельного рассмотрения.

Основной производственной единицей в ней является клан (tribe) в 100-200 человек, который работает над отдельным продуктом. Он представляет собой матрицу: делится на кроссфункциональные производственные отряды (squad) и функциональные отделы (chapter). Отряды реализуют новый функционал и состоят из специалистов разных специализаций, которые дополняют друг друга. А отделы координируют работы специалистов из разных команд, использующих общие технологии, решая такие задачи, как разработка мобильных интерфейсов в едином стиле, однородная работа серверной части или развитие технологий тестирования. Отметим, что отделы работают над применением технологий в рамках продукта, а вот для развития технологий в целом по компании существуют еще гильдии (guild) по интересам. По мере роста компании над кланами появились структуры следующего уровня – альянсы (alliance) и бизнес-единицы (business unit).

Конструкция – очень сложная и многоплановая и во многом обусловленная контекстом компании. Spotify ей делится, но с предостережением: «используйте наши опыт, но не пытайтесь тупо скопировать, оно не взлетит, мы это точно знаем, потому что у нас самих конструкция развивается и растет». Но много попыток именно механического копирования, обычно неудачных. А вот идеи заложены плодотворные.

При этом в самой компании Spotify организационная структура развивается очень быстро. И я хочу интересующимся порекомендовать доклад Yuliya Kurapatenkava на Saint TeamLeadConf-2018, в котором она рассказывала про логику развития (мой конспект есть в отчете с конференции, сам доклад по-английски). И вы можете сравнить то, что звучит в докладе с тем описанием фреймворка, которое доступно по ссылке в начале раздела и фиксирует состояние несколько лет ранее.

Здесь стоит рассмотреть практическое применение подобных фреймворков. Один продукт, над которым работают несколько команд, далеко не всегда означает единственный продукт в смысле софта, более того, часто речь идет об одном бизнес-продукте, поддержка которого со стороны софта требует общей серверной части и нескольких приложений на разных платформах – web и мобильных. Естественным образом для того, чтобы какой-то новый функционала стал доступен конечным пользователям, он часто должен быть реализован в серверной части и для каждой из платформ. И тут может быть два подхода: сделать команды, каждая из которых сосредоточенна вокруг каждого софтверного продукта, при этом только она работает с кодовой базой продукта и отвечает за его архитектуру. В этом случае для организации могут применяться фреймворки, подобные LeSS.

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

Так вот, в зависимости от потока задач и этапа развития компании предпочтительная структура может сильно изменяться. И сейчас IT-компании умеют достаточно быстро и успешно перестраивать свою структуру в зависимости от потребностей развития продукта. Я хочу сослаться на опыт компании ivi. На TeamLeadConf-2018 Евгений Россинский рассказывал, как они обеспечивали целостность продуктов и поддерживали знания разработчиков при переходе к кроссфункциональным командам от команд, собранных вокруг отдельных приложений. А через год TeamLeadConf-2019 он же рассказывал как за год они для решения задач реинжиниринга ядра продукта вернулись к командам, организованным по приложениям, провели реинжиниринг, а затем – снова перешли к кросс-функциональным командам, и все это - за один год, и продолжая мониторинг производительности, чтобы не допустить деградации.

Компания ivi предоставляет чистый цифровой продукт. Однако, похожая бизнес-структура сейчас характерна и для банков и для туроператоров, потому что их продукты сейчас все больше и больше перемещаются в цифровую сферу. Но, насколько я знаю, быстро пересобираться таким образом они еще не умеют, да и для IT опыт ivi является передовым. И, думаю, это может дать хорошее представление о том, какова она – динамично развивающаяся и перестраивающаяся современная цифровая компания, насоклько быстро она умеет изменяться.

Scaled Agile Framework (SAFe) является самым сложным Agile-фреймворком, но при этом – самым популярным. Это сложная конструкция уровня компании с управлением потоками создания ценности и архитектурой. На мой взгляд, популярность этого фреймворка сродни популярности PMBOK или RUP – в нем есть все и на все случаи жизни, и предлагается просто взять нужное. Те, кто читал мою статью «Развитие и провал регулярного менеджмента в IT» не удивятся моему мнению, что у это – неработоспособная конструкция, хотя и привлекательная в своем инженерном совершенстве. И он не будет работать по тем же самым причинам – его сложность превышает разумный предел, при этом обвинить сам фреймворк будет невозможно, всегда окажется, что это вы не смогли его правильно реализовать.

Но дело не только в сложности фреймворка: SAFe пытается за счет сложных регламентов превратить запутанную область в сложную, а это – невозможно (подробнее о сложности областей – в моей статье «Место Agile-команд в компании»). Однако, SAFe может быть полезен как теоретический источник, подобно PMBOK. Кстати, автором фреймворка является Дин Леффингуэлл (Dean Leffingwell), один из авторов RUP.

Довольно интересен фреймворк Enterprise Scrum предлагает переход от создания IT-продукта к поставке ценности, управляемой набором связанных метрик. К сожалению, в отличие от всего остального он не завершен. Его создатель Mike Beedle, кстати, один из авторов Agile-манифеста был, к сожалению убит в Чикаго весной 2018 года, и работа не завершена. Однако, на сайте есть достаточно подробная конструкция системы метрик, совместимая с Agile-методами управления, и, возможно, она вам окажется полезной при конструировании собственной, хотя в готовом виде ее, естественно, брать не стоит. Поэтому я и даю ссылку.

На этом я завершаю эту статью. Полное оглавление серии «Менеджмент цифрового мира» можно увидеть у меня на сайте. В следующей статье мы поговорим про кейсы Agile-трансформации. Продолжение следует…

Фреймворки есть не только у программистов. P3.express — новый легковесный фреймворк для управления проектами. Включает в себя 37 шагов, разделенных на семь фаз.

Не нужно тратить годы, чтобы изучить его. Спокойно и без боли можно попробовать P3.express уже в текущих проектах.

Это не очередная попытка изобрести велосипед. Метод основан на PRINCE2 и PMBoK Guide — подходах, которые вобрали в себя лучшие практики проектного менеджмента. Сначала коротко о каждом, потом о виновнике торжества.

PRINCE2

PRINCE2, «британский принц проектного менеджмента», — это структурированный фундаментальный подход к управлению проектами. Весьма популярен в Великобритании, США, Канаде, странах Восточной и Северной Европы, отчего и получил свое название.

На западе его используют многие крупные компании. Например, Siemens, Bank of New York, ВАТ, крупнейшие банки и телекоммуникационные операторы Великобритании, Philips, Microsoft, Unilever, Tesco, Philip Morris UK, GlaxoSmithKline, Tesco, Shell, Nokia, Novartis, HSBC, Cornhill, Sun, Hitachi, Fidelity, и другие.

В России принципы PRINCE2 применяют в международных британских фирмах, как например, British American Tobacco и British Telecom, а также в крупнейших международных американских корпорациях (IBM и Hewlett Packard).

Позволяет вести проекты системно, при этом легко масштабируется и интегрируется с другими методологиями, как например, Agile или CMMI — ведь у PRINCE2 нет своего регламента по методам и подходам. Подразумевается, что каждый менеджер использует те, которыми привык пользоваться.

Проекты в PRINCE2 делятся на фазы с четко заданным временем начала и окончания.

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

Следующий этап — построение карты последовательности продуктов (product flowchart), которая описывает все взаимозависимости субпродуктов и последовательности при реализации. Фактически проектный план выглядит не как дерево задач, а дерево продуктов.

Все результаты делятся на две категории — продукты управления (management products) и специализированные продукты (specialist products).

Продукты управления — это все документы, подготовленные в ходе работы. Обязательный — PID (Project Initiation Document).

PID — достаточно объемный документ, который включает в себя Project Brief с бизнес-кейсом (то, что мы привыкли называть Project Vision), описание продуктов (Product Description, нечто наподобие User Stories из Scrum), Product Flowchart, и, соответственно детальный проектный план.

Пример

Зона «Маасвлакте 2» порта Роттердам, крупнейший инженерный проект в Нидерландах в XXI веке, был построен на год раньше срока благодаря методологии PRINCE2. Порт Роттердама — самый большой в Европе, но даже он столкнулся с проблемой нехватки места, когда грузооборот вырос. Для решения проблемы построили искусственный остров площадью 2000 гектаров и стоимостью два миллиарда евро. В 2013 году голландские портовики облегченно выдохнули — со следующим расширением можно хорошо подождать. А авторы PRINCE2 на протяжении девяти лет ежегодно вносили улучшения в подход, так что триумфальный опыт «Маасвлакте 2» улучшил и методологию.

Пример

Национальный энергооператор Новой Зеландии Transpower в 2008 году решил создать программу, которая будет симулировать потребление энергии и тем самым показывать, как оно вырастет в будущем. С помощью PRINCE2 программное обеспечение было уже готово в 2010 году, а в копилке методологии появился впечатляющий IT-проект, в ходе работы над которым авторы значительно улучшили и сам подход.

PMBoK

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

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

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

PMBOK Guide и PRINCE2 работают на одну цель и сильно пересекаются. Поэтому логично, что на их стыке образовался P3.express.

P3.express — чем отличается от других

P3.express взял лучшие черты из фундаментальных и гибких методов, попытавшись преодолеть многие их недостатки. По сути, это такой гибрид.

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

Предположим, что задача — произвести велосипед (обычный, не программный). И в Agile, и в P3 процесс начинается с планирования. А вот дальше пути расходятся.

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

По P3.express велосипед будут собирать четыре команды: одна будет делать раму, вторая — колеса, третья — фурнитуру (педали, болты, цепь, катафоты), четвертая отвечать за сборку. Каждая выпустит свой продукт.

Вырисовываются два основных проектных риска:

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

P3.express, как и PRINCE2, предписывает разбивать конечный продукт «велосипед» на субпродукты: «рама», «фурнитура», «колеса». При этом каждый субпродукт получает свой product description (описание): колесо должно быть такого-то диаметра, с такой-то втулкой, крепиться такой-то фурнитурой, рама должна выдерживать такую-то нагрузку.

Дальше выстраивают product workflow diagram — очередность, по которой субпродукты должны быть готовы.

PRINCE2 часто критикуют из-за того, что там отсутствует ретроспектива и общение с командой, так называемый «мягкий менеджмент». Из-за чего возникают недопонимания, конфликты в команде, и проект стопорится. Людям, как минимум, нужно выговориться и выпустить пар, а как максимум — подвести промежуточные или окончательные итоги по проекту и поделиться впечатлениями.

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

Все это учел P3.express.

P3.express — фазы

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

Фреймворк работает по священному принципу Парето — 20% усилий дают 80% результата.

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

Подготовка проекта

Шаг 02. Подготовить резюме проекта

Шаг 03. Назначить руководителя проекта

Шаг 04. Развернуть информационную систему

Шаг 07. [Выбрать внешних исполнителей]

Шаг 08. Провести аудит подготовки

Шаг 10. Провести стартовую встречу

Планирование цикла

Шаг 13. [Выбрать внешних исполнителей]

Шаг 15. Провести стартовую встречу цикла

Еженедельные действия

Шаг 17. Измерить и задокументировать ход проекта

Шаг 18. Работать с отклонениями

Шаг 20. Провести еженедельный аудит

Пример письма менеджера своей команде между этапами

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

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

Если вы следовали рекомендациям p3x, то все документы хранятся в одном месте и хорошо структурированы. Всё, что вам требуется — перенести их в архив и изменить права доступа.

Используйте Google Forms, или аналогичный сервис, чтобы создать и разослать опросник, и получить анонимные результаты. Далее скопируйте их в шаблон Здоровье Проекта и продолжите процесс.

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

Ежедневные действия

Шаг 23. Реагировать на RICs на основе делегированных полномочий

Шаг 24. Принять готовые продукты от Тимлидов и исполнителей

Закрытие цикла

Шаг 25. Оценить удовлетворенность заказчика и команды

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

Шаг 28. Получить одобрение и передать продукт

Шаг 29. Передать Бизнес-кейс ответственному лицу

Шаг 30. Оценить удовлетворенность заказчика и команды

Шаг 31. Провести аудит проекта

Шаг 32. Извлечь уроки и заархивировать проект

Шаг 33. Объявить и отметить окончание проекта

После проекта

Шаг 35. Свериться с Бизнес-кейсом и оценить выгоды

Шаг 36. Спланировать дополнительные действия, если необходимо

Шаблоны документов по P3.express можно скачать здесь.

А дальше что?

P3.express — пока что самое новое и современное, что нам предлагает проектный менеджмент. Но помните: никакая методология — не панацея. Проведем ближайшую аналогию с чеклистами — это такая классная штука, которая люто помогает в работе, но дает эффект почему-то далеко не у всех. Чеклисты виноваты или те, кто их внедряет?

Скоро P3 начнет активно продвигаться в России, так что ждем на каждой PM-конференции в ближайшие пару лет. А вы пока можете поделиться ссылкой с коллегами-управленцами.

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

Стандартный фреймворк для управления проектами можно разбить на три большие части:

Жизненный цикл проекта. Ключевое различие между методологиями Waterfall и Agile заключается в том, что эти фреймворки включают в себя разные жизненные циклы. Например, фреймворк Waterfall состоит из пяти стандартных фаз:
Подготовительный этап
Планирование
Исполнение
Контроль
Завершение

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

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

Руководство PMBOK описывает фреймворк как базовую структуру для понимания сути управления проектами. Менеджеры проектов выбирают фреймворк, который больше всего подходит для их проекта или команды. Мы объясним, как выбрать соответствующий фреймворк для проекта в разделе Е.

В чем разница между методологией и фреймворком?

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

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

Б. Что общего у Agile-фреймоворков?

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

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

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

В. Фреймворк Scrum

Методология Scrum была разработана в 1990-х гг., и ее основы были изложены в статье в Harvard Business Review под названием «Разработка нового продукта. Новые правила игры». Большинство менеджеров проектов считают Scrum самым популярным Agile-фреймворком.

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

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

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

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

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

Scrum требует определенных ролей и обязанностей для участников Agile-команды, в том числе следующих:

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

Scrum также имеет собственную уникальную терминологию. Далее приведены важнейшие термины, часто используемые при работе с фреймворком Scrum:

Бэклог продукта. Бэклог — это список задач и требований, которые должны быть выполнены применительно к конечному продукту. За создание бэклога и управление им отвечает владелец продукта.
Спринт. Спринт — это период времени для выполнения набора задач из бэклога. Длительность спринтов должна быть одинаковой. Обычно это две недели, хотя спринт может длиться от одной до четырех недель в зависимости от потребностей команды и проекта.
Планирование бэклога. Планирование бэклога (иногда его еще называют планированием спринта) — это определение задач в бэклоге, которые нужно включить в каждый из спринтов.
Бэклог спринта. Часть бэклога, назначенная текущему спринту.
Ежедневный Scrum. Проектная группа встречается каждый день, чтобы обсудить ход работ за последние сутки, ожидаемый прогресс за следующие сутки и возникающие проблемы. Обычно такие встречи называются ежедневный Scrum или стендап и длятся около 15 минут.
Ретроспектива. Каждый спринт должен заканчиваться обзорным совещанием, которое называется ретроспектива. Команда рассматривает свои достижения и обсуждает возможности что-то улучшить в ходе следующего спринта.
Scrum-доска. Scrum-доска помогает участникам команды видеть бэклог спринта и управлять им. Доска может быть настоящей или виртуальным инструментом в системе управления проектами. Обычно на доске есть три столбца: «К исполнению», «В работе» и «Выполнено». По мере выполнения объектов из бэклога они перемещаются по доске из одного столбца в другой. Поэтому все видят, что им нужно делать в следующем спринте и как продвигается работа.
Артефакт. Бэклог продукта, бэклог спринта и инкремент продукта — это три артефакта Scrum в проекте. Бэклог продукта и бэклог спринта отражают работу, которую нужно сделать, а инкремент продукта — это часть продукта, которую команда создала в ходе текущего спринта.

Г. Другие популярные Agile-методики управления проектами

Хотя Scrum — одна из самых популярных Agile-методик управления проектами, это не единственный доступный для вас вариант. Вы можете задать себе вопрос: что представляет собой Agile-планирование и какой фреймворк следует выбрать? Вы можете выбрать любую из пяти других Agile-методологий управления проектами:

1. Kanban

Kanban — это простой и наглядный способ управления проектами. Он изначально разрабатывался как метод планирования и помогает командам создавать продукцию точно в срок (JIT), позволяя всем участникам видеть, как продвигается проект и что будет дальше.

Kanban ориентирован на визуализацию рабочего процесса, когда задачи разбиваются на небольшие части. Фреймворк Kanban во многом похож на Scrum. Здесь также используется доска для отображения информации и отслеживания хода работ, причем задачи распределяются по трем основным столбцам: «К исполнению», «В работе» и «Выполнено». Но в отличие от Scrum, Kanban-доска отражает всю работу по созданию продукта без разделения на спринты.

Kanban помогает выявить препятствия и лишние затраты, а также снизить время ожидания.

2. Экстремальное программирование (XP)

Экстремальное программирование (XP) — Agile-фреймворк, изначально созданный для Agile-проектов по разработке программного обеспечения. Как и Scrum, этот фреймворк нацелен на постоянную разработку и доставку продукта заказчику и использует интервалы или спринты.

Однако фреймворк XP опирается на принципы проектирования и включает 12 основных приемов, специфичных для сферы разработки программного обеспечения. Это следующие приемы:

Игра в планирование
Частые небольшие релизы
Приемочное тестирование клиентом
Простота проектирования
Парное программирование
Разработка через тестирование
Рефакторинг
Непрерывная интеграция
Коллективное владение кодом
Стандарт оформления кода
Метафора системы
40-часовая рабочая неделя для программистов

3. Функционально-ориентированная разработка (FDD)

Функционально-ориентированная разработка — еще один Agile-фреймворк, специфичный для сферы разработки программного обеспечения. Он нацелен на создание моделей через каждые две недели. Также он требует отдельного плана разработки и проектирования для каждой функции модели, то есть превосходит все остальные Agile-фреймворки по объему документации. Из-за жестких требований к документации FDD лучше подходит командам с расширенными возможностями проектирования и планирования.

Фреймворк FDD разбивает проекты на пять базовых повторяющихся видов деятельности:

Разработка общей модели
Составление списка необходимых функций системы
Планирование работы над каждой функцией
Проектирование функции
Реализация функции

4. Метод разработки динамических систем (DSDM)

Метод разработки динамических систем (DSDM) возник из-за потребности в общем отраслевом фреймворке для быстрого создания программного обеспечения. DSDM предусматривают доработку, и любые вносимые изменения в ходе разработки должны быть обратимыми. Как и Scrum, XP и FDD, фреймворк DSDM разбивает проекты на мелкие спринты.

Этот фреймворк основан на восьми основных принципах:

Фокус на потребностях бизнеса
Своевременная поставка
Сотрудничество
Постоянно высокое качество
Инкрементный подход на прочном фундаменте
Итеративная разработка
Постоянное и четкое взаимодействие
Демонстрация контроля

5. Crystal

Crystal — это семейство Agile-методологий, включающее в себя Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Red и т. п. У каждой из этих методологий есть свой уникальный фреймворк, и выбирать методологию следует в зависимости от нескольких факторов, в том числе от размера команды, приоритетов и важности проекта. Принимая решение о том, как внедрить Agile-методологию, очень важно понимать, что для различных проектов в зависимости от их уникальных характеристик требуются различные наборы политик, практик и процессов.

Является ли бережливое управление проектами (Lean) Agile-фреймворком?

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

Устранение потерь
Повышение качества
Создание знаний
Отсроченные обязательства
Быстрая поставка
Уважение к людям
Полная оптимизация

Д. Определение эпика Agile

В Agile-методологии управления проектами эпики — это «крупные истории пользователей».

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

Но что если на написание каждой главы потребовалось бы восемь недель? История пользователя оказалась бы слишком большой для одного спринта и считалась бы крупной историей или эпиком.

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

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

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

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

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

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

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

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

Предлагаем посмотреть видеоролик Knowledge Hut, более подробно демонстрирующий определение и ценность эпиков Agile.

Е. Лучшие рекомендации для менеджеров проектов по выбору оптимального фреймворка

Если вы можете выбирать из более чем шести популярных Agile-фреймворков, как узнать, который из них подходит для вашего проекта?

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

Вот семь лучших рекомендаций по управлению проектами, основанных на стандарте по оценке зрелости управления проектами в организациях (Organizational Project Management Maturity Model, OPM3) и руководстве по внедрению управления проектами в организациях от Института управления проектами (PMI).

Оцените объемы проекта. Большой длительный проект может быть трудно разбить на двухнедельные спринты. Но если его размах трудно определить и он может расти, то Agile, скорее всего, лучше подойдет, чем более традиционный фреймворк.
Определите движущие факторы проекта. Очень важно знать экономическое обоснование проекта и его ценность для организации. Какие преимущества он даст вашей компании?
Составьте представление о ключевых целях клиента, ожидаемых результатах и приоритетах проекта.
Выявите все факторы, цели, результаты и приоритеты проекта, на которые могут повлиять различные методологии. Например, если ваша цель — максимальная экономичность, возможно, вам подойдет бережливая методология Lean. Если клиент рассчитывает получить подробную документацию, правильным выбором может стать FDD.
Составьте список возможных методологий, подходящих для вашего проекта, и расставьте их по порядку на основе критериев, выявленных на прошлом этапе.
Выбирайте фреймворк, подходящий для большинства факторов, целей, результатов и приоритетов. Если какие-то результаты важнее остальных, можете расставить приоритеты, чтобы не упустить самое важное. Вам нужно выбрать фреймворк, который даст наилучший результат с наименьшим риском.
Выбрав фреймворк, отслеживайте его эффективность. Суть всех Agile-методологий заключается в гибкости и адаптивности. Если выбранная вами методология не дает желаемого результата, следует модифицировать или даже заменить ваш фреймворк.

Ж. Бесплатные инструменты для управления Agile-проектами

Все, что вы используете для управления Agile-проектами, является Agile-инструментом для управления проектами. Самый простой пример — это доска со стикерами, но и многие сложные цифровые инструменты также позволяют работать с Agile-фреймворками, такими как Scrum и Kanban.

p3express — простой фреймворк для управления проектами. Он состоит из хорошо структурированных пошаговых инструкций по реализации проекта от момента возникновения идеи проекта до получения ожидаемых выгод.

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

Не будем описывать роли или должности, давайте сразу на примерах…

Я внезапно стал проджектом и не знаю, что делать.
Ситуация стрессовая и зачастую неожиданная. Читать умные книжки некогда, вникать в море терминов сложно, а лажать не хочется. P3X поможет быстро сформировать целостное представление о предстоящей работе, поможет грамотно задать вопросы и спланировать работу, а главное, снизить переживания из-за вашей “неопытности”.

У нас в компании разрабатывается/разработана своя методология!
Отлично! Вы довольны тем, как она работает? Все придерживаются методологии? Изучите P3X и сможете понять, что в вашей корпоративной методологии можно доработать или упростить.

Я простой член команды…
ЧЛЕН КОМАНДЫ, а не рядом проходили. Задумайтесь, вам комфортно работать? В проекте всё прозрачно? Команда идёт к успеху? Возможно, P3X подскажет, как разрешить ваши проблемы.

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

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

Авторами фреймворка являются европейские эксперты с многолетним опытом Nader K Rad и Frank Turley.

Шаги в P3express разбиваются на 7 групп:
1) Подготовка проекта
2) Планирование цикла
3) Еженедельные действия
4) Ежедневные действия
5) Закрытие цикла проекта
6) Закрытие проекта
7) После проекта

Каждая группа содержит шаги с описанием действий на каждом шаге, например:

Шаг 08. Провести аудит подготовки
Подготовка проекта практически завершена, и пришло время оценить свою работу, используя чек-лист “Здоровье Проекта” — 1_Аудит_подготовки.
В случае низких оценок вам необходимо выявить и проанализировать источник проблемы.
СКАЧАТЬ ШАБЛОН “ЗДОРОВЬЕ ПРОЕКТА”

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

На всех необходимых шагах предусмотрены шаблоны:
– Рабочая доска проекта
– Бизнес-кейс проекта
– Резюме проекта
– Чек-листы аудитов
– Примеры коммуникаций
– Реестр рисков, проблем, изменений
– Реестр прогресса

Акценты P3express:
– Коммуникации — они органично встроены в фреймворк таким образом, что вам не удастся о них забыть, даже если очень хочется.
– Здоровье проекта — это чек-листы или процедуры, следование которым поможет вам оперативно выявить проблемные зоны проекта, будь то процессы или мотивация участников проекта.
– Циклы — регулярные действия разбиты на “естественные” циклы — ежемесячные, еженедельные, ежедневные.

Чтобы применять P3express:
– Не нужно учить новые слова
– Не нужно искать/менять программное обеспечение
– Не нужно приобретать и читать много книг

Скорее всего. P3express подходит для большинства обычных проектов — пилите продукт, проводите форум, разрабатываете ИТ-решения на заказ? P3X вам подходит.

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

Читайте также: