epic что это значит в проекте

Тема, эпик, история, задача: терминология метода story mapping

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

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

Истории

(aka задачи из продуктового бэклога, единицы работы)

История — это отдельная функция или требование, которое выдвигает бизнес. Иногда историю можно пустить в продакшн за один спринт. История должна быть составлена по принципу INVEST — расшифровка в предыдущем посте:

Хорошая пользовательская история соответствовать следующим критериям:

I — независимая (independent),

N — обсуждаемая (negotiable),

V — несет ценность для бизнеса (business value),

E — достаточно информации для оценки(estimate),

S — компактный размер (size),

T — трестируемая (testable)

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

Истории часто пишут в конкретном формате:

Хотя этот формат уже прижился и стал нормой, это не единственный возможный подход. Одна из команд подчеркнула, что они выносят ценностную часть (“чтобы [….]”) вперед. Я думаю, это толковая идея, потому что мы всегда должны руководствоваться четкой бизнес-причиной: поэтому, мне кажется, разумно начинать историю с ценности.

Интересуетесь свежими статьями по дизайну? Вступайте в группу на Facebook.

Источник

Мини-справочник и руководство по Scrum

Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.

Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.

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

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

Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса

— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.

Мини-справочник Scrum

Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.

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

Основные обязанности и ответственность Product Owner при управлении Product Backlog:

Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.

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

Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Размер команды составляет от 5 до 9 человек (5 оптимально). Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся. Это как некий единый организм, состоящий из отдельных элементов.

Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).

User – пользователь продукта.

Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.

Epic (эпик) – одна из нескольких глобальных функций продукта. В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика.

User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.

Task (таск) – задача, фрагмент, который необходимо выполнить для реализации цели проекта.

Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.

Sprint Goal (спринт гоол) – цель спринта.

Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно выполнить за спринт.

Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие.

Story Points (стори поинтc) – единица оценки сложности выполнения задачи. Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. На проекте из одного-двух спринтов использовать Story Points нет смысла, если только не для получения практики.

Daily Scrum Meeting (дэйли скрам митин) – ежедневное собрание не более 15 минут, проводимое в одно и то же время. Участвует скрам тим, наблюдать могут все. Проводит скрам-мастер. Цель митинга – оперативный обмен информацией, все в курсе происходящего, нет коммуникационных разрывов. Задаются три вопроса: что сделал вчера? что будешь делать сегодня? какие препятствия встают на пути к цели?

Sprint Review (спринт ревью) – обзор спринта, участвуют все, встреча открытая. Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.

Sprint Retrospective Meeting (спринт рэтроспэктив митин) – ретроспектива, участвует скрам тим. Собрание за «круглым» столом. Обсуждаются вопросы: что прошло хорошо, а что плохо? что можно было сделать лучше? Главное, никого не обличать! Рассматривается рабочий процесс. Цель – совершенствование рабочего процесса, стать «супер» командой.

Definition of Done (DoD) (дэфэнишин оф дан) – критерий, определяющий степень готовности задачи. Применяется в тех случаях когда окончательно невозможно проверить готовность задачи, например, если элемент функционала находится в другой скрам команде или компании. Описание DoD начинается со строчки «done = », например, done = функционал реализован в тестовой среде, требуется выгрузка и проверка в основной среде.

Velocity (велосити) – скорость команды; для аналитики строится график Velocity, где по оси Х кол-во спринтов, а по оси Y Story Points.На основе этих показателей выстраиваются средние Velocity и Story Points.

Burndown Chart (бёрдаун чарт) – диаграмма сгорания задач. Направление графика сверху вниз. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Первому дню спринта соответствует максимальное кол-во Story Points.

Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика снизу вверх. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Последнему дню спринта соответствует максимальное кол-во Story Points.

Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Остановку инициирует Product Owner. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination. Затем Спринт запускается вновь.

Руководство Scrum

Product Backlog
Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.

Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.

123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.

User Story

Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?

Формируется Sprint. Sprint Planning Meeting. Scrum Poker

Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.

Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:

Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.

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

Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.

Sprint Retrospective Meeting. Ретроспектива.

Проводится в последний день спринта.

Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.

Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?

Источник

Эпики

Agile эпики: определение, примеры и шаблоны

Что такое Agile эпик?

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

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

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

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

Эпик: запуск в марте 2050 года

История: Обновите диапазон дат, чтобы включить даты запуска в марте 2050 года.

История: Уменьшите время загрузки для запрошенных списков рейсов до 250 PPM при запуске

История: Уменьшите общее потребление топлива на 1%

История: Наймите нового инженера по продвижению вместо Гари. # garygate2050

Понимание эпиков в рамках полной гибкой программы

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

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

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

Создание Agile эпика

Разбейте agile эпик

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

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

Измерение Agile эпиков

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

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

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

Узнайте, как настраивать диаграммы сгорания в программном обеспечении Jira

Понимание Agile эпиков

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

Источник

Типы задач в Jira — что такое Epic, Story, Task

В Jira существует 5 базовых типов задач:

Если вы хотите узнать подробнее о типах задач в Jira — вы в правильном месте.

В этой статье мы разберемся с определениями issue, эпик (epic), история (story), задача (task), под-задача (sub-task) и баг (bug), посмотрим зачем они нужны и как они связаны.

Что такое Issue в Jira?

Все задачи, созданные в Jira, называются issue (или “проблема”).

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

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

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

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

Изначально в Jira есть 5 базовых типов проблем, но, при необходимости, их можно дополнять / изменять / удалять.

Что такое Эпик (Epic) в Jira?

Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов.

Для примера можем рассмотреть эпик “Разработать блог для сайта N”.

Под “разработать” может подразумеваться:

Как мы видим, объем работ — большой. Количество людей, которые будут принимать участие в работе — большое. Время на реализацию — явно не 2 часа 🙂

Все характеристики эпика соблюдены)

Основное предназначение эпика — организация работ.

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

Из-за своего объема и абстрактности эпики всегда разбиваются на части, которые описывают более конкретные “шаги” для решения проблемы.

Эти части называются история и задача.

Если вы хотите разобраться в эпиках более детально:

Что такое История (Story / User Story) в Jira?

История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт.

Она описывает реализуемую работу (или функционал) с точки зрения конечного пользователя и, обычно, имеет заголовок вида:

Как [тип клиента], [хочу/могу то-то], [чтобы делать что-то]

Если продолжить рассмотрение примера эпика Разработать блог для сайта “N”, можно выделить такие истории:

Теперь части работы стали меньше и они — более понятные. Их можно смело отдавать командам на оценку!

Истории оцениваются командой в story points.

Также в них обязательно должны быть критерии приемки (acceptance criteria), благодаря которым команда сможет понять, что работа сделана до конца.

Написание хороших историй — это целая наука!

Если вы хотите разобраться в историях более детально:

Задача (Task) в Jira

Задача (task) — техническая задача, которую делает один из членов команды.

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

Продолжаем пример с блогом)

Задачи, которые помогут в реализации:

Как вы видите, задачи — это очень конкретные технические моменты, которые нельзя “преобразовать” в истории, так как ими занимается один человек.

Но, без таких задач — блог не получится завершить 🙂

Некоторые компании / команды оценивают задачи в часах

Как показывает моя практика — это пустая трата времени, сил и ожиданий.

Практически всегда оценка не совпадет с реальным временем выполнения, причем не важно, оценку делает Junior или Senior разработчик (у Senior отклонение меньше, но оно все равно есть)

Так, задачу оцененную в “два часа от силы” могут делать неделю, а задачу оцененную в “5 часов” — 30 минут 🙂

Вместо оценки задачи в часах — лучше просить разбивать задачу на под-задачи (о них — ниже)

Большое количество проблем с типом “задача” в беклоге может указывать на присутствие микро-менеджмента ☠️

В такой ситуации команда не участвует в проработке лучших вариантов решения реальных проблем!

Анализ и подготовка задач происходит “наверху”, задачи опускаются “вниз”, и чаще всего (ввиду не понимания корня проблемы) впоследствии ничего не решают!

Под-задача (Sub-task) в Jira

Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды.

Разбиение задач на под-задачи позволяет проводить более точное оценивание трудозатрат, потому что нам проще оценивать работу по частям 🙂

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

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

Например, для истории “Как клиент, я могу связаться с суппортом компании, отправив заявку на странице /contact-us, чтобы узнать больше о компании” под-задачи могут быть такими:

Баг (Bug) в Jira

Задачи типа Баг (Bug) 🐛 фиксируют ошибки, которые нужно проанализировать и может быть исправить️️️️ ❗️❗️.

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

Внедрение Zero Bug Policy помогает избавиться от этой проблемы раз и на всегда.

Создание отличных баг-репортов являеться ключевым навыком любого тестировщика.

У нас есть отдельная статья о багах и баг-репортах в которой есть пример баг-репорта в Jira и много чего интересного 🙂

Выводы

Приведенные типы задач лишь базовые!

Jira — очень гибкий инструмент! Она позволяет добавить новые типы задач, которые нужны именно Вам!

Существуют команды, которые собирают эпики в большие “мега” проекты. Или те, кто создают требования как тип задач, для более удобной связи требований — тестов — задач/багов.

Главное — не бояться разбираться в чем-то новом и постоянно экспериментировать! 🥼⚗️🧪

Удачи в Ваших проектах 🥳🤩

Что такое Epic в Jira?

Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов

Что такое Story в Jira?

История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт

Что такое Task в Jira?

Задача (task) — техническая задача, которую делает один из членов команды

Что такое Sub-task в Jira?

Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды

Что такое Bug в Jira?

Баг (bug) — задача, которая описывает ошибку в системе

Источник

Эпики agile. Определение, примеры и шаблоны

Разделите большой объем работы на небольшие истории с помощью эпиков agile.

Просмотр тем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подпишитесь и получайте больше статей

Thanks for signing up!

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

С помощью этих пошаговых инструкций вы научитесь создавать эпики в Jira Software и работать с ними

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

Пользовательские истории — это требования к системе, которые зачастую выражены в виде «личность + потребность + назначение». Узнайте, как истории выступают в качестве ориентиров для agile-проектов и как начать работу с ними.

Источник