Agile/Scrum projektas su keliomis komandomis

Pilnai įdiegus Adform‘e Scrum 7 tarpfunkcinėse komandos dirba prie 6 posistemių (produkto užduočių sąrašų). Be abejo, posistemės yra vienos sistemos dalys, tad jos gan glaudžiai susiję. Kilo klausimas: kaip komandoms įgyvendinti funkcionalumą kuris liečia kelias posistemes/komandas? Praktika dar kartą įrodė, jog pritaikius pagrindines Agile praktikas, viskas pasidaro greičiau, kokybiškiau ir paprasčiau.

Kaskadinis planavimas

Pradėjome nuo to kas atrodė logiškiausia. Išsiaiškiname užduotis, ką kuri komanda turi padaryti. Tada susiskirstome eiliškumą kuri komanda turi pradėti, kuri naudos pirmos komandos rezultatus ir darys savo dalį (užduočių priklausomybės). Pagal tai sudarėme planą ir susiskirstėme jį Sprintams. Planavime/diskusijose dalyvavo visų komandų Produkto savininkai, Scrum meistrai ir nariai iš komandų. Supaprastintas planas atrodė taip:

Tačiau nuo programinės įrangos kūrimo realybės nepabėgsi 🙂 Pirmajai komandai jau pirmo sprinto metu kilo techninių klausimų, kurie turejo įtakos  ir kitų komandų užduotims. Kadangi kitos komandos dirbo prie savo sprinto užduočių, jų trukdyti nebuvo galimybės. Tad pirma komanda darė ką galėjo pabaigti savo užduotį. Prasidėjus antrajam sprintui, pirmai ir antrai komandai reikėjo sinchronizuoti darbus sprinto pradžioje, padaryti reikiamus pakeitimus. Sprinto gale, be abejo, kartu testuoti integracinėje aplinkoje ir pataisyti, kad viskas veiktų kartu. Tas pats (tik jau su visomis trimis komandomis) nutiko prisijungus trečiajai komandai. Taigi realus kelių komandų užduoties įgyvendinimas atrodė taip:

Visi kartu

Pasimokę iš šios pamokos, kitą kelių komandų užduotį atakavome kitaip. Pirmiausia, suformavome „tigrų komandą”. Ją sudarė: pagrindinis produkto šeimininkas (bendrai atsakingas už šį funkcionalumą) ir po porą techninių žmonių iš kiekvienos komandos. Pirmame susirinkime produkto šeimininkas pristatė biznio reikalavimus. Tigrų komanda turėjo galimybę išsiklausinėti kas neaišku. Tada išsiskirstėme, o tigrų komanda per kelias dienas turėjo patys susiorganizuoti ir susitarti dėl įgyvendinimo detalių (prisiderinant prie savo vykdomų užduočių sprintuose kartu su komanda). Pagrindinis skirtumas buvo tas, kad visi žinojo, jog užduotis komandos turės įgyvendinti vienu metu, t.y. visos komandos pradės dirbti kartu kitame sprinte. Po kelių dienų susitikome ir tigrų komanda trumpai pristatė planuojamą įgyvendinimo dizainą. Taigi visos komandos žinojo ką planuotis sprinto planavimo metu. Darbų planas laike atrodė taip:

 

Realybė buvo ta pati: vos pradėjus įgyvendinti užduotis kilo klausimų, reikėjo keisti/papildyti pradinius dizainus. Tačiau buvo didžiulis skirtumas: visos komandos tarpusavyje greitai komunikavo šiuos pokyčius ir iš karto juos įgyvendino. Jie žinojo, jog nei viena komanda nebaigs sprinto pagal DONE kriterijų jei nebaigs visos. Tad įsipareigojimas buvo bendras, kuris dar labiau kėlė norą bendradarbiauti.

Rezultatas: funkcionalumas buvo įdiegtas pagal planą! Nuo šiol visas kelių komandų užduotis mes organizuojame būtent taip!

 

Išmoktos pamokos

Užduočių išdėstymas viena po kitos (kaskadiškai) neveikia realybėje. Pirmos užduoties įgyvendinimas pakeis sekančių planus. Tad pirma pradėjusi komanda vėliau vėl turės grįžti prie užduoties kuri atrodė jau pabaigta.

Dirbant kelioms komandoms kartu prie bendro funkcionalumo padaugėja komunikacijos laiko, bet tai atsiperka nes pokyčiai ir integracija daroma iš karto.

Programuotojams iš pradžių tai atrodo neįveikiama užduotis, nes reikia išmokti programuoti neturint galutinių pirmos komandos rezultatų (pvz. duomenų bazės kurią antra komanda turi naudoti). Ilgiau padiskutavus randami sprendimai, kai užtenka susitarti dėl pirminių dizainų, sukurti netikrus (mock) objektus, juos adaptuoti/detalizuoti įgyvendinimo metu.

 

Naudos

Planavimas su „tigrų komanda” užtrunka daug trumpiau nei detalaus kaskadinio plano ir priklausomybių suderinimas su visomis komandomis (skaičiuojant sunaudotas žmonių valandas).

Laiko prasme, funkcionalumas pristatomas daug greičiau! Jeigu jums jo taip greitai nereikia, verčiau pradėkite visi kartu vėliau, negu švaistykite laiką vienai komandai pradedant anksčiau.

Funkcionalumas pareikalauja mažiau bendrų laiko sąnaudų, nes nėra vėlyvo perdarymo, visi pakeitimai daromi iš karto ir labai greitai.

Funkcionalumo kokybė gerėja, nes ją vienu metu integruotai testuoja visos komandos!

 

Apibendrinimas

Tarpfunkcinėje komandoje aiškiai matosi nauda dirbti kartu prie vienos užduoties (no multitasking). Apie tai jau rašiau: „Scrum naudojimas mažose kompanijose/komandose” (http://scrum.blogas.lt/scrum-naudojimas-mazose-kompanijosekomandose-124.html). Tačiau tai puikiai veikia ir tarp komandų! Taigi Agile praktika: mažas dizainas ir jo realus įgyvendinimas visiems kartu prisitaikant prie reikiamų pokyčių, tikrai veikia. Pabandykit!

Lauksiu komentarų/klausimų 😉

Tagged with: , , , ,
Posted in Agile, Agile praktikos, Fokusavimasis, Komanda, Scrum
2 comments on “Agile/Scrum projektas su keliomis komandomis
  1. Simonas says:

    Liuks! panasu principa galima pritaikyti tiesiog komandoje kai reikia dalintis vieno feature uzduotis ir kai manoma kad vienas negali pradeti be kito. Sia mintim pasidalinai praeitoje konferencijoje. Veikia 🙂 Dekui!

  2. Sveikas Simonai,

    Džiugu išgirsti įrodymą jog tai veikia ne tik mums! Taip, komandose tai būtina įgyvendinti jei tikrai norite jog komanda būtų tarpfunkcinė ir galėtų kartu sprinte įgyvendinti reikalaujamas funkcijas. Kitaip tariant, jei norite turėti tikrą Scrum komandą 😉 Spėju teko truputį pasiginčyti su programuotojais ir padiskutuoti kaip tai įmanoma padaryti, bet pradėjus pasirodo jog tai ne taip ir sunku.

    Man įdomu buvo pačiam įsitikinti jog šie principai veikia ir tarp komandų. Galbūt yra atsiras tokių kurie tai pabandys/bandė ir patvirtins jog Agile praktikos puikiai veikia ne tik mums?! 😉

    Vaidas

Artimiausios mokymų klasės
Data Mokymai - Lektorius
2017 m. gruodžio 14-15 d. Certified Scrum Master (CSM) - Alexey Krivitsky (anglų kalba)
2017 m. gruodžio 14-15 d. Certified Agile Leadership CAL1 - Angel Diaz-Maroto (anglų kalba)
2018 m. sausis 18-19 d. Certified Scrum Product Owner (CSPO) - Lasse Ziegler (anglų kalba)
2018 m. sausio 26 d. Agile projektų valdymo pagrindai - Vaidas Adomauskas (lietuvių kalba)
2018 m. vasario 8-9 ICAgile sertifikuotas profesionalas (ICP) - Vaidas Adomauskas (lietuvių kalba)
2018 m. Management 3.0 Change and Innovation Practices
2018 m. Reikalavimų valdymas Agile projektuose - Vaidas Adomauskas (lietuvių kalba)
2018 m. Better Retrospectives - Jeff Campbell (anglų kalba)
2018 m. Kanban System Design (KMP I) - Gaetano Mazzanti (anglų kalba)
Visi mokymai
Archives
Categories
Kontaktai

Viešos mokymų klasės:
E-paštas: mokymai (at) agilecoach.lt
Mob. tel.: 8 686 32487

Konsultacijos ir mokymai įmonėms:
E-paštas: vaidas (at) agilecoach.lt
Mob. tel.: 8 686 32487