Оригінальна стаття від Продакт Менеджера Сергія Алєксєєва з сайту dou.ua перекладена Софією Зеленською, перегляд – Іван Вільчавський.
У статті я розповім про те, як використовувати такий інструмент, як 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 /subtask) — використовується для детальнішого поділу користувацької історії розробниками та 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 | У цій секції знаходяться користувацькі історії, над якими йде активна робота клієнта і вендора. Це, так би мовити, робоча область БА/ПО, з якою він взаємодіє на щоденній основі. | Бізнес-аналітик бере в розробку одну фічу, над якою починає роботу. Обговорення з клієнтом, створення мокапів і декомпозиція фічі на користувацькі історії. |
| Ready for Grooming | У цій секції повинні знаходитися тільки ті користувацькі історії, які готові до оцінки командою.
На кожній сесії пленнінг-покеру БА/ПО обирає підготовлені історії з цього списку й обговорює з командою. Історії в цій секції вже мають бути перевірені клієнтом і погоджені на реалізацію в такому вигляді. |
Історії відсортовані зверху вниз за бізнес-пріоритетами.
Для користувацьких історій, які знаходяться в цій секції, має бути прописаний “Definition of Done”. Як мінімум такі пункти:
|
| Ready for development | Ця секція потрібна, щоб кожен учасник проєкту бачив стан готового беклогу на розробку.
У ній містяться користувацькі історії, які вже затверджені та узгоджені з усіма стейкхолдерами, а також команда надала свою оцінку за кожною з них. Історії, які успішно пройшли “Grooming”. |
Історії відсортовані зверху вниз за бізнес-пріоритетами.
Приклад: велосіті проєкту становить 100 сторіпоінтів. Є 3 команди, які розробляють по 20/20/60 сторіпоінтів у спринт. Загальна кількість користувацьких історій у цій секції – 15 на суму 90 сторіпоінтів. Висновки:
|
| Next Sprint #N | У цій секції знаходяться користувацькі історії, які БА/ПО вважає раціональним взяти в розробку в найближчий спринт. Наповнення секції може змінюватися в будь-який час. Це так звана буферна зона, щоб відповідальній людині було легше зрозуміти, скільки і яких історій можна буде зробити для команди. | Історії/дефекти відсортовані зверху вниз за бізнес-пріоритетами, а потім і технічними. |
| Current Sprint #N | Це поточний спринт певної команди. У ньому знаходяться користувацькі історії та дефекти, які раніше були обрані командою на плануванні. У цей спринт потрапляє більшість історій з “Next Sprint #N”. | Історії/дефекти відсортовані зверху вниз, ґрунтуючись на технічних залежностях.
Кожна історія розбита на завдання для frontend-, backend-розробників, тестувальників. |
Окремо потрібно сказати про секцію “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 або якогось сертифікованого фахівця. Достатньо зібратися командою всередині свого проєкту і обговорити проблеми, які у вас зараз існують.
Якщо ви хочете вивести свою команду розробки або проєкт на новий вищий і якісніший рівень, тоді ця схема для вас! Якщо у вас виникнуть питання щодо впровадження або адаптації всього вищеописаного, пишіть мені в будь-який канал зв’язку.