Agilný vývoj vs. waterfall: čo vybrať, aby ste neplatili za nesprávny softvér
Dodávateľ ponúka dvojtýždňové sprinty. Vy potrebujete cenu, termín a istotu, že nový systém zvládne chod firmy. Iný dodávateľ sľubuje presný plán, lenže zamestnanci ešte netušia, ako by mali nové obrazovky fungovať. Správny postup závisí od toho, čo už viete a čo sa ešte musíte dozvedieť.
Pri vývoji na mieru sa dá splniť zadanie a napriek tomu postaviť systém, ktorý ľudia obchádzajú. Dá sa tiež priebežne upravovať každá funkcia a pritom stratiť prehľad o rozpočte. Označenie „agilný“ ani „waterfall“ vás pred týmito výsledkami neochráni. Rozhoduje spôsob overovania požiadaviek, zodpovednosť za rozhodnutia a pravidlá, podľa ktorých prijímate hotovú prácu.
Pre slovenskú firmu, ktorá objednáva CRM, e-shop alebo klientsky portál, preto nie je prvou otázkou počet stretnutí vývojárov. Potrebuje vedieť, kedy uvidí použiteľný výsledok, čo môže zmeniť a aký vplyv to bude mať na cenu a spustenie. Práve podľa toho má zmysel vyberať postup.
01Rozhoduje, ktoré požiadavky máte overené
Agilný vývoj postupuje po menších častiach. Tím vytvorí použiteľnú funkciu, overí ju a podľa zistení upraví ďalšiu prácu. Je užitočný tam, kde poznáte obchodný cieľ, ale ešte hľadáte najlepší spôsob, ako ho dosiahnuť. Princípy Agilného manifestu zdôrazňujú priebežné dodávanie hodnotného softvéru a spoluprácu medzi ľuďmi z firmy a vývojármi.
Waterfall, teda vodopádový model, organizuje projekt do nadväzujúcich fáz, napríklad analýzy, návrhu, implementácie a overenia. Pred prechodom do ďalšej fázy sa schvaľujú dohodnuté výstupy. Takýto postup môže byť vhodný pri stabilných požiadavkách, pevne určených rozhraniach a závislostiach, ktoré treba zladiť vopred. Zmeny nevylučuje, ale rieši ich cez dohodnuté posúdenie a schválenie.
Rozdiel nie je v tom, či tím plánuje. Rozdiel je v tom, koľko detailov sa snaží uzavrieť vopred a ako často plán upravuje podľa skúsenosti s fungujúcim softvérom. Dokumentácia, zmluva aj plán majú svoje miesto v oboch postupoch. Aj Agilný manifest výslovne priznáva hodnotu týmto veciam, hoci väčšiu váhu dáva fungujúcemu softvéru, spolupráci a schopnosti reagovať na zmenu.
- Ak ešte overujete potreby používateľov, rozdeľte riešenie na menšie použiteľné časti a získavajte spätnú väzbu.
- Ak je výsledok podrobne opísaný a závisí od pevných termínov iných dodávateľov, pomôžu jasné fázy a schvaľovanie výstupov.
- Ak má projekt pevné technické hranice a zároveň neisté používateľské potreby, dohodnite kombináciu oboch postupov.
02Porovnanie, ktoré pomôže pri výbere dodávateľa
| Otázka | Agilný postup | Waterfall |
|---|---|---|
| Ako vzniká zadanie? | Cieľ sa určí vopred, detaily sa priebežne spresňujú. | Podrobný rozsah a kritériá prijatia sa schvaľujú pred realizáciou. |
| Kedy firma overuje výsledok? | Pravidelne na použiteľných častiach, ktoré ovplyvnia ďalšie priority. | Pri dohodnutých kontrolách návrhu, výstupov fáz a hotového riešenia. |
| Ako sa menia požiadavky? | Mení sa poradie alebo rozsah ďalšej práce s posúdením dopadov. | Zmena schváleného zadania prejde dohodnutým schvaľovaním. |
| Ako sa plánuje? | Podrobne na najbližšie obdobie, ostatné kroky s primeranou neistotou. | Výraznejšie vopred podľa fáz, závislostí a míľnikov. |
| Čo je v dokumentácii? | Rozhodnutia, požiadavky, rozhrania a informácie potrebné na prevádzku. | Schválené zadanie, návrh, výstupy fáz a podklady na prevzatie. |
| Kedy sa testuje? | Pri tvorbe jednotlivých častí aj pri overovaní celku. | Kontroly a čiastkové testy môžu prebiehať priebežne, finálne overenie má vlastný míľnik. |
| Koľko času potrebuje klient? | Pravidelný priestor na rozhodovanie, skúšanie a určovanie priorít. | Najmä intenzívnu prípravu a účasť pri dohodnutých schváleniach. |
| Čo určuje cenu? | Dohodnutý obchodný model, rozsah a kapacita tímu. | Dohodnutý obchodný model, presnosť zadania a schválené zmeny. |
Pýtajte si ukážku toho, ako dodávateľ eviduje rozhodnutia a overuje výstupy. Užitočnejšie než pekná prezentácia metodiky je konkrétna požiadavka s kritériami prijatia, výsledkom testu a záznamom, kto ju odsúhlasil. Podľa týchto podkladov sa dá neskôr rozlíšiť nedokončená práca, chyba a požiadavka, ktorá v pôvodnom rozsahu nebola.
03Agilný vývoj: keď správne riešenie zistíte až pri používaní
Predstavte si modelový klientsky portál pre slovenskú servisnú firmu. Majiteľ chce menej telefonátov o stave zákaziek. Prvé zadanie obsahuje rozsiahly prehľad, dokumenty, správy a hodnotenie služby. Pri skúšaní však klienti najviac potrebujú jednoduchú informáciu, či môžu zariadenie vyzdvihnúť. Rozsiahly prehľad môže počkať.
Tím preto najprv pripraví úzky, ale úplný postup: klient sa prihlási, otvorí svoju zákazku a vidí aktuálny stav. Overí sa aj to, odkiaľ stav prichádza, čo sa stane pri výpadku prepojenia a kto smie údaje zobraziť. Pri ďalšom rozhodovaní už vychádzate z toho, ako si klienti s portálom poradili. Podobnú logiku má overenie nápadu pred vývojom MVP.
Agilný postup potrebuje človeka z firmy, ktorý vie rozhodnúť medzi potrebami obchodu, účtovníctva a prevádzky. Ak každý vedúci pridáva vlastné zadanie a nikto neurčuje poradie, vývoj sa rozbieha viacerými smermi. Dohodnite, kto rozhoduje, ktorí používatelia budú výsledky skúšať a dokedy dostane tím odpoveď. Ich účasť patrí do plánovania kapacity.
Scrum nie je synonymum agilného vývoja
Scrum je jeden konkrétny rámec práce. Podľa Scrum Guide 2020 trvá sprint najviac jeden mesiac a jeho výsledok musí byť použiteľný a overený. Dvojtýždňový sprint nie je povinnosť. Ani jeho koniec automaticky neznamená verejné vydanie pre všetkých zákazníkov. Použiteľný prírastok sa dá vydať aj skôr; produkčné nasadenie treba zladiť s pripravenosťou prevádzky.
Dohodnite si aj význam slova „hotové“. Pri portáli nestačí, že sa obrazovka otvorí. Potrebujete overené oprávnenia, správanie pri chybe, skúšku na mobilnom telefóne a podklady pre správcu. Pre pravidelné vyhodnotenie pripravte reálnu úlohu, ktorú si človek z firmy môže vyskúšať. Zoznam naprogramovaných obrazoviek sám osebe neukáže, či portál znižuje počet telefonátov o stave zákaziek.
04Waterfall: keď potrebujete držať pevné rozhrania a nadväzujúce termíny
Iná modelová situácia: distribučná firma mení prepojenie e-shopu s ERP. Formáty údajov sú zdokumentované, účtovníctvo má odsúhlasené pravidlá a dodávateľ ERP vyhradil konkrétny termín prechodu. Prioritou je preniesť objednávky, ceny a skladové stavy podľa známych pravidiel. Otvorená diskusia o vzhľade obrazoviek tu nevyrieši hlavnú závislosť.
Má zmysel schváliť mapovanie údajov, správanie pri opakovanej požiadavke, pravidlá pre chyby a podmienky migrácie. Potom sa overí návrh prepojenia, implementácia a pripravenosť na prechod. Každý míľnik má jasný výstup a človeka, ktorý ho prijme. Podklady k rozhraniam a prevádzke potrebujete aj po odovzdaní projektu; praktické otázky rozoberá aj text o prepájaní systémov cez API.
Waterfall nemusí znamenať, že sa prvý test uskutoční až na konci. Testovacie scenáre môžete pripravovať pri príprave požiadaviek, návrh preveriť na vzorke údajov a jednotlivé komponenty testovať počas vývoja. Aj príručka NASA k overovaniu produktov opisuje overovanie v rôznych fázach životného cyklu a prípravu testovacích postupov už počas návrhu. Je to príklad princípu, nie požiadavka na bežný firemný projekt.
Slabým miestom je predpoklad, že schválené zadanie naozaj vystihuje potreby. Ak si firma objedná CRM podľa starého formulára v Exceli a obchodníci ho prvýkrát vyskúšajú až pred odovzdaním, môže dostať správne naprogramovaný nesprávny proces. Aj pri fázovom postupe preto včas ukážte používateľom prototyp a skúste zložité prípady.
05Kombinácia postupov: pevný základ, priebežné overovanie funkcií
Pri e-shope na mieru môžu byť pravidlá ERP a termín migrácie pevné, zatiaľ čo zákaznícky účet či opakovaná objednávka sa ešte hľadajú. Celý projekt nemusíte natlačiť do jedného režimu. Najprv odsúhlaste rozhrania, zdroj pravdivých údajov, oprávnenia a podmienky prechodu. Používateľské postupy potom rozvíjajte v menších častiach.
Hranice musia byť čitateľné. Zmena tlačidla v košíku môže zostať v najbližšej iterácii. Zmena výpočtu dostupnosti tovaru môže zasiahnuť ERP, sklad aj zákaznícku podporu a vyžaduje širšie schválenie. Zapíšte, kto takýto dopad posúdi a kto rozhodne o ďalšom postupe. Tým zabránite tomu, aby „priebežné spresnenie“ potichu zmenilo celé riešenie.
Kontrola pred spustením zostáva spoločná: skúška migrácie, záloha, pripravená podpora a postup návratu pri probléme. Fungujúca funkcia v testovacom prostredí ešte nedokazuje, že je pripravený sklad alebo účtovníctvo. Pri kombinovanom postupe si preto oddeľte overenie funkcie od rozhodnutia, či je firma pripravená začať ju používať.
06Rozpočet a zmluva: čo si dohodnúť skôr, než sa začne programovať
Agilný vývoj automaticky neznamená účtovanie podľa hodín. Waterfall automaticky neznamená pevnú cenu. Obchodný model a organizácia vývoja sú dve samostatné rozhodnutia. Pevná cena potrebuje dostatočne zrozumiteľný rozsah, predpoklady a pravidlá pre zmeny. Platba za odpracovaný čas potrebuje priebežný prehľad o práci a jasné oprávnenie ďalší rozpočet schváliť.
Ak trváte na pevnom rozpočte aj termíne, určite poradie funkcií a minimálny prijateľný výsledok. Nová požiadavka môže nahradiť menej dôležitú funkciu, môže sa odložiť alebo si vyžiada nový rozpočet a termín. Ak je celý rozsah nevyhnutný, nezakrývajte neistotu sľubom, že tím všetko stihne. Najprv overte neznáme prepojenie či migráciu a až potom spresnite záväzky.
- Prevzatie práce: konkrétne kritériá, spôsob skúšania a človek, ktorý výsledok odsúhlasí.
- Priebežný prehľad: čo je použiteľné, čo sa ešte dokončuje, koľko sa minulo a aký je aktualizovaný odhad zvyšnej práce.
- Zmena zadania: stručný opis, dôvod, dopad na cenu a termín a schválenie pred realizáciou.
- Odovzdanie a prevádzka: prístupy, zdrojový kód, dokumentácia, zodpovednosť za nasadenie a dohodnutá podpora.
Aj malú zmenu posudzujte podľa dopadu. Nové pole v CRM môže ovplyvniť export, vyhľadávanie, existujúce záznamy aj integráciu. Rozsah neodhadujte iba podľa veľkosti prvku na obrazovke. Takýto prehľad pomáha firme vedome rozhodnúť, za čo zaplatí, a dodávateľovi vysvetliť, čo zmena vyžaduje.
07Sedem otázok, ktoré si položte nad vlastným projektom
Sadnite si spolu s človekom z prevádzky a dodávateľom nad tieto otázky. Odpovede píšte ku konkrétnym funkciám. „Zadanie máme hotové“ je málo, ak ešte nikto nevidel reálne výnimky pri reklamácii alebo storne objednávky.
- Čo má softvér zmeniť v každodennej práci? Pomenujte výsledok, napríklad objednávku bez ručného prepisovania. Určite, na akých údajoch alebo pozorovaní si overíte, že zmena pomohla.
- Ktoré požiadavky sú naozaj stabilné? Oddeľte pevné účtovné a integračné pravidlá od predstavy o obrazovkách. Pri neoverenom postupe počítajte so skúšaním a úpravami.
- Kto bude priebežne skúšať výsledok? Vyberte ľudí, ktorí danú prácu vykonávajú, vrátane menej skúseného kolegu. Potvrďte ich dostupnosť a prístup k testovacím údajom.
- Kto rozhodne pri rozdielnych požiadavkách? Určite jedného zodpovedného človeka a jeho zastupovanie. Ak rozhodnutie potrebuje ďalšie schválenie, zohľadnite jeho čas v pláne.
- Od čoho závisí spustenie? Spíšte prístupy, súčinnosť dodávateľa ERP, kvalitu údajov, migráciu a školenie. Aj pri pravidelných iteráciách potrebujete prístup k testovaciemu prostrediu.
- Ktorá neskorá zmena bude najdrahšia? Nový vzhľad prehľadu a zmena vlastníctva zákazníckych údajov majú odlišný dosah. Najrizikovejšie predpoklady overte pred rozsiahlym vývojom.
- Čo má prednosť pri probléme: termín, rozsah alebo rozpočet? Dohodnite minimum pre prvé spustenie a pravidlá schvaľovania zmien. Zodpovední ľudia majú poznať rovnaké priority.
Keď nedokážete odpovedať na prvé otázky, začnite prípravnou fázou s vopred dohodnutým rozsahom, cenou a výstupmi. Jej účelom je spresniť zadanie a riziká. Nemá byť otvoreným záväzkom pokračovať vo vývoji bez rozhodnutia o ďalšom rozpočte.
08Ako pripraviť prvú etapu vývoja
Nasledujúci postup je odporúčaný rámec prípravy, nie sľub termínu dodania. Dĺžka jednotlivých krokov závisí od projektu a dostupnosti ľudí. Každý krok má skončiť podkladom, podľa ktorého viete rozhodnúť o pokračovaní.
- Vyberte jeden pracovný postup. Spíšte problém, používateľov, systémy, minimálny výsledok a obmedzenia. Dohodnite, čo do prvej etapy nepatrí.
- Rozdeľte známe a neznáme. Pri novom portáli vyskúšajte prototyp s používateľmi. Pri integrácii overte dostupnosť rozhrania a vzorku údajov. Výsledok zapracujte do zadania.
- Dohodnite rozsah a zmeny. Určite rozhodujúceho človeka, kritériá prijatia, schvaľovanie zmien a prehľad nákladov. Vyberte iterácie, fázy alebo ich kombináciu.
- Otestujte prvú funkčnú časť. Overte reálnu úlohu od začiatku do konca vrátane výnimiek. Podľa výsledku upravte ďalšie priority a pripravte prevádzkové podmienky spustenia.
Pri ponuke na webovú aplikáciu na mieru žiadajte aj opis tejto spolupráce. Viete, kto sa zo strany firmy zapojí, čo sa bude overovať a čo dostanete pri odovzdaní? Potom sa dá posúdiť, či zvolený postup zodpovedá projektu. Samotná nálepka metodiky vám túto odpoveď nedá.
09Časté otázky
Je agilný vývoj vždy rýchlejší a lacnejší než waterfall?
Nie. Môže pomôcť skôr odhaliť nesprávnu predstavu o funkcii a odložiť menej dôležitú prácu. Vyžaduje však rozhodovanie a priebežnú spätnú väzbu. Pri stabilnom zadaní a pevných závislostiach môže dobre fungovať aj fázový postup. Cenu a čas posudzujte podľa konkrétneho rozsahu a rizík.
Musíme pri agilnom vývoji používať Scrum?
Nie. Scrum je konkrétny rámec, agilný vývoj je širší prístup. S dodávateľom si dohodnite pravidlá, ktoré skutočne používate. Pre firmu je podstatné, ako často overí použiteľný výsledok, kto určuje priority a ako sa sledujú náklady a kvalita.
Znamená dvojtýždňový sprint nové verejné vydanie každé dva týždne?
Nie. Dĺžka sprintu a termín produkčného nasadenia sú odlišné veci. Novú funkciu môže firma najprv overiť v testovacom prostredí alebo s menšou skupinou používateľov. Verejné spustenie závisí aj od migrácie, podpory a pripravenosti nadväzujúcich systémov.
Dá sa agilný projekt objednať za pevnú cenu?
Áno, ak je jasné, aký rozsah a predpoklady cena pokrýva a ako sa schvaľujú zmeny. Dá sa tiež dohodnúť pevný rozpočet na etapu s prioritami. Pri zmene požiadaviek musíte otvorene posúdiť, či sa upraví rozsah, cena alebo termín. Metodika tento obchodný rozhovor nenahrádza.
Testuje sa pri waterfall modeli až na konci?
Nemusí. Scenáre prijatia sa môžu pripravovať už pri príprave požiadaviek a čiastkové kontroly či testy počas návrhu a vývoja. Finálne overenie celku zostáva samostatným míľnikom. Od dodávateľa si vypýtajte plán, ktorý ukáže, čo sa overí v každej fáze.
Čo ak nemáme čas pravidelne skúšať aplikáciu?
Určite zástupcu firmy s oprávnením rozhodovať a vyhraďte mu čas. Ak to nejde, obmedzenie povedzte dodávateľovi vopred a dohodnite realistické kontroly. Menej spätnej väzby zvyšuje neistotu o správnosti riešenia; samotné premenovanie projektu na waterfall ju neodstráni.
Môžeme začať waterfall modelom a neskôr prejsť na agilný vývoj?
Áno, napríklad po schválení rozhraní a podmienok migrácie môžete používateľské funkcie rozvíjať priebežne. Dohodnite nové pravidlá priorít, prevzatia práce a riadenia zmien. Skontrolujte aj rozpočet a zodpovednosti, aby obe strany očakávali rovnaký spôsob spolupráce.