Jak rozvrhnout odhad času mezi analýzu a implementaci v agilním týmu

Častou chybou je, že se analytický odhad započítává do implementace, a tým pak má pocit, že má na kódování méně času, než ve skutečnosti potřebuje. Proto doporučuji oddělit v odhadu dvě položky: „analýza" a „implementace", a každou z nich komunikovat zvlášť. Například u středně složitého user story může být analytická část 20 % celkového času, ale u komplexního systému s integracemi to může být 60 %. Neexistuje univerzální poměr, proto vždy vycházejte z konkrétních souvislostí.

Nejprve si vytvořte seznam všech činností, které s úkolem souvisí, i když se nezdají být důležité. Rozdělte si práci na fáze – příprava, implementace, kontrola, nasazení. Ke každé fázi si zapište nejen hlavní úkol, ale i vedlejší aktivity: komunikaci s kolegy, koordinaci s jiným týmem, čtení dokumentace, hledání chyb, psaní testů, aktualizaci CI. Čím konkrétnější seznam, tím lépe.

Druhým krokem je vytvoření vlastního portfolia. Nemusíte mít přístup k placeným nástrojům – postačí vám bezplatné aplikace, které dobře znáte, nebo dokonce vlastní malý projekt. Vyberte si jednoduchou webovou stránku nebo mobilní aplikaci a začněte ji systematicky testovat. Zapisujte si každý nález do tabulky: popište krok, jakým jste problém reprodukovali, očekávané chování, skutečné chování a případně i prioritu. Dbejte na to, aby váš popis byl srozumitelný i pro člověka, který aplikaci nezná. Tento dokument pak poslouží jako ukázka vaší práce při pohovoru. Častým omylem je testování pouze „šťastné cesty" – tedy že vše funguje, když uživatel postupuje správně. Zkuste se zaměřit na okrajové případy, prázdná pole, nezvyklé vstupy nebo přerušení připojení.

V neposlední řadě si dejte pozor na přehnaný optimismus plynoucí z „známého prostředí". I když děláte podobný úkol jako minule, objeví se změny v knihovnách, v prostředí nebo v požadavcích. Vždy přidejte alespoň malou rezervu na neznámé. Když je úkol nový, klidně zdvojnásobte hrubý odhad – realita se tomu často blíží.

Proč méně end-to-end testů znamená víc jistoty Na vrcholu pyramidy jsou end-to-end testy, které projíždějí celou aplikaci jako uživatel. Tyto testy jsou pomalé, drahé na údržbu a náchylné na rozbití kvůli maličkostem (např. jiná barva tlačítka). Proto jich pište minimum – jen pro kritické cesty, jako je registrace, nákup nebo přihlášení. Před každým spuštěním se ujistěte, že testovací prostředí je stabilní a data jsou předvídatelná. Vyhněte se používání testovacích čísel karet nebo náhodných e-mailů, které vyžadují ruční zásah. Ideální je, když si testy generují vlastní data a po sobě uklízejí.

Dokumentace REST API často bývá tím posledním, na co vývojáři myslí. Přitom právě ona rozhoduje o tom, jak rychle frontend pochopí možnosti backendu a jak bez chyb je využije. Dobře vedená dokumentace není luxus, ale nástroj, který šetří hodiny práce oběma stranám. Než začnete psát, ujasněte si, kdo bude dokumentaci číst – frontend vývojář, který nezná interní strukturu vašeho systému. Pište tedy srozumitelně, strukturovaně a hlavně konkrétně.

Testovací pyramida není jen teoretický model, ale praktický nástroj, který vám pomůže udržet náklady na testování pod kontrolou. Základní myšlenka je jednoduchá: čím níže v pyramidě test stojí, tím by ho mělo být více, a naopak. Na dně jsou rychlé a levné jednotkové testy, uprostřed integrační testy a na vrcholu pomalé end-to-end testy. Když tohle rozdělení nedodržíte, skončíte s testy, které běží desítky minut, jsou křehké a při každé změně kódu vyžadují ruční opravy.

Základním stavebním kamenem je popis každého endpointu. Uveďte jeho HTTP metodu, cestu a účel – co dělá, jaká data přijímá a co vrací. Nezapomeňte na příklady požadavků a odpovědí, a to včetně hlaviček a stavových kódů. Často se stává, že dokumentace obsahuje jen příklady úspěšné odpovědi, ale chybí popis chybových stavů. Přidejte proto tabulku možných chyb – proč k nim dochází, jak vypadá tělo odpovědi a jak by na ně měl frontend reagovat. Typickou chybou je také opomenutí autentizace – popište, jak se token předává, kdy expiruje a co se stane při neplatném přístupu.

Dobrá dokumentace by měla obsahovat i ukázkové scénáře použití. Místo izolovaných příkladů ukažte, jak jednotlivé endpointy spolupracují při řešení typické úlohy – třeba jak načíst seznam položek, přidat novou, upravit ji a smazat. To pomáhá frontendu pochopit kontext a návaznosti. Nezapomeňte také na popis stránkování, filtrování a řazení, pokud je API podporuje – frontend pak nemusí vymýšlet vlastní řešení. V neposlední řadě myslete na to, že dokumentace by měla být snadno prohledávatelná. Používejte konzistentní názvy, členění do sekcí a klíčová slova. Vyhněte se zdlouhavým úvodům a marketingovým frázím – jde o technický manuál, ne o prodejní text.