Neplánuje se

V porovnání s vodopádovým modelem se lidé domnívají, že se v agilním vývoji nic neplánuje, protože se pořád něco mění a jakékoli plány nemají smysl.

Naopak, v agilním přístupu se plánuje dokonce více. Rozdíl je, že se neplánuje jen v jedné úvodní fázi, ale plánuje se průběžně, plány se často upravují podle aktuálních potřeb a změna se upřednostňuje před dodržením původního plánu.

Nepíše se žádná dokumentace

Pokud si pod dokumentací představíte obsáhlý dokument třeba ve wordu, kde je detailně popsána funkcionalita a technické řešení nějakého systému nebo aplikace, pak opravdu není moc vhodné takovou dokumentaci dělat. Důvodem jsou časté změny, které agilní vývoj podporuje. Taková dokumentace pak rychle zastarává, není v silách nikoho ji aktualizovat a původní náklady na její vytvoření jsou zbytečně vynaložené. Výjimkou je, pokud cílem požadavku je právě vytvoření obsáhlé dokumentace za nějakým účelem, který přináší zadavateli určitou hodnotu.

Není ale pravda, že se při agilním vývoji dokumentace nevytváří. Dokumentace se skládá hlavně z jednotlivých zadání ("user story") a z testovacích scénářů ("test case"). Na produkci se totiž nedostane nic, co nebylo zadáno a otestováno, takže veškeré informace můžete zpětně dohledat zde. Pokud potřebujete mít někde popsané návrhy řešení velkých systémů, pak je vhodné toto sepsat někam na wiki (pouze na high level úrovni) a z jednotlivých požadavků pro vývoj se odkazovat tam.

Obecně lze ale říct, že se při agilním vývoji dokumentuje méně. Jedním z důvodů je také to, že lidé mají snahu se za dokumentací "skrývat". Místo aby osobně prodiskutovali problém, tak ho radši písemně zdokumentují. A to zhoršuje celkovou komunikaci.

Netestuje se

V agilním vývoji, při rychlých iteracích není čas na testy, protože se neustále něco mění. Takto k tomu bohužel přistupuje hodně lidí.

V agilním vývoji se naopak klade velký důraz na kvalitu. Vývoj nikdy nesmí opustit cokoli, co není otestováno. Opakované testy se pokrývají automaty, menší dočasné testy se mohou dělat manuálně a QA je vždy součástí vývojového/produktového týmu.

Dokonce jeden z agilních přístupů je vyvíjet pomocí Test Driven Development (TDD), tzn. nejprve napsat test podle požadavku a pak teprve kód, který tímto testem projde. Tím se zajistí 100% pokrytí testy.

Nedělají se návrhy řešení(design)

Protože v agilním vývoji není žádná fáze analýzy, studie proveditelnosti apod. fáze, lidé se domnívají, že se v agilním vývoji žádné návrhy řešení nedělají.

Agilním vývoj možná využívá více návrhů řešení, než klasický přístup. Jen na to není vyčleněná některá fáze před vývojem, kde se vytvářejí velké designy systémů, které neplatí už pár minut po začátku vývoje. Design se řeší průběžně při vývoji a je založen spíše na refactoringu, kde vývojáři postupně zlepšují již navržené a naprogramované věci.

Nedostatek zkušeností

Hodně lidí si myslí, že si stačí o agilním vývoji něco přečíst, zajít na nějakou konferenci nebo školení, udělat si certifikát "Certified ScrumMaster" a že pak mají dostatek znalostí na to, aby ve firmě zavedli agilní vývoj. Po zavedení nových technik, jako jsou sprinty, stand-upy, retrospektivy apod. si naivně myslí, že fungují agilně. Bez pochopení agilních principů ale po nějaké době zjistí, že jim to moc nefunguje a mají tendenci se vracet zpět ke starému způsobu vývoje.

Mám rád jedno přirovnání: Když si nastuduji, jak udělat sushi, budu ho schopný připravit a možná mi dokonce bude chutnat. Jak ale mohu vědět, že je to opravdu dobré, správně udělané sushi, když jsem ho nikdy před tím nejedl?

Co s tím? Spolupracujte s člověkem, který má reálnou zkušenost s úspěšným fungováním agilního vývoje, který si to "zažil" a který vám tuto zkušenost dokáže předat.

Implementace pouze v rámci IT vývoje (R&D)

Bohužel velké množství společností se snaží aplikovat agilní vývoj pouze na Development a nezahrnou do potřebných změn své zadavatele, ať je to běžný uživatel, platící zákazník nebo Business. Pak ale naráží na to, že je omezuje okolí svým "jiným fungováním" a řeší problémy při styku "agilního světa" s "neagilním".

"Agilní vývoj" není jen o vývoji. Možná větší část potřebných změn ve firmách leží právě na zadavatelích, kteří musí fungovat také agilně. Jak se říká "rubbish in, rubbish out" neboli, když máte špatné zadání, nemůže z toho vzniknout nic kvalitního. I Business musí pochopit agilní principy a spolupracovat podle nich s produktovými týmy.

Produktové týmy nejsou "produktové"

Jste si jisti, že víte, co je Váš "produkt"? Často se stává, že agilní vývoj se aplikuje na týmy, které nemohou fungovat ani trochu nezávisle, protože to co vyvíjejí, není produkt, který by měl nějakou hodnou pro uživatele/zákazníka. Jakýkoli požadavek na takový tým pak s sebou nese dopad do jiných týmů a ani jednoduchá funkcionalita nemůže být plně vyvinuta jedním týmem.

Je potřeba si ujasnit co je Vaším produktem, jakou část můžete relativně nezávisle poskytovat uživatelům/zákazníkům a podle toho sestavte týmy tak, aby v nich byli lidé se všemi potřebnými znalostmi. Nestavte týmy podle znalostí a nezkoušejte následně na ně ohnout produkt, dělejte to opačně.

QA není součástí vývoje

Ve vodopádovém modelu je jasně oddělený vývoj od testů. Při přechodu na agilní vývoj, např. Scrum, pak ve firmě tento zvyk přetrvá (co taky se zavedeným QA týmem). Výstupem sprintů je tak neotestovaná změna nebo nová funkcionalita a přitom je tento požadavek prezentován jako dokončený (vždyť hlavní práci, tedy vývoj, jsme dokončili a už to stačí "jen" přetestovat). Víte, kolik věcí se vám vrací z testů zpět k vývojářům v různých fázích projektu?

Principem agilního vývoje je rychlá změna, rychlá zpětná vazba a rychlá reakce na zpětnou vazbu. Jednou z důležitých zpětných vazeb je i výstup z testů. Aby vývojář tento výstup dostal co nejdříve, je potřeba začlenit testy přímo do vývoje a sprintu. Výstupem ze sprintu nesmí být nic neotestovaného. Takže pokud si vývojáři nedokáží svůj výtvor správně otestovat, pak musí být QA součástí produktového týmu. Za kvalitu má být zodpovědný hlavně vývojář, tester pouze ověřuje, jestli developer neudělal někde chybu.

Nedostatek automatických testů

Automatizované testování je základem pro dosáhnutí požadované kvality produktu při krátkých cyklech vývoje. Kdykoli vývojář něco dodělá, je potřeba spustit test, na základě kterého co nejrychleji vývojář zjistí, zda neudělal někde chybu. I při implementaci malé změny je potřeba přetestovat celou aplikaci, protože i nepatrná změna může mít zásadní dopad do jiné části aplikace. Není v lidských silách, aby takto rychlá zpětná vazba pro vývojáře byla zajištěna manuálním testem.

Automat není potřeba psát na každou změnu (pokud tedy neděláte Test Driven Development), jestliže předpokládáme, že se nová věc bude ještě měnit. Novinky je možné dočasně testovat manuálně. V případě, že se změna stane standardní součástí aplikace, pak je potřeba ji pokrýt automatickým testem.

Tvorba automatických testů často padá na názoru, že je to zbytečně nákladná činnost. V dobře nastaveném agilním vývoji se ale dostanete k potřebě testovat každý den nebo i dokonce vícekrát za den. Při takto častém testování se investice určitě vyplatí a bez automatů nejste schopni správně testy jinak pokrýt.

Odhady pracnosti nezahrnují všechny činnosti

Často se stává, že při odhadech pracnosti jednotlivých požadavků týmy zapomínají začlenit do odhadu všechny činnosti, které na požadavku dělají. Nejčastěji to jsou testy. Možná kvůli tomu, že cíleně nebo podvědomě pořád oddělují vývoj a testy, viz odstavec výše. I malá změna může znamenat obsáhlé testy, takže pokud nedáte do odhadů pracnosti i náročnost testů, pak začne docházet k tomu, že např. nejste schopni dokončovat požadavky v rámci sprintů. Náklady na testy musí být součástí odhadů pracnosti a zadavatel musí znát celkovou náročnost na základě které se rozhoduje, jestli do implementace jít nebo ne.

Jedna z nejtěžších dovedností vývojáře je provést správný odhad pracnosti určitého požadavku. Většinou dochází k podhodnocení, což vede k nestíhání termínů, což zpětně vede k tomu, že všechny odhady se násobí "magickou" konstantou, aby se finální odhad přiblížil realitě, což ale také většinou moc nefunguje.

Jeden z důvodů proč je obtížné odhadnout správně čas potřebný k dodělání příslušného požadavku je ten, že vývojář dopředu neví, jakým způsobem tento vymezený čas stráví. Úkol, na který standardně vývojář potřebuje např. 8 hodin čistého času, mu zabere 2-3 dny, když je stále vyrušován jinými věcmi nebo dokonce déle, pokud dělá na více věcech najednou. Dalším z důvodu je, že dokud vývojář nezačne reálně na požadavku pracovat, tak neví, s čím se bude muset potýkat a je to stále jen nepřesný odhad na základě nějaké předešlé zkušenosti s jinými, i když podobnými, požadavky.

Klíčem k úspěchu jak dělat správné odhady, je dělat opravdu "odhad pracnosti". Pojďme si nejprve rozklíčovat tato slova pomocí Slovníku spisovného jazyka českého:

• Odhad = přibližné určení, stanovení něj. rozměru, počtu, hodnoty, ceny něčeho úsudkem, bez měření, počítání ap.
• Pracnost = množství práce potřebné k zhotovení výrobku n. vynaložené na výrobní postup.

Z toho vyplývá, že děláme pouze odhady, které nemohou být z podstaty věci přesné a takto s nimi dále musíme pracovat. Dále, že neodhadujeme časovou náročnost, ale množství práce, které musíme vynaložit.

K takovým odhadům se používají bodové hodnoty (např. Story points), které říkají pouze to, jak je určitý požadavek "složitý" v poměru k jinému již odhadnutému požadavku (jestli požadavek B je menší nebo větší než požadavek A a zhruba o kolik) viz Wiki - Planning poker.
Některé týmy používají tzv. T-shirt sizing, kde ohodnocují požadavky pomocí písmen S,M,L,XL. Já osobně tento způsob estimace nedoporučuji ze dvou důvodu. Za prvé nejste schopni tyto hodnoty sčítat a jednoduše říct, kolik požadavků se vejde do iterace. Za druhé není jasné jaký je poměr těchto hodnot mezi sebou (je XL 2x vetší než L nebo je jen o 50% větší?). Pokud použijeme číselné hodnoty, tyto problémy odpadají, protože každý umí sečíst a porovnat čísla mezi sebou.

Složitost problému není jen v tom, jestli mám vytvořit jedno pole na formuláři nebo udělat celou novou aplikaci. Složitost také ovlivňuje např. stav kódu formuláře, do kterého mám jedno pole přidat, jestli vše dokáže udělat vývojář sám nebo se musí zkoordinovat více lidí nebo jestli nám tato malá úprava nenaruší některé věci okolo, které se musí také upravit.

Na odhady pracnosti mají vliv 3 věci: riziko, komplexnost a úsilí. Součtem těchto hodnot dostaneme celkovou pracnost/složitost problému.

• Riziko - může vzniknout na základě špatného a nečitelného kódu, nejasných závislostí, neznalosti problému, potřebě použít novou technologii apod.
• Komplexnost - zdrojem může být složitost algoritmu, struktury dat apod. viz Wiki - Complexity.
• Úsilí - jaké úsilí musíme vyvinout, abychom něco dokončili. Kolik kroků musíme udělat, kolik různých věcí musíme změnit, jaké jsou interní procesy (např. potřeba schvalovaní kritických věcí), s kolika lidmi je potřeba spolupracovat apod.

Použití této metody nevede k přesným odhadům jednotlivých požadavků, ale ke správnému rozdělení požadavků mezi sebou. Pak nevadí, když tým podhodnocuje své odhady o X procent, protože takto podhodnocené jsou v průměru všechny požadavky. A jak je možné, že to nevadí? Důvodem je měření a používaní Velocity týmu.

Velocity týmu je hodnota, která udává kolik bodů je tým schopen dokončit v průběhu jedné iterace (např. sprintu). A ačkoliv např. v každé iteraci jsou jednotliví vývojáři jinak vyrušováni, množství takto stráveného času má tendenci být konstantní v porovnání s ostatními iteracemi. Takže velocity se pouze sníží, ale je dále také konstantní. Díky velocity pak má tým a jeho okolí jasnou zpětnou vazbu o tom, kolik se toho dokončilo v minulých iteracích a kolik se toho dokončí s největší pravděpodobností v iteraci následující.

Toto nám dává jednoduchý, ale sofistikovaný nástroj. Pokud tým požadavky podhodnocuje, vede to k tomu, že v průběhu iterace nestihne vše, co si naplánoval. To způsobí, že se velocity sníží a do další iterace se podle této velocity naplánuje méně požadavků, které už tým stihne dokončit. Naopak pokud tým požadavky nadhodnocuje, v průběhu iterace stihne více věcí, než si původně naplánoval, což velocity zvýší. Postupně se tak velocity ustálí na reálné kapacitě týmu.

Velocity je založena na striktních pravidlech. Nikdy do velocity nezapočítávejte hodnoty nedokončených požadavků. Nikdy nedovolte, aby se konec iterace posouval i jen třeba o pár hodin. Tyto věci princip zpětné vazby založený na velocity narušují a dostanete se do stavu, kdy nejste schopni velocity správně vyhodnocovat, plánovat a dokončovat další požadavky. Velocity má tendenci být na začátku projektu nebo při vytvoření nového týmu nestabilní. Počkejte 2-3 iterace v průběhu kterých se velocity stabilizuje. Po tomto čase byste měli být schopni dosahovat stejné velocity ve všech dalších iteracích.

Nejprve bych rozdělil chyby do dvou množin.

První množina jsou chyby, které vznikly a našly se v průběhu sprintu nebo těsně po něm, ale ještě se nedostaly na produkční prostředí a neovlivňují uživatele. Tyto chyby nijak neodhadujte, jednoduše je opravte v aktuálním sprintu. Znalost vyvíjené funkcionality je čerstvá a cena potřebné opravy bude nízká. Může to sice trochu ovlivnit velocity týmu, ale na druhou stranu máte velocity, která odpovídá dodávání "bezchybného" kódu. Základním pravidlem v tomto případě je, že chybný kód nebo neotestovaný požadavek se nesmí dostat ze sprintu.

Druhá množina jsou chyby, které jsou již na produkci a které tam ani nemusel zanést aktuální tým. Některé společnosti tento typ bugfixingu řeší pomocí dalšího nezávislého týmu, který opravuje pouze chyby a který funguje pomocí Kanbanu. Tento způsob má ale svá úskalí:

• Nemusí být efektivní, aby chybu opravoval jiný člověk/tým než ten, který příslušnou funkcionalitu vyvinul a má tedy nejlepší znalost problému.
• Nemusí být lehké najít vývojáře, který by chtěl dělat pouze bugfixing.
• Je finančně a kapacitně náročné mít dva nezávislé týmy pro jeden produkt a z toho jeden, který nevyvíjí nic nového.

Co tedy dělat v případě, že máme jeden tým, který se kompletně stará o produkt?

K chybě v backlogu se chovejte stejně jako k novému požadavku. Dělejte odhad pracnosti a prioritizaci. Product manager má pak možnost upřednostnit opravu chyby oproti nějaké nové funkcionalitě nebo naopak říct, že nový požadavek je důležitější než oprava méně závažné chyby.

Jak ale odhadnout náročnost opravy chyby, když pro správný odhad pracnosti potřebujeme vědět původ chyby, což ale může znamenat vynaložení většiny potřebného úsilí k opravě chyby?

Zkuste chyby odhadnout podobným způsobem jako ostatní požadavky pomocí parametrů riziko, komplexnost a úsilí viz Odhady pracnosti. Možná se budete divit, kolik chyb takto nakonec zvládnete odhadnout.

U chyb, které opravdu nedokážete odhadnout nebo analýza potřebná k odhadu pracnosti by de facto chybu opravila, zkuste alespoň snížit míru nejistoty např. takto: pokud používáte Story pointy (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40), kde hodnota 40 je nejvyšší hodnota kterou přidělujete novým požadavků, přidělte chybám hodnoty 13 nebo 20. Tím pokryjete riziko, že neznámý bug může být složitý.

Pokud je odhad pracnosti opravy chyby velký a nejste si jisti, zda se vám vejde do sprintu, pak je možné opravu rozdělit na 2 úkoly - zjištění důvodu chyby a samotnou opravu chyby. Samotný úkol zjištění důvodu chyby může mít vlastní akceptační kriteria a výstup se dá prezentovat (Customer demo).

Příklad:

Zákazník je velká firma, která nemá žádný nástroj pro týmovou spolupráci, soubory (včetně velkých specifikací) interně sdílí pomocí adresářové struktury na sdíleném disku, nemá nástroj pro management požadavků a používá specializovaný nástroj na správu chyb (např. ALM). Nástroje jsou přístupné pouze z interní sítě nebo přes VPN.
Dodavatel používá úplně jiný systém pro správu požadavků, týmovou spolupráci a management chyb (např. TFS - Team Foundation Server). Tento systém si ale maximálně chrání, protože tam má veškeré své know-how a neumožní zákazníkovi jakýkoli přistup.

Takže existují dva úplně odlišné světy, které technicky spolu nekomunikují. Aby byla možná alespoň nějaká výměna informací, komunikace se nastaví např. následovně:

• Týmová spolupráce - běžné krátké informace nebo malé soubory se posílají přes maily. Výsledkem je kupa mailů s různým obsahem, s různou verzí příloh a informací. Při diskuzích se pak lidé odvolávají na nějaký zaslaný mail, který byl ale mezitím již několikrát aktualizován. Navíc v průběhu mailové komunikace se různě mění adresáti, takže není jistota, že všichni mají tutéž informaci.
• Sdílení souborů - větší soubory se se posílají přes FTP a ještě zašifrovaně kvůli bezpečnosti. Tím se dost zesložiťuje práce a ne všichni chtějí s takovými dokumenty pracovat. Proto se zvolí člověk, který sleduje, jestli přes FTP nepřišlo něco nové, tyto soubory rozšifruje a nakopíruje na interní úložiště.
• Management požadavků - zákazník určitým způsobem (většinou formou specifikace) dodá zadání dodavateli. Dodavatel zadání rozpadne na menší kousky podle potřeb svého týmu a ty eviduje ve svém systému. Za nějakou dobu (iterace) pak dodavatel dodá vše co pochopil ze zadání. V průběhu iterace se aktuální stav požadavků nikde nesdílí. Zákazník zjišťuje reálný obsah a stav dodávek až při předání.
• Management chyb - obě strany si evidují chyby ve vlastních systémech, které nejsou nijak propojené. Proto je nutné tyto systémy synchronizovat manuálně. K tomu je na každé straně určen člověk, který zpracovává různé notifikace, svůj systém aktualizuje a čas od času pošle souhrnný report pro kontrolu, že obě strany mají sjednocený aktuální stav.

Tento styl je běžný pro vodopádový model vývoje, kdy stačilo si nesdílet různé informace pouze v určitých fázích projektu a mezi těmito fázemi se víceméně nekomunikovalo. K přímému, rychlému a jednoduchému sdílení informací to má daleko.

Pozn. Proč je VPN problém?
Mohlo by se zdát, že připojení do interní sítě přes VPN, je elegantní řešení bezpečnosti. Kdokoli se zvenku připojí a může využívat všechny nástroje jako by byl v kanceláři na interní síti. Problém je ale v tom, když např. vývojář od externího dodavatele už VPN používá k připojení do své vlastní sítě. A protože nemůže být najednou připojen do dvou sítí, pak si musí vybrat. Nemůže např. programovat a zároveň číst zadání. Což opět zásadně omezuje a znesnadňuje komunikaci.

Jak toto ale změnit, když chcete fungovat agilně a komunikace na denní bázi je zásadní?

Obecné řešení:

• Používejte nové platformy k tomu určené. Zabezpečte si ji proti okolnímu světu, ale co nejvíce usnadněte použití lidmi na projektu. Ano, budete bohužel muset občas obejít různá interní nařízení, ale ty tu většinou jsou spíše z historických důvodu než proto, aby něco opravdu řešili natož, aby Vám usnadnili práci.
• Dohodněte se s dodavatelem na použití konkrétních nástrojů, které budou jednoduše přístupné a použitelné pro všechny členy týmu. Využívejte "cloudové" služby. I sebelepší systémy, které jsou v interní síti, jsou složitě přístupné z okolního světa a tím pádem i problematicky použitelné druhou stranou (zákazník/dodavatel).
• Eliminujte mailovou komunikaci pomocí různých kolaboračních platforem, které slouží pro efektivní týmovou spolupráci.
• Vyhněte se zasílání dokumentů mailem, nasdílejte příslušný dokument online. Elegantně tím vyřešíte verzování, rychlou editaci více lidmi najednou. Stačí pak znát odkaz na příslušný dokument a všichni mají přístupnou poslední verzi.
• Požadavky a evidenci chyb řešte v jednom, tomu určeném, nástroji, který je přístupný všem online. Všichni členové týmu budou mít lepší přehled o aktuálním stavu projektu a stávajících/budoucích požadavcích. Je dobré mít pouze jeden systém na požadavky i evidenci chyb. Pak lze prioritizovat oboje najednou a dodavatel přesně ví, kdy co má dodat, zda upřednostňujete opravu chyb proti dodání nové funkčnosti nebo naopak.
• Vyhněte se manuálnímu kopírování čehokoli kamkoli.

Konkrétní řešení:

• Confluence - kolaborační platforma, která zásadně zlepší komunikaci a spolupráci uvnitř týmu. Lze tu online sdílet různé informace, ukládat zápisy ze schůzek, zadávat úkoly a sledovat jejich plnění. Výborně se také hodí na komunikaci kolem požadavků, tvorby design apod. Mnoho diskuzí lze vést v tomto nástroji a tedy ne přes mail.
• JIRA / ALM - systém pro správu požadavků a chyb. Požadavky lze jednoduše zadávat, spravovat, kategorizovat a prioritizovat. Pokud nelze sloučit správu nových požadavků (JIRA) a správu chyb (ALM), pak je potřeba tyto dva systémy propojit a automaticky synchronizovat (existují k tomu různé nástroje).
• Google Drive - jednoduchá platforma pro sdílení dokumentů. Jednoduše nasdílíte složky nebo soubory, online vidíte provedené změny, všechny soubory se verzují, změny lze doplnit komentáři.