když poprvé začnu pracovat s agilním produktovým týmem, jednou z nejčastějších situací, kterou najdu, je situace, kdy týmy mají dlouhé a frustrující schůzky s plánováním sprintu, protože položky nevyřízených položek jsou špatně definovány a nejsou dobře pochopeny; mají pomalou rychlost a špatný design, protože detaily se během sprintu stále zpracovávají; a množství odpadu a přepracování je velmi vysoké, protože položky nevyřízených položek nebyly ověřeny.

pamatujte, že naším cílem vyššího řádu je ověřit naše nápady nejrychlejším a nejlevnějším možným způsobem. Ve skutečnosti budování a spuštění nápad produktu je obecně nejpomalejší, nejdražší způsob, jak ověřit myšlenku.

proto jsem velkým zastáncem toho, co se někdy označuje jako Dual-Track Agile (aka Dual Track Scrum, Fake It Before You Make It, Build Things That Don ‘t Scale / Build Things That Do Scale, Move Fast/Don’ t Break Things, Continuous Discovery / Continuous Delivery atd.).

dříve jsem to označoval jako pouhé objevové sprinty, ale to má důsledky časově ohraničeného objevu a také serializace fází. Jeff Patton se mnou poprvé sdílel termín “Dual-Track Scrum” a dávám přednost tomuto termínu, protože lépe zachycuje paralelní povahu objevu a doručení.

Discovery track je o rychlém generování ověřených položek nevyřízených produktů a Delivery track je o generování uvolnitelného softwaru.

dalším důvodem, proč se mi líbí Dual-Track agilní metafora je, že jsem si mnoho lidí v podstatě dělá malé mini-vodopády v rámci jejich Scrum. Produktový manažer dělá nějaké” požadavky ” práce, a to je předán návrháře, který dělá jeho návrhy a generuje jeho artefakty (obvykle komentované drátové modely), a pak to je předán doručovací tým stavět a testovat.

naproti tomu v Dual-Track Agile není pracovní tok charakterizován tím, že každá role přináší artefakty do dalšího kroku; spíše je to spolupráce-produktový manažer, designér a vedoucí inženýr spolupracují vedle sebe na vytváření a ověřování položek nevyřízených položek.

čtenáři těchto článků vědí, jak důležitý považuji design uživatelské zkušenosti, ale jednou z obtíží pro mnoho agilních týmů je to, že rytmus a tempo Agile může být u tradičních týmů UX velmi obtížné. Proto jsem fanouškem Lean UX. Lean UX a Dual-Track Agile jsou vyrobeny pro sebe. Spíše než se soustředit na artefakty, Zaměřujeme se na prototypy a ověřování těchto prototypů v Discovery, s další výhodou, že prototyp slouží jako specifikace pro dodání.

a co je nejdůležitější, na rozdíl od Vodopádového procesu, kde se validace provádí po vydání, v Dual-Track Agile ověřujeme během Discovery. V principu ověřování co nejrychleji a nejlevněji, většinu času můžeme ve skutečnosti provést naši validaci, než napíšeme jakýkoli výrobní kód, v duchu “fake it before we make it”.”

pokud je váš produktový tým frustrován množstvím odpadu a pomalým tempem při dosahování skutečných obchodních výsledků, zvažte vyzkoušení Dual-Track Agile. Zjistěte, zda to může inspirovat úroveň spolupráce, rychlá iterace a validace, která má za následek mnohem lepší práci.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.