Agiilne tarkvaraarendus, selgitatult

Üsna sageli kuuleme küsimust, “Mida see agiilne töökorraldus, millest te oma igapäevatöös juhindute, täpsemalt tähendab?” Püüame sellelt saladuselt siin katte eemaldada.

Täielik pühendumine ühele projektile

Meie arendajad on projekti käigus 100% pühendunud vaid sellele projektile ja kliendile. Kuna me kasutame oma töös paarisprogrammeerimist, on kliendi teenistuses korraga kas kaks, neli või enam inimest. Neil ei ole samal ajal käsil muud tööd ja kogu fookus on vaid ühel projektil ja kliendil. Peamine põhjus - ümberlülitumine projektilt projektile võtab aega ja aeg on väga kallis ressurss.

Codeborne on väga lihtsa ja lameda struktuuriga ettevõte - kliendid suhtlevad otse arendajatega, ilma igasuguste vahendajateta. Info liigub tellijalt täitjale otse, kadudeta. Tiimil on ka juht, kes on esmane kontaktisik. Nagu ka Agiilse tarkvaraarenduse manifestis kirjas, valdkonna spetsialistid ja tarkvaraarendajad peavad töötama igapäevaselt koos kogu projekti vältel.

Pidev kommunikatsioon

Kogu projekti vältel oleme kliendiga pidevas kontaktis, olgu selleks iganädalased iteratsioonikoosolekud, vestlus Skype’s või mõnes muus meediumis nagu Slack või Fleep, lisaks veel meilivahetus. Eesti klientidega teeme iteratsioonikoosolekud reeglina silmast silma kohtumistena, kas siis kliendi või meie juures. Välismaiste klientidega on kohtumised reeglina Skype vahendusel.

Kuna silmast silma kohtumisi ja isiklikku kontakti ei asenda mitte kuidagi, siis välismaiste klientidega püüame ikka kord kuus kohtuda, kas siis teeme ise külaskäigu kliendi juurde või vastupidi. Uued kliendid kutsume alati enne projekti algust endale külla, et tekiks isiklik arusaam, kuidas me töötame.

Iteratsioonikoosolek

Mida me teeme iteratsioonikoosolekul? Kõigepealt näitame live-keskkonnas funktsionaalsust, mille oleme valmis teinud viimasest kohtumisest alates (tavaliselt nädala jooksul). Teiseks vaatame koos kliendiga üle konkreetsed tööd ja eesmärgid järgnevaks iteratsiooniks.

Peamise infokanalina kasutame Pivotal Tracker‘i lahendust, kuhu paneme kirja ja järjestame kõik kasutajalood, kus anname märku tööde staatusest (näiteks, kas midagi on valmis testimiseks) ning kus klient annab tagasisidet tehtud tööle. Kasutajalood paneme kirja lihtsas ja kõigile arusaadavas keeles, hõlbustamaks hilisemat valideerimist, kas funktsionaalsus töötab või mitte. Näiteks “kasutaja saab siseneda keskkonda” või “administraator näeb ja saab muuta tootetüüpe”.

Kasutajalugude kirjapanek

Projekti alguses paneme kliendiga ühiselt kirja peamised kasutajalood, reastame nad prioriteetide järgi ja lepime kokku projekti olulisemates etappides. Selleks ei pea kliendil kaasas olema “100-leheküljeline tootekirjeldus”, piisab heast ja selgest ärilisest nägemusest, mida lahendus peab suutma teha.

Meie eesmärk on kliendile anda vaid seda funktsionaalsust, mis loob kliendile väärtust (mitte seda, mis kuskil kunagi kirjutatud dokumendis kirjas on). Oleme oma töös kokku puutunud juhtumitega, kus ka väga põhjaliku tootekirjelduse olemasolul suudame koos kliendiga teemat lahates genereerida situatsioone, mida ei olnud võimalik ette valmis mõelda. Agiilse lähenemise üheks plussiks on paindlikkus sellistele juhtumitele kiirelt reageerida.

Muudatused on teretulnud

Tänu lühikestele iteratsioonidele ja olles pidevalt kliendiga kontaktis, oleme valmis prioriteetide muutumiseks. Ja prioriteedid muutuvad meie praktikale tuginedes sageli! Kas on põhjuseks konkurendi tegevus või tuli testimise / arendamise käigus lihtsalt uus mõte või selgus mingi iseärasus kliendi back-end süsteemides - vahet pole, me oleme muutusteks valmis. Kõige olulisem on need muudatusotsused koos teha, edendamaks kliendi äritegevust.

Pidev töötava tarkvara tarne

Agiilse tarkvaraarenduse manifesti põhimõtetest teame, et “kõige olulisem on tagada kliendi rahulolu, tarnides talle vajalikku tarkvara võimalikult kiiresti ja tihti” ning “edu peamiseks mõõdupuuks on töötav tarkvara”. Ilusalt ja lihtsalt öeldud - me järgime neid, tarnides klientidele uut tarkvara igapäevaselt, harvemini ka paaripäevase intervalliga.

Kliendilt kiire tagasiside saamine lühikeste nädalaste perioodide kaupa on lisaks ka heaks motivatsiooniks lamedas organisatsioonis tegutsevale tiimile. Kas klient sai seda, mida soovis? Kui jah - väga hea, saab uued kasutajalood ette võtta. Kui ei - parandame vea kiiresti ja taas saab uued teemad ette võtta.

Kiiresti uue projektiga klientideni

Ühe esimese projekti eesmärgina soovime piiratud hulka reaalseid kasutajaid saada meie loodavat tarkvara kasutama, veendumaks selle toimimises. Näiteks pankadest klientidel soovitame avada rakendus töötajatele (keda on sageli tuhandeid!) juba peale esimest 4 nädalat arendamist. Selline lähenemine annab projektile kiireima ja täpseima tagasiside. Töötajad on ju suure tõenäosusega parimad oma toodete tundjad! Lisaks selline ettevõttesisene laiapõhjaline kaasamine valmistab klienditeenidajad palju paremini ette avalikuks turuletulekuks - kõik on ise põhjalikult tootega tutvunud.

MVP ehk minimaalne elujõuline toode

Agiilne lähenemine koos pideva töötava tarkvara tarnega annab kliendile veel ühe plussi - klient võib projekti käigus otsustada, et aitab arendamisest, teeme siin pausi. Näiteks kui paistab, et MVP tase on saavutatud varem kui algselt planeeritud ning saab teenuse juba avalikuks teha. Veel realiseerimata funktsionaalsuse võib seejärel valmis teha järgmiste iteratsioonide käigus ja tuua samm-sammult klientideni või jätta ootele järgmiseks projektiks.

Teadmiste jagamine läbi koostöö

Meie kliendid saavad valmisarendatud tarkvara omanikeks ja on vabad otsustama, kellega nad seda edasi arendada soovivad - jätkavad meiega, enda sisemiste jõududega või mõne muu partneriga.

Sujuvamaks teadmiste jagamiseks võib meie kontoris üsna sageli näha pilti, kus kliendi arendajad arendavad paaris meie inimestega. Selline lähenemine on meie praktikas osutunud kõige efektiivsemaks teadmiste edasiandmiseks. Samuti töötavad meie arendajad vahel kliendi juures.

Agiilsed kliendid

Agiilse tarkvaraarenduse põhimõtete järgimine seab mõned nõuded ka klientidele. Eelkõige valmisolekut kiireks tegutsemiseks ja paari võtmerolli täitmist, sõltudes projektist:

• tooteomanik, kes tunneb äri vajadusi suures plaanis ning leiab vajaliku kontakti, kes suudab toote või äriprotsesside detaile lahti seletada ja kes on kogu projekti vältel kättesaadav kui esmane kontakt;

• IT kontakt suuremates või olemasoleva infrastruktuuriga projektides, kes hoolitseb kõigi tehniliste küsimuste eest ja tagab töökeskkonna. Kuna me töötame reeglina omast kontorist, siis kõikvõimalikud ühenduse teemad alates VPN-st kuuluvad siia alla.

Teisalt ei ole need nõudmised projektile pühendatud personali osas teab-mis-suured, kui eesmärgiks on millegi uue ehitamine või olemasoleva muutmine.

Koodi ülevaatamised

Me pidevas fookuses tarkvara kvaliteedile on oma kindel koht koodi ülevaatustel, kui projektiga on seotud üle 1 paari arendajaid. See tähendab igapäevaselt u. pooletunniseid tiimisiseseid kogunemisi, kus vaadatakse üle, mida eelmisel päeva uut tehti ning arutatakse küsimusi, kuidas juba käes olevaid või tulevasi ülesandeid lahendada.

Iganädalane TeX

Tihedamaks kogemuste jagamist kogu Codeborne tiimi sees toimuvad meil iganädalased sisemised TeXid ehk “technology exchange” sessioonid kus kolleegid jagavad infot uuematest meetoditest, mida on kas juba kasutatud või kuskil loetud või nähtud.

Esinemine kolleegide ees ja küllaltki teravatele küsimustele vastamine mitte ainult ei tõsta igaühe teadmisi erinevate probleemide lahendamisel vaid treenib ühtlasi ka avaliku esinemise oskust, mis on väga vajalik igapäevatöös.

Retrospektiivid

Õppimaks juba möödunust ja parandamaks tulevikuks, toimuvad meil suuremates/pikemates projektides retrospektiivid. Vahel sisemiselt, aga parem ikka koos kliendiga. Nendes sessioonides me jälgime tavaliselt hoia/muuda/proovi mudelit: millised olid head asjad projektis, mida hoida; mida muuta, et rohkem väärtust luua ja millised on uued ideed, mida proovida? Lisaks teeme kõigi töötajatega vähemalt korra aastas sarnase mudeliga tagasivaate kogu ettevõtte tegevusele.