SCRUM v praxi: čo vyvolá zmena špecifikácie v šprinte?

Čo myslíte, radšej mať zlý smer, ako nemať žiaden smer? Chcem apelovať na všetkých zákazníkov a vlastníkov produktu (Product Ownerov), aby si preleteli tento článok.

SCRUM je agilná metodika, ktorá víta zmeny. Napriek jeho veľkej otvorenosti, prečo nie je možné meniť špecifikáciu existujúceho šprintu? Aby z projektu nevznikol totálny dezorganizovaný chaos, ktorý môže viesť k zrušeniu projektu. Ako v Iraku po nedávnom „importe demokracie“.

Čo je a čo nie je zmena? Pre vlastníkov produktu mám zlú správu: toto vie posúdiť iba SCRUM Master alebo SCRUM Team Members. Z pozície neprogramátora je to rovnaké, ako keď vaša malá dcéra na vás vycerí zúbky a vy máte povedať, či má alebo nemá kaz. Nemáte šajnu. Vo všeobecnosti sa dá povedať, že pod pojmom „zmena“ nerátame teraz skutočne drobné zmeny, ako napr. úprava textov, zmena farieb, zmena obsahu tlačítok alebo drobné posunutia komponent. Pri všetkom, kde sa hýbu vstupné a výstupné údaje, vetrite, že zrejme nejde o drobnú zmenu.

Pre účely tohto článku si predstavme, že tvoríme webový portál. V šprinte, ktorý momentálne vykonávane máme pevne dané User Stories (používateľské príbehy), ktoré budeme implementovať. Máme stanovený časový odhad (v človekohodinách), koľko budú trvať jednotlivé User Stories.

Pls. nedáme ďalšiu User Story do šprintu?

Ak by sa zákazník (alebo Product Owner, či neskúsený SCRUM Master) snažil vsunúť jeden User Story do existujúceho šprintu, vyvolal by nasledujúce činnosti z pohľadu SCRUM Mastera:

Príprava zmeny v údajovom modeli: ak pôjde o dátové položky, bude treba prekopať dátový model
Príprava zmeny logického návrhu - modelu tried: zmenenému dátovému modelu prispôsobíme nový diagram trie
Príprava zadania pre: HTML5/CSS3 vývojára, Frontend programátora, Backend programátora
Otestovanie zmeny a integrácia do celku
Optimalizácia riešenia z hľadiska času a náročnosti na HW

Koho by sa zmena týkala?

Aké činnosti a ktorých ľudí by ovplyvnila jedna User Story v existujúcom šprinte?

Online kurz programovania v Jave

Programovanie nie je ťažké! Kódenie vlastných appiek v nástroji Java je veľká zábava. Do konca leta programujete vy sami alebo vaše bystré deti svoje prvé appky

Prvá hodina zadarmo!

SCRUM Mastera: architektúra údajov v ERD/UML, architektúra tried v UML
Team Membera: Programátora HTML5 + CSS3: grafika v pretransformovaná do CSS3
Team Membera: PHPv5/7 OOP frontend programátora: preprogramovanie modulu kódu a otestovanie a optimalizácia
Team Membera: JAVA8 SE backend & midlleware programátora: preprogramovanie modulu kódu a otestovanie a optimalizácia

Demotivácia tímu

Pokiaľ SCRUM Master nebude aktívne pracovať na stmeľovaní tímu, tím vie pomerne ľahko domotivovať a rozhádať aj sám. Veď nato, aby ste rozhádali dvoch ľudí, nepotrebujete vysokú školu.

Teraz ale uvažujme ideálny prípad, kedy sa ľuďom robiť chce, majú sa radi a majú vytvorené také podmienky, v ktorých sa im dobre pracuje. Predstavte si, že ste pôvodne definovali User Story, s ktorou sa team Member poriadne vyhral tak, aby bola presne podľa vašich pôvodných predstáv. V práci zostal dlhšie, dokonca odriekol svoj obľúbený squash preto, aby práca bola kvalitne a načas odovzdaná. Následne zmeníte špecifikáciu tejto User Story. Vy si myslíte, že ide iba o drobnú úpravu, no reálne ide o zmenu toku údajov, ktoré vyžadujú zmenu databázového modelu, a tým následne aj kódu. Budete tvrdiť, že ide o banalitu. Aké myslíte, že to v team Memberovi vyvolá? Netvrdím, aby ste nemenili špecifikáciu existujúcich User Stories, len aby ste vyvolanie týchto pocitov brali aspoň trochu do úvahy.

Aké je riešenie?

Počuli ste o kaskádovom efekte? Ak niekde vznikne nejaká zmena, môže preskočiť aj do oblasti, kde k nej nie je žiaden priamy dôvod. Ako to preniesť do praxe pri vývoji softvéru? Predstavme si, že tabuľky na portáli filtrujeme univerzálnym filtrovaním modulom, ktorý využívajú všetky tabuľky cez štandardné rozhranie. Ak zmeníme univerzálne filtrovanie tabuliek (napr. internú štruktúru tried, ktoré riešia filtrovanie), môže nám to ovplyvniť (resp. vyvolať nečakaný stav) tabuliek, ktoré taktiež používajú modul univerzálneho filtrovania. Z programátorského hľadiska, jedine, ako sa vieme brániť voči tomuto nešváru je priebežne testovať, čo je základ prevencie.

Aká je ale prevencia toho, aby ste najprv navrhli User Story a po implementácií ju menili? Mohli by ste si ju vizualizovať aspoň pomocou Wireframe (drôtový 2D model, logická obrazovka, kde neuvažujeme grafiku, stačí na čistú A4 s perom) aj keď pôjde banalitu. Už len tým, že porozmýšľate, ako by mala vizuálne vyzerať si možno ujasníte črty tohto príbehu už na začiatku jeho tvorby. Možno sa dostanete mysľou do stavu, keď už je User Story implementovaná a možno domyslíte jej dôsledky a spresníte jej zadanie. Možno keď si skúsite predstaviť samotný príbeh vo výslednej imlementácií, spíšete si na papier jednotlivé body, prídete na ďalšie veci.

Ešte raz opakujem, SCRUM je agilná metodika, ktorá víta zmeny. Jej prvoradným cieľom je kvalitný softvér. Aby sme sa vyhli počiatku dezorganizácie a chaosu šprintu, ako lepšie riešenie vidím v dodržaní nasledovného postupu: