Скрамбан (Scrumban)

Скрамбан (Scrumban) - це Agile-орієнтований підхід та один із Agile frameworks до створення продукту, який є гібридом Скраму та Канбану. Скрамбан був спочатку розроблений як спосіб переходу від Скраму (Scrum) до Канбану (Kanban).

У міру того, як метод Kanban ставав все більш популярним, Scrumban був розроблений як спроба полегшити існуючим Scrum-командам початок вивчення концепцій Lean і Kanban.

Методи Скрамбан (Scrumban)

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

У випадку децентралізованих команд часто використовується програмне забезпечення для візуального управління, таке як Assembla, Targetprocess, Eylean Board, JIRA, Mingle або Agilo for Trac.

Проводяться зустрічі з планування, щоб визначити, які Історії користувачів потрібно завершити в наступній ітерації. Потім історії користувачів додаються на дошку, і команда завершує їх, працюючи над якомога меншою кількістю історій користувачів одночасно, наскільки це практично можливо (робота в процесі, або WIP - work-in-progress). Щоб ітерації були короткими, використовуються ліміти WIP, а також встановлюється тригер планування, щоб знати, коли планувати наступну ітерацію - коли WIP падає нижче заздалегідь визначеного рівня. У Scrumban немає наперед визначених ролей; команда зберігає ролі, які вже має.

Ітерації (Iterations)

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

Швидкість (Velocity) (міра продуктивності) часто використовується командою для оцінки проблем і тенденцій в її пропускній здатності, щоб підтримувати постійне вдосконалення.

Планування на вимогу (On-demand planning)

Планування в Scrumban базується на вимозі і відбувається тільки тоді, коли спрацьовує тригер планування. Тригер планування пов'язаний з кількістю завдань, що залишилися в розділі "To Do" на дошці - коли вона зменшується до певного числа, відбувається подія планування.

Кількість завдань, які повинні викликати подію планування, не визначена заздалегідь. Вона залежить від швидкості команди (наскільки швидко можна завершити решту завдань) і від часу, необхідного для планування наступної ітерації. Завдання, заплановані на наступну ітерацію, додаються до розділу "To Do" на дошці.

Визначення пріоритетів (Prioritization)

Під час планування рекомендується визначити пріоритетність завдань. Це означає, що завдання додаються на дошку з позначеними пріоритетами. Це допомагає членам команди знати, які завдання слід виконати в першу чергу, а які можна виконати пізніше.

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

Планування за розміром відра (Bucket size planning)

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

Ці три відра представляють три різні етапи плану і зазвичай називаються 1-річним, 6-місячним і 3-місячним відрами.

Відро на 1 рік призначене для довгострокових цілей компанії, таких як вихід на новий ринок, випуск нового продукту тощо. Коли компанія вирішує рухатися далі з планом, він переходить до 6-місячного відра, де викристалізовуються основні вимоги цього плану.

Коли компанія готова приступити до реалізації плану, вимоги переносяться в 3-місячне відро і розбиваються на чіткі завдання, які повинна виконати проектна команда. Саме з цього відра команда черпає завдання під час зустрічі з планування на вимогу і починає працювати над завданнями.

Дошка (The board)

Базова дошка Скрамбану (Scrumban) складається з трьох колонок:

• To Do,
• Doing і
• Done.

Після планової наради завдання додаються в колонку To Do, коли член команди готовий працювати над завданням, він переміщує його в колонку Doing, а коли завершує - в колонку Done.

Дошка Scrumban візуально відображає прогрес команди. Колонки дошки завдань адаптуються і розширюються в залежності від прогресу роботи команди. Найпоширеніші доповнення включають колонки пріоритетів у розділі To Do і такі колонки, як Design, Manufacturing, Testing у розділі Doing.

Обмеження WIP - Щоб забезпечити ефективну роботу команди, методологія Scrumban передбачає, що член команди повинен працювати не більше ніж над одним завданням одночасно. Щоб переконатися, що це правило дотримується, Scrumban використовує ліміт WIP (work in progress). Цей ліміт візуалізується у верхній частині розділу "Виконано" на дошці (також може бути в кожному стовпчику цього розділу) і означає, що тільки ця кількість завдань може знаходитися у відповідному стовпчику одночасно. Ліміт WIP зазвичай дорівнює кількості людей в команді, але може бути збільшений залежно від специфіки роботи команди.

Ліміти To Do - для того, щоб проводити більш продуктивні наради з планування, кількість завдань у розділі To Do також може бути обмежена. Так само, як і у випадку з лімітами WIP, вони проставляються вгорі розділу To Do або над відповідними стовпчиками і обмежують кількість завдань у розділі To Do або в певних стовпчиках.

Команда (The team)

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

Принцип витягування (Pull principle)

У Scrumban завдання не призначаються членам команди лідером команди або менеджером проекту. Кожен член команди сам обирає, яке завдання з розділу "To Do" він збирається виконати наступним. Це гарантує безперебійний потік процесу, де всі члени команди завжди однаково зайняті.

Заморожування функцій (Feature freeze)

Заморожування функцій використовується в Scrumban, коли наближається дедлайн проекту. Це означає, що команда може працювати лише над тими функціями, які вже є в розробці, і не може додавати жодних додаткових функцій.

Сортування (Triage)

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