Agilní vývoj
Také známo jako Agile, Agilní vývoj, Sprint
Stručně
Stavět po krátkých krocích, vydávat často něco použitelného a nechat plán opravit skutečnou zpětnou vazbou.
Agilní vývoj je způsob práce, kdy dvoutýdenní úsek končí něčím, co se dá ukázat, proklikat a posoudit, místo půlročního plánu, který buď vyjde, nebo je pozdě. Podstatné není obřadnost, ale to, že zpětná vazba od lidí, kteří produkt skutečně používají, ještě stihne změnit, co se staví dál.
Co dělá tým agilním
Fungující software na konci úseku, viditelný klientovi. Backlog, který tým poctivě řadí podle hodnoty. Krátká schůzka, kde se mluví o tom, co komu stojí v cestě, a ne že jezdí report. Retro, ze kterého vzejdou dvě změny, které někdo opravdu dodrží. Když chybí tyhle čtyři věci, dělá tým obřady, ne agile.
Druhá půlka je na straně klienta. Musí být k dispozici někdo s reálnou rozhodovací pravomocí — demo každé dva týdny, odpověď do dne na otázku, která blokuje práci. Agile bez rozhodujícího člověka je tým, který rychle dodává domněnky.
Poctivá poznámka: „agile“ je často jen nálepka
Můžete mít Ganttův diagram, denní statusy, fixní cenu za fixní rozsah i třicet stran dokumentace a říkat tomu agilní. Můžete mít patnáctiminutový stand-up, zatímco každý sprint je přecommitovaný a plán měnit nikdo nesmí. Obojí je vodopád s vyměněnou nálepkou a nálepka zlý způsob rychlejší neudělá.
Při náboru nebo nákupu se ptejte, co se změnilo po posledním retru a kdy naposledy demo vedlo ke zrušení funkce. Když odpověď není, je proces kostým. Cena kostýmu se platí dvakrát: za obřady a pak za zklamání, když se ve skutečnosti nic nepřizpůsobí.
Kde je vodopád správná odpověď
Některá práce musí být naplánovaná celá a předstírat opak je to drahé. Integrace platebního terminálu certifikovaná kartovou asociací, migrace, při které musí přežít každý řádek, regulovaný výkaz, kde pole určuje zákon, instalace v nemocničním prostředí — tam jsou požadavky dané a pečlivý plán je cennější než iterace.
Agile i tam pomáhá na okrajích: seřadit práci podle rizika, udělat jeden svislý řez od začátku do konce, než se začne zvětšovat, a každé dva týdny něco ukázat. Realistická pozice je „hlavně iterativně, plánovaně tam, kde se musí“ — ne náboženská volba mezi dvěma prapory.
Zdroje
Související pojmy
MVP (minimální životaschopný produkt)
Nejmenší verze produktu, která prokáže, že jádro nápadu funguje pro skutečné uživatele — ne rozbitý polotovar.
Akceptační kritéria
Testovatelné věty, které říkají, kdy je funkce hotová — rozdíl mezi spokojeným klientem a nekonečnou hádkou.
Code review
Druhý pár očí nad změnou, než se dostane do produkce — nachytá chyby, designové problémy i nepříjemná překvapení včas.