Как сделать спринт в jira

Обновлено: 08.07.2024

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

Должен сказать сразу, что эта методика не является эталоном или гарантией того, что ваши проблемы исчезнут. Но я четко знаю и с уверенностью могу сказать, что на момент написания статьи по этой методике было реализовано 4 проекта за последние 3 года, и метод работает! Вы можете модифицировать метод под свои нужды. Если не получается самостоятельно, тогда зовите меня :)

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

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

Основные рекомендации и пререквизиты

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

снижение стоимости на поддержание бэклога и управление им;
стандартизация процессов на проекте;
прозрачность происходящего с продуктом.

Поделитесь принципами работы с бэкклогом со своей командой. Расскажите, как вы будете управлять требованиями:

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

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

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

Что надо использовать в Jira для управления бэклогом

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

Версии (versions) — представляют временные отметки в проекте. В своей практике я всегда использую названия R.1 / R.Next. Все требования, которые появляются в процессе взаимодействия с клиентом в текущем релизе, должны быть зафиксированы и не теряться, поэтому те требования, которые не входят в текущий релиз, я помещаю в R.Next.

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

Теги (labels) — это ключевые слова, по которым можно легко сгруппировать/находить определенную информацию. Например, в своих проектах, я часто использую теги типа Web, APP, Integration. Чтобы быстро искать нужную информацию по разным запросам от разных участников проекта — QA, Клиента, Dev). Донесите всем, какие теги вы уже создали и зачем, а также расскажите команде, что беспорядочное создание тегов по любому поводу приведет к хаосу.

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

Фильтр (issues and filters) — просто мощный инструмент, который позволяет упростить процесс поиска данных или аналитики данных на ежедневной основе. Рекомендую вам использовать быстрые фильтры на верхней панели самой доски.

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

Для пользовательской истории у меня вот такой был пример:

Для задач вот такой процесс:

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

Задача / подзадача (task /sub task) — используется для более детального разделения пользовательской истории разработчиками и QA. О детализации задач идут целые войны! У каждого свой подход и методика, так же, как и по написанию пользовательских историй. Скажу пока одно: чем опытней разработчик, тем детальней описание задач и больше их количество под конкретной пользовательской историей. Задачи нужны в первую очередь самому разработчику, чтобы через неделю он мог вспомнить, что нужно сделать в определенной пользовательской истории.

Баг (bug) — этот тип сущностей служит для фиксирования проблем/недочетов во время разработки. О том, каким должен быть жизненный путь бага, какие должны быть уровни критичности бага и как управлять багами, мы поговорим в отдельной статье.

Схематическая структура Jira для управления бэклогом

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

Перетаскивание истории из одной секции в другую при помощи drag & drop.
Быстрый поиск информации через поиск самого браузера.
Быстрая фильтрация по нескольким параметрам: Релиз + Эпик + настраиваемый быстрый фильтр (Customer OK, Customer Review и так далее).
Быстрая работа с определенной пользовательской историей после ее нахождения.

Секции и их предназначение

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

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

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

На каждой сессии пленнинг покера, BA/PO выбирает подготовленные истории из этого списка и обсуждает с командой. Истории в этой секции уже должны быть проверены клиентом и получено согласие на их реализацию в таком виде.

Истории отсортированы сверху вниз по бизнес-приоритетам.

Как минимум следующие пункты:

требования четкие и недвусмысленные;
мокап;
тестовые данные, если необходимо.

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

Истории отсортированы сверху вниз по бизнес-приоритетам.

Пример: велосити проекта составляет 100 сторипоинтов. Есть 3 команды, которые разрабатывают по 20/20/60 сторипоинтов в спринт. Общее количество пользовательских историй в данной секции — 15 на сумму 90 сторипоинтов.

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

Каждая история разбита на задачи для FE, BE, QA.

Критериями хорошо организованного бэклога являются следующие характеристики: Deep, Invest, Dive. Приоритизация, декомпозиция, определение зависимостей и прочее — достаточно большие темы для обсуждения. Я буду отдельно рассказывать о каждой из них. А пока более детально вы можете почитать тут.

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

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

CR (Change request) — используется для того, чтобы помечать те пользовательские истории, которые считаются изменениями на требования. Ставится бизнес-аналитиком вендора.
HLE (High level estimate) — используется для того, чтобы показать, что оценка пользовательской истории является высокоуровневой и там есть определенные допущения. Ставится бизнес-аналитиком вендора.
Customer_Review — используется для указания клиенту, что пользовательская история готова к рассмотрению и обсуждению с клиентом. Ставится бизнес-аналитиком вендора.
Customer_Hold — используется для того, чтобы показать, что конкретная пользовательская история нуждается в доработке командой вендора. Ставится человеком со стороны клиента.
Customer_Approved — используется, чтобы отметить конкретную пользовательскую историю как утвержденную. Ставится человеком со стороны клиента.

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

Как это выглядит в реальности

Многие из вас могут сказать, что этот подход классный только на бумаге и схемах. Привожу вам пример реальной Jira:

Концепты похожего типа обговариваются на таких конференциях, как Atlassian Summit U.S. 2017 (вот видео) Если вы хотите идти в ногу со временем, вам просто необходимо начать разбираться в том, как это построить и как получить максимальную выгоду для своего проекта.

Почему это нужно

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

Команда разработки — это завод, который выпускает продукт итерациями. Чем хуже будет сырье для вашего завода, тем хуже конечный продукт или выше издержки на само производство продукта. Задумайтесь над тем, чтобы перестать разрабатывать программное обеспечение на аматорском уровне и перейти в высшую лигу с четкими процессами и оптимальными трудозатратами. Для этого не обязательно сразу звать Scrum/Agile coach или какого-то сертифицированного специалиста. Достаточно собраться командой внутри своего проекта и поговорить о проблемах, которые у вас сейчас существуют.

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

Считается, что любовь и работа — понятия несовместимые, однако украинские IT-компании не обделили вниманием дату 14 февраля.

Компания Apple объявила о том, что созданный ею язык программирования Swift теперь доступен с открытым исходным кодом, что по её.

Битва адептов продуктовой разработки и сотрудников аутсорсинговых компаний не утихает и утихать, по-моему.

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

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

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

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

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

Лично для меня оказалось наиболее удобно использовать одну доску для текущих задач и планов, а не несколько (изначально я хотела делать разные доски по темам, например: Здоровье, Финансы, Спорт, Отпуск, Недвижимость и т.п.), а все свои цели оформлять отдельными эпиками.

Сейчас я расскажу как делаю доску на своем примере - это классический шаблон + Скрам.

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

После добавляю к эпикам задачи или подзадачи. Если задачу нельзя разделить, Я создаю ее в виде Task, если можно разделить на подзадачи, тогда в виде Story в которую потом добавляю Subtask. В одном эпике у меня может быть по несколько сторей и тасок.

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

Самое сложное - правильно поделить большие задачи на подзадачи и брать в спринт то, что реально планируешь сделать.

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

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

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

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

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

Тэги, чеклисты, плагины, цветные карточки задач - все это есть в джире бесплатно и помогает сделать ее еще удобнее и радостнее.

Рассмотрим главную сущность Jira Software Atlassian — Issue. Она же тикет, таск и задача. Не все знают, что за этими названиями скрываются разные по своей сути сущности. Поэтому нужно понимать, к чему приводит выбор того или иного типа, что мы получим и как будем сущностью пользоваться. Если не учесть эту разницу, в работе начинается путаница и ведение проекта превращается в ад.

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

Типы Issue

Все Issue разделены на две категории.

1. Standard Issue Type
2. Sub-task Issue Type

Внутри каждой категории проблем Jira Software Atlassian предлагает набор уже встроенных типов задач.

Standard Issue Type

Sub-task Issue Type

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

Структура Issue в Jira.

Глобальные типы проблем

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

Добавление нового типа задач в Jira.

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

Standard Issue Type и Sub-task Issue Type формируют базовую связку родительской и дочерней задачи. Если в начале работы выбрать не тот пункт, в дальнейшем мы не сможем выстроить корректную взаимосвязь между задачами.

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

Standard Issue Type

Проблемы этого типа — автономные сущности:

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

Sub-task Issue Type

Проблемы этого типа — несамостоятельные сущности:

Они могут быть созданы только как часть уже существующей проблемы категории Standard Issue Type.
Для них отдельно невозможно поменять спринт или убрать их из него вовсе. Если мы убираем из спринта родительскую задачу, автоматически убирается и дочерний Sub-task.
Они по умолчанию наследуют то значение спринта, которое имеет их родительская проблема.
Подтаски не отображаются в бэклоге. Мы видим только их родительские задачи.

Проблемы категории Sub-task Issue Type включены в Jira по умолчанию. Если для выстраивания ваших процессов они не нужны, их можно отключить: настройки — Issue Types — Sub-tasks — Disable Sub-Tasks.

Sub-task Issue Type в Jira.

Частные типы проблем (задач)

Внутри каждой категории глобальных проблем Jira Software Atlassian предлагает набор уже встроенных частных проблем (типов задач) и возможность создавать собственные.

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

По умолчанию в Jira установлены следующие Issue Types:

Обратите внимание, что Sub-task относится к категории Sub-task Issue Type, а все остальные типы проблем к категории Standard Issue Type.

Принципиальные отличия задач типа Epic

Эпик относится к Standard Issue Type, но отличается от всех других типов задач этой категории:

Мы можем использовать только тот эпик, который уже предложен сервисом. Его невозможно скопировать, создать через кнопку Add issue type или как-то еще.
Внутри эпика нельзя создать задачу категории Sub-task Issue Type.
Эпик — это единственный в своем роде тип задачи с возможностью занимать высшую ступень в иерархии задач.
Задачи внутри эпика остаются автономными и не наследуют его свойства.
Дочерней для эпика можно сделать любую задачу из категории Standard Issue Type, кроме него самого.

Создание кастомных (частных) Issue Type

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

Заходим в настройки (значок шестеренки у аватарки аккаунта).
Выбираем пункт Issues.
Нажимаем кнопку Add issue type (в правом верхнем углу страницы).
В появившемся окне задаем название, описание и выбираем глобальный тип проблемы (Standard или Sub-task).

При этом если в левом меню выбрать пункт Issue Types, увидим все типы задач, которые есть в нашем воркспейсе на данный момент. А выбрав меню Sub-tasks, увидим только подзадачи.

Здесь отображаются все виды Issue Type вашего воркспейса.

Структура вложенности и организация деревьев задач

Для каких именно целей использовать различные типы Issue каждая команда решает самостоятельно. Это зависит от принятых ей особенностей выстраивания процессов. Однако техническое взаимодействие между различными Issue Type регламентирует Jira. Все задачи можно выстроить максимум в три ступени иерархии. Распределяться по уровням они могут ТОЛЬКО ТАК.

Структура подчинения различных типов задач в Jira.

Неужели, все это важно знать

Мы видим, как начинающие администраторы Jira создают слишком много кастомных типов задач. Видим, как они пытаются выдать одну задачу за другую, изменив только название и иконки задач. Так не работает.

Каждый тип Issue Type — это отдельная сущность. У нее есть назначение, определенные свойства и взаимосвязь с другими задачами. А еще разные типы задач мы используем для того, чтобы назначать каждому из них свой процесс. Иначе мы не увидим, как продвигается работа в команде.

В Jira, конечно, можно создать неограниченное количество кастомных типов задач. Но если их слишком много, это приводит лишь к путанице и не дает никакой наглядности. Лучше выделять не более 5-ти типов задач для одного проекта. Наличие каждого из них должно быть обоснованно и оправданно. Если у вас есть вопросы по Jira, напишите нам.

В следующей статье расскажем, как настраивать Workflow в Jira. Если правильно настроить воркфло, все этапы работы бизнеса становятся прозрачными и предсказуемыми :)

Я переношу ряд проектов из одного экземпляра JIRA в другой, используя импортер JSON. Хотя импортер может назначать проблемы для существующих спринтов, сами спринты должны существовать - ограничение текущей версии JIRA Importer.

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

Он не выглядит так, как API JIRA REST может создавать новые спринты - хотя люди говорят о greenhopper/1.0/sprint/create endpoint, его не существует.

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

Любая надежда? Могу ли я ВСТАВИТЬ новые записи в таблицу AO_60DB71_SPRINT с SQL-клиентом? Благодарю!

Читайте также: