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

Якщо ви хочете вивести свою команду розробки або проект на новий більш високий і якісний рівень, тоді ця схема для вас! Якщо у вас виникнуть питання щодо впровадження або адаптації всього вищеописаного, пишіть мені в будь-який канал зв'язку.

Опубліковано: 10/01/19 @ 08:00
Розділ Різне

SEO Блог