Když odhad času slíbíte, klient čeká zázrak. Co dělat místo toho
Typickou chybou je použít NoSQL jen proto, že je „moderní", a pak zjistit, že potřebujete složité transakce napříč více záznamy. NoSQL databáze často podporují transakce pouze v rámci jednoho dokumentu nebo klíče. Pokud potřebujete převod peněz mezi dvěma účty, kdy musíte atomicky upravit oba záznamy, raději zůstaňte u SQL. Stejně tak si dejte pozor na agregační funkce – většina NoSQL databází je zvládá, ale syntaxe je méně unifikovaná než SQL. Počítejte také s tím, že přechod z SQL na NoSQL vyžaduje změnu myšlení: přestanete normalizovat data a začnete je ukládat tak, jak je čtete.
Sledování skutečného času je nezbytné pro zlepšení budoucích odhadů. Po dokončení úkolu si zapište, kolik času zabraly viditelné a kolik skryté činnosti. Po třech až pěti takových záznamech uvidíte, jaký je průměrný podíl skryté práce ve vašem projektu. Tento údaj pak použijte jako základ pro další plánování. Vyhnete se tak opakovanému zpoždění a dotazům vedení, proč termín nevyšel. Odhad se stane spolehlivějším nástrojem, ne jen číslem v tabulce.
Když se řekne databáze, většině vývojářů se vybaví tabulky s řádky a sloupci, tedy klasický SQL. Jenže moderní aplikace často pracují s daty, která se do pevné struktury nevejdou – třeba s dokumenty, grafy nebo časovými řadami. Právě pro tyto případy existuje NoSQL. Nejedná se o jednu technologii, ale o rodinu databází, které se liší způsobem ukládání i dotazování. Než se do NoSQL pustíte, je důležité pochopit, kdy dává smysl a kdy naopak zvolit osvědčený SQL.
Typickou chybou je slibovat „průběžně budeme informovat". Tato fráze nic neznamená a zákazník si pod ní představí každodenní hlášení. Mnohem lepší je hned na začátku domluvit, kdy přesně budete posílat zprávy (například každý pátek odpoledne) a co v nich bude (stav, zpoždění, nejbližší krok). Pokud víte, že něco může sklouznout, oznamte to dřív, než se to stane. Zákazník vám odpustí zpoždění, ale nikdy neodpustí ticho a náhlé zjištění, že se práce nestíhá.
Pokud se rozhodnete pro NoSQL, začněte s jednoduchým případem a postupně rozšiřujte. Například si vytvořte dokumentovou databázi pro ukládání článků na blogu. Do jednoho dokumentu vložte obsah, autora, tagy i komentáře. To vám umožní jediným dotazem načíst celý článek i s komentáři, což by v SQL znamenalo spojení tří tabulek. Pozor ale na to, že pokud chcete zobrazit seznam všech tagů napříč články, tento model vás nutí procházet všechny dokumenty. V takovém případě si vytvořte separátní kolekci tagů a aktualizujte ji při každém uložení článku. Tento kompromis mezi denormalizací a konzistencí je klíčový pro efektivní využití NoSQL.
Základní pravidlo zní: odhad nikdy neprezentujte jako jediné pevné číslo. Místo fráze „hotovo za tři týdny" použijte rozpětí, které má logické zdůvodnění. Například „práce zabere 3 až 5 týdnů, záleží na tom, kdy dodáte podklady a kolik změn si během realizace necháte schválit". Tím zákazníkovi vysvětlíte, že čas není magická konstanta, ale proměnná, kterou ovlivňují i jeho vlastní kroky. Tento přístup ho nutí přemýšlet o tom, co může udělat pro to, aby se termín zkrátil.
Častou chybou je plánovat úkoly těsně za sebou bez rezervy na přepínání kontextu. Když programátor přechází mezi dvěma úkoly, mozek potřebuje čas na obnovení souvislostí. Stejně tak schůzka uprostřed dne rozdělí práci na dva kratší bloky, které jsou méně efektivní než jeden souvislý celek. Pokud víte, že vás čeká porada, naplánujte si práci na menší celky, které lze dokončit mezi schůzkami. Do odhadu pak zahrňte také čas na zápis poznámek nebo předání informací kolegům.
Pamatujte, že pyramida není statická. S tím, jak se mění architektura aplikace, mění se i poměr testů. Na začátku projektu můžete mít více integračních testů, protože ještě nemáte stabilní rozhraní pro mockování. Po pár měsících se hranice ustálí a vy je převedete na jednotkové. Klíčové je pravidelně revidovat testovací sadu: jednou za kvartál se podívejte, které testy nikdy neselhávají, které opakovaně vyžadují opravy a které už neodpovídají aktuálnímu chování systému. Testy, které nikdo nespouští nebo jim nikdo nerozumí, jsou horší než žádné — dávají falešný pocit bezpečí.
V praxi to znamená, že většinu testů píšete na úrovni jednotek — malé a izolované testy, které ověřují jednu třídu nebo funkci. Nad nimi jsou integrační testy, které kontrolují spolupráci mezi komponentami, a na vrcholu end-to-end testy procházející celou aplikací. Typická chyba začátečníků je obrátit pyramidu vzhůru nohama: spoléhat se hlavně na UI testy, které jsou pomalé, křehké a při sebemenší změně selektoru selhávají. Výsledkem je sada testů, která běží hodiny a většinu času jen křičí falešné poplachy.
