что такое спринт в jira
Узнайте, как использовать спринты в Jira Software
Руководство по работе со спринтами в Jira Software
Просмотр тем
Учебное руководство по спринтам Jira
Краткое описание: спринт — это фиксированный отрезок времени в цикле непрерывной разработки, за который команды выполняют работу из бэклога продукта. К концу спринта команда, как правило, создает и внедряет работающую версию продукта, знаменующую очередной этап его развития. Благодаря Jira Software бэклог оказывается в центре вашего совещания по планированию спринта, и вы можете оценивать истории, корректировать объем работ в рамках спринта, отслеживать скорость и расставлять приоритеты между задачами в режиме реального времени.
Из этого учебного руководства вы узнаете, как можно работать со спринтами в Jira Software. В нем не рассматриваются командные ритуалы, которые вы проводите вне Jira Software, такие как собрания по планированию спринта, ретроспективы и ежедневные стендапы. О них можно прочитать в статье «Применение Scrum с помощью Jira Software».
10 минут на прочтение. Прохождение учебного курса занимает не менее 2 недель
Вы создали проект Scrum в Jira Software.
Вы добавили в бэклог проекта задачи.
Спринт — это фиксированный отрезок времени, за который команды выполняют работу из бэклога продукта. Спринты обычно продолжаются одну, две или четыре недели. К концу спринта команда, как правило, создает и внедряет определенное изменение работающего продукта.
Шаг 1. Создание спринта
Нажмите кнопку Create Sprint (Создать спринт) в верхней части бэклога.
Если вы хотите спланировать работу на несколько недель вперед, можно создать несколько спринтов.
Шаг 2. Перенос историй из бэклога в спринт
Когда вы создали спринт, нужно наполнить его задачами. Но прежде обсудите со своей командой, какую работу вы хотели бы взять под свою ответственность. Пусть каждому участнику команды достанется достаточный объем работы.
Создавая спринт впервые, вы можете не знать, сколько задач добавлять в него. Это нормально, ведь понять это можно со временем. Прежде чем добавлять задачи в спринт, рекомендуется всей командой оценить их сложность. По завершении спринта вы увидите, сколько усилий команда смогла уделить спринту.
Со временем вы начнете понимать возможности команды, и это поможет в планировании будущих спринтов. Подробнее об оценке сложности см. в руководстве «Применение Scrum с помощью Jira Software».
Чтобы добавить истории в спринты, выполните следующие действия.
Перейдите в бэклог.
Перетащите задачи из бэклога в спринт.
Также добавить задачу в спринт можно, отредактировав задачу и изменив поле Sprint (Спринт).
Шаг 3. Начало спринта
Когда задачи добавлены в спринт и команда готова приступить к работе, нужно начать спринт.
Спринт можно начать только при следующих условиях.
У вас нет другого начатого спринта. Если вам нужно несколько активных спринтов одновременно, воспользуйтесь настройкой Parallel Sprints (Параллельные спринты).
Спринт находится в верхней строке бэклога. Если вы хотите начать запланированный спринт, который расположен на позиции ниже, измените порядок спринтов, чтобы вывести его в первую строку.
Чтобы начать спринт, выполните следующие действия.
Перейдите в Бэклог проекта Scrum.
Выберите спринт, который нужно начать, и нажмите Start Sprint (Начать спринт).
При необходимости измените название спринта в поле Sprint Name (Название спринта) и добавьте цель спринта в поле Sprint Goal (Цель спринта). В полях Start Date (Дата начала) и End Date (Дата завершения) выберите дату начала и дату завершения спринта соответственно.
Если вы не можете сказать точно, сколько должны продолжаться спринты, рекомендуем выбрать две недели. Это достаточно большой промежуток, чтобы что-то закончить, и при этом достаточно краткий промежуток, позволяющий команде регулярно получать отзывы о работе.
Шаг 4. Отслеживание прогресса команды
Во время спринта имеет смысл отслеживать прогресс команды. Для этого можно, например, обратиться к разделу Sprint Report (Отчет по спринту).
Во время спринтов команды совместными усилиями выполняют истории, которые они приняли на себя в начале спринта. Как правило, для этого нужно много работать в команде, поэтому рекомендуется каждый день проводить стендапы, чтобы каждый участник команды понимал, чем занимаются остальные.
Шаг 5. Завершение спринта
Чтобы завершить спринт, выполните следующие действия.
При необходимости выберите спринт, который нужно завершить, из раскрывающегося списка со спринтами.
Если в разделе Active sprints (Активные спринты) доски значится несколько спринтов, то нужно выбрать один из спринтов, чтобы появилась кнопка Complete Sprint (Завершить спринт).
Нажмите кнопку Complete Sprint. Все завершенные задачи исчезнут из раздела Active sprints (Активные спринты).
При наличии в спринте незавершенных задач будет предложено перенести их:
в один из будущих спринтов или
Пометьте эпик как завершенный, когда вся работа, запланированная для него, выполнена. Чтобы упростить задачу, рекомендуется во время создания эпика определить четкие критерии его готовности. Чтобы пометить эпик как завершенный, выполнять все истории, связанные с ним, необязательно.
Оптимизируйте спринты с помощью автоматизации
Когда вы поймете, как работают спринты, вы сможете оптимизировать процессы, используя автоматизацию. Вот три правила автоматизации, которые часто используются в спринтах Jira.
Эти и сотни других правил автоматизации можно найти в библиотеке шаблонов Jira Automation.
Хотите узнать больше?
Подробнее об использовании методики Scrum в команде см. в нашем руководстве «Применение Scrum с помощью Jira Software».
Подробнее о работе со спринтами в Jira Software см. в нашей документации по спринтам.
Изучение того как использовать спринты в программном обеспечении JIRA
Узнайте, как использовать спринты в Jira Software
Руководство по работе со спринтами в Jira Software
Учебник по спринтам в Jira
Время:
10 минут чтения. Завершить в течение 2 недель или более
Аудитория:
Вы новичок в agile разработке программного обеспечения или Jira Software
У вас есть разрешение на управление проектами ( Administer Projects permission) для всех проектов на вашей доске Scrum. См. Управление разрешениями проекта (Managing project permissions) для получения дополнительной информации.
Необходимое условие (Предпосылки):
Попробуйте бесплатно (ссылка)
ЧТО ТАКОЕ СПРИНТ?
Шаг 1: Создать спринт
Обратите внимание, что вы можете создать более одного спринта, если хотите запланировать работу за несколько недель.
Шаг 2: Наполните свой спринт историями из списка необходимых требований (backlog).
После того как вы создали свой спринт, вам нужно будет заполнить его задачами. Прежде чем сделать это, убедитесь, что вы сели со своей командой и обсудили, какую работу вы хотели бы выполнить. Убедитесь, что вы добавили достаточно работы для всех в команде.
СКОЛЬКО ЗАДАЧ ДОЛЖНЫ МЫ ДОБАВИТЬ?
Когда спринт закончится, вы увидите, сколько усилий команда смогла посвятить спринту.
Со временем вы сможете почувствовать работоспособность команды, что поможет вам соответствующим образом планировать будущие спринты. Подробнее об оценке читайте в нашем руководстве «Как делать scrum с Jira Software».
Чтобы добавить истории в свои спринты
Обратите внимание, что вы также можете добавить задачу в свой спринт, отредактировав задачу и обновив поле Sprint.
Шаг 3: Начните спринт
После того, как вы добавили задачи в свой спринт, и команда готова к работе, вам нужно будет начать спринт.
Обратите внимание, вы можете начать спринт, только если:
Чтобы начать спринт
НАСКОЛЬКО ДЛИТЕЛЬНЫМИ ДОЛЖНЫ БЫТЬ НАШИ СПРИНТЫ?
Шаг 4: Отслеживайте прогресс работы вашей команды
ЧТО МЫ ДОЛЖНЫ ДЕЛАТЬ ВО ВРЕМЯ НАШИХ СПРИНТОВ?
Во время спринтов команды работают вместе, чтобы завершить истории, которые они посвятили в начале спринта. Как правило, для этого требуется много совместной работы (сотрудничества), поэтому мы рекомендуем проводить ежедневные групповые встречи-летучки, чтобы вы знали, над чем работают все в команде.
Шаг 5: Закройте спринт
Чтобы закрыть спринт
КОГДА Я ДОЛЖЕН ОТМЕТИТЬ ЭПИК, КАК СДЕЛАННЫЙ?
Пометьте свой эпик как завершенный, когда вся работа над эпиком закончилась. Чтобы сделать это проще, мы рекомендуем подойти к этому с четким определением выполненного (сделанного) для вашего эпика. Любые истории, связанные с эпиком, не обязательно должны быть завершены, чтобы пометить его как завершенный.
Хотите узнать больше?
Если вы хотите узнать больше о внедрении scrum для своей команды, обратитесь к нашему руководству «Как сделать scrum с помощью программного обеспечения Jira».
Более подробную информацию о работе со спринтами в Jira Software можно найти в нашей документации по спринтам.
Есть вопросы? Спросите Сообщество Atlassian.
Механизмы Jira, которые позволяют эффективно структурировать работу
Любая команда разработчиков при уходе от модели «waterfall» или любого другого традиционного стиля управления проектами сталкивается с одним и тем же вопросом «как мне структурировать свою работу?». К счастью метод разработки по методологии Agile использует четыре четких механизма для того, чтобы структурировать любой проект:
Работая с такими механизмами команды разработчиков могут организовать свою работу разбив ее на небольшие части, достаточные для того, чтобы отдавать предпочтение обратной связи с клиентом и отойти от привычного стиля управления проектами.
Способность изменять и адаптировать план разработки, на основании текущей информации является признаком гибкости. Мы определили 4 механизма, которые помогут сделать проект гибким, и покажем, как они применяются в аджайл на практике. Но сначала поговорим о разнице самих механизмов.
Epic vs Story
Эпики – наиболее крупные объекты, представляющие собой множества задач. Эпики могут охватывать несколько спринтов и версий. В отличие от эпиков версии исчисляются релизами программного обеспечения, и при необходимости могут включать в себя несколько эпиков. Эпики помогают команде создавать иерархию и структуру, в то время как истории – отслеживать конкретные детали задачи, и могут быть разбиты на подзадачи.
Эпики обычно сводятся к более стратегическим целям или инициативам. Эти инициативы обычно разрабатываются в процессе долгосрочного планирования и формирования стратегии развития.
Что такое эпик?
Эпик — это большой объем работы, который можно разбить на несколько небольших задач. Например, исследование производительности релиза. Эпик может охватывать более одного проекта, если несколько проектов включены в доску, к которой принадлежит эпик.
В зависимости от того какую структуру agile Вы используете (scrum, kanban или Ваш собственный выбор) эпики могут использоваться по разному. Для канбана эпики могут использоваться в качестве направляющих для сегментации различных потоков работ. Если вы используете скрум, эпики могут помочь обозначить работу в Ваших спринтах, как в примере ниже.
Миссия на Марс — это эпик в этом спринте. TIS 1, TIS 2 и т.д.. — все задачи в спринте (TIS Sprint 1). Вы должны заметить, что в спринте есть как задачи (истории) так и эпики.
Оценка эпиков.
Диаграммы Burndown также используются для визуализации эпиков, которые поддерживают мотивацию команды и информируют о продвижении работ все заинтересованные стороны.
Такая диаграмма наглядно показывает характер развития agile. На ней можно наблюдать как идет процесс работы команды, а также когда заказчик добавил или удалил задачи. Такое прозрачное отображение данных позволяет любому участнику проекта оценить прогнозы развития, упрощает диалог с заказчиком и доверительные отношения на всех уровнях.
Что такое задача?
Задача (история или рассказ пользователя)– наименьшая единица работы в agile структуре. Это требование к программному обеспечению, которое выражается в нескольких коротких предложениях, в идеале использующих нетехнический язык.
Цель пользовательской истории — вернуть конкретное состояние заказчику. Обратите внимание, что «заказчик» не обязательно должны быть внешними конечными пользователями в традиционном смысле, они также могут быть внутренними заказчиками или коллегами в Вашей компании, которые зависят от Вашей команды.
Истории пользователей (задачи) — это несколько предложений на простом языке, которые описывают желаемый результат. Они не вникают в подробные требования.
Пример задачи – рассказа пользователя.
Истории пользователей нарисованы владельцем продукта, а затем команда разработчиков коллективно решает более подробные требования. Задачи — это гранулированные работы, которые помогают определить элементы реализации и предстоящего спринта.
Используя тот же пример, что и выше, задачи в этом спринте имеют оценку, приоритет, правопреемник, эпичность и описание, поэтому каждый может получить быстрый обзор выполняемой работы.
Что такое версия?
Версии — это фактические выпуски программного обеспечения для потребителя. Помните, что в конце каждого спринта команда должна иметь возможность отправлять программное обеспечение заказчику. Версии — это контролируемые изменения, которые владелец продукта действительно получает.
Версии часто развиваются по множеству спринтов, как эпики. Эпик также не должен полностью «дублировать» версию. Продуманные владельцы продуктов могут растягивать эпик на несколько версий. Представляя эпик в нескольких версиях, владелец продукта может узнать, как рынок реагирует на этот эпик и принимает решения о дальнейшем развитии продукта, а не делает один гигантский релиз.
Пример использования версий
Владелец продукта может структурировать стратегию выпуска версий ПО следующим образом:
Область изменения версии также является естественной частью развития проекта по методу agile. Графики Burndown наглядно показывают, как версия эволюционирует с течением времени. Изменения в версии должны обсуждаться со всей командой, чтобы держать всех в курсе дела.
Что такое спринт?
Спринт — это короткий период, в течение которого команда разработчиков реализует и обеспечивает дискретное и потенциально увеличиваемое приращение приложения, например. рабочая версия. Если Вы еще не имели практики работы со спринтами, мы рекомендуем использовать фиксированную двухнедельную продолжительность для каждого спринта. Этого промежутка времени достаточно для того, чтобы добиться чего-то, но не так много, чтобы испытывать нехватку отзывов потребителей.
Спринты являются частью структуры scrum. Команды kanban, напротив, работают над следующей задачей по мере возможности ее решения. В этом случае прогнозирование не требуется.
Scrum команды фиксируют набор задач в течение фиксированного периода времени. Теоретически, спринты могут длиться одну, две или четыре недели. Длина спринта определяется командой, которая работает над проектом. После определения частоты спринтов команда постоянно работает в этом ритме. Спринты с фиксированной длиной увеличивают точность оценки сроков работы и позволяют прогнозировать будущую скорость для команды в аджайл проекте. Делать выводы можно, как только будут получены данные из нескольких завершенных спринтов.
Пример спринта Вы уже видели на скриншотах выше. TIS Sprint 1 – это множество задач.
Несколько вещей, которые вы должны знать о спринте:
Отличным инструментом для любой команды scrum являются графики burndown. Они четко отслеживают прогресс на протяжении всего спринта с «оставшейся работой» по оси Y и «временем» на оси X. Диаграммы и графики Burndown являются мощным мотиватором для команды, и фокусируют каждого ее члена на работе над спринтом.
Масштабирование.
У более крупных организаций часто есть несколько команд agile, работающих над общим проектом, а планирование портфолио — ключевая часть работы agile в масштабе. Эпики и версии закладывают основу для надежного управления портфолио на уровне команды. Управление портфолио охватывает программы отслеживания в нескольких командах, сохраняя при этом тот же уровень гибкости на более высоких уровнях организации. Узнайте больше о гибкости в масштабе большой организации в разделе agile portfolio.
Наша компания предоставляет различные услуги по внедрению, оптимизации, переносу, обучению работы с продуктами jira, обращайтесь [email protected]
5 шагов к Agile с инструментами JIRA
Екатерина Базылева, менеджер a1qa, сертифицированный Scrum-мастер и SAFe Agilist, рассказывает об инструментах JIRA, которые позволяют планировать Agile-проекты, управлять ими и отслеживать эффективность работы команды.
Как инструменты JIRA помогают выполнить работу по гибким методологиям?
Под «работой» подразумевается любая рабочая задача: написание тестовой документации, составление плана по тестированию, проведение регрессионного теста или подготовка обучающего мероприятия в центре компетенции.
В первую очередь эта статья будет полезна тем, кто:
Начнём. У каждого менеджера проекта есть to-do list из рабочих задач и, возможно, даже не один. У кого-то список состоит из множества мелких задач одного проекта, у кого-то включает несколько проектов.
Нередко выполнение задач зависает, при этом к ним постоянно добавляются новые. Мы периодически перебираем этот список и верим, что вот завтра, хотя нет, лучше в понедельник начнём разбирать его. Знакомо?
Продуктивно решать все возникающие задачи – это один из постулатов работы по гибким методологиям. Однако не стоит ждать, когда к вам придёт проект, который должен быть выполнен по Agile. Возьмите свой текущий проект и сами реализуйте его с соблюдением Agile-принципов.
Для этого достаточно выполнить 5 шагов.
ШАГ 1 — Создание и настройка Agile Board
Создайте борд (Jira-Agile-Getting Started), на котором вы будете отслеживать ход выполнения задач и управлять ими в бэклоге. Борд можно сделать как для задач конкретного проекта, так и для выборки, в которую будут входить несколько проектов.
Вот так выглядит Agile Board по умолчанию:
Теперь настроим его под себя.
Настраиваем колонки (Columns). Они будут отражать жизненный цикл задач. При этом можно настроить произвольное количество колонок и дать им свои названия.
На борд можно добавить дорожки (Swimlanes), которые помогут структурировать задачи. Среди доступных вариантов можно выбрать дорожки по группе задач (Epics), по исполнителю (Assignee) или по задачам (Stories). Последний вариант особенно удобен, если активно используются подзадачи. Также дорожки можно настроить по собственным фильтрам (или вовсе обойтись без них).
Для того чтобы скрыть или, наоборот, показать специфические задачи, можно добавить быстрые фильтры (Quick Filters) и, например, отфильтровать только задачи на обновление тестовой документации или задачи конкретного QA-инженера. Фильтры задаются через JQL-запросы.
В конце нужно определиться, в каких единицах будут оцениваться задачи. Самые распространённые варианты – это стори-поинты (Story Points) и часы, но могут быть и другие единицы, предлагаемые JIRA.
ШАГ 2 — Упорядочение списка задач в бэклоге
После того как Agile Board создан в режиме «Планирование» или в бэклоге (это зависит от версии JIRA), нам становится доступен удобный интерфейс для превращения хаотичного списка задач в упорядоченный бэклог.
Теперь все задачи находятся в одном месте, их легко оценивать и располагать по приоритету, передвигая вверх и вниз.
Итак, мы создали и настроили Agile Board в JIRA и составили бэклог с задачами. Что же дальше?
ШАГ 3 — Планирование спринтов
Когда список задач большой, лучшее, что можно сделать, – выбрать несколько самых приоритетных и выполнить их. Давайте запланируем первый спринт.
Capacity – объем работы, который команда может сделать в течение спринта. Эта цифра учитывает доступность людей, а также тот факт, что люди будут работать над задачами спринта не всё своё время. Часть времени будет уходить на коммуникацию внутри команды и другие активности.
Например:
Размер команды – 2 специалиста, занятых полный рабочий день.
Продолжительность спринта – 2 недели.
Общее количество рабочих часов – 160. При этом мы знаем, что одному из инженеров нужно пройти тренинг по веб-сервисам (16 часов) и на коммуникацию по задачам у команды уходит 20% рабочего времени.
Итого, capacity на спринтовые задачи получится (160-16)*0,8=115,2 ч.
ШАГ 4 — Выполнение спринта
Настало время выполнить набранные задачи, т. е. завершить спринт.
На шаге 1 мы создавали и настраивали Agile Board. Теперь он поможет нам проследить, на каком этапе находится каждая из задач, кто и какую задачу выполняет.
Можно сразу назначить каждой задаче исполнителя. Если ваша команда достаточно самоорганизованная, то ребята могут сами брать себе задачу из списка свободных. Как только пользователь передвигает задачу в In Progress, он автоматически становится ее исполнителем.
Если вы регулярно логируете время и обновляете Remaining Time, то сможете использовать график сгорания, или график хода выполнения работ (Burndown Chart). Он покажет ваш прогресс по отношению к цели спринта и поможет оценить шансы на его успешное завершение.
Серая линия на графике показывает идеальный ход выполнения проекта.
Красная линия – объём незакрытых задач, зелёная – потраченное время. Если красная линия справа снизу встречается с серой в одной и той же точке – это лучший вариант развития событий.
На примере выше у команды явно есть проблемы: объем выполненной работы заметно меньше запланированного. Если они не ускорятся в последние дни спринта, то не успеют завершить все запланированные задачи в срок.
Эта же команда идет с опережением, и ей стоит подыскать себе дополнительные задачи, если положительный тренд сохранится.
ШАГ 5 — Завершение спринта, ретроспектива
Этот шаг хоть и последний, но не менее важный. Agile — это не только борды, стори и спринты. Это также поиск узких мест и усовершенствование процесса.
Поэтому после нажатия на кнопку End Sprint стоит потратить немного времени, чтобы посмотреть, как всё прошло, т. е. провести ретроспективу.
И не расстраивайтесь, если первый спринт у вас будет «комом».
Ретроспектива: на что обратить внимание?
Velocity – это скорость работы команды, тот объём, который команда может завершить за спринт. Завершить – это значит закрыть задачу и переместить ее в колонку Done.
Вот мы и выполнили последний шаг нашего Agile-проекта.
Как видите, 5 шагов к Agile действительно просты. Давайте ещё раз их перечислим:
На первый взгляд JIRA кажется сложной, но полученная польза однозначно стоит потраченных усилий и времени.
В следующей статье рассмотрим несколько интересных профессиональных «фишек» работы в JIRA.