Konečně(!) jsme se dostali do (nějak rozumně) fungujícího nového procesu vývoje. Jako všichni, kteří se pokoušeli změnit fungování vývoje, jsme si leckde nabili hubu i my. Alespoň ale už máme možnost systematicky identifikovat, kde to vázne, a postupně tyto zádrhely odstraňovat.

Tady je TOP10 poznámek z našeho prostředí.

Všichni musí znát a chápat proces. Všem musí být jasné, kdo je kdy za co zodpovědný. Je jedno, jestli to vyřešíme pomocí přepínání stavů úkolů, nebo přiřazením úkolů konkrétním lidem, nebo kombinací obojího. Důležité je, aby tomu všichni rozuměli a všichni věděli, co a kdy se od nich čeká. A protože nikdo netvrdí, že tento proces je jednou pro vždy daný (naopak), musí být změny vysvětlovány všem zúčastněným.

Je třeba aby všichni znali a chápali proces nakládání s chybami a dalšími záležitostmi (zejména) z produkce. Každý musí vědět, co znamená, že chyba je označena za kritickou a jak je na ni třeba reagovat. Stejně tak každý musí vědět, kdy chybu lze označit za kritickou a nezneužívat toho.

Úkol je splněn (DoD), pokud je naprogramován, otestován a akceptován — po stránce logiky, po stránce správnosti, ale i po stránce kvality kódu. Toto je důvod, proč je nebezpečné pouštět se do příliš mnoha nových úkolů dříve, než je skutečně akceptováno to, co je rozpracováno. Jinak to končí tak, že máme rozpracováno 10 věcí a nic hotovo.

Termíny jsou termíny — ať už byly stanoveny jakkoliv. Pokud vím, že termín je v pondělí večer a v pátek před tím (a ještě i v pondělí) tvrdím, že vše stíhám, tak není obhajitelné, že v úterý na DEMU to nemám (nebo že to nefunguje a zjistí se to až tam). Pokud něco na DEMU prezentuji jako hotové a pak se zjistí, že to nemám ani naprogramované (natož otestované), pak už to snad ani nejde nazvat nedorozuměním. Ani tak nejde o to, že něco neumím nebo neznám. Jde v zásadě o problém komunikace. Každá komunikace, zejména ta psaná, by měla končit jasným call-to-action — tj. co od protistrany očekávám, nebo mám v plánu udělat, pokud nedostanu vyjádření. Otázka k zamyšlení: “Jak řešit, když to příště dopadne podobně?”

Pravděpodobně nastanou situace, kdy se začne valit na poslední chvíli dokončená práce od programátorů. To samo o sobě často vede ke zbytečným chybám. V těchto chvílích se může tester zbláznit, protože pravděpodobně neví, kam dřív skočit a tím pádem často ani nemá prostor udělat svou práci kvalitně. Naopak na začátku iterace má tester často trochu volněji. Řešením může být posunout testera z role primárního vykonavatele testů do role, kdy připraví (v době kdy má volněji) kvalitně připraví testovací scénáře. Na konci iterace pak v případě potřeby můžou pomoct ostatní členové týmu, kteří takové scénáře odehrají.

Neříkám, že si to programátoři po sobě nemají otestovat. Je hezké, že proklikáním na vývojové mašině ušetříme nějaká režijní čas související s vydáním verze, ale toto přináší víc problémů než užitku (taky jsem to ale dělal). Jednak proto, že testujeme na lokální mašině, kde máme nainstalováno kdoví co a nakonfigurováno kdovíjak — ale pravděpodobně určitě jinak, než na produkčním nebo testovacím prostředí. Další nešvar je testování z IDE (Visual Studia) — ano je fajn, že když to spadne, tak díky debuggeru často hned víme, kde a často i proč — ale kód zbuilděný v debug konfiguraci se může často chovat jinak než produkční release build. Řešením je kompilovat na buildserveru a testovat na testovacím prostředí.

Odhadování náročnosti úkolů není nejvíc zábavná činnost pod sluncem. Je potřeba to dělat. Je potřeba to dělat kvalitně. A je potřeba být na takovou diskusi čerstvý a soustředěný, ušetří to mnoho problémů během vývoje. Nikdo se nevydrží dostatečně soustředit celý den (ani celé odpoledne), je lepší tyto schůzky dělat raději častěji a mít je kratší.

Je ku prospěchu všech zúčastněných, pokud se zákazník účastní DEMA a ideálně i plánování. Jen tak bude vědět, co se vyrobilo a jestli je to to, co chtěl a kdy chtěl. Pokud to tak je, tak jsou všichni spokojení. Pokud není, tak DEMO není to nejlepší místo, kde to řešit. Proč? Protože problém nastal dost možná někde úplně jinde, někde mnohem dříve.

Ničemu nepomůže, když zahltíte programátory a testery víc, než je zdrávo. Pokud jsou součástí týmu lidi, co se starají o ASAP věci z produkce, naplánujte jim raději o něco méně práce na novém vývoji. Při pracovní době 8h takovým lidem naplánujte třeba jen 6h, zbytek jim nechte na řešení potřeb produkce. Ostatní tuto rezervu nepotřebují, přinejmenším ne stejně velkou.

Někdy to nejde podle plánu — někdo onemocní, někdo potřebuje akutně volno. To se stává a bude stávat, nemá cenu s tím bojovat. Pokud první den sprintu zjistíte, že se kapacita změnila, ukázalo se jako zásadní řešit to ihned (ne až po týdnu). Výpadek kapacity na začátku iterace je zásadní v tom, že na začátku iterace se obvykle snažíme vyřešit ty nejdůležitější úkoly — ty, co mají největší prioritu, popř. velké riziko, že to nepůjde, jak má.

Důležité je, že jsme se do toho pustili a začali. Teď je potřeba vnímat, jak to funguje, pružně reagovat a vylepšovat. Jak se dařilo vám při zavádění nového procesu vývoje, ať už jakéhokoliv? Narazili jste na podobné obtíže? A jak s nimi bojujete?

LinkedIn ↗