Straipsnyje Darbai komandoms ar komandos darbams? bandžiau pagrįsti savo praktika, kodėl stabilios komandos yra daug efektyvesnės negu besikeičiančios. Agile metodai taip pat geriausiai veikia ir teikia daugiausiai naudos kai suburiame stabilias komandas. Sulaukiau kelių straipsnio komentarų/klausimų (dėkui, lauksiu daugiau!), tad atsakant į juos, straipsnyje Stabilių komandų formavimas – Adform patirtis pasidalinau patirtimi, kaip mes subūrėme stabilias komandas Adform‘e. Liko atsakyti į paskutinę Luko ir Artiom klausimų dalį: ką daryti su darbais atskiriems komandos nariams (verslo pasiūlymai, konsultacijos, naujų projektų architektūros) ir ką daryti projektų pradžioje/pabaigoje, kai visos komandos nereikia.
Visos užduotys turi būti dedamos į produkto užduočių sąrašą
Iš tikrųjų, tai tik įprotis mums liepia darbus paskirti konkrečiam žmogui. Net jei kalbame pvz. apie verslo pasiūlymo paruošimą klientui. Kas mus stabdo tiesiog šį darbą įtraukti į produkto užduočių sąrašą (Product Backlog) ir paduoti komandai kaip kitą eilinę užduotį? Tikriausiai tą darbą planuos ir apsiims daryti tas pats žmogus, kuris ir šiaip jį darytų, tačiau tai leidžia mums neišimti žmogaus iš komandos, išlaikyti komandas stabilias. Dar daugiau, kadangi tai komandos atsakomybė pabaigti sprintą atlikus visus darbus iki galo, brandžios komandos nariai nepaliks kolegos vieno, jam padės, pateiks siūlymų. Taip mes gausime dar ir kokybiškesnį produktą. O klientui nusprendus pirkti iš jūsų paslaugą, ši komanda jau žinos apie ką eina kalba, taigi turėsite žymiai greitesnį startą.
Adform‘e mes įtraukiame visą komandą ir į produkto užduočių sąrašo sudarymą/tikslinimąir tam organizuojame produkto užduočių sąrašo tikslinimo susirinkimus (Product Backlog grooming meeting). Tai leidžia nepridaryti planų „iš oro”, o jie daromi kartu su komanda, kuri žino artėjančius projektus ir gali jiems geriau pasiruošti.
Dauguma užduočių turi būti planuojamos, jei norime efektyvaus darbo
Jau girdžiu jus sakant: „tokių darbų planuoti neįmanoma, jie nukrinta kaip iš dangaus”! Vieni tai vadina “supportu”, kiti – konsultacijomis, dar kiti tiesiog „projektais” (įdomus apibrėžimas neplanuotiems darbams J). Kaip su tuo tvarkytis rašiau viename iš pirmųjų straipsnių Scrum naudojimas mažose kompanijose/komandose, apie tai diskutavome ir Agile Lietuva naudotojų susitikime. Ši tema tikrai „karšta”, tad nusipelno atskiro straipsnio. O dabar pasakysiu tik tiek: jei pradėsite matuoti ir suprasti kiek jums tai kainuoja (žmonių sugaišto laiko ir resursų atžvilgiu), pamatysite, jog labai daug tokių „degančių” darbų gali palaukti kelias dienas, t.y. iki kito sprinto pradžios. Ypač, kai per sekantį sprintą jie padaromi kokybiškai ir iki galo, o ne prabėgom, dirbant vienu metu prie kelių projektų (multitasking).
Projekto pabaigos/pradžios užduotys yra tokios pat kaip ir visos kitos
Jei nustojame surinkinėti žmones į žmonių grupes (kurias klaidingai vadiname komandomis) kiekvienam projektui, projektų pradžios/pabaigos problema taip pat pranyksta. Į sprintą dažniausiai įtraukiamos įgyvendinti kelios funkcijos (minimalūs parduodami vienetai, daugiau apie tai straipsnyje: Kodėl verčiame darbuotojus dirbti prie kelių projektų iš karto?). Pirmi sprinto darbai gali puikiai būti pirmo projekto paskutinės užduotys, gal dar kažkokie paskutiniai diegimo darbai, o likusieji – naujo projekto pirmos funkcijos. Stabilios komandos nariai lengvai susiplanuos tokias užduotis taip, kad visi komandos nariai turėtų pakankamai darbo viso sprinto metu. O jei ir teks padėti kolegai padaryti kažką ir ne iš savo ekspertinės srities, tai juk tik geriau! Mes juk komanda ir mūsų bendras tikslas yra sėkmingai užbaigti sprintą.
Taigi ar tokie pasiūlymai įmanomi jūsų įmonėse? Kas dar trukdytų suburti stabilias komandas? O galbūt yra nuomonių iš žmonių dirbančių stabilioje komandoje? Parašykit komentaruose.