Янв. 10

Как настроить Jira для управления бэклогом: пошаговая инструкция

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

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

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

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

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

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

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

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

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

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

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

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

Небольшая рекомендация для проектных менеджеров. Не пытайтесь сделать так, чтобы бизнес-аналитики и дизайнеры создавали подзадачи под конкретными пользовательскими историями, чтобы отслеживать затраченные часы. Это бесполезная затея в этом контексте, да и в принципе. Работа дизайнера и бизнес-аналитика достаточно творческая, поэтому четко сказать, куда и сколько времени сегодня уйдет у одного из них практически невозможно. По плану у аналитика на сегодня может быть разбор фичи «Х» на целый день, но по факту на ее анализ и описание может уйти 2 часа, а все остальное — на решение проблем с командой, дизайнером, клиентом и еще бог знает с кем.

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

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

Доска (board) — используется для отображения «issues» в определенном виде. Есть два вида доски: Scrum и Kanban. Описанный концепт работает для типа Scrum. Поэтому при старте проекта выберете именно эту доску. Нам нужен Scrum из-за специфики того, как визуально разбита информация.

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

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

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

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

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

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

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

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

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

Пользовательская история (story) — это отдельный тип сущностей, который я создаю на своих проектах. Он необходим для того, чтобы никого не путать терминологией. Вы также можете назвать это PBI (Product Backlog Item). Создание данного типа обусловлено внешним рынком. Людям, которые будут приходить на проект, будет намного легче привыкнуть к знакомым словам. Вы не будете путать понятия во время разговора о «тасках». Люди перестанут уточнять: это для разработчика «таска» или все же пользовательская история?

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

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

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

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

Плюсы работы с пользовательскими историями прямо на «борде»:

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

Минимальный набор требуемых секций в моем концепте: Backlog, BA in Progress, Ready for Grooming, Ready for Development, Next Sprint #N, Current Sprint #N. Такая структура позволит вам решить множество проблем, которые связаны с поставкой требований на разработку. Любому члену проекта, будет понятно, что происходит с бэклогом, на какой стадии каждая фича или отдельное требование, где есть проблемы в процессе разработки требований.

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

Пользовательские истории двигаются снизу вверх (Backlog => Next Sprint #N).

Название секции	Предназначение	Комментарий
Backlog	Все, что вы еще не начали разбирать или разрабатывать, находится в этой секции. Разные уровни детализации и форматы, в которых это записано. Как только появляется новое требование во время обсуждения какого-то функционала, я создаю историю и кладу ее в бэклог, если это требование не имеет отношения к фиче, над который я работаю в данный момент.	Это могут быть пользовательские истории, к которым прикреплен имейл от кого-то с конкретными требованиями, фотографии из каких-то сессий. Может быть просто большой текст с рассказом о том, чего бы хотелось, или список.
BA in Progress (более детальное видео)	В этой секции находятся пользовательские истории, над которыми идет активная работа клиента и вендора. Это, так сказать, рабочая область BA/PO, с которой он взаимодействует на ежедневной основе.	Бизнес-аналитик берет в разработку одну фичу, над которой начинает работу. Обсуждение с клиентом, создание мокапов и декомпозиция фичи на пользовательские истории.
Ready for Grooming	В этой секции должны находиться только те пользовательские истории, которые готовы к оценке командой. На каждой сессии пленнинг покера, BA/PO выбирает подготовленные истории из этого списка и обсуждает с командой. Истории в этой секции уже должны быть проверены клиентом и получено согласие на их реализацию в таком виде.	Истории отсортированы сверху вниз по бизнес-приоритетам. Для пользовательских историй, которые находятся в этой секции, должен быть прописан «Definition of Done». Как минимум следующие пункты: требования четкие и недвусмысленные; мокап; тестовые данные, если необходимо.
Ready for development	Эта секция нужна, для чтобы каждый участник проекта видел состояние готового бэклога на разработку. В ней находятся пользовательские истории, которые уже утверждены и согласованы со всеми стейкхолдерами, а также команда предоставила свою оценку по каждой из них. Истории, которые успешно прошли «Grooming».	Истории отсортированы сверху вниз по бизнес-приоритетам. Пример: велосити проекта составляет 100 сторипоинтов. Есть 3 команды, которые разрабатывают по 20/20/60 сторипоинтов в спринт. Общее количество пользовательских историй в данной секции — 15 на сумму 90 сторипоинтов. Выводы: Вашей команде не хватает 10 сторипоинтов для полной загрузки каждой из команд. Вероятность того, что все эти пользовательские истории пойдут в следующий спринт — 50/50. Там могут быть технические зависимости или фичи с низким приоритетом. Вам необходимо иметь в данной секции в 1,5 больше сторипоинтов для ваших команд, чтобы они имели возможность выбрать и создать равномерную загрузку каждого из членов команды.
Next Sprint #N	В этой секции находятся пользовательские истории, которые BA/PO считает рациональным взять в разработку в ближайший спринт. Наполнение секции может меняться в любое время. Это так называемая буферная зона, чтобы ответственному человеку было легче понять, сколько и каких историй можно будет сделать для команды.	Истории/дефекты отсортированы сверху вниз по бизнес-приоритетам, а затем и техническим.
Current Sprint #N	Это текущий спринт определенной команды. В нем находятся пользовательские истории и дефекты, которые ранее были выбраны командой на планировании. В этот спринт попадает большинство историй из «Next Sprint #N».	Истории/дефекты отсортированы сверху вниз основываясь на технических зависимостях. Каждая история разбита на задачи для FE, BE, QA.

Отдельно нужно сказать о секции «CR Bucket». Ее наличие зависит от того, оперируете ли вы таким термином, как «Change request», у себя на проекте или нет.

Критериями хорошо организованного бэклога являются следующие характеристики: 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 или какого-то сертифицированного специалиста. Достаточно собраться командой внутри своего проекта и поговорить о проблемах, которые у вас сейчас существуют.

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