Agilita není nekonečný seznam meetingů
Slovo „agilní“ dnes používá téměř každý technologický tým.
Denní stand-up. Sprint planning. Retrospektiva. Backlog. Story points.
Jenže samotné procesy ještě neznamenají rychlý vývoj.
Pokud projekt nemá jasnou prioritu, rozhodování trvá týdny a během každého sprintu se mění zadání, můžete mít všechny agilní ceremonie světa a produkt stejně nevydáte.
Agilní vývoj pro nás znamená především jednu věc: rychle dostat správný produkt k reálným uživatelům.
MVP není osekaný produkt
Minimum Viable Product bývá často zaměňováno za nejlevnější možnou verzi aplikace.
To je špatně.
MVP musí být dostatečně kvalitní na to, aby vyřešilo hlavní problém uživatele. Jen neřeší všechno najednou.
Místo vývoje dvaceti funkcí proto hledáme několik klíčových, bez kterých produkt nedává smysl.
Všechno ostatní může přijít později.
První fáze: problém a scope
Než vznikne první řádek produkčního kódu, potřebujeme pochopit, co vlastně stavíme.
Jaký problém produkt řeší? Kdo ho bude používat? Jak vypadá hlavní uživatelský scénář? Které funkce jsou skutečně nutné pro první verzi?
Právě tady se často rozhoduje o tom, jestli projekt skončí za několik měsíců, nebo se potáhne rok.
Dobře definovaný scope odstraní obrovské množství práce ještě předtím, než vůbec začne.
Druhá fáze: design a technický základ
Po definici scope vznikne uživatelský flow, wireframy a následně samotné rozhraní.
Současně řešíme technickou architekturu produktu.
Nejde o to připravit systém na hypotetických sto milionů uživatelů. Potřebujeme vytvořit dostatečně robustní základ, který zvládne současné požadavky a zároveň nás nezamkne do slepé uličky.
Design a development proto neběží jako dva oddělené světy. Probíhají společně.
Třetí fáze: krátké vývojové cykly
Produkt stavíme po funkčních částech.
Každý cyklus musí skončit něčím, co lze reálně ukázat a otestovat.
Klient tak nečeká několik měsíců na první funkční verzi. Produkt vidí průběžně a může reagovat ve chvíli, kdy je změna ještě levná.
To zároveň výrazně snižuje riziko situace, kdy tým tři měsíce vyvíjí něco, co si zadavatel představoval úplně jinak.
Transparentnost je rychlejší než mikromanagement
Rychlé projekty nevznikají tím, že každý den kontrolujete vývojáře.
Vznikají tím, že celý tým ví, co je priorita, kdo za co odpovídá a co aktuálně blokuje další postup.
Proto preferujeme jednoduchý systém:
jasný backlog → jasná priorita → krátký cyklus → demo → feedback → další iterace.
Bez desítek statusů a několika vrstev schvalování.
Tři měsíce nejsou magické číslo
Ne každý produkt lze postavit za tři měsíce.
Pokud ale první verze jednoduchého digitálního produktu vyžaduje rok vývoje, velmi často není problém v programování.
Problém bývá v rozsahu.
Cílem MVP není vytvořit finální produkt. Cílem je co nejrychleji ověřit, že základní myšlenka funguje.
Proto je někdy nejlepší funkcí ta, kterou se rozhodnete vůbec nevyvíjet.
