Moj prvi susret sa XP-om
Moj prvi susret sa Agile metodologijama je XP projekat u softverskoj kući Leuven (Belgija), koja je pravila migraciju velikog, 30 godina starog mainframe sistema na Java (jsf, kodo, Oracle, Sun) platformu. Te 2005. godine bio sam svjedok brzoj transformaciji jednog velikog, staromodnoga i tromog (RUP) tima u efikasnu XP mašinu koja melje sve pred sobom.
NB: RUP (Rational Unified Proces, IBM) sa svojim iterativnim pristupom je u to vrijeme bio "the way to go" u razvoju softvera u zapadnoj Evropi i generalno u svijetu.
Šta je to XP ili eXtreme Programming? Mnogo literature se može naći na internetu o tome, a najjednostavnija definicija je da je XP grupa pravila kojih se programerski tim treba pridržavati: collective ownership, continuous integration, test driven development, pair programming, daily standup, sustainable pace...
Naš tim je bio striktan u praćenju svih, tada definisanih, XP pravila, i vodio nas je čovjek koji je već tada imao dugogodišnje iskustvo sa XPom. Ja sam, kao prvi XP coach na našem projektu, imao svakodnevne "brainwashing sesije" s njegove strane i svi smo pročitali Kent Beckovu knjigu već u prvih par sedmica itd.
Bilo nas je 20tak programera (ne računam analiste, menadžere) i na početku smo funkcionisali kao jedan veliki tim koji se kasnije, dolaskom novih ljudi, organizovao u 3 funkcionalna tima (30ak programera).
Kakav je osječaj raditi na XP projektu? Pokušat ću da opišem stvari koje su me najviše dojmile u tom periodu, stvari zbog kojih sam od tada, pa do današnjeg dana čvrstog vjerovanja da je Agile najbolja metodologija za uspješan razvoj softvera.
Collective ownership. Kod je svačiji. Svi treba da znaju sve o sistemu (kodu i konfiguraciji). Ne postoje ljudi "bez kojih se ne može". Računari su svačiji. Kada ujutro dođete na posao, vi ne znate gdje ćete sjesti jer nemate svoj računar (svi računari su identično konfigurisani i mogu bukvalno svaki dan da se reformatiraju sa novim imidžom), sjedate za prvu mašinu koja je slobodna i čekate stand up meeting (Scrum) da dobijete zadatak za taj dan ili dio tog dana. Cilj je da su podijeljeni zadaci (tasks ili stories) u što većoj mjeri "vertikalni", a nikada horizontalni; primjer: ako pravite dio nove stranice, onda završavate i biznis koja ta stranica koristi, kao i komunikaciju sa bazom podataka. Klasične podjele među ljudima "on zna baze" i "ona je najbolja u stranicama" prestaju da postoje.
Pair programming. XP je glasan. Ako niste dio tima i ako niste koncentrisani da sa svojim parom završite neki zadatak, sve vam se čini kao jedan veliki kokošinjac, jer previše je buke. Za svakim računarom u jednoj velikoj prostoriji sjede 2 osobe i neprestano pričaju i komentarišu stvari koje vide na ekranu. Pair programming je dakle pravilo u kome za svakim računarom sjede dva programera: driver, onaj koji kodira (vozi) i navigator,onaj koji promatra drivera, ukazuje na greške, razmišlja o stvarima koje nas čekaju, koje smo premetnuli s uma. Pravilo je bilo da se svakih 15ak minuta uloge mijenjaju. Nekada smo tu frekvenciju mijenjali u funkciji TDDa (jedan piše test, a drugi implementaciju). Pair programming je najefikasniji metod za transfer znanja. Pair programming je također najefikasniji metod za pravljenje kvalitetnoga softvera. Code review u timu u kome se parovi mijenjaju sa dovoljno dinamike je pretežno nepotreban. Dakle, parovi treba da se mijenjaju, ako ne u jednom danu, onda sigurno u idućem. Moj posao XP coacha je između ostalog bio da u standupu argumentujem potrebu da neko treba da promjeni paira, ukoliko taj neko to nije sam izjasnio kao potrebu. Nekada smo "repairing" radili u podne, da osvježimo dinamiku rada. U svakom slučaju, "story lead" je onaj koji je odgovoran za delivery (i burndown update) svog dijela posla, on ostaje sa odgovornošću za svoj story, a parovi koji sjede pored njega/nje se mijenjaju.
Test driven development (TDD) je definitivno najmoćniji princip koji sam u tom vremenu savladao i od tada pokušavam koristiti na svim projektima. Savladati TDD se sastoji u prihvatanju sljedećeg pravila: ne postoji promjena koda ili konfiguracije ili bilo kojeg artifacta koji je dio sistema u produkciji, ako prije toga niste napravili test koji pokazuje šta ta promjena tačno donosi sistemu. Taj isti test treba da padne (red) na samom početku jer vaše promjene još nema. Zatim napravite planiranu promjenu sistema (kod ili konfiguracija ili baza) i test tada treba da uspije (green). Faza nakon toga je refactoring ili poboljšanje koda koji ste upravo napravili sa redovnim izvršavanjem testova kao garancijom da daljnje promjene i poboljšanja neće promijeniti pozitivan rezultat testa. Red-green-refactor. Testovi su idealan način dokumentacije. Metode u testu koje sadrže čitave rečenice u svom naslovu su uobičajena pojava jer nema boljeg načina da se sistem opiše nego u testu koji garantuje da sistem radi ono što treba da radi. Da bi se pobrinuli da niko ne piše nijedan drugi vid dokumentacije, nismo dozvoljavali bilo koju vrstu komentara u kodu. Imali smo automatske testove koji skeniraju kod i javljaju ako je neko pisao komentare u kodu.
Continuous build osigurava redovnu egzekuciju svih testova u svrhu kontrole koda koji su svi programeri checkirali u source control. Prije bilo kojeg checkin-a, svaki programer je dužan uzeti "build token" (kod nas je to bio jedan mali teady bear) i staviti na vidljivo mjesto pored svog računara, zatim sinhronizovati svoj kod i pokrenuti build process, nakon čijeg pozitivnog izvršenja može da se napravi check in. Taj isti build process ili pretežno znatno veća verzija napravljena na produkcijskom operativnom sistemu ( = full build) je sastavni dio procesa continous builda koji svaku noć provjeri da li je neki test pao kao posljedica svih checkin-ova prethodnog dana. U tom slučaju se na centralnom monitoru pojavi crvena boja kao znak svima u timu da prvo build treba da se riješi prije nego se krene sa daljnim razvojem.
Iako ima još mnogo toga što bih mogao napisati o XPu, završit ću sa komentarom još jednog važnog pravila u XPu: sustainable pace. Stvarno je bitno ne raditi prekovremene sate ako istinski pratite XP. Pregoriti će te.
U stvari, naša percepcija je bila da sva pravila XPa treba da se poštuju ako želite postići balans i dugotrajnost u izradi kvalitetnoga softvera. Nepoštivanje samo jednog od njih može imati fatalne posljedice.
Zvuči poznato? Želite čuti više od ljudi sa sličnim iskustvima? Pridružite nam se!
Sejo Ćesić
Certified ScrumMaster® (CSM)
