O agilných metodikách sa dnes píše a diskutuje dosť často. Veľa firiem, a nielen softvérových, prechádza zo zastaraných metodík, waterfall metodiky a jej variácií, práve na agilné metodiky. Poďme sa pozrieť, čo im táto zmena prináša a ako prebiehala ich adaptácia vo WebSupporte.
Agilný softvérový vývoj je skupina vývojových metodík popísaných v manifeste z roku 2001. Vychádzajú z názoru, že najlepší spôsob ako preveriť funkcionalitu systému, je čo najrýchlejšie ho vyvinúť, odprezentovať ho zákazníkovi a na základe spätnej väzby ho upravovať. Na realizáciu každého projektu potrebujeme čas, zdroje vyhradené na tento čas a funkcionalitu, ktorú musíme implementovať. Pri tradičných metodikách je funkcionalita fixná a čas a zdroje sú variabilné. Agilná metodika má, naopak, fixné čas a zdroje, zatiaľ čo variabilná je funkcionalita.
Všetko je ohraničené časom (timeboxed), do ktorého sa treba zmestiť. V praxi to vyzerá tak, že celý vývoj je rozdelený do časových rámcov (iterácií). Tím programátorov odhadne jednotlivé požiadavky na funkcionalitu a vyberie tie, ktorým sa bude venovať v danej iterácii. Pri výbere sa riadi hlavne kapacitou tímu a časovou náročnosťou tak, aby sa úlohy zmestili do časového rámca. Nezabúda sa ani na biznis a prioritu. V každej iterácii musia vývojári doručiť nejakú biznis funkcionalitu.
Počas vývoja sa vždy vyskytnú komplikácie a tím zistí, že nestihne implementovať všetko. Namiesto predlžovania iterácie alebo priberania ďalších developerov vyberie funkcionalitu, ktorú presunie do ďalšej iterácie, alebo ju nahradí jednoduchšou funkcionalitou. Môže nastať aj opačná situácia, že vývoj napreduje rýchlejšie, ako bolo plánované. Vtedy tím jednoducho vyberie ďalšiu požiadavku na funkcionalitu, aby bol čas využitý čo najefektívnejšie. Pravdaže všetko priebežne konzultuje s klientom.
Základné hodnoty
- Interakcia a individualita prevláda nad procesmi a nástrojmi
- Fungujúci software prevláda nad rozsiahlou dokumentáciou
- Spolupráca zákazníka prevláda nad rokovaniami o kontrakte
- Reakcia na zmeny prevláda nad nasledovaním plánu
12 agilných princípov
- Najväčšou prioritou je uspokojiť zákazníka skorým a priebežným dodávaním hodnotného softvéru
- Úpravy požiadaviek sú vítané aj neskôr počas vývoja. Agilné procesy podnecujú zmenu stať sa konkurenčnou výhodou zákazníka
- Dodávať funkčný softvér často, každý týždeň až mesiac, s preferovaním kratšieho času
- Spolupráca obchodníkov a vývojárov denno-denne, počas celého projektu
- Tvorba projektov okolo motivovaných ľudí. Zabezpečiť im všetko potrebné, podpora ich potrieb a dôvera, že svoju prácu dokončia
- Najúčinnejšou a najefektívnejšou metódou šírenia informácií v tíme je osobný rozhovor
- Funkčný softvér je hlavným kritériom napredovania
- Agilné procesy propagujú udržateľný vývoj. Sponzori, vývojári a užívatelia by mali byť schopní udržať tempo donekonečna
- Neustála pozornosť k technickej excelentnosti a dobrému dizajnu zlepšuje agilitu
- Základom je jednoduchosť – umenie maximalizovať množstvo práce, ktorú nie je potrebné urobiť
- Najlepšia architektúra, požiadavky a dizajn sa vynárajú zo samoorganizovaného tímu
- Tím v pravidelných intervaloch reflektuje, ako byť efektívnejší. Potom adekvátne prispôsobí svoje chovanie
Výhody agilnej metodiky
- Zákazník vidí, v akom stave je vývoj, je jeho súčasťou
- Predchádza sa nedostatočnému porozumeniu špecifikácie
- Zákazník počas vývoja upresňuje svoje požiadavky, čím si produkt priebežne dotvára podľa svojich predstáv
- Intenzívna komunikácia zabezpečuje skoršie odstraňovanie chýb a znižovanie rizika nedodržana dodávky hotového produktu
- Zníženie byrokracie
- Celkové zvýšenie efektivity a produktivity
Najznámejšie agilné metodiky a frameworky
- Extrémne programovanie, XP
- SCRUM
- LEAN Development
- Feature Driven Development
- Test Driven Development
- Crystal
- Agile Unified Process
V ďalšej časti si rozoberieme podrobnejšie niektoré z agilných metodík a frameworkov, ich typické vlastnosti, výhody a aj nevýhody.
Zdroje
Matúš Kosa (@fetket)
3 odpovede na “WS Agilne: Agilná metodológia”
Dve keywords by som pridal: business value a refactoring
Prioritou cislo jedna je „business value“. Aku hodnotu ta praca da zakaznikovi. Co z tej namahy je predatelne. Stale drzat v hlave business value velmi velmi pomaha. Z dvoch dovodov: V prvom rade zakaznik dostane svoju business value skor a uvidi vysledok, bude sa tesit, lebo plati za vysledok (business value) a v druhom rade programator vie uplne perfektne na com robi a co chce dosiahnut. A ako vieme, mat jasny ciel je cool vec na zvysenie produktivity.
Pri vyvoji sa berie business value ako hlavna priorita. Pocas iteracie tym v prvom rade prinesie business value a potom sa venuje inym veciam.
A tie ine veci, to je refactoring. Vylepsovanie kodu, prekopavanie, atd. V pripade napriklad Ruby je uplne bezne ze ziadna metoda nema viacej ako 3-5 riadkov. Inac v tomto odporucam http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672 – este som sa k nej nedostal, ale pocuvam dobre veci.
A refactoring sa samozrejme netyka iba kodu, ale aj UI. Vylepsovanie UX, zlepsovanie dizajnu, atd.
Jop a vela krat som pouzil spojenie „business value“ ale jednoducho to je take dolezite 🙂
Pravdaze je business hodnota dolezita, ale pri niektorych aplikaciach sa zo zaciatku pracuje na core funkcionalite z vacsej miery ako na business.. Je ale podstatne, aby bola kazdu iteraciu dorucena nejaka business hodnota tak aby zakaznik videl progress. S tym mozem len suhlasit. Nechcel som v prvom clanku rozoberat vsetko podrobne, postupne sa dopracujeme aj k refactoringu.
S postupny vyvojom prace na business hodnotach exponencialne rastu a prace na core funkcionalitach umerne klesaju.
Podrobnejsie by som sa tomu chcel venovat v dalsich castiach, ale mozete si pozriet video Jeff Sutherlanda (jedneho so zakladatelov Agile alliance) ten to velmi pekne vysvetlil v svojej prezentacii v googli: http://video.google.com/videoplay?docid=-7230144396191025011#docid=8795214308797356840
Agile v prvom rade dodava biznis hodnotu, na to je orientovane. Zakaznika nezaujima nejaky core a pod. Jeho zaujima, co mu to a najma kedy prinesie. Teda strukturalizacia biznis poziadavky, jej rozpad na atomizovane poziadavky (funkcne,nefunkcne, systemove atd.) je viac ako potrebna, nepostradatelnou, nevyhnutnou je ich prioritizacia, teda ich dolezitost. V tomto pripade je vyznam Core funkcionalita a funkcionalita Nice to Have. Riesenie refaktoringu v tomto kontexte nehra rolu, vobec. Je to cisto zalezitost vyvojarskeho timu, aby si spravil poriadok, vedel rychlo dodavat,, zakaznika to vobec nezaujima. Agilne sposoby vyvoja v prvom rade musia prinasat nasadenie do produkcie v co najkratsom case, co prinesie konkurencnu vyhodu zakaznikovi.
Poznamka: V pripade agilneho vyvoja je potrebne, aby zakaznik si uvedomil, ze variabilna funkcionalita moze byt vyhodou, ale i nevyhodou, teda, ze za konstantny cas a naklady moze dostat mercedes alebo skodovku. Preto ucast zakaznika v jednotlivych artefakoch agilnej metodologie je viac ako nutna. Agilna metodika nefunguje spolahlivo a uplne, pokial sa nou riadi len izolovana skupina a neakceptuje externe vplyvy.
Ciel -> produktivita. Zial, je to pomerne chybne takto uvazovat. Na co mi je produktivita, ak neviem umiestnit produkt na trhu??? Ze mam vysoku produktivitu, ze som efektivny mi moze hovorit a davat vyznam len a len vtedy, ked produkujem a mam za to zaplatene (vid. TOC).