logotype
Scrum

Kdo zadává požadavky na tým, který jede agilní vývoj?

Nedávno jsem měl na jednom meetingu debatu o tom, kdo může ve Scrumu vytvářet stories a dávat je do backlogu. Je to vždy jenom Product owner? 

Standardní situace - developer říká že je potřeba přidat či změnit část aplikace, ale musí počkat na product ownera, aby se na to podíval. To je v pořádku, tak to má být. Product owner je zástupce zákazníka, resp businessu a jako takový je jediný opravněný schvalovat změny. Co ale nebylo zcela standardní, je přístup, jakým jsou tyto požadavky zaznamenány. 

Požadavky na novou funkcionalitu, či její změnu jsou v agilním světě tvořeny formou stories. Jedná se de facto o nejmenší přírůstek aplikace, který stále ještě přináší hodnotu pro zákazníka. Pokud je ve Scrumu samoorganizující se tým (který nese za produkt opravdovou zodpovědnost) alfou a omegou, je nutné, aby od samotných programátorů a testerů přicházelo co nejvíc nápadů na zlepšení. Jedině tak je možné dosáhout stavu, že tým bude šlapat jak švýcarské hodinky a finální produkt bude ten nejlepší na světě.

Aby se takového stavu ale dosáhlo, je bezpodmínečně nutné podporovat tým jak to jen jde. A právě na meetingu, kde jsem byl, zazněla věta od seniornějšího člena týmu, že není možné přidat žádnou další story do backlogu, protože tady není Product owner. A vzhledem k tomu, že Product owner bude v práci až za týden, bude se muset počkat. Při otázce proč to není možné udělat i bez něj, jsem dostal oodpověď, že Product owner nechce, aby se v backlogu "hrabal" někdo další a byl v tom pak zmatek.  

Tento přístup se dá možná ještě pochopit v situaci, kdy se backlog nedá nijak filtrovat, případně nijak měnit pohled na položky v něm uložené. A nebo pokud se nápady, které vzniknou de facto ad hoc na různých poradách, zaznamenají někam jinam, aby se na ně nezapomnělo a v budoucnu se s nimi mohlo pracovat. V situaci, kdy ale nic takového není, postrádá snaha Product ownera mít uhlazený backlog za každou cenu smysl.

Co se tedy stalo po tomto meetingu? Programátor svůj nápad již na dalších nezmínil a dělal to, co mělo podle Product ownera hlavní prioritu. Jeho motivace zlepšovat věci byla pak menší než dříve, protože tam chyběla ta opravdová zodpovědnost za budoucí vývoj. Netvrdím, že jakěkoli plánování práce má být za každou cenu diskuze a vyjednávání. Naopak je dobře, že direktivním způsobem může někdy rozhodovat jen omezený počet zúčastněných. Vždy je ale potřeba se zamyslet nad dlouhodobým přístupem a zvážit možné změny, co a jak dělat třeba trochu jinak.

 

 

2019  MIddleware.cz - blog nejen o informačních technologiích