Фреймворк и методология разница

Обновлено: 02.07.2024

Это пятая статья из серии «Введение в Agile». В ней мы расскажем о самом популярном подходе в области Agile – фреймворке Scrum.

До этого мы разбирались в отличиях гибких и классических подходов к управлению, области применения Agile-подходов, характеристиках Agile-команды и способах перехода на Agile:

Что такое фреймворк

Первый вопрос, который возникает при виде словосочетания «фреймворк Scrum»: а что такое фреймворк и чем он отличается от стандарта или методологии?

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

Немного истории

Scrum (Скрам) был разработан в 1995 году Джеффом Сазерлендом и Кеном Швабером. Перед Сазерлендом была поставлена задача: менее чем за 6 месяцев разработать замену основному программному продукту компании «Easel Corporation». Прочитав все, что смог найти о повышении производительности команд, Джефф предложил свой подход. Он объединился со своим коллегой Кеном Швабером для формализации подхода и в 1995 году Scrum был представлен всему миру.

Почему «Скрам»?

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

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

Скрам широко известен, так как его применяет большинство команд, работающих по Agile. По результатам 13-го ежегодного исследования State of Agile – 2019, Scrum остается самым популярным фреймворком. Однако следует понимать, что, как у любого подхода, у Скрама помимо сильных сторон есть и ограничения.

Среди преимуществ Скрама – четкость, простота и наличие единого официального источника информации. Все требования изложены в официальном Руководстве по Скраму (Scrum Guide) .

Ограничения Скрама

В то же время с применением Скрама связаны определенные сложности. В одной из предыдущих статей мы рассказали, что для работы в Agile нужна особая команда: небольшая, профессиональная, плоская (без иерархии и руководителей), которая сама принимает решения о способе достижения результата.

Эти же требования применимы и к командам, которые работают по Скраму: ответственность за результат в них распределена между участниками команды (у всех одна роль – «разработчик»), которые заведомо мотивированы на достижение этого результата. Этим сотрудникам не нужно каждый день ставить задачи и контролировать выполнение, они самостоятельно договариваются о том, как выстроить работу, и нацелены не на выполнение отдельных задач, а на создание законченного продукта или части такого продукта (инкремента), имеющих ценность для заказчика.

Структура фреймворка

Скрам состоит из 3 ролей, 5 событий и 3 артефактов (носителей информации о продукте). Каждый элемент Скрама взаимосвязан с другими и обязателен для применения. Общая схема фреймворка представлена на рисунке ниже. Мы кратко опишем весь процесс, а затем подробнее остановимся на каждом элементе.

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

Работа команды разработки делится на равные промежутки времени – спринты. Рекомендуемая длина спринта – от 1 до 4 недель. Количество спринтов не ограничивается. Проект может быть завершен когда Владелец продукта получил требуемый функционал, когда дальнейшая работа над продуктом не требуется или экономически не востребована.

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

Объем или количество требований, которые Команда может выполнить за спринт, определяется на основе опыта: в течение нескольких спринтов анализируются обязательства, которые взяла на себя Команда разработки при Планировании спринта, и фактический объем выполненных требований. Такой подход называется эмпирическим. В результате устанавливается условно-постоянный объем, который Команда стабильно прорабатывает за Спринт – производительность Команды.

После Планирования спринта запускается процесс Разработки, в ходе которого Команда разработки работает над требованиями из Бэклога спринта.

Для оперативного планирования и решения проблем ежедневно проводятся Скрам-встречи, или «летучки». На них участники Команды разработки обсуждают, что удалось сделать за прошедший день, что планируется на следующий, и какие возникли проблемы. Важная характеристика Скрам-встречи – ее жесткая ограниченность по времени. «Летучка» не должна занимать более 15 минут.

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

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

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

Резюме

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

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

Краткие вводные:

PRINCE2 (Projects in a Controlled Environment) – структурированный метод управления проектами, разработанный в 1989 году Central Computer and Telecommunications Agency (CCTA) в Великобритании.

PMBoK – фреймворк (свод знаний) по управлению проектами, разработанный в 1996 году Project Management Institute (PMI) в США.

ISO 21500:2012 «Guidance on project management» - международный стандарт, разработанный проектным комитетом ISO/PC 236 «Управление проектами».

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

PRINCE2

PMBoK (6 издание, 2017г.)

ISO 21500:20112

Определение проекта

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

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

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

Процессы

7 процессов: Начало проекта, руководство проектом, инициация проекта, контроль стадии, управление границами стадии, управление созданием продукта, закрытие проекта.

49 процессов, объединенных в 5 групп процессов: инициация, планирование, исполнение, мониторинг и контроль, закрытие.

39 процессов, объединенных в 5 групп процессов: инициация, планирование, исполнение, управление, завершение.

Предметные темы / группы (курсивом отмечены различающиеся темы)

7 тем:

1. Экономическое обоснование,

3. Управление качеством,

5. Анализ и управление рисками,

6. Управление изменениями содержания,

7. Принятие решений.

10 областей знаний:

1. Управление интеграцией проекта,

2. Управление содержанием,

3. Управление сроками,

4. Управление стоимостью,

5. Управление качеством,

6. Управление человеческими ресурсами,

7. Управление коммуникациями,

8. Управления рисками,

10. Управление заинтересованными сторонами.

10 предметных групп:

2. Заинтересованные стороны,

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

Структура стадий проекта:

1. Стадия инициации,

2. Последующие стадии (создание продуктов, соответствующих требованием),

3. Финальная стадия (приемка результатов, подведение итогов проекта).

Минимальное количество стадий в проекте – 2 (инициация и финальная).

Все проекты могут иметь следующую структуру жизненного цикла:

1. начало проекта;

2. организация и подготовка;

3. выполнение работ проекта;

4. завершение проекта.

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

Принципы

7 принципов (универсальны и не требуют обоснования):

1. Постоянная оценка целесообразности,

2. Учет предыдущего опыта,

3. Определенные роли и обязанности,

4. Управление по стадиям,

5. Управление по исключениям,

6. Фокус на продукте,

7. Адаптация к внешним условиям.

Шестое издание PMBoK основано на процессной составляющей с четкими входами, выходами и инструментарием.

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

ISO 21500 по аналогии с PMBoK основан на процессной составляющей.

Ответственность за результат проекта

Ответственный руководитель (куратор/спонсор проекта) полностью отвечает за успех проекта.

Менеджер проекта управляет проектом на ежедневной основе в рамках полномочий, делегированных Управляющим советом.

Руководитель проекта = единый ответственный за результат.

Руководитель проекта обеспечивает общее руководство и управление работами проекта и отвечает за получение результатов проекта.

Инструменты управления

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

Предоставляет расширенный список инструментов и методов по каждому процессу управления проектом.

Стандарт не описывает конкретных инструментов для реализации процессов управления.

Возможность гибкого применения

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

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

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

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

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

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

Можно ли назвать Скрам процессом?
Если Скрам и процесс, то он точно не повторяющийся . Объяснить это на деле не так просто, потому как сам термин “процесс” обычно подразумевает алгоритмические предсказуемые шаги, повторяющиеся действия и принудительный иерархический контроль – то, чего можно ожидать от методологии.

Скрам – это не директивный процесс. Если о нем и говорится, как о “процессе”, то как о процессе-служителе. Скрам помогает всем вовлеченным игрокам найти то , что наилучшим образом подходит для них и их рабочих процессов. Игроки находят объем работы, необходимой для заполнения разрыва между полученным промежуточным результатом и желаемым конечным результатом.

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

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

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

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

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

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

Жизненный цикл проекта. Ключевое различие между методологиями 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.

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