Agile методология управления проектами: Эпики | Atlassian — Независимое театральное объединение "Зрительские симпатии"

Содержание

Эпики | Atlassian

Краткое описание: в Agile эпик — это объем работы, который можно разбить на несколько отдельных заданий (так называемых «пользовательских историй») в зависимости от потребностей или запросов клиентов или конечных пользователей. Эпики играют важную роль в успехе команд Agile и DevOps.

В Agile и DevOps эпик предназначен для организации заданий. Это определенный объем работы, который разделяется на отдельные задания (так называемые «истории», или «пользовательские истории») в зависимости от потребностей или запросов клиентов или конечных пользователей.

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

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

Что такое эпик в agile?

Эпик — это большой объем работы, который можно разбить на несколько историй поменьше (в Jira они называются «задачами»). Часто эпики объединяют несколько команд, работающих над несколькими проектами; более того, часто их можно отслеживать на нескольких досках.

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

Пример эпика в agile

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

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

Команда разработчиков ПО, ответственная за процесс приобретения билетов на корабль, старт которого запланирован на март 2050 года, может организовать свой эпик следующим образом:

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

В это же время команды разработки ракетных двигателей могут внести в эпик следующие истории:

Эпик: запуск ракеты, март 2050 г.
История: поддерживать давление в топливных баках на уровне > 250 млн⁻¹ фунтов на кв. дюйм во время запуска.	История: сократить общий расход топлива на 1 %.	История: нанять нового специалиста по ракетным двигателям взамен Гэри. #garygate2050

Место эпиков в законченной agile-программе

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

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

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

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

Создание эпика в agile

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

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

Узнайте, как эпики реализованы в Jira.

Деление эпика на составляющие в agile

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

Роль или тип пользователя. Создайте уникальную историю для каждого типа пользователя. «Ускоренный вход в систему для новых посетителей», «ускоренный вход в систему для существующих клиентов» и т. д.
Упорядоченные этапы. Разделите процесс на этапы и создайте историю для каждого.
Культура. Ориентируясь на то, как заведено в команде, решите, будет ли история быстро выполнимой задачей или проектом на неделю.
Время. Если в команде не принято иначе, отводите на выполнение истории не больше одного спринта.

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

Количественная оценка эпиков в agile

Чтобы наглядно представить эпики, используются диаграммы Burndown. С их помощью команды находят мотивацию, а заинтересованные лица из руководящего звена — информацию. То, насколько хорошо составлена диаграмма Burndown для эпика, показывает, насколько точно организация следует принципам agile.

На диаграмме Burndown для эпика показан объем работы, фактически выполненный в ходе спринта или эпика, и плановый объем работы. Горизонтальная ось X диаграммы отражает время, а по вертикальной оси Y располагаются истории или задачи.

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

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

Узнайте, как настраивать диаграммы Burndown в Jira Software.

Оптимизируйте эпики с помощью автоматизации

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

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

Эти и сотни других правил автоматизации можно найти в библиотеке шаблонов Jira Automation.

Перейти в библиотеку

Общие сведения об эпиках в agile

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

Max Rehkopf

Я считал себя «хаотичным раздолбаем», но методики и принципы agile помогли навести порядок в моей повседневной жизни. Для меня истинная радость — делиться этими знаниями с другими людьми, публикуя многочисленные статьи, участвуя в беседах и распространяя видеоматериалы, которые я создаю для Atlassian.

Пользовательские истории | Примеры и шаблон

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

Есть тенденция считать, что пользовательские истории — это, говоря проще, функциональные требования к программному обеспечению. Но это не так.

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

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

Что такое пользовательские истории в agile?

Пользовательская история — это наименьшая единица работы в методике agile. Это конечная цель, а не возможность, сформулированная с точки зрения пользователя ПО.

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

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

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

Пользовательские истории изящно вписываются в методики Agile, такие как Scrum и Kanban. В Scrum пользовательские истории добавляют в спринты и отслеживают на диаграммах Burndown в течение спринта. Команды, работающие по методике Kanban, добавляют пользовательские истории в бэклог и пропускают их через рабочий процесс. Именно так Scrum-команды совершенствуют навыки оценки и планирования спринта, повышая точность прогнозов и свою гибкость. С помощью историй команды Kanban начинают более профессионально распоряжаться незавершенной работой (WIP) и могут в дальнейшем совершенствовать рабочие процессы.

Пользовательские истории также составляют значительные элементы методик Agile, такие как эпики и инициативы. Эпики — это большие рабочие задачи, которые делятся на несколько историй. Группа эпиков образует инициативу. Благодаря этим крупным структурам каждодневные усилия команды разработчиков (в работе над историями) ведут к достижению целей организации, выраженных в эпиках и инициативах.

Подробнее об эпиках и инициативах

Зачем нужны пользовательские истории?

Для команд разработчиков, которым agile в новинку, пользовательские истории кажутся лишним шагом. Почему бы просто не разбить большой проект (эпик) на несколько шагов, а потом разбираться с ними? Но с историями команда получает необходимый контекст и связь между задачами и ценностью, которая возникает в результате выполнения этих задач.

Пользовательские истории обладают несколькими важными преимуществами.

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

Узнайте, как пользовательские истории реализованы в Jira Software

Работа с пользовательскими историями

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

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

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

Как написать пользовательскую историю

При написании пользовательских историй держите в уме следующее.

Критерии готовности работы. Как правило, история считается «выполненной», когда пользователь может сделать то, что было запрошено. Тем не менее, четко сформулируйте цель.
Краткое описание задач и подзадач. Определите, какие конкретно этапы нужно пройти и кто несет ответственность за каждый из них.
Типы клиентов. Для кого? При наличии нескольких типов конечных пользователей желательно написать несколько историй.
Этапы как часть цепи. Напишите историю для каждого этапа, составляющего более масштабный процесс.
Обратная связь. Поддерживайте связь с пользователями, чтобы увидеть проблему или потребность их глазами. Зачем гадать, если можно услышать историю из уст самих клиентов?
Время. Время — очень щекотливая тема. Многие команды разработчиков боятся поднимать вопросы о времени совсем, полагаясь на свои оценки. Истории должны выполняться за один спринт, поэтому истории, которые могут занимать недели или месяцы, следует разбивать на несколько историй поменьше. Как вариант, считайте их самостоятельными эпиками.

Сформулировав пользовательские истории, позаботьтесь о том, чтобы они были доступны всей команде.

Шаблон и примеры пользовательских историй

Пользовательские истории часто представлены в виде простого предложения следующего вида:

«Как [тип клиента], [хочу то-то], [чтобы делать что-то]».

Давайте разберем эту формулировку.

«Как [тип клиента]»: для кого мы выполняем эту работу? Нам не так важна должность, сколько личность, что стоит за типом клиента. Вот Макс, например. Нашей команде нужно иметь единое представление о том, что Макс за человек. К счастью, мы опросили множество Максов. Мы понимаем, как работает этот человек, как он думает и что он чувствует. Мы испытываем к Максу эмпатию.
«Хочу то-то»: в этой части заключается намерение пользователя — не возможностей, которыми он пользуется. Чего пользователь хочет добиться? В этом утверждении не должно быть ни слова о способах реализации. Если вы описываете какую-либо деталь пользовательского интерфейса, игнорируя цель пользователя, вы упускаете суть.
«Чтобы делать что-то»: какое место отведено этому сиюминутному желанию клиента в более широком масштабе? Какую пользу в целом хочет извлечь клиент? Какую крупную проблему нужно решить?

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

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

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

Начало работы с пользовательскими историями в agile

В пользовательских историях раскрываются суть и цели повседневной работы участников команды разработчиков. Зачастую они написаны в форме «тип клиента + потребность + цель». Чтобы процесс работал как часы, важно понимать роль историй: именно в них объясняется, что должна сделать команда и почему она должна это сделать.

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

Max Rehkopf

Что делает проект успешным

Добавлено в ваш журнал CPD

Просмотрите или отредактируйте это действие в журнале CPD.

Перейти к моей цене за день Только участники APM имеют доступ к функциям CPD Становиться участником Уже добавлено в журнал CPD

Просмотрите или отредактируйте это действие в журнале CPD.

Перейти к моей цене за день Добавлено в ваш сохраненный контент Перейти к моему сохраненному контенту

PM Условия успеха проекта — это серия независимых исследований, направленных на выявление основных факторов, которые приводят к успешной реализации проектов, программ и портфелей.

Отчет «Динамические условия успеха проекта 2021» основан на

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

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

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

Скачать отчет за 2021 год

Кто является целевой аудиторией?

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

Почему это важно?

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

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

Кто принимал участие в исследовании?

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

Каковы основные проблемы?

Этот отчет отделен от «Условий успеха проекта 2015» на том основании, что в исследовании изучались в основном факторы, не связанные с проектом, которые, тем не менее, могут повлиять на успех проекта.

Это исследование проводилось при беспрецедентных обстоятельствах в условиях пандемии Covid-19. Все аспекты исследования проходили полностью виртуально; это послужило формированию ответов от сообщества управления проектом.

Где я могу прочитать больше?

Загрузите отчет «Динамические условия успеха проекта».

Что ты открыл?

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

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

Девять найденных динамических состояний:

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

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

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

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

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

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

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

Это помогает организациям реагировать на меняющиеся требования и ситуации.

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

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

Скачать отчет за 2021 год

Условия успеха проекта

В ходе исследования было выявлено 12 факторов успеха, также известных как схема успеха APM. Из этого было обнаружено, что пять факторов имеют «самую сильную и наиболее последовательную связь» с традиционными показателями успеха проекта: время, стоимость и качество. Это были:

1. Планирование и анализ проекта

2. Цели и задачи

3. Эффективное управление

4. Компетентные проектные группы

5. Стремление к успеху

Скачать отчет за 2015 г.

Кто является целевой аудиторией?

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