Když klient chce termín hned, nabídněte mu realitu

U každého požadavku nastavte metodu, URL a tělo. U metod GET a DELETE tělo obvykle nebývá potřeba, u POST a PUT naopak. V záložce Body zvolte raw a formát JSON, pokud API očekává JSON. Častá chyba je zapomenutá hlavička Content-Type: application/json. Bez ní server tělo ignoruje nebo vrátí chybu 415. Stejně tak si dejte pozor na to, zda posíláte data jako form-data, x-www-form-urlencoded nebo raw – záměna vede k nečitelným chybám.

Po prvním zeleném testu přidejte druhý případ, který ověří hraniční hodnotu. Například prázdný vstup, nulu nebo záporné číslo. Právě tam se objevují chyby, které běžné použití neodhalí. Nespěchejte na pokrytí celého modulu. Raději mějte tři spolehlivé testy než dvacet náhodných. Pokud test opakovaně selhává bez změny kódu, pravděpodobně obsahuje skrytou závislost nebo špatně nastavená očekávání.

Odhad není soutěž v přesnosti na minuty. Je to nástroj, jak se domluvit na očekávání. Když budeš skryté činnosti zveřejňovat už při zadávání, přestanou být skryté. Tým je uvidí, vedení je uvidí a ty nebudeš muset vysvětlovat, proč to trvalo déle. Začni u příštího úkolu: než řekneš termín, projdi si, co všechno se kolem něj skutečně stane.

Pull request není jen místo pro schválení. Je to poslední šance odhalit chyby dřív, než se dostanou do hlavní větve. Nastavte si ochranu hlavní větve tak, aby vyžadovala alespoň jedno schválení a zelené testy. Do popisu pull requestu napište, co změna řeší a jak ji ověřit — recenzent pak nemusí hádat. Vyhněte se dvěma krajnostem: schvalování bez čtení a blokování kvůli stylistickým drobnostem, které patří do automatické kontroly.

Začněte tím, že si před odhadem ujasníte, kde analytika končí a implementace začíná. Analytika obvykle zahrnuje sběr požadavků, rozpracování scénářů, návrh datových toků, dohodu s byznysem a zápis akceptačních kritérií. Implementace je pak samotný kód, testy, revize a nasazení. Pokud tyto hranice nejsou pojmenované, lidé si pod pojmem „hotovo" představují různé věci a odhad se rozpadne při prvním upřesňování.

Na konci každé schůzky shrňte dohodu písemně. Stačí tři věty: co dodáte, do kdy a co k tomu potřebujete. Tím se vyhnete nedorozumění. Pokud zákazník trvá na nereálném termínu, řekněte jasně, co se stane, když ho přijmete: buď to bude mít vliv na kvalitu, nebo na jiné zakázky. Nechte ho rozhodnout. Odpovědnost za rozhodnutí pak nesete společně.

Od izolace k prvnímu spuštění Vytvořte testovací soubor pojmenovaný stejně jako testovaný modul, jen s příponou podle konvence vašeho jazyka. Uvnitř napište jednu testovací metodu, která připraví vstupy, zavolá funkci a porovná výsledek s očekávanou hodnotou. Nepřidávejte hned deset případů. Jeden test, jedno tvrzení. Pokud test selže, chcete přesně vědět, co je špatně. Spusťte testovací runner a sledujte výsledek. Červená je v pořádku, pokud odhalí skutečnou chybu v kódu nebo v očekávání.

Ptejte se na priority, ne na datum Místo otázky „Kdy to potřebujete?" se ptejte „Co je pro vás nejdůležitější?" Zákazník často řekne, že to musí být do pátku, ale po chvíli zjistíte, že jde o jednu konkrétní funkci. Pak můžete dodat zbytek později a termín dodržíte. Pokud se ptáte na datum, dostanete datum. Pokud se ptáte na hodnotu, dostanete informaci, se kterou se dá pracovat.

Nejčastější chyba začátečníka je testovat příliš mnoho najednou. Test, který ověřuje pět různých věcí, se později těžko udržuje. Další častou chybou je závislost na vnějším prostředí. Test, který prochází jen na vašem počítači, není unit test. Pokud funkce volá jinou funkci, která sahá do sítě, nahraďte ji jednoduchou atrapou. Atrapa vrací předem danou hodnotu a vy tak ověříte pouze logiku, kterou skutečně testujete.

Odhady času jsou nejčastější zdroj konfliktů se zákazníky. Ne proto, že bychom neuměli pracovat, ale protože slibujeme termíny, které nedokážeme dodržet. Zákazník pak ztrácí důvěru a vy ztrácíte zakázku. Řešení není v lepším plánování, ale v lepší komunikaci. Tady je postup, jak mluvit o čase tak, aby to fungovalo.

Nejdřív si ujasněte, co vlastně odhadujete. Zákazník často slyší jen konečné datum, ale vy potřebujete mluvit o fázích. Rozdělte práci na části a u každé řekněte, co je potřeba dodat vy, co zákazník a co třetí strana. Tím se vyhnete tomu, že slíbíte termín, který závisí na někom jiném. Zároveň tím získáte prostor pro upřesnění, když se něco změní.

Nikdy neslibujte termín, který jste si neověřili. Typická chyba je říct „to bude hotové do týdne" hned na prvním callu. Lepší je říct: „Odhaduji to na týden, ale potřebuji si projít zadání a do zítra vám potvrdím, jestli to platí." Tím získáte čas a zákazník ocení, že nejste unáhlený. Pokud termín potvrdíte až po analýze, máte větší šanci ho dodržet.