V minulém dílu seriálu o lesku a bídě používání SCRUMu ve firmách jsme poukázali na zmatení, které termín SCRUM často působí, a na jeho nejasný význam. Dnešní díl bude zaměřen na plánování, jež je častou bolístkou současného IT, ve kterém velké množství projektů plán (ať už finanční, či časový) překročí.
Dejte nám Plán
Důležitou schopností každého týmu je umět odhadnout, kolik práce dovede za jednotku času, typicky zvanou sprint, dodat ve výstupní kvalitě, kterou lze předat zákazníkovi. Způsobů, jak toho dosáhnout, je vícero, od intuice přes člověkohodiny až po storypointy. A prakticky vždy je potřeba nějak vhodně klasifikovat třídy obtížnosti, a je jedno, jestli to zařídíte ad-hoc porovnáváním úkolů, definovanými třídami obtížnostmi či storypointy.
Častým nešvarem v této oblasti je ovšem buď úplné neřešení odhadů týmem, či jejich svěření do rukou jediného člena týmu, například projektového manažera či šéfa vývojářů. Tým se pak „jenom veze“, což jde proti myšlence, aby se právě tým sám podílel na tom, co se dělá i kolik se toho do sprintu vejde – a zejména pak na tom, k jakému termínu se upíše.
Dalším častým nešvarem je lpění na odhadování jednotlivých dílčích úkolů v člověkohodinách, na kterém často bazíruje management, který tyto odhady používá ke sledování jednak toho, jak se ve sprintu postupuje, a dále pak toho, jak se postupuje napříč produktem jako celkem.
Předchozí bod nás přivádí k ještě závažnějšímu nešvaru, totiž k zadání od managementu, abyste s týmem rozanalyzovali následující seznam featur, všechno poodhadovali a pak naskládali do sprintů, abyste zjistili, jestli to teda všechno stihnete udělat do půlky příštího roku v takovém a takovém budgetu. Udělat to sice jde, ale není to pak už prostě vodopád? Neztrácí se hlavní smysl SCRUMu? Budou ty odhady v momentu, kdy se k nim dostanete, ještě validní?
Nerozporuji, že takové odhady jsou někdy potřeba, jenže dělat je skrze SCRUM metodiku je poněkud zoufalé a neefektivní, nehledě na to, že v ideálním světě váš tým skutečnost, že používá metodiku SCRUM, činí poněkud hůře kompatibilním s FTFP (fix time fix price) účtováním, což je rovněž třeba brát v úvahu.
V příštím díle tohoto seriálu si povíme, jaké nešvary při používání SCRUMu způsobuje, když se váš tým snaží honit příliš mnoho zajíců.
Sdílet článek