Krovinių kultas
Kai kurie mano papasakoti dalykai labai susiję su plačiai žinomu reiškiniu – krovinių kultu. Šis reiškinys veikiausiai senas kaip pasaulis, tačiau įvardintas buvo tik Antrojo pasaulinio karo metu. Melanezijos čiabuviai stebėdavo amerikiečių stovyklas ir matydavo kaip iš dangaus nusileidžia orlaiviai, o iš jų po to nešamos prikrautos dėžės. Tai kažkiek siejosi su mitologija ir pasakojimais apie dievus, atnešančius dovanas žemės gyventojams. Čiabuviai taip pat norėjo dovanų iš dangaus, todėl pradėjo imituoti lėktuvų nusileidimo takus -pasigamino kokosines ausines ir visa kita, kas pasirodė reikalinga dovanoms priimti. Taigi principas yra toks, kad imitacine veikla siekiama gerų rezultatų, tačiau praleidžiamos esminės priežastys, kodėl tai turėtų veikti. Mūsų komandoje tai labai dažnai pasitaikydavo ar vis dar pasitaiko įvairiais atvejais, tad turiu keletą pastabų jums:
Žiūrėkite vienas kitą
standups: statuso raportavimas tikrai neduos rezultato, kurio siekiama. „Ką dariau vakar, ką darysiu šiandien ir kas nesiseka” gali būti imituojama atkartojant tai, kas matoma lentoje ar ekrane. Renkite susitikimus kitur ir žiūrėkite vienas į kitą užuot susitelkę į vieną lentą. Dar geriau – eikite kartu kavos ar arbatos.
Formatas “+, -, Δ”
Retrospektyvos: formatas “+, -, Δ” arba „kas gerai, kas blogai, ką pakeisti” gali būti labai lengvai imituojamas. Komanda kaip proceso privalumą kelias retrospektyvas iš eilės įvardija tokius dalykus kaip good teamspirit, supporting colleagues ir t.t. Smagu, kad draugaujate, bet kaip tokie dalykai gali padėti tobulinti procesą?
Netinkamas padengimas testais
Galima siekti 100% code coverage, bet praleisti esmines klaidas. Tai, kad testo metu buvo iškviestas metodas, dar nereiškia, jog buvo atlikti verslui išties svarbūs tikrinimai.
Modulių testų rašymas po implementacijos
Niekada negalite žinoti, ar parašytas testas iš tikrųjų testuoja tai, ką tikitės. Per 100 sprintų esu ir pats parašęs tokių testų ir jų radęs pas kitus. Atrodo, kad testuoja, kodas veikia, bet pakeitus esminę detalę, testas vis dar sėkmingai įvykdomas, nors turėtų baigtis klaida.
Greitas darbas su IDE, klaviatūra ir kitais įrankiais
Lengva imituoti našų kolegą greitai spaudinėjant klaviatūros mygtukus ir sparčiai naviguojant tarp programų. Vis dėlto toks skubėjimas blaško ir didina klaidų tikimybę. Lėta yra sklandu, o sklandu yra greita. Seniai žinoma taisyklė, kurios reikėtų nepamiršti.
Ką rasite 100 Scrum sprintų e.knygoje?
Savo e.knygoje dalinuosi ScrumMaster patirtimi ir istorijomis iš savo komandos, kurios gali padėti pasimokyti iš geriausių mūsų sprendimų bei patirtų klaidų. E.knyga suskirstytas į kelis skyrius:
- Tikslus planavimas – ne visada tikslus. Šiame skyriuje pasakoju apie tai kaip sprintai atrodė tik pradėjus juos atlikti, kokios buvo pagrindinės išmoktos pamokos ir kaip atsirado tikslas eiti link #NoEstimates.
- Ar automatizacija būtina visada? Tai istorija iš vieno komandos sprinto apie atvejį, kai automatizacija tikrai nebuvo geriausias sprendimas.
- Ar tikrai reikia standups? Kontroversiški žodžiai iš ScrumMaster lūpų, tiesa? Visgi, scrum tėra puikiai suręstas karkasas, tad ar tikrai reikia laikytis visų taisyklių, kai komanda jau susiformavusi? Į tai atsakau šiame skyriuje.
- Kaip atsikratyti ilgo planavimo? Sprinto planavimas atimdavo didelę dalį darbo dienos. Čia pasakoju kaip šį laiką sutrumpinti.
- Planuoti pagal user story kiekį? Kaip išskirstyti darbus taip, kad nereiktų planuoti valandomis, bet pagal user stories?
- Priėmimo kriterijuose negali būti funkcinių reikalavimų. Komandos istorija apie funkcionalumo kūrimą, kuris savyje turėjo funkcinių reikalavimų ir išsiskaidė į daugiau nei 9 story points.
- Jei parašyta “panašiai kaip sistemoje X”, ruoškitės paslėptam sudėtingumui. Nutinka, kad „panašiai kaip sistemoje X” iš tiesų reiškia „nežinau, kaip galėtų būti geriau, todėl tiks kaip buvo kitur…” Tad kaip teisingai planuoti tokį darbą, kokių klausimų klausti?
- Krovinių kultas. Apie kurį jau skaitėte.
Kviečiu perskaityti:
Tikiuosi, jog mūsų komandos patirtis, jums atneš naudos.
