Problémy s adopcí agilních přístupů – část 3

předchozím příspěvku jsme diskutovali jako první krok nutnost zahrnout tým vývoje do změny způsobu práce (do implementace Agile) a také se shodnout na tom, proč vůbec změnu chceme nebo potřebujeme. V tomto příspěvku probereme další vhodné kroky, kterými jsou:

  1. Vytvoření akceptačních kritérií a definice stavu hotovo
  2. Řízená a vědomá rizika a zaměření se na architekturu

Definovat akceptační kritéria a hlavně DoD

Akceptační kritéria a definice stavu hotovo (DoD) jsou klíčem k tomu, jak dosáhnout úspěšné dokončování a doručení toho, k čemu jsme se zavázali. Chybějící akceptační kritéria vedou většinou k:

  • nekonečným akceptacím a dohadům se zákazníkem, jestli je dokončená a demonstrovaná funkčnost opravdu to, co zákazník chtěl,
  • osobním interpretacím a vymýšlení nových drobností a funkčností programátory, což způsobuje tzv. gold plating – neustálé vylepšování již doručitelné funkčnosti, což stojí firmu čas i peníze.

Proto je vhodné mít součástí user stories či use case i akceptační kritéria ve formě popisu akcí, vstupů a výstupů funkčnosti, ale i kreslených/modelovaných vizuálních storyboards (budoucích obrazovek).

Chybějící DoD, jenž jsou interní týmovou dohodou, zase způsobují:

  • rozdílnou kvalitu od každého vývojáře (jiné konvence a komentáře kódu, jiná nebo žádná forma dokumentace, rozdílný druh a forma testů),
  • syndrom „90% hotovo“ – však to znáte, za chvíli už to budu mít, 2 dny uplynou a pořád nic…

Chybějící akceptační kritéria a DoD způsobují nejasnosti na obou stranách a jejich důsledkem je také to, že si vývojáři pořád berou do iterací/sprintů více práce a nedokončené věci neustále přesunují do dalších, případně mají problém vůbec něco hotového doručit…

Přečtěte si více o tom, jak na konstrukci akceptačních kritérií a DoD. Existuje také množství kvalitních zahraničních blogů na téma akceptační kritéria a Definition of Done.

Neopomenout rizika a architekturu!

Jelikož je Scrum pouze metoda řízení a neobsahuje inženýrské praktiky (tj. jak se jako vývojář mám dostat od požadavku ke kódu), je častou chybou začínajících týmů chaos ve vývoji a opomenutí technických, resp. architektonických prací. Takové opomenutí může brzy způsobit technický dluh, který se projeví vyšší chybovostí, zhoršující se výkonností, špatnou údržbou a čitelností kódu aplikace.

Smyslem Scrum je implementovat jednoduchý motor, který umožňuje doručovat co nejrychleji něco, co funguje a lze předvést zástupci zákazníka či přímo zákazníkovi. Ale právě proto, že je tak jednoduchý na implementaci, může způsobit problémy minimálně u programátorsky méně zkušených či méně disciplinovaných týmů. Scrum prostě neříká JAK se dostaneme od vágních požadavků ke kódu, tj.:

  • Jak identifikujeme objekty, které potřebujeme? Jak předejít duplikacím?
  • Jak detailně a jakou formou provádíme návrh? Kdo schvaluje návrhová rozhodnutí? Píší se někam, ať příště víme?
  • Jak toto vše dokumentujeme? Kam to ukládáme?
  • Co konvence zápisu kódu (jak, co a kam píšeme)?
  • Děláme revize kódu? Kdy? S kým?
  • Do jakých vrstev je třeba zasahovat…?
  • Děláme testy? Jaké?
  • Jaké prostředí používáme a jak se nastavuje? Kdo je spravuje?
  • Apod.

Stejně důležitá jako architektura jsou i možná rizika. Riziky řízený přístup říká, že identifikujeme možná rizika a definujeme akce na jejich snížení, které se stanou úkoly pro jednotlivé členy týmu v následujících iteracích. Přečtěte si jak na to.

Proto je vhodné nezapomínat zařadit do iterace/sprintu i architektonické úkoly a akce na snížení či odstranění aktuálně identifikovaných rizik.

O tom, že vyvíjet Agilně jde již s touto základní výbavou (iterativní framework jako například Scrum, akceptační kritéria, zaměření se na rizika a architekturu), svědčí praktické ověření se studenty, kteří během dvou semestrů dokáží pomocí tohoto přístupu doručit webové aplikace na komerční úrovni používané v praxi.

Posledním ale neméně důležitým krokem je pravidelně provádět retrospektivu, která umožní kousek po kousku upravit a dál podle potřeb měnit zavedený způsob práce. Ale o tom až v dalším dílu.

Příspěvek byl publikován v rubrice Články se štítky , , , , , , . Můžete si uložit jeho odkaz mezi své oblíbené záložky.

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *