Agilní metody řízení projektů

Knihu jsem si vybral, jelikož jsem mnohokrát slyšel o agilním managementu jako atraktivní alternativě ke klasickému waterfallovému stylu řízení a o této metodice jsem nic moc nevěděl. Některé metody popsané v této knize by bylo vhodné aplikovat na naše prostředí a do našich projektů, proto kromě teorie popsané v knize popisuji v této eseji i způsoby, jak bychom tyto metody mohli aplikovat. 

Agilní management je dynamický rychlý, interaktivní, přizpůsobivý, iterativní, zábavný, hravý, rychle reagující na změnu.  

Základní kámen agile managementu je manifest: 

• Jednotlivci a interakce před procesy a nástroji 
• Fungující software před vyčerpávající dokumentací 
• Spolupráce se zákazníkem před vyjednáváním o smlouvě 
• Reagování na změny před dodržováním plánu 

Tyto hodnoty byly vytvořeny za účelem využití agile managementu při vývoji softwaru, ale lze aplikovat i u jiných typů projektu.

Co je to “Lean”? 

Jde o proces převzatý z tovární výroby. Jejich nejznámějším uživatelem je Toyota. Jde o “zeštíhlování” procesu, dělání věcí jen když jsou potřeba.

Lean Software Development funguje na následujících principech: 

• Odstraňte vše, co nepřináší hodnotu 
• Zlepšujte se a učte se již v průběhu práce 
• Rozhodujte se co nejpozději 
• Dodávejte práci, jak nejrychleji to jde 
• Dejte týmu důvěru a zodpovědnost 
• Zaměřte se na celkový výsledek 

Jaké jsou nejčastější důvody pro přechod na agilní metody? 

• Flexibilita – V případě že zákazník chce výsledky okamžitě, je možné že s waterfallovým stylem managementu nebudete stíhat splnit požadavky zákazníka. V tento moment je vhodné přejít na agile. 
• Efektivita – Je prokázané, že spolupráce je efektivnější než práce jednotlivce. Chvíli trvá, než si tým na sebe zvykne, ale funguje to skvěle. 
• Předvídatelnost - Agile rozděluje projekty na kratší úseky. Na jejich začátku celý tým společně plánuje a na konci společně reflektuje. To časem docílí toho, že se přesnost odhadů zlepší. 
• Kvalita – Na začátku zapojíme do vývoje zákazníka. Ten nám vysvětlí, jak a proč bude produkt používat. Po malých kouscích zákazníkovi ukazujeme výsledky a on na jejich základě dokáže své požadavky upravovat. Výsledkem je, že zákazník vám produkt nevrátí jako nepoužitelný a nebude trvat na jeho přepracování. 
• Zábava - Členové týmu budou vědět proč a na čem pracují, budou chápat smysl produktu a rozumět zákazníkovi. 

Role 

Scrum Master 

Mezičlánek mezi týmem a jakýmkoliv rušivým elementem zvenku. Jeho cílem je vytvořit samostatný, efektivní a spokojený self-organized tým. 

• Pomáhá týmu dosáhnout jeho cílů 
• Odstraňuje problémy 
• Motivuje tým k lepším výsledkům 
• Chrání tým před vnějšími vlivy, které by ho mohly odvádět od soustředěné práci na definovaném cíli

Měl by upřednostňovat koučovací principy, podporovat tým a jednotlivce v jejich rozvoji, být komunikativní, vnímavý a utlumovat případné konflikty v rámci týmu. Neměl by být direktivní. 

Product Owner 

Vlastník produktu, definuje priority, má na starosti Business Value a ROI produktu. Je zodpovědný za Product Backlog. S tím mu pomáhá tým lidí, který obvykle obsahuje zástupce zákazníka, uživatelů, software architekta, User Experience, jiné Product Ownery.

Product Owner tráví čas spíše se zákazníky, jeho úkolem je porozumění produktu. To pak komunikuje s týmem, managementem a zákazníky tak, aby všichni věděli, kam jdeme, proč a jak. 

Self-organized tým 

Agilní týmy často spoléhají na své jednotlivé členy a nastavují adaptivní proces, který jeho členové mohou ovlivnit a změnit. Nutnou podmínkou je mít společný cíl. Týmu je umožněno podílet se na Product Backlogu a přispět tak tomu, že jim práce bude vyhovovat a zákazník dostane to nejlepší možné.

Scrum tým 

Správný Scrum tým je nejen self-organized, ale i multifunkční a vzájemně zastupitelný. Tým se sám rozhodne, kdo na čem bude pracovat, kdo komu pomůže a kterou znalost by si měl začít pozvolna budovat, aby byl jako celek co nejefektivnější. Týmy si často ze zvyku v rámci Sprintu nastaví malý Waterfall, kdy začínají analýzou. Když je analýza hotová, vývojáři to nakódují a následně testeři otestují. Testeři ze začátku nemají moc práce, vývojáři jsou přetížení. Tomu lze odpomoct tím, že budou spolupracovat nad rámec svých klasických rolí.

Správný Scrum tým pracuje již od začátku společně na User Story. Analytik se zamýšlí, jak to bude fungovat, a odpovídá na otázky vývojáře, jak se daná funkcionalita bude chovat. Ve trojci je s nimi ještě tester, který se na User Story dívá z pohledu toho, jak by se daná funkcionalita mohla rozbít a rovnou identifikuje případné chyby. 

Zákazník 

Se zákazníkem chcete být partnery. Znát sebe, své schopnosti a možnosti; znát zákazníka, rozumět jeho potřebám a businessu. Zákazník se v Agilu podílí na projektu, funkcionalitě produktu, určuje priority. Základem je transparentně komunikovat o úspěchu i problémech, respektovat zákazníka a snažit se splnit více než to, co chce - dát mu to, co opravdu potřebuje. Zákazník v těchto modelech často podepisuje jen rámcovou smlouvu a detaily se ladí až za průběhu.

Role projektového manažera 

Stará se o to, aby byl projekt správně reportovaný ve všech systémech firmy, stará se o rozpočet a timesheet. 

Sprint 

Opakující věci jsou pro lidi příjemné a snadno si na ně zvyknou. Vzhledem k pravidelnosti cyklů jsou výsledky prezentované pokaždé včas a díky plánování dostaneme vždy to, co jsme čekali. Délka by měla být vždy taková, abychom stihli funkcionalitu vypracovat, prezentovat zákazníkovi a na jeho konci udělat tzv. Sprint review. Délka by měla zároveň reflektovat dynamiku a celkovou délku projektu. 

• Nevíte-li jak dlouhý sprint nastavit, začněte dvěma týdny. 
• Máte-li pocit, že za Sprint nestihnete nic dokončit, zamyslete se, proč to tak je. Možná se snažíte splnit příliš mnoho funkcionality najednou, nebo se dá něco vylepšit na spolupráci v týmu. 
• Délku Sprintu v průběhu neměníte, podle reflexe pouze upravíte délku toho následujícího. 
• Nikdo, ani Product Owner, nemá právo měnit obsah Sprintu v jeho průběhu.

Product Backlog 

Má ho na starost Product Owner, měl by být ale přístupný všem. Jednotlivé položky Product Backlogu odpovídají jednotlivým funkcionalitám produktu, tedy něčemu, co přináší zákazníkovi hodnotu.

Jedna z metod, jak zaznamenávat funkcionality je pomocí tzv. User Story. Jde vždy o nezávislé celky, které by měly dát zákazníkovi hodnotu a je možno je zákazníkovi prezentovat a získat zpětnou vazbu. Funkcionalita je vždy popsána z pohledu zákazníka.

Správný Product Backlog obsahuje nejen popis User Story, ale i odhad komplexity/náročnosti v relativních jednotkách ohodnocený týmem o prioritu. Je seřazený podle priority do pyramidy. 

Product Backlog může obsahovat třeba tyto položky: 

• ID 
• Epic 
• Super User Story 
• User Story 
• AK (akceptační kritéria) 
• Review Comments (kde obvykle tým zadá informace o review) 
• Test (kde tým zadává informaci o testování, které testy prošly a kdo je pouštěl) 
• Attachment (např. obrázek, jak to má vypadat) 
• Comments (pro cokoli, co si potřebujete poznamenat) 
• Estimates 
• Priority

Reference pro větší celky je obecně doporučované udržovat ve třech úrovních (Epic, Super User Story, User Story). Backlog je dobré mít někde uložený (např. MS Excel). 

Sprint Backlog 

Součást Product Backlogu, obsahuje prioritní funkcionality, které se tým zavázal dodat v rámci Sprintu. 

User Story 

Základní formát je: “Jako Uživatel chci Funkcionalitu, abych dostal Business Value.” 

User Story by měla být jednoznačně popsatelná, vytvářet obrázek, nezávislá, přinášet hodnotu, testovatelná, a také malá (zkráceně “INVEST”). Je vždy zaměřená na obchodní hodnotu a popisuje přínos, který od ní očekáváme.

Příklady pro online půjčovnu domácích zvířat: 

• Jako rodič si chci půjčit zvíře, aby moje děti věděly, jaké to je se o nějaká zvíře starat. 
• Jako příbuzný chci mít možnost koupit upomínkový předmět s fotkou půjčeného zvířete, abych měl pro děti dárek. 
• Jako dítě si chci vybrat z obrázků, které zvíře si půjčíme, aby se mi líbilo.

INVEST Kritéria 

• I – Independent 

User Story musí být na sobě nezávislé. Stejně jako když děláte carpaccio ze slona. Plátek po plátku definujeme jednotlivé funkční řezy. Jdete po funkcionalitě, ne po technologii. Je podstatná hlavně diskuze mezi Product Ownerem a týmem.

• N – Negotiable 

Popsatelný, vysvětlitelný. Product Owner musí být schopen User Story vysvětlit týmu tak, aby jí rozuměl a byl ji schopen ohodnotit.

• V – Valuable 

Musí mít hodnotu. Myslí se tím striktně hodnota pro uživatele.

• E – Estimable 

Ohodnotitelný. User Stories hodnotí tým. Aby danou funkcionalitu byl schopen ohodnotit, musí jí rozumět, protože odhad je jen vedlejším produktem kvalitní diskuze o funkcionalitě.

• S – Small 

Malá. Tým musí být schopen User Story dokončit nejdéle za polovinu jednoho Sprintu. Jinak se potřeba ji rozdělit.

• T – Testable 

Otestovatelná. Je to také schopnost odpovědět si na otázku “Jak se pozná, že je User Story hotová”, tedy jestli máme dostatečně nadefinovaná akceptační kritéria a User Story rozumíme. 

Epic a Super User Story 

Poté, co se pokusíte User Story definovat, často zjistíte, že potřebujete ještě něco, co je širší, co vám udržuje globální kontext a drží jednotlivé User Stories pohromadě. Když začínáte definovat Product Backlog, je vhodnější začít u velkých celků. Takový funkční blok se nazívá Epic. User Stories, které ještě zcela nesplňují metodiku INVEST, se nazívají Super User Stories. Tedy User Stories musí být INVEST a cokoliv většího nebo špatně definovatelného je Super User Story nebo Epic. 

Akceptační kritéria 

Seznam podmínek, které musí být splněné, aby mohla být User Story akceptovaná jako dokončená. Na akceptačních kritériích se domlouvá tým s Product Ownerem nejpozději při plánování Sprintu. 

Ohodnocení 

Agilní metody používají na ohodnocení User Stories obvykle relativní jednotky. Ohodnocuje vždy celý tým. Ohodnocujeme náročnost, komplexitu, není to o čase. Zohledňujeme i míru rizika. Na začátku si zvolíte nějakou referenční hodnotu a k ní pak ohodnocujete další User Stories. Každé další hodnocení pak je relativní vůči ostatním - již ohodnoceným- funkcionalitám. 

Rychlost 

Po skončení každého Sprintu tým sečte ohodnocení dokončených User Stories. Výsledek je jejich rychlost. Nedokončené User Stories v jakémkoliv stadiu rozpracování jdou zpět do Product Backlogu, a do rychlosti se tedy nepočítají. Dobře fungující týmy mají obvykle rychlost stabilní/předvídatelnou. 

Meetingy

Scrum Meeting 

Jednou z nejznámějších praktik, které se v agilních metodikách používají, je Scrum Meeting. Tým se sejde pravidelně každý den a sdílí informace o tom, na čem pracovali včera, na čem budou pracovat dnes a jestli mají se svým úkolem nějaké problémy, o kterých by tým měl vědět. Scrum Master je pouze v pozici moderátora. 

Odpovídá se na následující otázky: 

• Co jsem dokončil včera 
• Co dokončím dnes 
• Problémy 

Je důležité omezit detailní diskuse o konkrétních problémech nebo technických řešení. Ty se přesouvají do dalších meetingů. 

Retrospektiva 

Má obvykle několik fází: 

• Úvod - Připomeneme si pravidla retrospektivy a projdeme společně seznam akcí z minulého retra a potvrdíme si aktuální program.

• Sběr dat - Snažíme se posbírat co nejvíce informací o současném stavu: co funguje a co by šlo naopak zlepšit.

• Hlubší porozumění informacím - Snažíme se identifikovat příčiny a pochopit podstatu identifikovaného problému či najít prostor pro zlepšení. 

• Brainstorming možností - Je základním stavebním kamenem retrospektivy. Bez konkrétních akcí, kterými můžeme danou oblast adresovat, se problémy budou pořád opakovat a tým po čase ztratí zájem o nich mluvit. Zbude jen pachuť, nízká motivace a slova “vždyť s tím stejně nic nenaděláme, tak proč se vůbec scházet”.

• Shrnutí konkrétních akcí - Závěr retrospektivy je klíčový, shrneme v něm konkrétní kroky pro změnu či zlepšení, ujednání, dohody. Bez konkrétních akcí na další Sprint odsouhlasených celým týmem se retrospektiva stane jen povídáním bez možnosti cokoliv ovlivnit, a ztratí svou důležitost a smysl. 

Priority a Pre-planning 

Za prioritizaci je zodpovědný Product Owner. Měl by ve vlastním zájmu rozhodnout, kterou funkcionalitu upřednostnit, protože on je zodpovědný za výslednou úspěšnost produktu. Priority se určují na základě požadavků zákazníka. 

Plánování 

Když máme od Product Ownera priority na následující Sprint, můžeme začít plánovat. Plánuje celý tým. Planning začíná tím, že Product Owner představí jednotlivé User Stories. Tým potom vybírá, které zvládne za tento Sprint dokončit, a dává je do Sprint Backlogu. Scrum Master meeting moderuje tak, aby si tým uvědomil, kolik User Stories se již tým zavázal dokončit. Pomáhá týmu si ujasnit akceptační kritéria s Product Ownerem se stará o to, že závazek je reálně dokončitelný, ale zároveň motivující. 

Je dobré sečíst body vybraných User Stories a porovnat součet s rychlostí, které tým dosahoval za předchozí Sprinty. 

Sprint Review 

Stejně tak jako se na začátku Sprintu ptáme zákazníka, co by chtěl vidět, na konci každého Sprintu nadchází chvíle, kdy zákazníkovi ukazujeme, co jsme dokončili. Během Sprint Review se snažíme získat zpětnou vazbu na dokončené User Stories. Prezentujeme pouze dokončené User Stories. Tedy ty, které mají splněná akceptační kritéria, fungují, jsou otestovány, zrevidovány, popsány v dokumentaci a akceptovány Product Ownerem. 

Kanban 

Systém vymysleli v Japonsku. Továrny implementovaly takzvaný systém tahu, kde se potřebné díly pro daný stroj dodávaly “just in time”, tedy až když byly potřeba. A aby se na díly zbytečně nečekalo, každý díl měl pouze omezenou frontu, kde Dohly být připravené zásoby.

Dodržuje 3 principy: 

• Omezit rozpracovanou práci - work in progress 
• Minimalizovat čas průchodu - lead time 
• Vizualizovat progress 

V praxi rozdělujeme práci na 3 fáze: 

• Backlog 
• In progress 
• Done

Omezujeme při tom, kolik políček může každá fáze mít. Přitom je docela vědou, jak nastavit, kolik políček v každé kategorii bude. Kanban se obvykle doplňuje pravidelnou retrospektivou, Scrum Meetingem, spoluprací v týmu, Backlogem s User Stories či rolí Product Ownera. 

Jak stavět Product Backlog

Product Discovery 

První v čem musíte mít jasno, je vize. Ta by měla vypadat takto: 

• Vytvářet obrázek 
• Vzbuzovat emoce 
• Vytvářet konkrétní představu cíle 
• Být jasná, transparentní 
• Být těžko dosažitelná

Když jste s vizí spokojení, můžete pokročit o krok dál k tvorbě Product Backlogu. Začínáte s brainstormingem velkých Epiců. Ty potom odložíte a uděláte brainstorming s cílem vymyslet, kdo bude váš produkt používat. Vytvoříte si persony. To, když máte, přiřadíte persony k jednotlivým Epicům a začnete postupně rozpadat Epicy na jednotlivé User Stories s akceptačními kritérii. Výslednému Backlogu určíte priority. 

Story Mapping a Project Chartering 

Začínáte s nápadem: Co že to budeme dělat a co očekáváme? Poté se zamyslíme nad následujícími otázkami: 

• Co to je? 
• Co to není? 
• Jaké to je? 
• Jaké to má jméno? 

Chartering vám pomůže lépe definovat to, co chcete dělat a pochopit proč. 

Pak jste připraveni začít se Story Mappingem. Stejně jako v minulém příkladu začněte brainstormingem velkých funkcionalit. Co všechno budete u produktu potřebovat? Vytvoříte řadu funkcionalit, pro které budete generovat konkrétní možnosti, jak danou oblast pokrýt. Poté si vyberete prioritní User Story, které budete implementovat nejdříve. Je dobré se zamyslet, jak budete prioritizované User Story testovat. To vám pomůže si uvědomit, co je klíčové a jak poznat, že jsou hotové. 

ATP: 

Agilní metody lze aplikovat na náš projekt na výrobu recyklovaných podtácků. Zákazníkem je pro nás kavárna, která naše podtácky používá. Ideální situace by nastala, kdybych jakožto projektový manažer působil částečně jako Scrum Master, vytvořil pro tým prostředí, ve kterém si práci budou moci řídit sami a zákazník působil částečně jako Product Owner, který by zadával funkcionality, o které bychom mohli produkt rozšiřovat.

Vytvořili bychom společně Product Backlog, který by obsahoval ideální formu produktu a poté bychom produkt s týmem v rámci Sprintů vylepšovali. Nastavili bychom si parametry Sprintu, produkt rozšířili o určitou funkcionalitu, produkt prezentovali zákazníkovi a poté reflektovali na úspěšnost Sprintu. Tým by pracoval sám na různých prvcích funkcionality, zmenšily by se časové náklady na schůzky, každý člen týmu by věděl, co má za úkol a mohli bychom si vzájemně pomáhat, kdyby naše kapacity nebyly naplněné. Zákazník by po každém Sprintu měl rozšířenou funkčnost produktu a my bychom měli podněty na reflexi toho, jak efektivní naše práce byla.