V predchádzajúcej časti sme si niečo povedali o agilných metodikách ako celku: čo majú spoločné a na akých princípoch stoja. V tejto časti sa bližšie pozrieme na princípy Extrémneho programovania.
Túto metodiku zaviedol Kent Beck, po prvýkrát bola použitá v roku 1996. Jej základom je jednoduchý, realistický spôsob myslenia, používanie pomerne štandardných princípov a postupov, ako písanie kódu, testovanie, atď. Čo je na tom extrémne? Myšlienky dotiahnuté do extrémov. Vďaka tomu je možné dosiahnuť vyššiu kvalitu a pružnejšie reagovať na zmeny klientových požiadaviek počas vývoja. Manažéri, zákazníci aj developeri tvoria jeden tím. Ten sa samoorganizuje tak, aby bolo vyriešenie problémov čo najefektívnejšie. Pozrime sa na základné pravidlá.
Plánovanie
Základné požiadavky sú spísané do celkov (User stories), ktoré je možné odhadnúť a zaradiť do iterácií. Je to v podstate ekvivalent rozsiahlych dokumentov s rozobratými požiadavkami. Každá story je definovaná tak, aby bolo jasné, čo v sebe zahŕňa. Nedostatočné pochopenie by mohlo spôsobiť chybu v odhade. Je dôležité, aby sa každá story zameriavala na to, čo klient potrebuje, bez zbytočných detailov použitých technológií. S user stories priamo súvisí vznik akceptačných testov. Slúžia na overenie či bola daná požiadavka implementovaná podľa predstáv. Jedným zo známejších testovacích frameworkov je Selenium.
Aj vývoj je rozdelený do iterácií, avšak nie je presne definovaná ich veľkosť. Prispôsobuje sa požiadavkám klienta a často sú extrémne krátke. Dôležité je časté vydávanie releasov s novou funkcionalitou.
Manažovanie
Medzi najdôležitejšie pravidlá manažovania patrí naplánovanie iterácie tak, aby bol tím schopný implementovať všetky naplánované story. Príliš veľa nadčasov dlhodobo znižuje jeho výkon. Okrem toho treba nepretržite sledovať postup prác, eliminovať riziká a v prípadne nutnosti prekonzultovať s klientom preloženie menej prioritných stories do ďalšej iterácie.
Iným dôležitým princípom je zastupiteľnosť. Členovia tímu by sa mali pri implementácii požiadaviek do jednotlivých častí projektu striedať. Nemôže nastať situácia, že iba jediný člen tímu bude mať prehľad o tom, ako funguje nejaká časť systému. Pri plánovaní je takýto prístup veľkou výhodou.
Extrémnemu programovaniu treba prispôsobiť aj pracovné prostredie. Zariadenie by malo zohľadňovať neustálu komunikáciu. Ideálny je openspace s tabuľami na rôzne náčrty a zoznamom úloh, ktoré treba spraviť.
Častým problémom vo firmách bývajú dlhé meetingy, ktoré treba plánovať dopredu. Extrémne programovanie využíva, tak ako ďalšie agilné metodiky, stand up meetings. Bývajú zvyčajne ráno. Tím na nich stručne poinformuje a vykomunikuje problémy a ich riešenia. Rýchle meetingy pomáhajú udržať tím sústredený. Je dôležité, aby sa pri stand up meetingoch stálo. Podporuje to efektívne a rýchle vyjadrovanie.
Každý člen tímu musí presne vedieť, čo môže očakávať od ostatných. Pomáhajú tomu základné hodnoty a pravidlá Extrémneho programovania. Pokiaľ niektoré z týchto pravidiel nefungujú, treba ich upravovať a zlepšovať na pravidelných retrospektívnych meetingoch.
Architektúra
Základom je jednoduchosť. Implementácia jednoduchšieho dizajnu je vždy kratšia ako implementácia komplexnejšieho.
Extrémne programovanie využíva takzvanú systémovú metaforu. Je to metafora pre jednoduchú architektúru s niekoľkými kvalitami. Jedna z najdôležitejších je jej ľahká vysvetliteľnosť, bez spisovania rozsiahlych dokumentov. Ďalšia kvalita je konzistentnosť označovania tried a metód. Dobré názvoslovie významne pomáha lepšiemu porozumeniu celkovej architektúry.
Je dôležité implementovať len funkcionalitu, ktorá je nevyhnutná a klient ju požaduje. Netreba zabúdať ani na neustále refaktorovanie kódu. V mnohých prípadoch je efektívne použiť aj Spike riešenia. Sú to jednoduché experimenty, ktoré slúžia na rýchlejšie vyriešenie problémov. V podstate ide o kúsky kódov alebo programov, ktoré je možné vo väčšine prípadov po odhalení chyby zahodiť. Často sa používajú na brainstormovanie OOP aplikácií aj CRC karty.
Programovanie
Keďže programátori nemajú k dispozícii kompletnú špecifikáciu aplikácie, je nevyhnutné, aby bol zákazník neustále dostupný na prediskutovanie prípadných nezrovnalostí. Spolupracuje s tímom na vytváraní stories a odhadov a určuje ich prioritu.
Každý jeden kúsok kódu, ktorý ide do produkcie sa programuje v pároch. Pair programming je metóda, pri ktorej sedia dvaja programátori za jedným PC. Skúsenosť hovorí, že pokiaľ pár prekoná isté sociálne zábrany a programátori si uvedomia svoju rovnocennosť, dokážu za rovnaký čas implementovať toľko isto funkcionality, ako keby pracovali osve. Pridaná hodnota spočíva v kvalitnejšom kóde a omnoho menšej chybovosti.
Extrémne programovanie využíva aj princípy Test driven developmentu. Pred vytvorením hocijakej funkcionality musí byť najskôr napísaný jednotkový test (unit test). V prípade použitia PHP je možné použiť PHPUnit framework. Podobné testovacie frameworky sú dostupné aj pre iné jazyky. Písanie testov pred funkcionalitou núti programátorov implementovanú funkcionalitu podrobne rozanalyzovať. Pozerajú sa na novú funkcionalitu ako na čiernu skrinku, o ktorej vedia, aký bude mať vstup a aký výstup. Musia napísať test, ktorý pre všetky možné vstupy otestuje správny výstup. Keďže testujeme funkcionalitu, ktorá ešte neexistuje, testy musia failovať. Postupným implementovaním funkcionality by mali testy prechádzať. Nesmie sa vydať nový release bez toho, aby niektorý z testov neprešiel.
Releasovanie hotovej funkcionality uskutočňuje vždy iba jeden pár. Ideálne je mať na releasovanie vyhradený jeden počítač, aby aj ostatní videli, kedy je obsadený a releasuje sa.
Zdrojový kód je vlastníctvom celého tímu. Znamená to, že každý môže robiť zmeny v celom projekte, ako opravovať chyby, tak aj pridávať novú funkcionalitu.
Testovanie
Testovať treba všetko, neustále a vždy. Písanie unit testov rýchlejšie pomáha odhaľovať chyby aj neskôr počas vývoja. Tak isto sa píšu unit testy aj na chyby. Okrem unit testov sa pravdaže spúšťajú aj akceptačné testy na každú story a zapisujú sa ich výsledky. Story nie je dokončená pokiaľ neprejde všetkými akceptačnými testami.
Základné hodnoty extrémneho programovania:
- Jednoduchosť – základ je vytvoriť čo najjednoduchšiu verziu, ktorá bude spĺňať požiadavky a zároveň bude fungovať.
- Komunikácia – všetci sú súčasťou tímu a spolupracujú spolu od požiadaviek až po samotné písanie kódu.
- Spätná väzba – každú iteráciu treba brať seriózne, demonštrovať hotový kód skoro a často, pozorne načúvať pripomienkam
- Odvaha – vždy je potrebné hovoriť pravdu o priebehu a odhadoch, netreba sa ničoho báť, pretože nikto nepracuje sám, ale všetci ako tím
- Rešpekt – členovia teamu sa musia rešpektovať a pomáhať si, pretože sú všetci rovnocenní
Bližšie popísané procesy, pravidlá a hodnoty Extrémneho programovania môžete nájsť na http://www.extremeprogramming.org
Matúš Kosa (@fetket)
9 odpovedí na “WS Agilne: Extrémne Programovanie (XP)”
Robite u vas automatizovane akceptacne testy? V com? Ako rychlo to zbehne?
povedz mi viac o tom – ako sa dajú robiť automatizované akceptašné testy?
Takto, ked postavime user stories do pozicie akceptacnych testov, tak potom sa to da (fit/fitnesse/htmlunit je stary priklad, Cucumber + Webrat „nova“ vec nielen pre Rails)
Vyzera to nejako takto https://github.com/hidden/bonsai/blob/master/features/parallel_editing.feature a da sa to normalne spustit. Nieco ako rychlejsia nahrada za Selenium.
Robite hadam Pair Programming? O tom som este na Slovensku nepocul.
A este zaujimava vec, ktora by k tomuto stala za spomenutie je BDD, Behavior Driven Development.
BDD je to iste ako TDD – teda ako ho povodne ludia ako Kent Beck mysleli (staci si pozriet jeho TDD by example), len potom sa to zvrhlo, tak to „rebrandovali“ na iny slovnik
U nas vo WebSupporte vyuzivame SCRUM, bude o nom este podrobnejsi clanok, resp. seria clankov. Co sa tyka pair programmingu, do takej miery ako sa vyuziva v Extreme programmingu ho nevyuzivame. Prisli sme, ale na jeho vyhody pri rieseni komplikovanejsich bugov.
Co sa tyka akceptacnych testov, momentalne testujeme manualne, ale pohravame sa s myslienkou ich zaviest. Zakladny problem ale je, ze ich momentalne nema kto pisat. 🙂
Co sa tyka vykonnosti akceptacnych testov, nemam prehlad, ale po par pokusoch Selenium vyzeral ako schopny kandidat.
nasiel som toto videjko o extremnom programovani, mne sa to zda dost cool
http://www.youtube.com/watch?v=Ytu1Hxzr_Bs&feature=related
cele je to pekne, ale konci to vacsinou takto:
http://adilbertprogrammer.blogspot.com/
Bohuzial svata pravda, kus z kazdeho sa najde v kazdej vacsej firme.
Urcite existuju spolocnosti, kde to takymto stylom funguje. Pochybujem, ale ze do niecoho takeho moze viest pouzivanie agilnych metodik pri vyvoji.
Pokial existuje osoba, ktora dupe od zaciatku aby sa dodrziavali pravidla casom si na tie pravidla vzniku developeri ako aj ostatni. Stane sa to akysi standard. Ked uz raz nieco funguje, teamy podavaju adekvatne vysledky, kazdemu su jasne vsetky procesy, cesta k podobnym bodom by bola krok spat pre vsetkych.