Co se stane, když odhad času nesedí

Čistý kód v JavaScriptu neznamená krásně barevné zvýraznění v editoru. Znamená kód, kterému po půl roce porozumíš i ty sám, a který kolega opraví bez toho, aby se bál něco rozbít. Největší problém nebývá složitá logika, ale zbytečný chaos: nejasné názvy, dlouhé funkce a proměnné, které mění význam podle toho, kde se zrovna použijí.

Výkon se neměří jen na vlajkové lodi. Spusťte aplikaci na starším zařízení s omezenou pamětí a sledujte dobu spuštění, spotřebu baterie a plynulost posouvání. Zaznamenejte hodnoty před a po každé změně, jinak nepoznáte, který zásah situaci zhoršil. Testujte také přechod mezi sítěmi – z Wi-Fi na mobilní data – a chování aplikace při příchozím hovoru nebo oznámení.

Hlavní větev musí být vždy nasaditelná. To znamená, že každý požadavek na sloučení projde automatickou kontrolou a testy. Pokud testy nejsou, zaveďte alespoň ruční ověření na testovacím prostředí. Nikdy nesloučujte změnu, která rozbíjí build, i kdyby byla sebelepší. Oprava rozbité hlavní větve zdrží celý tým a často se řeší pozdě v noci.

Odhady času jsou nejčastější zdroj konfliktů mezi dodavatelem a zákazníkem. Ne proto, že by čísla byla špatná, ale proto, že se o nich nemluví stejně. Zákazník slyší „bude to hotové v pátek" a rozumí tomu jako slibu. Vy myslíte odhad za předpokladu, že se nic neposere. Rozdíl mezi slibem a odhadem je přitom zásadní – a je na vás ho pojmenovat dřív, než zazní první termín.

Dalším častým omylem je domněnka, že stačí ošetřit vstup na začátku aplikace. Data se mohou dostat do dotazu i z databáze, z mezipaměti, ze souboru nebo z externího rozhraní. Stejně nebezpečné je spoléhat na to, že magické uvozovky nebo automatické escapování vyřeší vše. Escapování je vázané na konkrétní znakovou sadu a konkrétní databázi. Při nesprávném nastavení připojení může být obejité. Parametrizace žádné takové podmínky nemá.

Dalším návykem je odhadovat v týmech, ne samostatně. Krátká diskuze nad úkolem odhalí rozdílné předpoklady. Jeden člověk počítá s hotovým API, druhý s tím, že se musí nejprve napsat. Stačí položit otázku: co vše musí být hotové, než tento úkol začne? Tím se vyhneme překvapením, která zdrží celý projekt.

Typickou chybou je odhadovat optimisticky podle nejlepšího scénáře. Lidé mají tendenci věřit, že tentokrát půjde vše hladce. Pomáhá stanovit odhad jako rozmezí: nejlepší případ, nejpravděpodobnější a nejhorší. Pro plánování používejte ten pesimističtější, ne ten nejnižší. Pokud se projekt zdá být v pořádku jen při optimistickém odhadu, je to varovný signál.

Nakonec přijměte, že odhad je jen předpověď. Po každém sprintu nebo milníku porovnejte plán se skutečností a zapište si, co odhad zkreslilo. Bez zpětné vazby se stejné chyby opakují. S pravidelnou reflexí se odhady zpřesňují řádově v desítkách procent, ne skokem. Cílem není dokonalost, ale předvídatelnost, která umožní lépe plánovat a snižovat stres.

Odhad času v softwarových projektech nebývá přesný, protože lidé nejsou stroje a zadání se mění. Přesto se dá systematicky zlepšovat. Nejde o to trefit termín na minutu, ale snížit rozdíl mezi odhadem a skutečností. Klíč je v opakování, měření a v ochotě přiznat chybu.

Základem je rozklad práce na malé části. Místo odhadu „napsat modul" odhadněte jednotlivé úkoly do dvou až čtyř hodin. U delších činností je dále rozdělte, dokud nezískáte položky, které dokážete představit jako konkrétní sled kroků. Malé úkoly se odhadují snáze a chyba se neprojeví tak dramaticky. Zároveň tím odhalíte skrytou práci, jako je psaní testů, revize kódu nebo komunikace se zadavatelem.

Měřte skutečný čas, ne jen ten strávený psaním kódu Většina vývojářů podceňuje režii. Do odhadu je potřeba započítat schůzky, čekání na odpovědi, opravy po testech a přepínání kontextu. Zaveďte si jednoduchý záznam: u každého úkolu si poznamenejte, kolik času zabral od začátku do dokončení včetně přerušení. Po několika týdnech uvidíte vzorce. Například že úkol odhadnutý na čtyři hodiny reálně zabere šest, protože dvě hodiny spotřebují porady a ladění prostředí.