Agilní přístup k plánování prací

Níže uvedený stručný souhrn vychází částečně z metodiky SCRUM Development Process Kena Schwabera a Mika Beedla. Pro zjednodušení však čerpám z podkladů online semináře Nathalie Udoviii, které jsou svým rozsahem pro tuto komparaci naprosto dostačující.

1. Plánování v rámci životního cyklu agilního projektu

Životní cyklus agilního projektu se skládá s předběžného naplánování projektu, plánu uvolňování výstupů projektu a jeho realizace v iteracích, jejichž součástí je vždy plánování rozsahu dané iterace a denní plánování. Jak v rámci předběžného plánování, tak i na začátku každé iterace má zákazník, který je součástí projektového týmu, možnost tvořit a měnit vlastnosti výsledného produktu, které jsou apriori označovány jako produktové nedodělky (Product Backlog). Toto je významná kvalita agilního přístupu, kterou si proto izolujme jako parametr P4-Flexibilita plánování.
Tým tvoří detailní definici (odhady) rozsahu pouze pro funkce implementované v nadcházející iteraci. Zatímco tradiční plánování se zaměřuje spíše na plánování aktivit, agilní plánování plánuje funkční vlastnosti produktu.

2. Časové škatulkování (Time Boxing)

Time Box (časová škatulka) je fixní množství hodin či dnů, v rámci kterého je nutno vytvořit určitou sadu vlastností. Daná iterace končí i v případě, že některé vlastnosti se nepodařilo vytvořit. Nedokončená funkcionalita se vrací mezi produktové nedodělky a stane se následně předmětem prioritizace. Prostřednictvím časových škatulek je na zákazníka vyvíjen tlak, aby sám určil, které vlastnosti mají větší důležitost a mají proto být dodány dříve. Tým je pak tlačen dodat reálnou přidanou hodnotu v rámci krátké, předem vymezené periody.

3. Předběžné plánování

Než agilní projekt započne, organizace stanoví projektovou vizi, cestovní mapu produktu a business case. Product Backlog vzniká sběrem požadavků, prioritizací vlastností a stanovení rámcových odhadů. Následně je zformován projektový tým. V rámci předběžného plánování načrtne architekt mnohdy už i základní architekturu produktu.

4. Produktové nedodělky (Product Backlog)

Za řízení a kontrolu produktových nedodělků odpovídá zákazník, který může po každé iteraci přidat nebo odebrat vlastnosti. Pohybuje se však vrámci limitu zafixovaného času a zdrojů (viz obrázek kap. Základní principy), a tak se může stát, že pokud přidá pracnou vlastnost, musí se rozhodnout, které jiné vlastnosti upozadí nebo zcela vypustí.

5. Agilní projektový tým

Obsahuje typizované role s odpovídajícími kompetencemi, do kterých jsou dosazeni pracovníci s vhodnými předpoklady. Součástí agilního týmu je vždy zákazník, resp. vlastník produktu, který se aktivně účastní prací a rozhodování v rámci týmu. Je tedy soustavně obeznámen s výstupy a směřováním projektu, což vede k jeho ztotožnění se sproduktem již během jeho vzniku a předchází se nepříjemnému překvapení či zklamání. Získáváme proto další důležitý parametr pro naši úvahu: P5-Míra zapojení zákazníka.

Tým má dvě části: Jádro a širší tým. Tým musí být schopen samo-organizace, což znamená, že rozhodnutí mají být prováděna v maximální možné míře na nejnižší úrovni. Tým je povzbuzován k samostatnosti a vnímání vlastní odpovědnosti za celek. Není řízen a kontrolován ze shora a jednotliví členové tak cítí potřebu společně vytvářet funkční výstupy.

Denní plánování se typicky týká jádra týmu. Jádro týmu tvoří: Vlastník produktu, Týmový coach (projektový manažer), Vývojář a Tester. Jádro je v širším týmu doplněno o Zákazníka, Architekta, Uživatele a Oborového experta. Ne všechny role musí být obsazeny nebo mohou být sloučeny. Doporučuje se dodržet velikost týmu mezi 6 a 12 členy.

  • Zákazník – poskytuje produktovou vizi, popisuje hlavní příběhy uživatelů, prioritizuje požadavky na začátku každé iterace, poskytuje zpětnou vazbu k předešlé iteraci.
  • Vlastník produktu – analyzuje tržní, konkurenční a ekonomické aspekty, spolu se zákazníkem definuje dlouhodobou i krátkodobou produktovou vizi a vysvětluje ji týmu, prioritizuje vlastnosti na základě očekávané návratnosti investice, definuje akceptační kritéria a pomáhá psát příběhy uživatelů.
  • Architekt – je zodpovědný za definici i udržení struktury a integrity řešení, je zodpovědný za funkční design a jeho komunikaci, řídí volbu použitých technologií, poskytuje podporu vývojářům, zajišťuje dodržení cílů v oblasti výkonnosti, spolehlivosti, provozovatelnosti a rozšiřitelnosti.
  • Vývojář – nemusí jít vždy pouze o jednoho pracovníka, je zodpovědný za vytvoření, ověření a dodání produktu (přírůstku), na konci každé iterace prezentuje výstupy ostatním členům týmu, provádí odhady pracnosti vlastností, účastní se plánování iterací, odhaduje technickou proveditelnost vlastností.
  • Týmový coach (projektový manažer) – zastřešuje proces plánování, zajišťuje zdroje, reportuje stav projektu, garantuje dodržování dohodnutých procesů a pravidel, odstraňuje překážky a řeší problémy vyžadující koordinovanou spolupráci, motivuje tým. Tato role plní vagilním týmu úlohu spíše „podpůrného vedení“, zajišťující službu týmu jako celku.

6. Plánování iterace

Na počátku každé iterace se projektový tým schází, aby potvrdil shodu na produktových nedodělcích a stanovených prioritách jednotlivých vlastností. V případě potřeby jsou provedeny změny. Tým se informuje o nových poznatcích a zkušenostech získaných vprůběhu práce na produktu. I tyto vstupy jsou následně vplánování zohledněny.

Po té, co tým obdrží více detailních vstupů od zákazníka, vývojáři vyberou dle priorit vlastnosti, o kterých si myslí, že je budou schopni v rámci nadcházející iterace vytvořit. Tým následně odhadne pracnost dodávky zvolených vlastností a stanoví osoby odpovědné za jejich dokončení. Plánovací cyklus může v rámci plánování iterace proběhnout i několikrát, dokud se nepodaří vměstnat plán prací do plánu iterací či plánu uvolňování výstupů.

7. Denní plánování

V rámci iterace probíhá denní plánování. Jedná se o krátké, přibližně 15-ti minutové porady, během kterých si tým koordinuje dělbu úkolů a identifikuje problémy a překážky (nesnaží se je ale na místě vyřešit; jejich řešení řídí následně vedoucí projektu).

8. Technika odhadování ‚Story Points‘

Samotný popis vlastností produktu by sám o sobě nestačil pro srozumitelné zadání vývoje. Proto se v rámci sběru požadavků vytvářejí i tzv. příběhy uživatelů (User Stories). Jde o stručný popis funkcionality a jejího užití z pohledu uživatele nebo zákazníka. Tyto příběhy uživatelů jsou rovněž využívány při prioritizaci produktových nedodělků a zadávání do vývoje.

Story Points (bodování příběhu) jsou jednotky, prostřednictvím kterých vyjadřujeme celkovou velikost příběhu uživatele nebo vlastnosti. Tým ohodnotí takovýmito body relativní náročnost každého příběhu v seznamu produktových nedodělků. Do tohoto hodnocení tak promítá komplexnost vlastností a úsilí, které bude muset vynaložit na jejich vývoj.

9. Rychlost týmu

Posledním střípkem do mozaiky agilního plánování je veličina nazvaná Rychlost týmu (Team Velocity). Jde o veličinu vyjadřující míru postupu vpřed. Jinými slovy jde o množství Story Points, které umí tým dokončit během jedné iterace. Na základě rychlosti týmu a celkového obodování všech příběhů v produktových nedodělcích můžeme určit, jak dlouho projekt potrvá a kolik iterací budeme muset přibližně naplánovat.
Vyjdeme-li z premisy zafixovaných zdrojů a času popsané v kapitole Základní principy, k jejímuž dodržování se celý projektový tým (včetně zákazníka) zavázal, vytváří se tak unikátní mechanismus sebekontroly zákazníka, jenž má k dispozici tým s garantovanou výkonností a může tak v garantovaném čase získat produkt, který bude s maximální pravděpodobností odpovídat jeho aktuální potřebám. Izolujme tedy poslední parametr P6-Míra kontroly zákazníka.