�ݺ�ߣ

Editor's Notes

1. Kokio ilgio sprintai Jums yra optimalūsKiek Jums žmonių reikia komandoje geriausiam rezultatui pasiektiKokių Jums žmonių reikia komandoje, kad užtikrinti geriausią rezultatąAtsakymas: nežinau – eksperimentuokitAš žinau kaip ir kas MUMS buvo geriausia
2. Prezentacijos planas: kaip buvo prieš, kaip yra dabar, ir kaip atsidurėm ten kur esam.
3. Krioklys. Nors projektinė kompanija, tačiau užsakymus/funkcionalumą verčiame į vidinius projektus, vidutiniškai 1-3 mėn trukmės.Komandų nebuvo – tai buvo grupė žmonių. Kiekvienas darydavo (bent) po viena projektąPer deadline sužinodavome tikrąjį deadline
4. Labai džiaugiuosi, jog laikomes agile manifesto Iš proceso pusės:Turim įdiegę ScrumPoreikiui esant naudojam Kanban (dažna prioritetų kaita, netinka scrum)Ilgalaikis planavimasIš bendravimo pusėsSaviorganizacija: net sprinto planavimas vyksta be SM jei jis negaliKliento (savo) įtraukimas į demo
5. Iš technologinės pusės:Pradėta taikyti daugiau XP praktikųVisada pasiruošę išleisti naują versiją (iš development-brančo)Pavydys: praktika padėjo po to kai reikėjo po 3 mėnesių išleisti ¾ padaryto projekto (Y)
6. Taigi, nuo ko viskas prasidejo.Reikia pasukti galvą?Priežastis kodėl minejo Ričardas. Man atrodo, labiausiai pjovė projektų „hands-off“, proceso permatomumas, kokybė. Raskit savo problemas ir priežastis. Scrum dėl scrum ar tiksliau procesas dėl proceso greičiausiai naudos neatneš.Visų pirma pasitariau su komanda, pristačiau jiem ScrumIš pradžių niekas neleido. Nors, atvirai pasakius, susitarem su direktorium, kad naudosim ką norim iš Scrum, tačiau taip, kad nekeistų sutarto krioklio proceso2 diegimo būdai: iš karto; pažingsniuiKuris būdas geresnis?: visi teigia priešingai nei bandė. Vadovo komentaras: iš karto.
7. Daug procesų mačiau, nei vienas nepadėjo. Šitas irgi nepadėsTas pats krioklys tik mažesnėm iteracijomPažiūrim – pamatysimBijojo daug susirinkimų, kad neliks kada dirbtPo diegimo:1 žmogus pabėgo del Scrum (vietoj statistinių 15%, kaip teigiama oficialiuose šaltiniuose)Patiko: įdomiau, matosi galas. Darbai tikrai užbaigiami (kilo motyvacija)Mokosi iš kito kodo, iš to kaip kiti projektuoja ir t.t.„Tai blyn, Scrume dyrbt reikia“
8. Praktikas rinkomes pagal tai kuri, kaip mums atrodė, įneštų didžiausią vertę į dabartinį procesąŽmogus turintis praktikos iš Scrum labai padėjo praktiniais patarimais. Pamatydavo kai kuriuos nukrypimus į šoną, patardavo, kai neaišku kaip teoriją pritaikyt praktiškai. Toks atsakymas iš visų komandų, kuriose jis dalyvavo
9. Projektas = iteracija: užduočių sąrašo planavimas ir sudarymasProdukto šeimininkas – komandaVis dar krioklio pagrindu sudarytos užduotys (iš specifikacijos skaldymas papunkčiui, kitaip sakant work breakdown structure). US atrodė geri, nešantys vertę ir t.t., bet negalėjom diegti, nes nebuvo taip kaip atrodė.
10. Atidavem backloga POIR PASIRODO: vienam produkto šeimininkui yra pakankamai ką veikt, kad susidoroti su „geru“ užduočių sąrašu vienai komandaiJei vartotojų istorijos prastai paruoštos ar nepristatytos iš anksto, sprinto planavimas truks gerokai ilgiau, pvz 4xPradėjom vertinti vartotojo istorijas story pointais, kad turėtumė velocity istoriją
11. Turime savo elektroninę lentą integrauotą su TFS.Elektroninė yra naudinga tarptautinėje įmonėje dėl matomumo ir analizės, bet nepatogi prižiūrėt (maintain).Paprasta lenta ant sienos labai efektyvi, kai reikia staigiai kąnors joje pakeisti. Minusas: tarptautinėje įmonėje, nėra matomumo nutolusiam asmenim.Naudojame iškart abi lentas
12. Per sudėtingas grafikas gali padaryti įrankį nenaudojamu
13. Viena iš didžiausių ir įdomiausiu šendienos mano uždavinių – saviorganizacija. Daug kas galvoja, kad tai neįmanoma ir supranta kaip paleidimą komandos likimo valiai. Tai irgi yra pažingsninis procesas.Delegavimas – vis daugiau leist. Balansavimas tarp tobulejimo ir anarchijos. Bėda gali nutikti tada jei saviorganizacija vyks taip, kaip nėra naudinga stakeholderiams. Anarchija reiškia „be lyderio“, bet tai nebūtinai yra chaosas. Pirmi žingsniai į saviorganizaciją: pvz demo arba sprint planningas - parodydavaukaipreikiagerai atlikti irkelissykiusdingau išsusirinkimųDisciplina (Scrum ne prieko, tačiau disciplina yra rimta sudedamoji meistriškumo dalis ir pradžioje labai padėjo auginant saviorganizaciją) – komanda pati sukūrė proceso sąrašą 20+ itemu
14. Kaip tai atrodė mūsų kasdieniniame darbe praktiškai
15. Pradejome taikyti Scrum projektui, kurį darėme jau pusę metų
16. Kadangi nepribaigėm iki galo tai ką turėjom (krioklio požiūriu):Tuntai bug‘ų iš esamos sistemos (ir tos dalies, kuri yra nebaigta programuoti, nes neatliktas pilnas testavimas, integracija ir pan.)Nepavyko daug sprintųNorejom parodyti kaip scrum yra cool - ypatingai mažas naujo funkcionalumo pristatymas nes:Pradžioje sprintam likdavo 1,5 dienos iš 2 savaičių. Tai reiškia, kad sulėtėjom su naujai pagamintu rezultatu (labai)5sp komanda darė menesį. Šiuo metu darom 10sp per dvi svaitesPirmas sprintas 0,5sp, sekantis 3,5Net ir tada buvo klaidųMes (komanda) daug skyrėm kokybės užtikrinimui ir tobulėjimui. Naujų praktikų, mokymų ir t.t. – pvz unit testing, always ready to deploy
17. Pagaliau supratę savo klaidą, paslėpėm dalį neištestuoto funkcionalumo, pribaigėm esmę (core) ir padarėm pirmąjį diegimą.Deja to nepakako, praleidom rimtą integracijos testavimą ir grįžus krūvai bug‘ų, teko Scrum atidėti keliom savaitėm.Šitoje vietoje baigsiu apie Scrum diegimą iš projektų pusės ir grįšime šiek tiek atgal, nes po pusės metų kai mes pradėjome pirmuosius Scrum žingsnius, įmonėje pasikeitė procesas iš krioklio į Scrum.
18. Pagaliau vadovybė atrado laiko panagrineti Scrum. Nors mes neparodem super greicio, musu komandoje dirba ne super zvaigzdes, netgi sprintu daug nepavyko pradžioje, bet mes pasiekeme daugiau nei pakankamai rezultatų tose srityse, kurios buvo esmines kompanijai (kokybė, permatomumas, efektyvesnė komunikacija, projekto uždarymas ir t.t.). Jau pilotinės komandos nebereikejo ir įvyko masinis Scrum diegimas įmonėje.
19. Turi pasikeisti žmonių tikslai iš asmeninių į komandinius arba turi atsirasti orientacija į komandos pasiekimus. Jei alga priklausys tik nuo asmeninių pasiekimų, komandinis darbas nebus toks koks reikia.Produkto šeimininkas spaudė įsipareigoti per sprinto planavimą. Faktas paprastas: darbas trunka tiek kiek jis trunka, o ne kiek „išgausi“ iš lūpų.Sunku buvo atlikti sprinto planavimą: Sprinto planavimas trukdavo dėl (viena iš priežasčių) nuklydimo į detales. Pabandėm be detalių ir sprintas baigėsi su tuo pačiu rezultatu (tas pats velocity)Geras pavyzdys užkrečia: Kitos komandos natūraliai mokosi iš mūsų
20. Netrukus po Scrum diegimo įmonėje, mūsų komanda gavo dealine ir užsakė daugiau nei galime funkcionalumo. Kadangi žinojome savo velocity, tai galėjom pamatyti, kad reikia dar daugiau žmonių ir kiek funkcionalumo tilps ir kas netilps
21. Mes nepradėdavom iš karto sekančio sprinto po vieno baigimo, tačiau taisydavom klaidas (support), darydavom grooming‘aLabiau pradejom kreipti dėmesį į tai, kad perteikti komandai tai ko klientui reikia iš tikrųjų vietoj techninio sprendimo
22. Sutaupėme laiko,kai story pointus pradėjom matuoti laiko, o ne dydžio perspektyvoje. Ne tai kad lengva matuot SP. Per diena įveikėme 4-5 mėnesius. Rezultatas: deadline atkeliauja už mėnesio, ir mes daug ką atidavę į produkciją ir matom kad spėsim su tuo kas liko.
23. Pradėjus Scrum, pradės lyst ir lyst įvairios problemos. Vieniems jos bus vienokios, kitiems kitokios. Jos priklausys nuo patirties ir darbo specifikos. Pasidalinau tomis, su kuriomis susidūrėme patys ir kurias dažniausiai teko girdėti ir iš kitų.Žinau tai užknisa! Žinot kas sakoma apie universalius daiktus?Todėl rekomenduoju turėti žmogų su agile patirtim arba sudalyvauti mokymuose.Kaip jau minėjau, greičiausiai bus daug nesėkmių, todėl neieškokite kaltų, o pagirkite žmones už surastus sprendimus.Kad ir ka pasirinksite, siūlau prisiminti, kad visos agile metodologijos remiasi agile manifestu. Gabūt ne visiem gyvenimo atvejam tiks Jūsų pasirinkimas, kaip, kad ir buvo mūsų atveju, tačiau reikėtu nepamiršti agile manifesto kaip esminių principų.