Paskutinis mano straipsnis Darbai komandoms ar komandos darbams susilaukė keleto labai įdomių klausimų komentaruose, kurie nusipelno atskiro straipsnio. Taigi šis straipsnis yra atsakymas į Luko klausimą „kokiu Vaidai principu rėmėtės formuodami komandas Adform’e“
Pilotinis projektas ir mokymai
Pirmiausia reiktų paminėti, kad Adform nenėrė į Agile aklai, tiesiog dėl mados. Mes turėjome labai aiškų poreikį: kompanija augo, tačiau turėjome išlikti greitai reaguojantys į besikeičiančius rinkos poreikius. Taigi iš esmės ieškojome klausimo į atsakymą: kaip suorganizuoti 50 žmonių darbą, kad kompanija liktų greita ir tuo pačiu lanksti pokyčiams. Kai papasakojau gamybos vadovui apie savo patirtį su Scrum Lavasoft‘e, supratome, kad šis metodas gali labai gerai mums tikti.
Viskas prasidėjo nuo pilotinio projekto. Pirmiausia suformavome gan suinteresuotų ir nebijančių naujovių žmonių komandą. Tada suradome svarbų vadovams, tačiau nelabai aiškų ir su „plaukiojančiais” reikalavimais projektą. Kaip ir buvom suplanavę, per du mėnesius (šalia kitų darbų ką turėjo padaryti komanda), paleidome šį produktą į rinką. Taigi pilotinis projektas įrodė, kad Scrum tvarkosi su mūsų iškeltomis problemomis.
Sekantis žingsnis buvo apmokyti daugiau žmonių kas yra Scrum. Gamybos ir projektų vadovai išvažiavome į sertifikuotų Scrum meistrų kursus. Tokius pačius kokius siūlome ir jums šį rudenį Lietuvoje Agile Turo Vilniuje metu. Grįžę pradėjome visų darbuotojų mokymus viduje apie Agile ir Scrum.
Komandų formavimas
Taigi grįžkime prie Luko klausimo. Tikrai nemažai diskutavome kaip būtų naudingiausia suskirstyti komandas. Mes pasirinkome taip vadinamą „big bang” variantą, nes atsakymas buvo aiškus: mes matome Scrum teikiamą naudą ir norime šiuos vaisius pradėti raškyti kuo greičiau.
Be abejo norėjome sukurti komandas tarp-funkcines. Mūsų sistema gan didelė tad tiesiog komandoje turėtų būti per daug žmonių, jeigu suburtume visus žmones kurių reikia įgyvendinti vieną pilnai veikiančią kliento funkciją. Taigi mes suskirstėme sistemą į logines (technines) sritis, kurias turėjo prižiūrėti atskiros komandos. Tada identifikavome kokių specialistų ir kiek reiktų kiekvienoje komandoje (kiek flash/UI/duomabazių, OLAP‘o ir kitų programuotojų).Išskirstėme testuotojus iš prieš tai buvusio atskiro skyriaus po visas komandas, taigi kiekviena komanda (su mažom išimtim) turėjo po testuotoją. Mūsų analitikai tapo pirmaisiais produktų šeimininkais, o produktų vadovai pirmaisiais Scrum meistrais.
Konkrečių žmonių suskirstymas į komandas buvo paremtas žiniomis apie jų norus ir turimus įgūdžius. Be abejo, kalbėjome su visais asmeniškai ir keitėme komandų sudėtį atsižvelgdami į išsakytais žmonių norus.
Tada buvo paliktas mėnesio pereinamasis periodas, kai žmonės turėjo užsibaigti jau pradėtus darbus, kad nuo 2010 metų kovo pradžios visos naujos komandos startuotų pagal iš anksto suplanuotą ir susinchronizuotą sprintų pradžios/pabaigos tvarkaraštį.
Išvados
Mums labai padėjo aiškiai matomas iššūkis, kurį norėjome išspręsti pasirinktu metodu. Scrum čia puikiai tiko. Be abejo, gamybos vadovo atvirumas naujovėms, noras pačiam sužinoti kas yra Agile ir Scrum, bei nuolatinė priežiūra, kad būtų sveikas balansas tarp proceso tobulinimui skiriamo laiko ir realių darbų atlikimo, buvo labai naudingas. Savalaikis pilotas ir mokymai taip pat prisidėjo, kad galėtume visą gamybą pasukti dirbti pagal Scrum vienu mostu.
Žinoma, jei jūsų vadovai nežino kas yra Agile arba nežino kokias IT projektų problemas Agile metodai sprendžia, „big bang” variantas jums sunkiai pavyks. Todėl dar kartą paskatinčiau „įtikinti” savo vadovus pirmiausia sudalyvauti Agile mokymuose ir konferencijose. Viskas prasideda nuo vieno „aha” momento!
Daugiau apie Adform ir Lavasoft kelionę į Scrum galite pamatyti pavartę pranešimo „Agile Brings Value: Two Scrum Implementation Success Stories and Lessons Learned” skaidres (žemiau) arba pasižiūrėję vaizdo medžiagą filmuotą „IT 2011 Industrial Tutorials” konferencijoje (anglų kalba).
Įdomu kokia kitų kompanijų patirtis buriant komandas. Pasidalinkite komentaruose.
Kitame straipsnyje planuoju parašyti apie kitas mintis iškeltas komentaruose: ką daryti su darbais atskiriems komandos nariams (verslo pasiūlymai, konsultacijos, naujų projektų architektūros) ir ką daryti projektų pabaigoje, kai visos komandos nereikia.