спринт jira что это
Механизмы 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]
Изучение того как использовать спринты в программном обеспечении 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 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 см. в нашей документации по спринтам.
Общие спринты в 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.
Именно это поведение обычно встречают пользователи. Они работают со спринтом и вдруг спринт закрывается. Никто из команды его не закрывал. В результате оказывается, что спринт был закрыт из другой доски, у которой фильтр выбирает тикеты из этого проекта.
Как можно использовать общие спринты?
Допустим у нас есть несколько команд, и у каждой команды есть свой проект. Каждая команда создает доску и работает на этой доске. Мы хотим увидеть спринты всех команд. Как мы это можем сделать?
Спринты
Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы.
Просмотр тем
Что такое спринты?
Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы. Спринты лежат в основе методологий scrum и agile, и правильный выбор спринтов поможет вашей agile‑команде выпускать более качественное программное обеспечение без лишней головной боли.
«При использовании scrum продукт разрабатывается в ходе нескольких итераций с фиксированной продолжительностью, которые называются спринтами и разбивают большие сложные проекты на небольшие задачи», — говорит Меган Кук, менеджер группы товаров для Jira Software в Atlassian.
Многие ассоциируют Scrum-спринты с Agile-разработкой программного обеспечения настолько часто, что Scrum и Agile принимают за синонимы. Однако это не так. Agile — это набор принципов, а Scrum — методика для активного решения задач.
Многочисленные сходства между глобальными задачами agile и процессами scrum вполне справедливо приводят к тому, что эти два понятия ассоциируются друг с другом. Благодаря спринтам команды могут следовать agile‑принципу «частой поставки рабочего программного обеспечения», а также реализовать agile‑задачу «реагирования на изменения в соответствии с планом». Установки scrum — прозрачность, проверка и адаптация — дополняют agile‑методику и играют главную роль в концепции спринтов.
Руководство по Scrum закладывает прочную теоретическую основу для обсуждения спринтов. Мы хотим внести немного красок в эту тему и делимся рекомендациями от людей, которые занимаются этой работой каждый день.
Как планировать и выполнять спринты в scrum
Авторы Scrum действительно все предусмотрели. Чтобы запланировать предстоящий спринт, нужно провести собрание по планированию спринта. Планирование спринта — это мероприятие, на котором команда сообща отвечает на два основных вопроса: какую работу можно выполнить в этом спринте и как она будет выполняться?
Выбором подходящих рабочих задач для спринта занимаются совместно владелец продукта, Scrum-мастер и команда разработчиков. Владелец продукта определяет цель спринта и задачи из бэклога продукта, при выполнении которых она будет достигнута.
Затем команда создает план, согласно которому будут выполняться задачи бэклога, чтобы к окончанию спринта вся работа была завершена. Выбранные рабочие задачи и план по их выполнению называется бэклогом спринта. К концу совещания по планированию спринта команда готова приступить к работе. Для этого необходимо просто выбирать задачи из бэклога спринта и менять их статус с «В работе» на «Готово» по мере завершения работы.
В течение спринта команда собирается на ежедневные Scrum‑совещания (стендапы), чтобы обсудить ход работы. Такие совещания нужны, чтобы выявить блокеры и проблемы, которые могут повлиять на достижение цели спринта.
По окончании спринта команда показывает выполненную работу на обзоре итогов спринта. Здесь можно продемонстрировать итоги работы заинтересованным сторонам и другим участникам команды до того, как они попадут в рабочую среду.
Завершите цикл спринтов на моем любимом собрании — ретроспективе спринта. Здесь команда может определить области, требующие улучшения в следующем спринте. С этими сведениями можно начинать следующий цикл спринта. Вперед!
Что стоит и не стоит делать
Даже если основы уже известны, большинство команд спотыкается в начале работы со спринтами. Меган Кук завершает эту дискуссию списком действий, которые стоит и не стоит делать при использовании спринтов, которые она сформулировала за годы своей работы.
И если уж вы работаете над тем, чтобы стать сильным специалистом по scrum, выполняя рекомендации, ознакомьтесь также с действиями, которые выполнять не следует.
Чего не стоит делать.
Оптимизируйте спринты с помощью автоматизации
Когда вы поймете, как работают спринты, вы сможете оптимизировать процессы, используя автоматизацию. Вот три правила автоматизации, которые часто используются в спринтах Jira.
Эти и сотни других правил автоматизации можно найти в библиотеке шаблонов Jira Automation.
Подробнее о спринтах
Спринты настолько известны (и настолько эффективны), что их часто считают первым шагом на пути к повышению гибкости. Но мы выяснили, что для освоения спринтов необходимо овладеть некоторыми взаимосвязанными понятиями Scrum и Agile. Изучите остальные статьи по Scrum, чтобы расширить знания и стать еще на шаг ближе к счастью от использования Scrum.