SCRUM v praxi: co vyvolá změna specifikace ve sprintu?

Co myslíte, raději mít špatný směr, než nemát žádný směr? Chci apelovat na všechny zákazníky a vlastníky produktu (Product Ownerů), aby si přeletěli tento článek.

SCRUM je agilní metodika, která vítá změny. Navzdory jeho velké otevřenosti, proč není možné měnit specifikaci stávajícího sprintu? Aby z projektu nevznikl totální dezorganizovaný chaos, který může vést ke zrušení projektu. Jako v Iráku po nedávném "importu demokracie".

Co je a co není změna? Pro vlastníky produktu mám špatnou zprávu: toto umí posoudit pouze SCRUM Master nebo SCRUM Team Members. Z pozice neprogramátora je to stejné, jako když vaše malá dcera na vás vyceří zoubky a vy máte říct, jestli má nebo nemá kaz. Nemáte šajnu. Obecně se dá říci, že pod pojmem "změna" nepočítáme nyní skutečně drobné změny, jako například. úprava textů, změna barev, změna obsahu tlačítek nebo drobné posunutí komponent. U všeho, kde se hýbou vstupní a výstupní údaje, vetřete, že zřejmě nejde o drobnou změnu.

Pro účely tohoto článku si představme, že tvoříme webový portál. Ve sprintu, který momentálně prováděno máme pevně dané User Stories (uživatelské příběhy), které budeme implementovat. Máme stanovený časový odhad (v člověkohodinách), kolik budou trvat jednotlivé User Stories.

Pls. nedáme další User Story do sprintu?

Pokud by se zákazník (nebo Product Owner či nezkušený SCRUM Master) snažil vsunout jeden User Story do stávajícího sprintu, vyvolal by následující činnosti z pohledu SCRUM Mastera:

Příprava změny v datovém modelu: půjde-li o datové položky, bude třeba překopat datový model
Příprava změny logického návrhu - modelu tříd: změněnému datovému modelu přizpůsobíme nový diagram tříd
Příprava zadání pro: HTML5/CSS3 vývojáře, Frontend programátora, Backend programátora
Otestování změny a integrace do celku
Optimalizace řešení z hlediska času a náročnosti na HW

Koho by se změna týkala?

Jaké činnosti a které lidi by ovlivnila jedna User Story ve stávajícím sprintu?

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 Master: architektura dat v ERD/UML, architektura tříd v UML
Team Membera: Programátora HTML5 + CSS3: grafika v přetransformována do CSS3
Team Membera: PHPv5/7 OOP frontend programátoru: přeprogramování modulu kódu a otestování a optimalizace
Team Membera: JAVA8 SE backend & middleware programátora: přeprogramování modulu kódu a otestování a optimalizace

Demotivace týmu

Pokud SCRUM Master nebude aktivně pracovat na stmelování týmu, tým umí poměrně snadno rozmotivovat a rozhádat i sám. Vždyť k tomu, abyste rozhádali dva lidi, nepotřebujete vysokou školu.

Nyní ale uvažujme ideální případ, kdy se lidem dělat chce, mají se rádi a mají vytvořeny takové podmínky, ve kterých se jim dobře pracuje. Představte si, že jste původně definovali User Story, se kterou se Team Member pořádně vyhrál tak, aby byla přesně podle vašich původních představ. V práci zůstal déle, dokonce odřekl svůj oblíbený squash proto, aby práce byla kvalitně a včas předána. Následně změníte specifikaci této User Story. Vy si myslíte, že se jedná pouze o drobnou úpravu, ale reálně jde o změnu toku údajů, které vyžadují změnu databázového modelu, a tím následně i kódu. Budete tvrdit, že se jedná o banalitu. Jaké myslíte, že to v Team Memberovi vyvolá? Netvrdím, abyste neměnili specifikaci stávajících User Stories, jen abyste vyvolání těchto pocitů brali alespoň trochu v úvahu.

Jaké je řešení?

Slyšeli jste o "kaskádovém efektu"? Pokud někde vznikne nějaká změna, může přeskočit i do oblasti, kde k ní není žádný přímý důvod. Jak to přenést do praxe při vývoji softwaru? Představme si, že tabulky na portálu filtrujeme univerzálním filtrováním modulem, který využívají všechny tabulky přes standardní rozhraní. Pokud změníme univerzální filtrování tabulek (např. interní strukturu tříd, které řeší filtrování), může nám to ovlivnit (resp. vyvolat nečekaný stav) tabulek, které také používají modul univerzálního filtrování. Z programátorského hlediska, jedině, jak se umíme bránit vůči tomuto nešvaru je "průběžně testovat", což je "základ prevence".

Jaká je ale prevence toho, abyste nejprve navrhli User Story a po implementaci ji měnili? Mohli byste si ji vizualizovat alespoň pomocí Wireframe (drátový 2D model, logická obrazovka, kde neuvažujeme grafiku, stačí na čistou A4 s perem) i když půjde banalitu. Už jen tím, že popřemýšlíte, jak by měla vizuálně vypadat si možná ujasníte rysy tohoto příběhu už na začátku jeho tvorby. Možná se dostanete myslí do stavu, kdy už je User Story implementována a možná domyslíte její důsledky a upřesníte její zadání. Možná když si zkusíte představit samotný příběh ve výsledné implementaci, sepíšete si na papír jednotlivé body, přijdete na další věci.

Ještě jednou opakuji, SCRUM je agilní metodika, která vítá změny. Její prvořadým cílemje "kvalitní software". Abychom se vyhnuli počátku dezorganizace a chaosu sprintu, jak lepší řešení vidím v dodržení následujícího postupu: