Что такое спринт в джире

Общие спринты в Atlassian Jira Software

В этой статье я хотел бы поговорить об Общих Спринтах (Shared Sprints) в Atlassian Jira Software.

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

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

Общие спринты — это важное понятие в Atlassian Jira Software, потому что знакомство с общими спринтами происходит, как правило, неожиданно, и кажется, что что-то пошло не так. Но это не так, и, если знать, как общие спринты работают, то можно их использовать для своих нужд.

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

Все примеры в этой статье я пробовал в Jira Software Cloud и в Jira Software Server 7.12.3.

Что такое общий спринт?

Общий спринт — это спринт, который виден на более, чем одной доске.

Например, есть вот такие скриншоты досок:

Можно увидеть, что на досках SCRUM и SCRUM2 есть спринт с названием SCRUM Sprint 3. Этот спринт виден на двух досках. Значит ли что мы видим общий спринт? Нет. В Jira Software может быть два разных спринта с одинаковым наименованием.

Как увидеть ид спринта?

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

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

Общий спринт

Теперь давайте посмотрим вот на этот скриншот:

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

Почему у нас один и тот же спринт на двух досках?

project = SCRUM OR priority is not EMPTY ORDER BY Rank ASC

project = SCRUM2 ORDER BY Rank ASC

Мы видим, что фильтр для SCRUM выбирает не только тикеты из проекта SCRUM, но и все тикеты в нашем инстансе Jira, у которых заполнен приоритет, а значит он выбирает и тикеты из проекта SCRUM2. Поэтому тикеты из проекта SCRUM2 видны и на доске SCRUM, и на доске SCRUM2. И поэтому если мы заполним поле Sprint в одном из тикетов, этот спринт появится на двух досках.

Спринт создается из доски и содержит ссылку на доску, из которой он создан. Для этого можно выполнить, например, rest/agile/1.0/sprint/sprintId и увидеть доску, из который спринт был создан. В нашем случае мы получим вот такой результат:

originBoardId = 3, а это доска SCRUM2. Это означает, что спринт изначально был создан на доске SCRUM2, а на доске SCRUM он появился потому, что тикет из спринта есть как на доске SCRUM2, так и на доске SCRUM.

Как себя ведут общие спринты?

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

Например, если мы переименуем спринт на доске SCRUM, то он переименуется и на доске SCRUM2. Если мы закроем спринт на доске SCRUM, то он и закроется на доске SCRUM.

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

Как можно использовать общие спринты?

Допустим у нас есть несколько команд, и у каждой команды есть свой проект. Каждая команда создает доску и работает на этой доске. Мы хотим увидеть спринты всех команд. Как мы это можем сделать?

Источник

Узнайте, как использовать спринты в 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 см. в нашей документации по спринтам.

Источник

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.

Источник

Спринты

Спринты

Что такое спринты?

ТВИИТ :«Спринты делают проекты более управляемыми, позволяют командам быстрее и чаще выполнять высококачественную работу и дают им больше гибкости для адаптации к изменениям».

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

Как планировать и выполнять scrum-спринты

Затем команда создает план того, как они будут создавать элементы списка необходимых требований (backlog) и получать их «Готов(-ыми)» до конца спринта. Выбранные рабочие элементы и план их выполнения называются «спринтом списка необходимых требований (backlog)». К концу планирования спринта команда готова приступить к работе с списком необходимых требований (backlog) спринта, перенеся элементы из этого списка в «Выполняется» и «Готово».

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

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

Что можно и нельзя

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

Что можно:

Пока вы работаете над тем, чтобы быть звездой Scrum с этими «разрешениями» (“do’s,”), следите также за несколькими красными флагами:

Не рекомендуется:

Узнайте больше о спринтах

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

По материалам Agile Coach «Sprints»

Источник

Механизмы 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]

Источник