Уточнення Беклогу Продукту: 14 Основних Принципів

Ми використовуємо його, щоби додавати ідеї, здатні підштовхнути нашу метрику Полярної зірки. Ми користуємося ним для узгодження функцій із нашим колесом ціннісної пропозиції. Ми навіть додали до нього деякі думки щодо створення версії застосунку для iOS (очевидно, на майбутнє). Поглянемо, як це працює на прикладі приведеного бьорн-даун чату.

По мірі поширення використання Скраму розробники, дослідники, аналітики, науковці та інші спеціалісти виконують свою роботу. Ми використовуємо слово “розробники” у Скрам не для виділення окремої групи, а для спрощення. Якщо ви отримуєте користь від Скраму, вважайте себе включеним у Скрам фреймворк. Не дарма ж такі кейси вважаються ледь не стандартом IT-індустрії та широко розповсюдженні як в розробці, так і в QA, BA тощо. Уточнення Product Backlog — це безперервний процес створення функціональних продуктових беклогів, що дозволяє команді Scrum без підготовки розпочинати планування спринту.

Планування релізу (Release planning) – це підхід до організації роботи, який бере до уваги гнучку природу процесу розробки системного забезпечення. Його основна мета – це контроль також регулярних проміжкових релізів, на відміну від традиційного підходу, де все фокусується переважно на великих основних релізах. Планування релізу відбувається після окреслення основної мети продукту, його вигляду та процесу розробки. Як вже було вказано, команда складається із спеціалістів різних напрямків, кожен з яких має свій погляд на думку. Посібник зі Скраму документує Скрам у тому вигляді, як його розробляли, розвивали та підтримували протягом понад 30 років Джефф Сазерленд та Кен Швабер. Інші джерела містять схеми, процеси та уявлення, які доповнюють структуру Скрам.

Способи, за допомогою яких цього досягають, можуть відрізнятися залежно від організацій, Скрам Команд та окремих осіб. Вони структуровані та уповноважені організацією керувати власною роботою. Коли люди працюють в Спринті у стійкому темпі, це покращує фокусування і послідовність Скрам Команди. Ми спостерігаємо за зростанням використання Скрам у сьогоденному складному світі, який постійно змінюється. Для нас честь бачити, що Скрам використовують у багатьох сферах, де роблять дійсно складну роботу, окрім розробки програмних продуктів, куди сягає корінням Скрам.

Спринти вносять прогнозованість у процес розробки, забезпечуючи проведення перевірки та адаптації на шляху до Цілі Продукту (Product Goal), як мінімум, раз на місяць. Якщо часові рамки Спринту є занадто довгими, то Ціль Спринта може стати неактуальною, складність завдання може зрости, а ризики збільшитися. Короткі Спринти можна використовувати для створення більших навчальних циклів та для того щоб зменшити в часі ризик витрат і зусиль. Спробуйте його таким який він є, та визначте, чи допомагають його філософія, теорія та структура досягати цілей та створювати цінність. Фреймворк Скрам цілеспрямовано неповний, він лише визначає частини, необхідні для впровадження теорії Скрам на практиці. Скрам будується на основі колективного інтелекту людей, які його використовують.

Особливості Scrum

Кожна нарада в Скрамі надає можливість формально перевірити та адаптувати Скрам артефакти. Такі події створені спеціально для того, щоб забезпечити необхідну прозорість. Відмова від проведення однієї з нарад призводить до втрати можливостей для перевірки та адаптації.

У ній великий проект розбивається на безліч маленьких підзадач-спринтів, кожна з яких виконується досвідченою та злагодженою командою в середньому за 2 тижні. Результати спринту — завжди щось цінне для проекту, що можна оцінити й протестувати в роботі. Для кожного спринту вибираються задачі зі списку-беклогу, який може вільно змінюватися відповідно до нової інформації про споживачів, ситуації на ринку та інших даних аналітики. Кожен елемент фреймворку має свою специфічну мету, яка важлива для повного розуміння цінності та результатів, які отримують за допомогою Скрам. Не вартий оприлюднення лише функціонал низького рівня, що є частиною (більшого) MMF. Під час спринту члени команди мають оновлювати беклог спринту в міру появи нових даних, але не рідше, ніж раз на день.

Робота не може вважатися частиною Інкременту, якщо вона не відповідає Визначенню Виконаної Роботи (Definition of Done). Саме Розробники, які виконуватимуть роботу, є відповідальними за оцінку розмірів елементів. Власник Продукту може допомогти Розробникам зрозуміти вимоги та дійти компромісного рішення. Ці зобов’язання існують для того, щоб посилити емпіризм та цінності Скраму для Скрам Команди та їхніх зацікавлених осіб.

Начало Работы

Такий підхід забезпечує чітке дотримання вимогою, уберігає від недоглядів чи переробок, забезпечуючи планомірний рух до мети. Головні принципи Scrum — ясність комунікації, прозорість і прагнення постійного вдосконалення. Популярними представниками цього підходу є такі методології як Scrum та Kanban. Інкремент народжується у той момент, коли елемент Беклогу Продукту відповідає Визначенню Виконаної Роботи. Метою Ретроспективи Спринту (Sprint Retrospective) є планування способів підвищення якості та ефективності роботи. Отже, я вирушив в Амстердам, аби дізнатися в Мелані Весселс, agile-коуча з Booking.com, як її колеги в компанії виконують свою роботу.

Щоразу, коли новий елемент вважається Готовим (Status Done), смуга на діаграмі підвищується. Таймбокс (Timebox) – це певний проміжок часу, який був узгоджений заздалегідь. Ми розглянемо пояснення до кожного з артефактів, і почнемо з беклогу продукту. Кен Швабер і Джефф Сазерленд вперше представили Скрам на конференції OOPSLA в 1995 році. Їх доповідь задокументувала знання, які Кен та Джеф отримали за попередні кілька років, та оприлюднила перше офіційне визначення Скрам.

Загальна концепція розвитку компанії у SAFe називається Portfolio Canvas. Це умовне полотно (анкета, шаблон, профіль), де відображається, чому та як бренд йде певним шляхом, яких цілей він прагне досягти. TransferWise – лондонська онлайн-служба грошових переказів, заснована в січні 2011 року естонцями Крісто Кярманном і Тааветом Хінрікусом. Незабаром після успішного завершення акціонерного краудфандингу, коли навесні наша команда зібралася на позаофісну зустріч у Барселоні, ми вирішили, що нам потрібен новий дедлайн. Краудфандингова кампанія добре прислужилася як спосіб зосередити командні зусилля.

Jira Product Discovery

Власник Продукту пропонує варіанти того, як продукт може збільшити свою цінність та користь у поточному Спринті. Потім вся Скрам Команда визначає таку Ціль Спринту, яка показує чому Спринт цінний для зацікавлених осіб. Ціль Спринту повинна бути опрацьована до закінчення Планування Спринту.

З тих пір посібник еволюціонував завдяки серії невеликих оновлень. З розширенням команди та масштабу продукту зростає і кількість нюансів беклогу. https://deveducation.com/ Наприклад, ви працюватимете частіше з рівнями епік та можливостей, а вже меншою мірою впливатимете на особливості та користувацькі кейси.

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

Хоча вони є корисними, проте не можуть замінити важливість емпіричного підходу. Тільки з огляду на те, що вже сталося, ми можемо приймати перспективні рішення. Для легкості роботи команди, найкраще коли всі наради проводять в один і той же час та в одному місці.

• Тоді вона визначає, які задачі треба виконати, щоб закрити кожну з історій.
• Це означало, що доводилося багато чого створювати «з нуля», і так само з усіма платіжними методами, які ми почали підтримувати.
• Вона дозволяє швидко та адаптивно реалізовувати як невеликі, так і масштабні проєкти, оптимізуючи при цьому витрати бюджету та залучення ресурсів.
• Сторі пойнтс застосовуються під час Скрам покеру (Scrum Poker) і більше про нього можна прочитати в іншій статті нашого блогу.

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

Щоб Власник Продукту успішно виконував свої обов’язки, всі члени організації повинні поважати його рішення. Усі рішення Власника Продукту відображаються у вмісті та впорядкуванні Беклогу Продукту, а також у перегляді Інкременту під час Рев’ю Спринту. Останнім часом в ІТ світі все більше дискусій з приводу різниці між Product Owner та Product Manager, а також відносно їх обов’язків. Якщо ви працюєте з невеликим продуктом, то дана проблема для вас не актуальна – бо ви виконуєте обидві ролі… Чим більше критеріїв ви вкажете, тим якіснішим функціоналом в підсумку порадуєте користувачів свого продукту.

Фактично, сьогодні власник практично будь-якого бізнесу потребує розуміння беклогів та вміння працювати з ними. Ведення беклогу нагадує одвічний танець двох протилежних партнерів — порядку та хаосу. Результатом стає не збільшення визначеності, а рух крок у крок із постійними змінами. Коли ви усвідомите, що дійсно ведете беклог, то, можливо, почнете більш прискіпливо ставитися до ідей численних фіч, що ніколи не будуть реалізовані.

Як правило, SAFe об’єднує все зазначене в одну інфраструктуру, яку ми можемо назвати загальним беклогом. З тією різницею, що у технічних аспектах використовується поняття Enables, яке й характеризує їх як тригери для роботи чогось (над чимось, якось і т.д.). Після надходження грошей нам бракувало конкретної дати для роботи в певному напрямку та утримання організованості.

Кожен Інкремент додається до всіх попередніх Інкрементів та ретельно перевіряється, щоб гарантувати, що всі Інкременти працюють разом. Для забезпечення цінності, Інкремент повинен бути придатним для використання. Хоча Ціль Спринту є зобов’язанням Розробників, вона забезпечує гнучкість щодо тієї роботи, яка є необхідною для її досягнення. Також, Ціль Спринту створює злагодженість і тримає фокус Скрам Команди, заохочуючи їх працювати разом, а не окремо.

Ця компетенція критично важлива для формування довіри стейкхолдерів та менеджменту до команди, яка регулярно постачає цінні Інкременти. Завдяки йому зручно організовувати роботу та ще зручніше стежити за прогресом проекту загалом. Ретроспектива завершує спринт і може тривати всього три години для спринту, що триває місяць. Перегляд спринту (Sprint Review) – це перегляд результату досягнутого за спринт. Він робить це, дозволяючи Скрам Команді вдосконалювати свої практики в рамках Скраму.