SCRUM 4 - Backlog, klient a dění kolem

V dnešním posledním díle seriálu o lesku a bídě používání SCRUMu ve firmách jsme ve finále, takže si povíme něco o nejzávažnějším nešvaru – špatné práci s backlogem a klientem. O co jde?

Tento článek vznikl pro firemní blog Trigama International s.r.o., originál najdete zde.

Backlog

V prvé řadě je nutné poznamenat, že každý projekt by měl mít svůj backlog – fyzické či virtuální místo, kam se ukládají a střádají možné featury a ideálně i další úkoly spojené s projektem, včetně pojmenování technického dluhu (tzn. věci k refaktorování). Hlava projekťáka se nepočítá, protože do ní si nemůžete přijít na návštěvu a rozhodně si nad ní nemůžete sednout se všemi účastníky projektu a prodiskutovat obsah dalšího sprintu.

Nemít backlog je jeden z nezávažnějších nešvarů, ale hned v závěsu se umísťuje nedívání se do něj a plánování sprintů ledabyle podle toho, co tým či projekťáka zrovna pálí nejvíc. Možná si říkáte, jak toho vůbec lze docílit, když podle SCRUMu by se to, co dělá, mělo primárně řídit zájmy klienta?

Klient je vždy na prvním místě!?

No a tím se dostáváme k úplně nejzávažnějšímu nešvaru používání SCRUMu – nezahrnutí klienta do celého procesu vývoje. Nemusí být nezbytně na všech aktivitách, ale některé jsou pro něj klíčové – měl by mít možnost ovlivnit, co se bude realizovat, a měl by po každém sprintu mít dostatečně podrobné zhodnocení, shrnutí či přímo ukázku toho, co se udělalo, kolik to stálo a jaký je další výhled.

Často je ale ze všech aktivit vyhozen se zdůvodněním, že je to všechno moc technické a že jestli o to management tak stojí, ať to pro něj udělají v separátních aktivitách. A tak se hned dostáváme ke druhému nešvaru, kterým je nahrazení klienta interním zástupcem (též nazývaným styčným důstojníkem či produkťákem), který je pověřen separátními aktivitami a překládáním technických detailů – časová i mentální náročnost tohoto ale poměrně často vede k tomu, že komunikace není dostatečně kvalitní, případně zcela zmizí. A hlavně interní zástupce nikdy nemůže znát potřeby klienta tak dobře jako klient sám… To vše dohromady nevěstí pro úspěch projektu nic dobrého.

Loterie prvovýstupu

Specifickým případem je pak vývoj nových produktů pro širší použití (tzn. nikoliv zakázkový vývoj), při kterých klient či klienti ještě (většinou) neexistují. I zde má ale klient své nezastupitelné místo – někdy lze nějaké budoucí klienty najít a provést validaci na nich. Spoléhat se na vizi jednoho člověka či malé skupiny osob, jak by výsledný produkt měl fungovat, je prostě loterie.

Tímto jsme se dostali až na konec série o nešvarech používání SCRUMu ve firmách. Jistě nejde o zcela úplný výčet, určitě jste zažili řadu jiných potíží, a možná vás dokonce kvůli tomu všemu začal SCRUM tak trochu iritovat. Než ho ale začnete nenávidět, neuškodí věnovat mu chvíli času – přečtěte si, kdy vznikl, v jakých podmínkách, co se snaží řešit… A pak se s odstupem podívejte, jaké síly či tlaky působí ve vašich organizacích, a mnohdy pochopíte, jaké nešvary vaše použití SCRUMu má a možná i proč.

Závěrem ale nezapomínejme, že SCRUM, stejně jako jakákoliv jiná metodika vývoje, řeší to, co by nás mělo trápit především – jak být profesionály v našem řemeslu – tedy jak spolehlivě dodat včas správný produkt v přijatelné ceně a kvalitě. A to je náš každodenní boj!

 
9. 12. 2020 20:43 programming


Tagy

informace (20), návod (2), mysql (1), užitečné (6), internet (1), komix (99), ironie (1), humor (99), Bůh (2), škola (38), plánování (1), Čas (2), hříchy (1), otroctví (1), esej (4), Erasmus (24), project management (2), programming (16), teamwork (1), bad code (1), práce (1)

Hledání

Odběr zpráv

RSS feed Blog (RSS)