Labai dažnai tenka girdėti mitą, jog vykdant projektą naudojant Agile metodikas neįmanoma žinoti projekto apimties, kainos ir pabaigos datos. Be abejo, tai yra netiesa. Projektas, pagal savo apibrėžimą, turi turėti apimtį, kainą ir nustatytą pabaigos datą, nesvarbu kokia metodika jis vykdomas. Tik taip klientas gali nuspręsti ar vykdyti šį projektą , ar jis jam atsipirks ar ne.
Kaip pavyzdį papasakosiu apie savo vykdytą projektą dirbant Švedijoje, kompanijoje Lavasoft. Vadovai susirinkę nusprendė, jog kompanijai būtinai reikia pagaminti antivirusinės programos įmonėms versiją. Taigi projektas prasidėjo. (Nuotraukoje žemiau yra projekto pabaiga, tad jei įdomu, kodėl aš pirmą kartą gyvenime jodinėjau ant dramblio, o ne ant arklio, skaitykite toliau :) )
Projekto apribojimai
Apimtis (scope): reikia sukurti serverių sistemą su vartotojo sąsaja įmonių IT administratoriams, kuri jiems leistų centralizuotai valdyti antivirusinę programą esančią tūkstančiuose jų prižiūrimų vartotojų kompiuterių.
Pabaigos data (deadline): dėl esamos rinkos situacijos, šią versiją turėjome pradėti pardavinėti klientams ne vėliau kaip po 4 mėnesių.
Kaina (cost): kadangi darbuotojai įmonėje dirbo prie kitų svarbių projektų, buvo nuspręsta samdyti 5 žmones iš partnerių įmonės Šri Lankoje. Papildomai, buvo paskirtas fiksuotas biudžetas serveriams testavimui ir apkrovimo (stress) testavimo programinei įrangai, bei vienai projekto vadovo (mano) kelionei į Šri Lanką.
Taigi, kaip matome, turėjome kritinį įmonei projektą, su aiškiai apibrėžtu kainos ir pabaigos datos apribojimu. Dar daugiau, turėjome riziką, nes jį vykdyti turėjo nutolusi komanda (dalis projekto komandos nuotraukoje žemiau).
Pasiruošimas projektui
Projekto vykdymo metodo pasirinkimas: kadangi projektas buvo įmonei labai svarbus ir turėjo papildomą riziką (išorinį vykdytoją), aš pasiūliau jį vykdyti Scrum metodu, kurį jau buvome bandę įmonės viduje. Įmonė Šri Lankoje buvo ITIL profesionalai ir ilgai įkalbinėjo naudoti „jų laiko patikrintą” metodiką, tačiau supratę, kad mes nenusileisime, pritarė mokytis naujo metodo (dar viena rizika!)
Rolių pasiskirstymas: iš užsakovo pusės aš tapau produkto šeimininku (Product Owner), jų projektų vadovė Scrum meistre (Scrum Master), o projektui paskirti analitikas, programuotojai ir testuotojas – komanda. Praktika parodė, jog man dar teko būti ir Scrum treneriu (Scrum coach), kuris mokė Scrum meistrę ir komandą kaip naudoti Scrum metodą.
Produkto užduočių sąrašo sudarymas: be abejo, pradėti projektą reikia projekto plano, kuris, Agile projektuose, yra produkto užduočių sąrašas (Product Backlog). Taigi surašiau projekto funkcionalumą vadovams suprantama kalba – baigtinėmis funkcijomis (instaliuoti serverių programinę įrangą, instaliuoti antivirusinę programą ant nutolusių kompiuterių, paleisti virusų paiešką ir valymą, gauti ataskaitas, valdyti nustatymus, teikti nuolatinius atnaujinimus ir pan.). Tada, kartu su vadovais jas suprioretizavome. Be abejo, norų (funkcijų) buvo daug, tačiau visi suprato, jog tik dalis jų paklius į pirmą projektą, pirmą paleidimą (po 4 mėnesių), o kitos bus perkeltos į sekančius paleidimus.
Susipažinimas ir proceso (Scrum) aptarimas su komanda: nuvykus į Šri Lanką pirmiausiai susipažinau su komanda ir pasikalbėjome kas yra Scrum, kodėl mes naudojame šį metodą valdyti projektui ir ko vieni iš kitų tikimės. Kadangi projekto metu būsime nutolę, taip pat susitarėme kaip organizuosime bendravimą ir visus Scrum susirinkimus – Sprinto planavimą, peržiūrą ir retrospektyvas (kasdienį Scrum jie darydavo be manęs).
Produkto užduočių sąrašo įvertinimas: nors iš patirties turėjau suvokimą, kiek užtruks kiekvienas funkcionalumas, tikrus įvertinimus reikėjo gauti iš tų žmonių kurie vykdys projektą. Laikydamiesi pagrindinės produkto užduočių sąrašo taisyklės – turėti “teisingo” dydžio užduotis – mes per vieną dieną sugebėjome su komanda išsiaaiškinti visas projekto funkcijas. Tą pačią dieną, pasinaudodami planavimo pokeriu (Planning Poker), įvertinome kiekvienos funkcijos dydį. Suma visų funkcijų įverčių mums aiškiai parodė, kad su rizika, bet į 4 mėnesių pabaigos datą turėtume suspėti. Taigi projekto planas buvo baigtas. Kaip pasirodė vėliau, funkcijų dydžių įvertinimai buvo pakankamai tikslūs. Tai dar kartą parodė, jog naudojant palyginamąjį vertinimą, projektų dydį galima įvertinti pakankamai greitai ir gan tiksliai.
Projekto vykdymas
Taigi aš grįžau į Švediją, ir pradėjome suplanuotus sprintus. Be abejo, kaip ir kiekvienas projektas, turėjome iššūkių. Žemiau pateikiu pora iš jų.
Sprinto peržiūra: pirma sprinto peržiūra (t.y. pirmo sprinto rezultatas) buvo visiškai nepasisekęs. Komanda nesuprato kodėl man neužtenka pamatyti kelių ekrano nuotraukų, kurias jie padarė, kaip įrodymą, jog funkcijos veikia. Per sprinto retrospektyvas teko nemažai aiškinti, jog noriu pamatyti veikiantį funkcionalumą. Jog tik taip galėsiu įsitikinti, kad tai ką jie padarė tikrai veikia ir daro tai ko mums reikia. Be to, turėsiu galimybę duoti viską pabandyti ir mūsų IT administratoriams, kad gauti bent jau „apytikrių” klientų grįžtamąjį ryšį. Taigi susitarėme, jog jie turi paleisti virtualias mašinas (serverius), kuriuose viskas instaliuotųsi nuo pradžios ir matytume kaip/ar funkcija TIKRAI veikia. Per kitus sprintus investavome laiko ir dirbome, kad šis procesas būtų kuo paprastesnis. Kai kam gali pasirodyti tai per didelė investicija, bet atsakymas mano būtų paprastas – pirma, aš žymiai aiškiau mačiau tikrą projekto progresą (veikiančias funkcijas); antra, mes neturėjome jokių „netikėtumų”, kad kažkas nesusiinstaliuoja ar nesusijungia projekto pabaigoje.
Per lėtas kūrimas pradžioje: kaip suprantate, jei pirmame sprinte komanda neparodė jokio veikiančio funkcionalumo, progresas yra lygus nuliui. Poroje kitų sprintų, komanda atidirbinėjo pilnos integracijos ir parodymo procesą. Jo nebuvo pirminiame produkto užduočių sąraše (buvo tik funkcijos). Taigi komandos greitis pradžioje pasirodė labai mažas. Aš jau buvau pradėjęs kalbėti su vadovais, kad visų numatytų funkcijų nustatytai projekto pabaigos datai nespėsime padaryti (juk apie blogas naujienas vadovus geriau informuoti anksčiau, nei vėliau!). Parodžiau, kurios funkcijos iš produkto užduočių sąrašo gali nepapulti į planuojamą paleidimą. Tačiau to neprireikė. Persilaužusi komanda pasivijo projekto planą ir galutinę versiją pardavimams pristatėme laiku.
Projekto pabaigimas ir išvados
Kaip jau minėjau, projektą baigėme laiku, be jokių didesnių problemų paskutinėmis projekto savaitėmis. Tai buvo labiausiai netikėta projekto komandai Šri Lankoje. Kaip paskui paaiškėjo per projekto retrospektyvas, jie buvo pasiruošė dirbti naktimis, projekto pabaigoje (kaip dažniausiai būna). Todėl jie buvo nelabai patenkinti, kai dirbo kelias naktis (mums to nereikalaujant) projekto pradžioje, kad pabaigtų prižadėtus darbus pirmiesiems sprintams. Tačiau patys pripažino, kad tai tikrai atsipirko. Kitą paleidimo projektą, be abejo vykdėme naudojant Scrum.
Kaip matote iš pavyzdžio, standartinis fiksuotos kainos, laiko ir apimties projektas buvo įvykdytas naudojant Scrum su nutolusia komanda, kurie Scrum bandė pirmą kartą. Jei kas nors jums sako, kad Agile nereikalauja projekto kainos ar pabaigos datos ar apimties apibrėžimo – netikėkite. Visos projektų valdymo metodikos to reikalauja, Agile taip pat.
Aišku, jeigu jums tai pirmas Agile projektas (kaip kad buvo komandai Šri Lankoje), būtina visai komandai pasimokyti iš ekspertų su kuo tas naujas metodas „valgomas”. Dar svarbiau, kad laikas nuo laiko kažkas prižiūrėtų, ar tikrai jo laikotės. Šiame projekte Scrum treneriu buvau aš, o kas jūsų įmonėje skiria laiko Scrum trenerio rolei, kalbasi su Scrum meistrais, padeda jiems augti ir tobulėti?
Jei turite klausimų apie šį projektą ar apskritai apie Agile fiksuotos kainos, laiko ir apimties projektuose, klauskite/pasakykite savo nuomonę komentaruose. Taip pat siūlau paskaityti mano anskčiau rašytą straipsnį „Agile projektai ir fiksuotos kainos, laiko bei funkcionalumo sutartys“.