Систематизація автоматизації грудня 2008

Персональна картка пам'яті

Багато паперу списано та й мегабайтів перекачано у процесі, коли одні намагаються зрозуміти, що таке Scrum, інші намагаються це пояснити. Головна перевага Scrum у цьому сенсі полягає в тому, що для того, щоб почати його застосовувати не потрібно багато чого - бери готові нескладні правила, мінімум артефактів, і коліщатка закрутилися. Але розуміння глибокої суті цього процесу настає далеко ще не відразу.

Як відомо, центром будь-якого scrum-проекту є product backlog. Це місце, куди product owner записує свої побажання, оцінюючи їхню значущість і разом із командою планує ітерації. Здавалося б, що може бути простіше? Але чим же цей підхід виявився кращим за інших? Чим він відрізняється, скажімо, від випадку, коли замовник просто заводить тікети, наприклад, JIRA? Що робить цей проект таким ефективним?

Для того, щоб це зрозуміти, достатньо поглянути на переклад терміна “backlog” (ну, або до тлумачного словника для носіїв мови):

борг, заборгованість
невиконані замовлення
резерви (товарів, матеріалів тощо)

На мою думку, значення цього терміна – квінтесенція всього процесу. Спробуймо розібрати його за пунктами.

Backlog – це не список завдань для розробників

Ні, звичайно, зрештою розробник працює зі списком конкретних завдань. Але спочатку, з погляду product owner, список конкретних завдань – це нудні подробиці. Насамперед із перекладу випливає, що backlog – цене список завдань і навітьне список user stories, які потрібно виконати, а списокнедоліків системи. Під недоліками маються на увазі недостатня функціональність, недостатня якість реалізації, недостатнявідповідність очікуванням бізнесу тощо. Тут видно чудову властивість терміна "недолік", яке полягає в тому, що воно узагальнює артефакти кількох підпроцесів: фіча, вдосконалення, дефет.

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

Такий підхід, серед інших переваг, має одну важливу перевагу: він побудований на позитивному мисленні творців, які прагнуть у своїй роботі до досконалості, підігріваючи творчий потенціал учасників процесу. Адже навіть Мікеланджело був прихильником такого принципу: на питання про те, як він створює такі досконалі скульптури, він відповів “Я просто беру різець і відсікаю від мармуру все зайве”. Правда, схоже? :)

Мається на увазі, що програма існує на етапі планування

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

Виживають найважливіші вимоги

Виходить, щопроцес управління недоліками підкреслюєеволюційну природу Scrum. Планування кожного спринту - це, по суті, природний відбір завдань, де критерієм відбору є ступінь її важливості для застосування на даному етапі еволюції. А механізм відбору є універсальним – боротьба за ресурси: ми просто обмежуємотривалість спринту. Ну і важливо спланувати спринт так, щоб після його закінчення ми отримали повноцінний екземпляр програми, який повинен бути як мінімум не гірший за попередній.

Навіщо це все?

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