Короткий огляд двох найбільш поширених методологій Agile: Scrum та Канбан за «Настільною книгою бережливого підприємця»

На кожну гучну історію успіху на кшталт Apple, Google чи Facebook припадає безліч провальних проєктів, через які компанії змушені згортати діяльність. Причина очевидна — більшість продуктів не відповідають реальним потребам клієнтів. Утім існує спосіб увійти до кола переможців. У «Настільній книзі бережливого підприємця», що вийде українською у видавництві Лабораторія, спільно з кофаундинговою компанією Genesis, автор книги Ден Олсен, спираючись на принципи Lean Startup і досвід роботи з Facebook, Box, Hightail, Medallia та іншими, пропонує покрокову модель досягнення продуктово-ринкової відповідності, що допоможе підприємцям, продакт-менеджерам й інноваторам знизити ризики, сфокусуватися на клієнтах і створювати продукти, які не лише купуватимуть, а й щиро полюблять.

Основні принципи Agile‐розробки були сформульовані в «Маніфесті Agile», який побачив світ у 2001 році (ознайомитися з його текстом та принципами створення продукту можна за посиланням: agilemanifesto.org). Agile заохочує якнайшвидшу та безперервну розробку дієвого програмного забезпечення з акцентом на створення реальної цінності для користувача. Одним із ключових принципів Agile є визначення продукту з погляду потреб клієнта — завдяки створенню користувацьких історій. Добре сформульовані історії зазвичай дотримуються простої структури: Як [тип користувача] я хочу [щось зробити], щоб могти [отримати бажану вигоду].

Agile також сприяє тісній співпраці між різними функціональними групами, де бізнес‐спеціалісти й розробники працюють разом щодня, бажано безпосередньо. Замість того щоб суворо дотримуватися плану, Agile підкреслює важливість гнучкості та здатності швидко реагувати на зміни. Команди досягають цього, виконуючи роботу в малих обсягах за короткі ітераційні цикли, отримуючи зворотний зв’язок і знання на кожному етапі, а не намагаються прописати всі вимоги на самому початку. І, зрештою, Agile фокусується на постійному покращенні процесу розробки продукту через зворотний зв’язок та експерименти. Існує кілька різних варіантів Agile‐розробки, серед яких можна виділити екстремальне програмування (XP) та бережливе розроблення програмного забезпечення. 

Scrum

Scrum — це найпопулярніша Agile‐методологія, яку досить легко впровадити завдяки численним чітким рекомендаціям щодо її застосування. Однією з основних особливостей Scrum є робота команди в межах чітко визначених часових інтервалів — спринтів або ітерацій, які мають фіксовану тривалість. Найчастіше використовуються двотижневі спринти, але також трапляються компанії, що застосовують їх тривалістю один, три або чотири тижні. Уся робота, яку виконує команда, береться з продуктового беклогу користувацьких історій — списку завдань, упорядкованого за пріоритетами. Історії додаються до нього власником продукту (Product Owner), що є однією з трьох ролей, визначених у Scrum. Він відповідає за формування пріоритетного беклогу, використовуючи відгуки від клієнтів та зацікавлених сторін. Зазвичай роль Product Owner бере менеджер продукту в команді. У деяких компаніях існує окремий власник продукту на додачу до менеджера, і вони тісно співпрацюють між собою. У менших стартапах, де немає такого спеціаліста, зазвичай це робить один із засновників.

Друга роль у Scrum — це член команди розробки. Згідно з рекомендаціями Scrum, група має бути мультидисциплінарною та володіти всіма необхідними навичками для виконання завдань. Здебільшого у Scrum‐команді є кілька розробників, які оцінюють розмір історій та створюють продукт.

Також важливі UX‐, візуальні дизайнери та тестувальники якості (Quality Assurance, або QA). Хоча традиційні рекомендації Scrum не розрізняють ієрархії ролей усередині команди, визнання окремих позицій є цілком допустимим. Дизайнери реалізують користувацькі історії, створюючи досвід взаємодії з продуктом, який передають через свої матеріали. Добре написані користувацькі історії містять критерії прийнятності для підтвердження того, що історія завершена та працює належно. Тестувальники QA перевіряють, чи відповідає продукт критеріям прийнятності, та гарантують його якість. Оптимальна чисельність Scrum‐команди — від п’яти до дев’яти осіб. Існує так зване правило двох піц: якщо їх не вистачить, щоб нагодувати всіх учасників, — значить, вас забагато. Команда повинна бути достатньо великою, аби виконати значний обсяг роботи за один спринт, але водночас такою, щоби зберігати згуртованість та уникати проблем із комунікацією, які нерідко виникають у великих групах.

Підписуйтеся на наші соцмережі

Третя роль — майстер, котрий допомагає команді ефективно працювати й підвищувати її продуктивність. У великих компаніях один Scrum‐майстер може працювати з кількома групами одночасно. Зазвичай це робить провідний розробник або менеджер з розробки. Хоча це не зовсім відповідає традиційним стандартам Scrum, іноді або роль майстра не закріплюється за конкретною особою, або обов’язки розподіляються між кількома членами команди. Група проводить підготовчі заходи до наступного спринту ще до його початку. Product Owner уточнює беклог, щоб переконатися, що історії, які будуть включені в наступний спринт, чітко сформульовані та зрозумілі команді. Зазвичай власник продукту робить це разом із технічним лідером або менеджером розробки під час зустрічі, присвяченої уточненню беклогу (або, як її ще називають, зустрічі з удосконалення беклогу). Рисунок 12.1 наочно демонструє робочий потік, зустрічі та підсумки, що відповідають принципам Scrum. 

Кожен спринт команда починає з планування, де вирішує, які користувацькі історії будуть реалізовані в наступній ітерації. Обрані переміщуються з продуктового в беклог спринту. Однією з важливих частин цього процесу є оцінка масштабу кожної історії за допомогою балів, які відображають відносну трудомісткість виконання конкретної задачі. Процес оцінювання зазвичай є радше мистецтвом, ніж точною наукою. Існує багато різних систем вимірювання. Деякі з них дозволяють присвоювати історіям будь‐яку кількість балів — скажімо, 1, 2, 3, 4, 5, 6 тощо. Один із популярних підходів — використання послідовності Фібоначчі, де допустимими значеннями є 1, 2, 3, 5, 8, 13 і так далі. Перевагою цього підходу є те, що він чітко відображає різницю між оцінками, які йдуть одна за одною. Інша популярна система — шкала «степенів двійки», де використовуються значення 1, 2, 4, 8, 16 тощо. Ще один популярний метод базується на «розмірах футболок» і використовує для оцінки масштабу користувацьких історій позначення, зазвичай застосовувані до розмірів одягу: малий, середній, великий та дуже великий.

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

Якщо бали за історії здаються вам дещо абстрактними — це природно, особливо на початку роботи з ними. Їхня основна мета — допомогти визначити робочу спроможність команди, відстежуючи, скільки балів вона в середньому опрацьовує за одну ітерацію. Цей показник називається швидкістю (velocity). Щойно група визначить свою середню швидкість, вона зможе використовувати цю цифру для більш точного планування майбутніх спринтів. Хоча спершу бальні оцінки можуть здаватися дещо умовними, згодом вони стають зручним інструментом для практичного вимірювання обсягу роботи. Для того щоб розрахувати швидкість, оцінки мають бути виражені в числовій формі. Тому, якщо використовується метод футболок, кожному розміру необхідно призначити відповідне числове значення.

Канбан

Ще одним популярним різновидом Agile‐підходу є Канбан.тВін виник на основі системи, розробленої автомобільним концерном Toyota для вдосконалення процесу збирання авто. Ця система орієнтована на виробництво за принципом «саме вчасно» (just‐in‐time) та на мінімізацію витрат.  На підприємстві працівники використовують канбан‐картки, які слугують фізичними сигналами та вказують на необхідність упровадження в роботу нового завдання. Цю систему адаптували для розробки програмного забезпечення, де замість паперових карток застосовують віртуальні. Кожна з них уособлює виконуване завдання, але більше не функціонує як сигнал. Натомість відповідальність за просування наступної робочої задачі покладається на членів команди.

Основний принцип Канбану — візуалізація робочого процесу. Кожна картка відповідає історії користувача або завданню, пов’язаному з нею. Вони розміщуються на спеціальній канбан‐дошці з кількома стовпцями, що відповідають етапам процесу й розташовуються в порядку виконання. 

• Беклог — список завдань, які ще не взяті в роботу, але вже впорядковані за пріоритетом і чекають на свою чергу.

• Підготовлення — обрані з беклогу й повністю готові до передачі в розробку.

• Розроблення — завдання, над якими команда активно працює просто зараз.

• Завершено розроблення — виконані, але ще не передані на тестувальний етап.

• Тестування — ті, що перебувають у процесі перевірки на відповідність вимогам та якості.

• Завершено тестування — успішно випробувані, але ще не залучені до фінальної версії.

• Впровадження — завдання, які пройшли всі необхідні етапи й були офіційно включені до готового продукту.

Деякі стовпці відображають безпосередньо виконувану роботу (наприклад, «Розроблення виконується»), тоді як інші позначають етапи очікування обробки (зокрема «Підготовлення», «Завершено»). Саме останні дають змогу зрозуміти, які завдання перебувають у черзі. Коли хтось із команди закінчує поточну роботу, то обирає першу за пріоритетом картку з відповідного стовпця та переходить до нової задачі. У міру просування завдання робочим процесом картку поступово переміщують з одного стовпця канбан‐дошки доинаступного. Завдяки цьому можна швидко побачити, над чим команда працює в поточний момент. Також легко визначити, на якому етапі виникають затримки, — це видно за стовпцями, де картки накопичуються найбільше. У Канбані контроль за кількістю завдань, що перебувають у роботі, здійснюється через обмеження обсягу незавершеної роботи (НЗР). Команда визначає, скільки карток одночасно може розміщуватися в кожному зі стовпців на дошці. Це і є ліміт НЗР, який дозволяє уникнути перевантаження та підтримувати рівномірний темп. Задачі поступово переходять від одного етапу до іншого, але перемістити картку далі можна лише тоді, коли в наступному стовпці ще є вільне місце — тобто не перевищено встановлену межу. Такий підхід сприяє стабільному потоку завдань і допомагає команді зосередитися на завершенні поточної роботи, а не накопиченні нової. Час від часу ліміти переглядають і коригують відповідно до змін у процесі, щоб підтримувати оптимальну продуктивність. На канбан‐дошці ці обмеження зазвичай указуються над відповідними стовпцями. Часто для етапів, що складаються з кількох взаємопов’язаних стадій — наприклад, «Виконується» та «Завершено» в межах однієї фази, — встановлюють спільний ліміт. Так, для етапу «Розроблення» може бути визначено, що загальна кількість карток у двох його стовпцях не повинна перевищувати трьох. Це сприяє просуванню їх праворуч, тобто стимулює колектив швидше обробляти вже розпочаті завдання, перш ніж братися за нові.

Філософія Канбану спрямована на постійне вдосконалення, тому важливо, щоб ваша команда регулярно знаходила й обговорювала способи покращити та пришвидшити свою роботу. Ідея полягає в тому, що поступово час виконання замовлення та тривалість циклу повинні зменшуватися, оскільки колектив оптимізує процеси та набуває більшої майстерності. Багато команд працюють в умовах нестабільного беклогу: завдання, які спочатку здавалися важливими, згодом можуть втратити пріоритет, оскільки додаються нові елементи. На відміну від Scrum, де беклог спринту зазвичай закріплюється на період ітерації, в Канбані група має змогу будь‐якої миті коригувати беклог. У таких динамічних умовах тривалість циклу може стати кращим показником ефективності. Проте важливо також стежити за тим, скільки часу займає підготовка елементів беклогу до розробки, щоб це не впливало на загальну пропускну здатність команди.Якщо обсяг завдань варіюється, ви можете побачити значний розкид у тривалості циклів: менші завдання матимуть коротший цикл, а більші — довший. Деякі групи спеціалістів Канбану використовують підхід із розмірами футболок (малий, середній, великий тощо) для класифікації робочих елементів, що дозволяє отримати більш точні значення тривалості циклу. У такому разі для кожного «розміру футболки» буде своя окрема тривалість циклу. Канбан не передбачає таких жорстко визначених процесів, як Scrum, тому жодні контрольні заходи не є обов’язковими. Проте багато команд, що працюють за Канбаном, проводять щоденні стендап‐зустрічі та періодичні ретроспективи.