Zdá sa, že každá technologická organizácia v súčasnosti praktizuje agilnú metodológiu pre vývoj softvéru alebo jeho verziu. Alebo aspoň veria, že áno. Či už ste v agilnom vývoji aplikácií nováčikom alebo ste sa vývoj softvéru učili pred desiatkami rokov pomocou metodiky vývoja vodopádu, dnes je vaša práca minimálne ovplyvnená agilnou metodológiou.
Čo je to však svižná metodológia a ako by sa mala praktizovať pri vývoji softvéru? Ako sa v praxi líši agilný vývoj od vodopádu? Čo je to životný cyklus agilného vývoja softvéru alebo agilné SDLC? A čo je scrum agilný verzus Kanban a ďalšie agilné modely?
Spoločnosť Agile bola formálne uvedená na trh v roku 2001, keď 17 technikov vypracovalo Agilný manifest. Napísali štyri hlavné princípy agilného riadenia projektov s cieľom vyvinúť lepší softvér:
- Jednotlivci a interakcie nad procesmi a nástrojmi
- Pracovný softvér nad komplexnou dokumentáciou
- Spolupráca so zákazníkom pri dojednávaní zmluvy
- Reagovanie na zmenu plánu
Before agile: éra metodiky vodopádov
Staré ruky ako ja si pamätajú časy, keď bola metodika vodopádu zlatým štandardom pre vývoj softvéru. Proces vývoja softvéru vyžadoval vopred veľa dokumentácie, než sa začalo s programovaním. Niekto, zvyčajne obchodný analytik, najskôr napísal dokument s požiadavkami na podnikanie, ktorý v aplikácii zachytil všetko, čo podnikanie potrebuje. Tieto dokumenty obchodných požiadaviek boli dlhé a obsahovali všetko: celkovú stratégiu, komplexné funkčné špecifikácie a vizuálne návrhy používateľského rozhrania.
Technológovia vzali dokument s požiadavkami na podnikanie a vyvinuli vlastný dokument s technickými požiadavkami. Tento dokument definoval architektúru aplikácie, dátové štruktúry, objektovo orientované funkčné vzory, užívateľské rozhrania a ďalšie nefunkčné požiadavky.
Tento vodopádový vývojový proces softvéru by konečne odštartoval programovanie, potom integráciu a nakoniec testovanie skôr, ako bude aplikácia považovaná za pripravenú na výrobu. Celý proces môže ľahko trvať pár rokov.
Od nás vývojárov sa očakávalo, že budeme poznať „špecifikáciu“, ako sa volala kompletná dokumentácia, rovnako ako to robili aj autori dokumentov, a často sme boli potrestaní, ak sme zabudli správne implementovať kľúčový detail uvedený na strane 77 dokumentu 200- stránkový dokument.
Samotný vývoj softvéru vtedy tiež nebol ľahký. Mnoho vývojových nástrojov vyžadovalo špecializované školenie a nikde v okolí neboli open source ani komerčné softvérové komponenty, API a webové služby, ktoré dnes existujú. Museli sme vyvinúť veci na nízkej úrovni, ako napríklad otváranie databázových pripojení a viacvláknové spracovanie údajov.
Aj pri základných aplikáciách boli tímy veľké a komunikačné nástroje boli obmedzené. Naše technické špecifikácie zodpovedali tomu, čo nás spájalo, a využívali sme ich ako Biblia. Ak sa požiadavka zmení, podrobíme vedúcich firiem dlhým procesom kontroly a odhlásenia, pretože komunikácia zmien v tíme a oprava kódu boli drahé.
Pretože bol softvér vyvinutý na základe technickej architektúry, boli najskôr vyvinuté artefakty nižšej úrovne a neskôr závislé artefakty. Úlohy boli pridelené zručnosťami a bolo bežné, že databázoví inžinieri najskôr zostavili tabuľky a ďalšie databázové artefakty, potom vývojári aplikácií, ktorí kódovali funkčnosť a obchodnú logiku, a nakoniec sa prekrylo používateľské rozhranie. Trvalo mesiace, kým ktokoľvek videl, že aplikácia funguje, a dovtedy boli zainteresované strany nepríjemné a často inteligentnejšie v tom, čo skutočne chcú. Niet divu, že implementácia zmien bola taká drahá!
Nie všetko, čo ste dali pred používateľov, fungovalo podľa očakávaní. Používatelia niekedy nepoužívajú žiadnu funkciu. Inokedy bola táto schopnosť všeobecne úspešná, ale vyžadovala nové technické zabezpečenie, aby sa podporila nevyhnutná škálovateľnosť a výkon. Vo vodopádovom svete ste sa tieto veci dozvedeli až po nasadení softvéru, po dlhom vývojovom cykle.
Súvisiace video: Ako agilná metodika skutočne funguje
Zdá sa, že všetci hovoria o agilnom vývoji softvéru, ale veľa organizácií nemá pevné pochopenie toho, ako tento proces funguje. Pozrieť sa na toto päťminútové video a dostať sa rýchlo do tempa.
Kľúčom k agilnému vývoju softvéru
Metodika vodopádu, ktorá bola vynájdená v roku 1970, bola revolučná, pretože priniesla disciplínu do vývoja softvéru, aby sa zabezpečilo, že bude treba dodržiavať jasné špecifikácie. Bol založený na výrobnej metóde vodopádu odvodenej z inovácií montážnej linky Henryho Forda z roku 1913, ktorá poskytovala istotu pri každom kroku výrobného procesu, aby sa zaručilo, že konečný produkt bude na prvom mieste zodpovedať tomu, čo bolo požadované.
Keď sa metodika vodopádu dostala do sveta softvéru, výpočtové systémy a ich aplikácie boli zvyčajne zložité a monolitické, čo si vyžadovalo disciplínu a jasný výsledok. Požiadavky sa v porovnaní s dneškom tiež pomaly menili, takže veľké úsilie bolo menej problematické. V skutočnosti boli systémy postavené za predpokladu, že sa nezmenia, ale pôjde o večné bojové lode. Viacročné časové rámce boli bežné nielen pri vývoji softvéru, ale aj pri výrobe a iných podnikových činnostiach. Ale tuhosť vodopádu sa stala Achillovou pätou v ére internetu, kde sa vyžadovala rýchlosť a flexibilita.
Metodológia vývoja softvéru sa začala meniť, keď vývojári začali pracovať na internetových aplikáciách. Veľa počiatočných prác sa robilo pri začínajúcich firmách, kde boli tímy menšie, boli farebne usporiadané a často nemali tradičné zázemie pre informatiku. Boli tu finančné a konkurenčné tlaky na to, aby sa webové stránky, aplikácie a nové funkcie dostali na trh rýchlejšie. V reakcii na to sa vývojové nástroje a platformy rýchlo zmenili.
To viedlo mnohých z nás pracujúcich v startupoch k spochybňovaniu metodiky vodopádu a k hľadaniu spôsobov, ako byť efektívnejší. Nemohli sme si dovoliť urobiť všetku podrobnú dokumentáciu vopred a potrebovali sme iteratívnejší a kolaboratívnejší proces. Stále sme diskutovali o zmenách požiadaviek, ale boli sme otvorenejší voči experimentovaniu a prispôsobovaniu sa potrebám koncových používateľov. Naše organizácie boli menej štruktúrované a naše aplikácie boli menej zložité ako staršie podnikové systémy, takže sme boli oveľa otvorenejší pre budovanie oproti nákupu aplikácií. A čo je dôležitejšie, snažili sme sa rozvíjať firmy, takže keď nám naši používatelia povedali, že niečo nefunguje, rozhodli sme sa ich radšej vypočuť.
Naše schopnosti a schopnosti inovovať sa stali strategicky dôležité. Mohli by ste získať všetky peniaze, ktoré ste chceli, ale nemohli by ste prilákať talentovaných vývojárov softvéru, ktorí sú schopní pracovať s rýchlo sa meniacimi internetovými technológiami, ak by ste sa k nim správali ako k podriadeným kódovačom otrocky podľa „špecifikácie“. Odmietli sme projektových manažérov, ktorí prichádzali s komplexnými rozvrhmi popisujúcimi, čo by sme mali vyvinúť, kedy by sa mali aplikácie dodávať, a niekedy dokonca aj to, ako štruktúrovať kód. Boli sme hrozní, keď sme sa dotkli trojmesačného a šesťmesačného harmonogramu, ktorý navrhovali a neustále aktualizovali projektoví manažéri vodopádu.
Namiesto toho sme im začali rozprávať, ako je potrebné navrhnúť internetové aplikácie, a výsledky sme dodávali podľa harmonogramu, ktorý sme iteračne vypracovali. Ukázalo sa, že nie sme takí zlí v dodaní toho, čo sme povedali, keď sa k tomu zaviažeme, v malých, týždenných až štvortýždňových intervaloch.
V roku 2001 sa skupina skúsených softvérových vývojárov dala dokopy a uvedomila si, že spoločne vyvíjajú softvérový vývoj odlišne od klasickej metodiky vodopádu. A neboli všetky v startupoch. Táto skupina, ktorá zahŕňala technologických predstaviteľov Kenta Becka, Martina Fowlera, Rona Jeffriesa, Kena Schwabera a Jeffa Sutherlanda, prišla s Agilným manifestom, ktorý dokumentoval ich spoločné viery v to, ako by mal moderný proces vývoja softvéru fungovať. Zdôraznili spoluprácu v oblasti dokumentácie, skôr sebaorganizácie ako rigidných postupov riadenia a schopnosti riadiť neustále zmeny, namiesto toho, aby ste sa uzavreli na rigidný proces vývoja vodopádu.
Z týchto princípov vznikla agilná metodika vývoja softvéru.
Úlohy v agilnej metodológii
Agilný proces vývoja softvéru vždy začína definovaním používateľov a dokumentáciou vízie o rozsahu problémov, príležitostí a hodnôt, ktorým sa treba venovať. Produktový vlastník vystihuje túto víziu a pri uskutočňovaní tejto vízie spolupracuje s multidisciplinárnym tímom (alebo tímami). Tu sú úlohy v tomto procese.
Používateľ
Agilné procesy vždy začínajú s prihliadnutím na používateľa alebo zákazníka. Dnes ich často definujeme s používateľskými osobnosťami, aby sme ilustrovali rôzne role v pracovnom toku, ktorý softvér podporuje, alebo rôzne typy potrieb a správania zákazníkov.
Vlastník produktu
Samotný proces agilného vývoja začína u niekoho, od koho sa vyžaduje, aby bol hlasom zákazníka, vrátane akýchkoľvek interných zainteresovaných strán. Táto osoba destiluje všetky poznatky, nápady a spätnú väzbu, aby vytvorila víziu produktu. Tieto vízie produktov sú často krátke a priame, ale napriek tomu vykresľujú obraz o tom, kto je zákazníkom, aké hodnoty sa riešia, a stratégiu, ako ich osloviť. Viem si predstaviť, že pôvodná vízia spoločnosti Google vyzerala asi takto: „Pomôžme každému, kto má prístup na internet, nájsť relevantné webové stránky a webové stránky pomocou jednoduchého rozhrania založeného na kľúčových slovách a algoritmu, ktorý vo výsledkoch vyhľadávania radí renomované zdroje vyššie.“
Túto osobu nazývame produktový vlastník. Jeho zodpovednosťou je definovať túto víziu a potom spolupracovať s vývojovým tímom na jej uskutočnení.
Pri práci s vývojovým tímom produktový vlastník rozdeľuje víziu produktu na sériu používateľských príbehov, ktoré podrobnejšie objasňujú, kto je cieľový používateľ, aký problém sa preňho rieši, prečo je pre neho riešenie dôležité a aké obmedzenia a kritériá prijatia definujú riešenie. Tieto príbehy používateľov majú prioritu vlastníka produktu a tím ich skontroluje, aby zabezpečili spoločné porozumenie toho, čo sa od nich požaduje.
Tím pre vývoj softvéru
Agilný vývojový tím a zodpovednosti jeho členov sa líšia od zodpovedností v tradičnom vývoji softvéru.
Tímy sú multidisciplinárne a sú zložené z rôznorodej skupiny ľudí so zručnosťami na vykonanie práce. Pretože sa zameriavame na dodávku funkčného softvéru, musí tím dokončiť kompletne fungujúce aplikácie. Takže databáza, obchodná logika a používateľské rozhranie systému Windows časť je vyvinutá a následne demonštrovaná - nie celá aplikácia. Aby to bolo možné, musia členovia tímu spolupracovať. Stretávajú sa často, aby sa ubezpečili, že každý je v zhode s tým, čo stavia, s tým, kto čo robí a s tým, ako presne sa softvér vyvíja.
Okrem vývojárov môžu tímy pre vývoj softvéru zahŕňať inžinierov zabezpečujúcich kvalitu (QA), ďalších inžinierov (napríklad pre databázy a systémy typu back-end), dizajnérov a analytikov v závislosti od typu softvérového projektu.
Scrum, Kanban a ďalšie agilné rámce
Mnoho agilných rámcov, ktoré poskytujú špecifiká vývojových procesov a agilných vývojových postupov, zosúladené s životným cyklom vývoja softvéru.
Najobľúbenejší agilný framework sa volá skrumáž. Zameriava sa na kadenciu doručenia s názvom a šprint a štruktúry stretnutí, ktoré zahŕňajú:
- Plánovanie - kde sú určené priority v šprinte
- Záväzok - kde tím skontroluje zoznam alebo nevybavené príbehy používateľov a rozhodne, koľko práce možno urobiť za dobu trvania sprintu
- Denné stretnutia typu standup - takže tímy môžu komunikovať o svojom stave vývoja a stratégiách)
Sprinty sa končia ukážkovým stretnutím, na ktorom sa produktivite ukáže funkčnosť, po ktorom nasleduje spätné stretnutie, na ktorom tím diskutuje o tom, čo dopadlo dobre a čo je potrebné v ich procese vylepšiť.
Mnoho organizácií zamestnáva majstrov alebo koučov, ktorí pomáhajú tímom riadiť proces skrumáže.
Aj keď dominuje scrum, existujú aj ďalšie agilné rámce:
- Kanban funguje ako proces fan-in a fan-out, kde tím vyťahuje príbehy používateľov z prijímacej dosky a poskytuje ich procesom postupného vývoja až do ich dokončenia.
- Niektoré organizácie používajú hybridný agilný a vodopádový prístup, ktorý využíva agilné procesy pre nové aplikácie a vodopád pre staršie aplikácie.
- Existuje tiež niekoľko rámcov, ktoré umožňujú organizáciám rozšíriť prax na viac tímov.
Zatiaľ čo agilné rámce definujú proces a spoluprácu, agilné vývojové postupy sú špecifické pre riešenie úloh vývoja softvéru vykonávaných v súlade s agilným rámcom.
Napríklad:
- Niektoré tímy používajú programovanie párov, kde dvaja vývojári kódujú spoločne, aby vytvorili kód vyššej kvality a umožnili starším vývojárom mentorovať tých mladších.
- Pokročilejšie tímy prijímajú vývoj a automatizáciu riadenú testami, aby zabezpečili, že základná funkčnosť prinesie očakávané výsledky.
- Mnoho tímov tiež prijíma technické normy, aby interpretácia užívateľského príbehu vývojárom neviedla iba k požadovanej funkčnosti, ale aby zodpovedala aj bezpečnosti, kvalite kódu, konvenciám názvov a ďalším technickým normám.
