Зазвичай фінансові питання (мається на увазі бізнес-питання) виносяться в пріоритет, а технічні, як правило, ігноруються чи просто виносяться за рамки. Також в аналізі розкриваємо питання інвестицій, потреб ринку і ЦА. Якщо так – продовжуємо проєкт, якщо ні, закриваємо концепцію та що таке скрам рухаємось далі. Без бачення беклоги компаній, які розробляють цифрове рішення, зазвичай містять все, окрім ключового.
Скрам-команда досягає цього рівня крутості, регулярно уточнюючи елементи продуктового беклогу в малих групах або ж цілою командою. Це відбувається в рамках планування Спринту і не один раз на Спринт, а частіше. Підсумовуючи, планування спринту – це важливий процес, який допомагає команді чітко окреслити свої цілі, розробити план дій та ефективно розподілити завдання. Дотримуючись правил scrum, ви можете значно підвищити шанси на успішне завершення спринту.
Дуже важливо, щоб елементи і розмір беклогу спринту визначала саме команда. Оскільки вони працюватимуть над задачами, вони й мають обирати, що робити. Наприклад, перед зимою ми приділяли максимум уваги закупівлі опалювальних приладів і зимової амуніції для ЗСУ. Під час блекаутів брали участь у обладнанні пунктів незламності, закуповували роутери і точки доступу для бомбосховищ у школах і дитсадках. Ми маємо гнучкі терміни і гнучкий процес, запаси на затримки і зміни.
Тоді Команда визначає, скільки з бажаного вони можуть зробити, щоб завершити необхідні частини протягом наступного спринту[6]. Протягом спринту команда виконує визначений фіксований список завдань (т.з. backlog items). Впродовж цього періоду ніхто не має права змінювати перелік запитів на виконання робіт, що слід розуміти, як заморожування вимог (requirements) протягом спринту. Це повний перелік та опис вимог, завдань, функціоналу – усього, що треба реалізувати під час розробки. Він дає змогу розробникам зрозуміти й візуалізувати завдання, які вони мають вирішити, розставити пріоритети з огляду на інтереси клієнта, оцінити завдання у годинах розробки. Зазвичай керівником product backlog виступає його власник (product owner).
Формуйте гнучкі команди, які будуть переслідувати складну мету, наприклад, якщо кінцевий продукт поки не визначений. І уникайте традиційних методів, якщо клієнти очікують швидких результатів. І до війни клієнти переходили з російського софту до KeyCRM, й причиною була саме складність того продукту, а не патріотичність (як в останні 2 роки). Нас тому й не дуже полюбляють IT-інтегратори, бо небагато роботи з налаштувань. Робочі завдання треба розставити у порядку пріоритетів на основі дорожньої карти. Найважливіші задачі, які потрібно виконати насамперед, мають знаходитись на початку беклогу.
Увесь список задач називається продуктовий беклог (product backlog), список задач на певний спринт – це беклог спринта (sprint backlog). Поглянемо, як це працює на прикладі приведеного бьорн-даун чату. До 13-го дня 20-денного спринту їй залишалося ще 600 годин роботи. Довелося звернутись до власника продукту, і той погодився прибрати зі спринту деякі історії користувачів. З цього часу команда стала просуватися вперед значно продуктивніше, і спринт було завершено успішно.
Тому пропонуємо вашій увазі більш детальний огляд кожного елементу та розбір кількох типових (майже) шаблонів. До речі, одна з ключових переваг SAFe полягає якраз у наявності цих шаблонів, які існують майже для всіх потенційних сценаріїв та процесів. Як і в будь-яких інших методологіях чи архетипах розробки, в SAFe є чітко описана модель вимог. Вони формулюють бачення того, що ми маємо отримати в підсумку розробки, як взагалі будувати процеси, щоб досягти встановлених цілей. У рамках методології Scrum команди розробників працюють невеличкими інтервалами – спринтами. Це важливо для розуміння різниці між беклогом продукту та беклогом спринту.
Його увагу зосереджено на ефективній комунікації і взаємодії, він гнучкий до змін у планах розробки і дозволяє не втратити великий шматок роботи, якщо бажання клієнта змінилися. Близько 30 років тому стало очевидно, що процеси, які використовуються для розробки програмного забезпечення, не працюють. Проекти реалізовувалися занадто повільно, а клієнти у підсумку не отримували того, що їм було потрібно. Вони використовуються для поділу в межах проєкту на більш дрібні частини.
Саме так називається кожне невелике підзавдання, з яких складається проект. Всі спринти повинні бути однаковими за тривалістю, та ви не повірите, але найчастіше довжина одного — два тижні, рідше за місяць. Під час формування беклогу спринту або продукту обов’язково деталізуйте завдання і виставляйте їх у порядку пріоритету.
У процесі завдання, найімовірніше, будуть коригуватися й актуалізуватися залежно від результатів просування – ці зміни також потрібно відображати в беклозі. Скрам-бан – це методологія управління проектами, яка поєднує в собі основні принципи скраму та канбану. Скрам-бан використовується для управління проектами, які мають невеликий обсяг роботи, або для проектів, де прогрес необхідно контролювати на щоденній основі. Від канбану скрам-бан взяв те, що робота здійснюється за допомогою канбан-дошки, а від скраму – використання ітераційного підходу. Product backlog — це документ, який має список вимог до функціональності, які упорядковані згідно зі ступенем важливості.
На цих зустрічах кожен член команди розповідає про поточний стан своїх задач. Опорні питання ви можете вигадати самі або скористатися шпаргалкою. Головна характеристика команди, яку вдасться «підсадити» на Scrum — усі її члени об’єднані навколо однієї мети. Вони створюють разом продукт, організовують фестиваль або впроваджують важливу реформу. Врахуйте, що у Scrum немає начальників і підлеглих — усі задачі обмірковують разом і відповідальні за результат теж усі.
Часто команди починають з порожнього DoR та додають до нього чекпоінти в процесі роботи, коли зіштовхуються на ретроспективах із проблемами не якісних та “сирих” вимог. Теги (labels) — це ключові слова, за якими можна легко згрупувати/знайти певну інформацію. Наприклад, у своїх проектах я часто використовую теги типу Web, APP, Integration. Щоб швидко шукати потрібну інформацію за різними запитами від різних учасників проєкту — QA, Клієнта, Dev. Донесіть усім, які теги ви вже створили і навіщо, а також розкажіть команді, що безладне створення тегів із будь-якого приводу призведе до хаосу. Дуже важливо підтримувати беклог завжди у актуальному стані.