Припустимо, ви заходите до себе додому, сідайте на старий диван, з якого стирчать пружини, дивіться на стару, облуплену меблі і говорите собі: «так далі тривати не може!». Ви рішуче хочете змінити всю свою стару, потерту меблі на нову, екологічну і функціональну, підігнані спеціально під ваші потреби. Причому варіант ширвжитку з IKEA - не розглядається, т. К. У вас є свої, чітко усвідомлені специфічні вимоги до домашньої обстановки.
Ви йдете до ДУЖЕ крутому майстру, щиро вважаючи, що тільки профі здатний втілити в реальність ваші бажання. Виявляється, що чекати потрібно буде приблизно місяць. Це кілька зменшило ваш запал, але рішення вже прийнято. Та й дуже незатишно повертатися на потерте лежбище. Ви вносите передоплату, розповідаєте свої ідеї дизайнера, який детально все фіксує, задає вам розумні питання, підписуєте договір і
Чекаєте. Ви чекаєте довгий місяць, за який вам обіцяли все зробити. І весь цей час - стара, незручні меблі попадається вам на очі і під ноги, дратує вас. Чекаєте. Куди поділася радість спонтанної покупки? Ніхто з майстерні вам не дзвонить, особливо не турбує, не звітує, питань не задає ... Чекаєте.
А потім чекаєте ще два тижні. І ви вже в сказі. Від колишньої рішучості залишилося не так багато - а чи варто було взагалі затівати переробку? А потім ще чекаєте, ще чуть-чуть і ще три години, на які ви раніше пішли з роботи. І ось вам привозять новий комплект. Збирають, розставляють, і вам в голову б'є цілком виразна думка. НЕ ТЕ!
Якщо не використовувати Scrum
Це зовсім не те, що ви собі уявляли. Хоча це, можливо, і відповідає тому, що ви розповіли дизайнеру, але це не те, що вам потрібно. Оббивка бліда і абсолютно не подобається вашій новій подружці. До того ж з'ясувалося, що у вашого пса - алергія на пух в подушках. Стіл занадто високий, а крісла - занадто громіздкі. Але це вже все узгоджено з фірмою-виробником і у них є ваша підпис. Поміняти нічого не можна, вірніше - можна, але це буде коштувати стільки ж грошей і займе ще стільки ж часу. Про гарантії результату можна взагалі не говорити.
Управління розробкою ПЗ - це майже як керівництво меблевою фабрикою
До речі, ви знаєте, чому довелося стільки чекати? Вам, можливо, буде приємна думка, що майстер тижнями працював над кожною дошкою вашого гарнітура, або вишивальниця днями робила стібок за стібком, щоб встигнути вчасно зробити якісну вишивку. Що все це щогодини звірялося з дизайном, а менеджер за якістю невсипно стежив за виробництвом.
По-перше, ви могли замовити поетапно розробляє ціни меблів, розробка якої повинна вестися по чітко поставленим вами пріоритетам. Припустимо, найбільше вам потрібен диван, тому, що старий вже зовсім того, а крісла і стіл можуть ще трохи потерпіти. Відповідно, диван буде першим у списку пріоритетів, а студія зобов'язується виготовити і доставити його в першу чергу.
Що це дає? По-перше, ви задовольняєте свою найважливішу потреба в першу чергу, і пружини вже не скриплять ночами. А, по-друге, якщо вашої нової подружки відразу не сподобався колір оббивки і ви рішуче захочете її поміняти (оббивку, що не подружку) - ваші витрати будуть тільки на диван, без необхідності міняти оббивку на кріслах (т. К. Ті ще не готові ). Або взагалі, ви можете абсолютно без витрат змінити склад замовлення, прибравши з нього крісла, і додавши пуфики.
По-друге, ви могли попросити студію щодня розповідати вам про хід роботи. Всього три простих питання: що було зроблено за вчора, які плани на сьогодні, які є проблеми - і ви отримуєте повний контроль над ситуацією. І це добре!
SCRUM допоміг би вам в ситуації, коли ...
- Купа грошей і часу пішла на опрацювання ТЗ, але по ходу роботи над проектом змінилася концепція або бізнес-процеси. Доводити проект до кінця в тому вигляді, як описано в ТЗ - немає сенсу. Гроші на ТЗ викинуті даремно. Розробник відмовляється вносити зміни по ходу роботи, посилаючись на ТЗ.
- Розробник показує проект в останній день перед запуском. Однак все зроблено не так, як ви собі це уявляли. Потрібна значна переробка. Розробник по-своєму трактує описані в ТЗ вимоги і відмовляється вносити зміни в проект на цій підставі.
- Потрібно запустити кістяк інтернет-проекту з мінімально-можливим бюджетом і термінами. Додаткові функції розробляти вже після запуску, коли проект почне відбивати початкові інвестиції.
Знайоме? Швидше за все при розробці була використана «водоспадна» модель, або все взагалі йшло як-попало. Scrum - це альтернатива, позбавлена перерахованих вище недоліків. І ось чому:
Механіка процесу в web-розробці
Ок, давайте перейдемо до замовний web-розробці. Про те, як оформити договірні відносини я розповім в кінці статті. А поки - подивимося на те, як буде побудований процес роботи. Я виходжу з того, що головний критерій щастя замовника - це коли він отримує не просто продукт, відповідний характеристикам, спочатку зазначеним у ТЗ, а то, що йому дійсно було потрібно. І отримує цей продукт так швидко, як це взагалі можливо. Нехай, не буде вистачати частини функцій, і їх будуть реалізовувати по ходу, але проект відразу почне приносити гроші, не чекаючи повної реалізації всіх дрібних внутрішніх деталей.
Далі ми будемо розглядати тільки фазу програмування (для простоти), хоча при бажанні подібний підхід можна поширити і на деякі інші фази робіт. Зауважу, що найбільш добре Scrum проявляє себе на технічно складних проектах з великим об'ємом програмування (хоча, при певній адаптації годиться і для складання типових сайтів). Отже, робота по Scrum будується наступним чином.
Backlog замість технічного завдання
Backlog - документ, який містить список всіх вимог до проекту (бачення проекту, список того, що повинно бути реалізовано). Пункти списку впорядковані за ступенем важливості. По ходу проекту список і пріоритети можуть мінятися, залежно від потреб замовника, нових ідей або зміни умов.
Так, в класичному Scrum мається на увазі, що замовник проекту може вносити будь-які зміни прямо по ходу проекту (але не в поточний етап розробки). Однак в разі розробки сайтів, бюджет здебільшого фіксований (виняток - деякі startup-проекти). А значить, і можливості замовника впливати на хід виконання - теж обмежені.
Проте, я вважаю, що потреба додавати або змінювати будь-які функції проекту для замовника дуже актуальна. Це допомагає розробити проект, який дійсно потрібен клієнту, а не те, що формально описано в ТЗ. Тому, як backlog-а у нас, як правило, використовується перелік завдань з технічного завдання, окреслених і закріплених в договорі, плюс фіксовані в доп. угодах доопрацювання, що виникають по ходу роботи.
Спринт - етап розробки. Вся розробка проекту йде короткими етапами (спринт). Функції, які потрібно реалізувати на кожному спринті - зафіксовані (їх не можна змінювати по ходу спринту). Вони розбиті на завдання, а завдання мають оцінки і пріоритети.
У класичному Scrum передбачається, що тривалість спринту фіксована і, як правило, становить від 2 до 4-х тижнів, в залежності від досвіду команди. Оскільки далеко не всі сайти вимагають настільки тривалої фази розробки (особливо з огляду на, що розробка ведеться 2-3 програмістами паралельно), ми вирішили обмежити тільки максимальну тривалість спринту. Нам підійшли двотижневі спринти. Однак, якщо команда може зібрати проект за 3 дні - значить ми формуємо 3-х денний спринт.
Результатом роботи кожного спринту стає повністю відтестовані проект, в якому реалізовані всі функції попередніх спринтів + приріст функціональності з поточного. Це дозволяє здійснити запуск проекту на самих ранніх стадіях, реалізувавши лише найнеобхідніший мінімум функціоналу, і вже паралельно з роботою сайту проводити розробку наступних за важливістю частин проекту.
Такий підхід хороший, наприклад, для інтернет-магазинів, які можуть запустити продажу (почати приносити прибуток замовнику) ще до того, як всі задумані функції будуть введені в лад.
Ху із ху на проекті
При розробці по scrum на проекті є парочка ключових ролей. Product Owner - власник продукту. Відповідає за представлення інтересів замовника і кінцевих користувачів на проекті. Чи не є членом команди розробників. В ідеалі це має бути представник замовника. Однак, оскільки ця роль накладає дуже високі вимоги до досвіду і компетенції індивіда в сфері розробки і розвитку інтернет-проектів, а так само вимагає постійного особистої участі в проекті (що не завжди можливо для замовника) - в нашому випадку цю роль виконує менеджер проекту.
Ну і звичайно, на проекті є команда розробників :-) А в ній: Scrum Master - член команди, що стежить за дотриманням принципів Scrum і проводить щоденні планерки. Роль не передбачає якихось додаткових повноважень по проекту, крім самого Scrum-а.
Робота по етапах і пріоритетам