Водопад или Scrum: как да изберете начина за изпълнение на вашия проект

При почти всеки първи разговор се появява един и същ въпрос, понякога изречен, понякога не: това ще го правите ли по водопадния модел, или гъвкаво? Зад него обикновено стои предишен опит. Или проект по водопадния модел, който година по-късно предаде нещо, което вече не вършеше работа; или „гъвкав“ проект, който така и не приключи, защото всеки спринт сменяше посоката.

И двата подхода работят; проблемът е, когато от интеграция с основната система се иска да се открива по пътя, а от дигитален канал — да се подписва на фази. Изборът зависи от три неща: колко определен е обхватът, кой може да определя приоритетите и как ще се приема всяка доставка. Тази статия е, за да изберете правилно.

Въпросът, който решава

Преди да говорим за етапи или церемонии, отговорете на това: можете ли днес да напишете достатъчно точно какво трябва да прави системата, когато е завършена?

• Ако да —защото го диктува норма, договор, процес, който вече съществува, или система, която ще се замени—, подходящо е да се работи на етапи. Стойността е в това да не се греши, и всеки етап намалява риска на следващия.
• Ако не —защото е нов продукт, дигитален канал или идея, която трябва да се изпита с потребители—, подходящо е да се работи на кратки цикли. Стойността е в това да се учи бързо, и всеки цикъл коригира посоката с онова, което вече е видяно.

Има и други признаци, които тласкат към едната или към другата страна:

На етапи: V-модел

Това е водопад: шест етапа, един след друг, всеки с предаваем резултат, който се преглежда, преди да се мине към следващия. Онова, което го превръща във V-модел, е кога се определят тестовете: не накрая, а от самото начало.

Етапите са шест:

1. Начало. Бизнес нуждата се записва като история: какво се иска да се постигне, защо, какви са границите ѝ и кой решава. Изглежда като формалност, а е най-евтиното нещо в проекта: тук недоразумението струва един разговор; по-късно същото недоразумение струва преработка.
2. Анализ. Установява се онова, което съществува: процеси, системи, данни и правила, включително тези, които знае само един човек от екипа. При старите системи този етап е този, който изненадва най-много, защото обикновено се появяват правила, които никой не е записал.
3. Проектиране. Първо се моделира бизнесът и след това технологията. Това се нарича проектиране, ръководено от домейна (DDD): частите на системата носят имената и границите на бизнеса, а не тези на базата данни. От тук излизат архитектурата, матриците с правила и тестовите случаи с очаквания им резултат. Това е точката, която най-много интересува този, който плаща: още от проектирането той знае спрямо какво ще приема.
4. Изграждане. Програмира се спрямо тази матрица. Всяка част пристига със своите модулни тестове и, когато се свързва с друга система, с тестове на тази връзка, които всеки може да пусне отново, като колекции на Postman или скриптове, без да зависят от нас. Тези тестове остават при клиента.
5. Тестване. Два отделни вида тестване. При тестването за качество (QA) проверка, независима от този, който е програмирал, изпълнява цялата матрица. При приемателното тестване (UAT) хората на клиента валидират в собствената си среда, със своите реални случаи. Това, че не го тества този, който го е направил, не е недоверие: който е програмирал, вече е решил кое е важно и затова не вижда онова, което е оставил извън обхвата.
6. Внедряване. Пускане в работа с договорен план за връщане назад, ръководство за ползване и за експлоатация и подкрепа през първите дни.

Защо се нарича „V-модел“

При водопад, воден линейно, тестовете обикновено се струпват след изграждането, когато една грешка вече е скъпа. При V-модела всеки тест се определя в етапа, който го поражда, и се изпълнява по-късно: модулните и интеграционните — по време на изграждането, а матрицата за качеството и приемането — в етапа на тестване, преди внедряването. Буквата V е заради формата на буквата, а не число:

Нарисувано, пътят надолу (начало, анализ, проектиране, изграждане) слиза по едната страна на буквата V, а тестовете се изкачват по другата, всеки срещу етапа, който проверява. Това е моделът, който предпочитаме там, където една грешка струва скъпо, защото всяко изискване е свързано с тестовете, които го проверяват. Ползваме го в облекчен вид: без документация, която не носи полза.

Какво изисква от вас: време в началото и в анализа и подписването на матрицата на тестовете при проектирането. Ако това е направено добре, изграждането изисква по-малко от вашето време, освен за решения или съществени промени.

Рискът при този подход: бизнесът да се промени, докато се изгражда. Смекчава се с къси етапи: по-добре е да се предава на участъци от по няколко седмици, отколкото в един-единствен блок от една година.

На цикли: Scrum

Scrum организира работата в спринтове от една до четири седмици; ние предпочитаме две или три. Във всеки се предава завършен и тестван инкремент, а не напредък в презентация.

Церемониите са малко и всяка има своето предназначение:

• Планиране на спринта (Sprint Planning). Целият екип договаря целта на цикъла, а тези, които изграждат, избират от приоритизирания списък онова, което могат да завършат, за да я изпълнят.
• Ежедневен Scrum (Daily Scrum). Петнайсет минути за екипа, за да прегледа как върви спрямо целта на спринта и да коригира плана за деня. Служи за отблокиране, а не за информиране на началник.
• Преглед на спринта (Sprint Review). Сесия за работа с изграденото в действие, заедно с този, който ще го ползва; с онова, което се научава, отговорникът за продукта коригира списъка.
• Ретроспектива (Sprint Retrospective). Екипът преглежда как е работил и променя едно-две неща за следващия цикъл.

И две неща, за които трябва да се внимава: приоритизираният списък (Product Backlog), чийто ред се определя от отговорника за продукта (Product Owner) и който е видим за всички, и дефиницията за „Готово“ (Definition of Done), която описва какво качество трябва да изпълнява всеки инкремент, за да се смята за завършен; освен това всяка история влиза със свои критерии за приемане.

Какво изисква от вас: отговорник за продукта с време и с пълномощия да решава. Това е изискването, което най-много се подценява. Без този човек Scrum се превръща в екип, който на всеки две седмици предава неща, които никой не преглежда.

Рискът при този подход: да се бърка гъвкаво с импровизирано. Гъвкавото не премахва тестовете и критериите за приемане: всяка история влиза със своите и излиза със своите тестове, точно както при работата на етапи.

Кога е подходящо да се ползват и двата

На практика много големи проекти имат и двете природи. Една застрахователна компания, която пуска дигитален канал за продажби, има нужда на етапи от интеграцията със своята система за полици (core) и с ERP, където една грешка струва пари и регулаторни последици. И има нужда на цикли от опита на клиента в канала, който се улучва само чрез изпитване с потребители.

Могат да се комбинират без хаос с три правила:

1. Ясна граница. Интерфейсите между двете части се проектират и се замразяват на етапи; зад тази граница всяка страна върви със своето темпо.
2. Един-единствен отговорник, който вижда двете части и ги поставя в един и същ календар.
3. Една и съща мярка за качество. И двете части се приемат спрямо тестове, написани преди изграждането на всяка част.

Споделеното пространство

Една методология дава малко, ако въпросите отнемат седмица, докато стигнат до този, който ги решава. Затова, независимо дали е на етапи, или на цикли, подходящо е да се работи в споделени пространства от първия ден: канал за пряк разговор с екипа, който изгражда (Slack, Microsoft Teams или този, който вече ползва вашата компания), и табло, на което се виждат задачите, техните отговорници и състоянието им (ClickUp, Jira или друго). Така клиентът следи проекта в реално време, а не в доклад накрая, и решенията остават записани с дата и с кой ги е одобрил.

Как да решите във вашия случай

Една практическа насока: прегледайте таблицата в началото. Ако повечето от вашите отговори попадат в една колона, започнете с този подход; ако се разпределят, вероятно ви подхожда да ги комбинирате. А ако още не знаете кой ви подхожда, нормално е: отговорът зависи от това коя част от вашия проект тежи повече. При първия разговор го преглеждаме с вас и ви казваме как бихме го изпълнили, участък по участък.