Guidebook

Jak zvládnout rostoucí scope při fixním termínu projektu?

Testing je nedílnou součástí projektového vývoje. Jeho správné nastavení může pomoci minimalizovat riziko, že se překročí naplánovaný termín spuštění projektu nebo že dojde k přečerpání domluveného budgetu.

Druhou kapitolou je pak rozšířená disciplína Quality Assurance, kam spadají témata jako pravidelná prioritizace scope, dobře sestavený tým nebo transparentní reporting.

Pojďme se společně podívat na to, jak v INVENTI přistupujeme k minimalizaci rizik spojených se situací, kdy roste scope projektu, ale jeho termín odevzdání zůstává neměnný.


Quality Assurance

Prioritizace a práce se scope

První krok, který se nám v rámci INVENTI osvědčil, je zavedení pravidelných prioritizačních schůzek se zadavatelem. Do prioritizace by neměly vstupovat pouze User Stories či (ne)funkční požadavky, ale i bugy. Současně je vhodné pokládat otázky typu: 

  • „Jedná se o skutečně důležitou funkcionalitu, bez které aplikace nebude použitelná?“ 
  • „Co se stane, pokud toto nebude fungovat?“ 

Je potřeba nastavit si jasná pravidla, podle kterých určujeme důležitost jednotlivých tasků.

Dalším bodem, ve kterém je nutné prioritizovat i důkladně plánovat, je samotný vývoj. Je třeba se neustále ujišťovat že hlavní vývojář organizuje práci jeho týmu a pravidelně s ním řeší nejen prioritu, ale i návaznost vývoje dílčích částí.

V tomto kroku pomůže také revize obsahu tasků. Mnohdy se totiž stává, že analytik pochopí zadání trochu jinak, čímž dochází ke zvyšování pracnosti. Ověřujeme tedy, že analytik zpětně validoval své výstupy se zadavatelem a že vývojář chápe zadání tak, jak ho analytik myslel.

Není nic horšího než prosezené hodiny na schůzkách kvůli tomu, že se týmy mezi sebou nedomluvily na vstupech/výstupech od druhé strany pro svou práci.

Aktualizované odhady

Velmi často se stává, že na začátku dostaneme odhady, ale poté už nedojde k aktualizaci zbývajícího času. Na týmových schůzkách sice slýcháváme, že někdo dělá na určitém tasku, který ještě nějakou dobu potrvá, nevíme však, kdy by to tedy mělo být hotové. Problém nastává, když je v ohrožení stihnutí domluveného termínu spuštění. Do tohoto stavu se samozřejmě nechceme dostat, a tak tým musí pochopit, že potřebujeme vědět, na čem jsme. 

Vždy týmu vysvětlujeme, k čemu tyto informace potřebujeme a jak s nimi budeme nakládat. Takové vysvětlení může znít například takto: „Pokud od vás vždy na konci dne nebudu mít aktualizovaný zbývající čas pro dokončení, budu počítat s dodáním dle původního odhadu. Když mi pak v den, kdy to mělo být dokončeno, řeknete, že to ještě není, budeme muset řešit přesčasy. Na konci dne mě tedy informujte, kolik toho zbývá, abych měl informace, se kterými mohu pracovat. Podle nich můžeme upravit backlog, zbývající scope nebo třeba zajistit včasnou pomoc a nebudeme muset pracovat přesčasy. Současně se poučíme z toho, o kolik se nám odhady rozchází, a příště si dáme větší prostor pro odchylky. Rozhodně není mým cílem se po vás vozit, že nestíháte odhady, to se běžně děje. Cílem je mít možnost na to reagovat a pracovat s tím.“

Získejte plnou verzi Guidebooku.

 Stačí zadat svůj email a zašleme vám ho! 👇