Typický šéf vývoje je člověk, který před pár lety přešel od vodopádového plánování k agilnímu přístupu. Řídí tým různě zkušených programátorů a jeho práce v mnohém připomíná práci projektového manažera. Musí dodat výsledek v dohodnuté kvalitě, rozsahu, a přitom nepřekročit plánované náklady. Může pracovat na větším projektu (např.: vývoj nového interního systému) nebo na kontinuálním vývoji a opravách existujícího softwaru (např. podpora SAP). Ať tak, či onak, jeho tým pracuje iterativně, práci plánuje do dílčích sprintů. Každý sprint je časově omezený úsek s pevně naplánovaným seznamem úkolů. Práci do sprintu plánuje zástupce byznys strany (typicky vlastník produktu nebo klíčový uživatel) v součinnosti s vývojovým týmem tak, aby se do plánu dostalo pouze to, co je možné realisticky splnit. Jeden cyklus má obvykle následující fáze: plánování, realizace, revize a testování.

V agilních týmech šéf vývoje úzce spolupracuje se scrum masterem. Šéf vývoje zodpovídá za kvalitu výsledného produktu, stará se o tým po manažerské stránce, vybírá nové členy týmu a sám reportuje vedení společnosti. Scrum master je potom zodpovědný za každodenní koordinaci týmu a prioritizaci úkolů. Řeší komunikaci s jakýmkoliv týmem, který je v projektu zapojený, řídí schůzky dle agilní metodiky (sprint kick off, každodenní stand-up meeting, sprint review, …). Jeho úkolem je rovněž zajistit pro tým dostatečnou koncentraci a odstínit jej od rozptylující komunikace.

Při hodnocení a hlídání projektu zajímají šéfa vývoje hlavně dvě otázky:

• Jsme schopni plnit domluvený plán včas a ve slíbené kvalitě?
• Pracujeme efektivně? Neplýtváme kapacitou?

Co znamená „splněno“?

Abychom změřili, nakolik se nám daří plnit cíle, musíme nejprve jednoznačně definovat, co to znamená splněný úkol. Tím z týmu odstraníme zbytečnou nejistotu ohledně požadavků na splnění úkolu a vyhneme se nepříjemným překvapením, kdy „hotová“ práce je pouze polotovar. Ušetříme si také nepříjemný ping-pong mezi vývojářem a kontrolou kvality (code review). Definice může být například seznam pravidel:

• Návrh nové funkčnosti je schválen.
• Analýza uživatelských scénářů byla provedena.
• Analýza proveditelnosti (proof of concept) byla dokončena.
• Nová funkce je implementovaná.
• Testování proběhlo v pořádku.
• Dokumentace je aktualizovaná.
• Funkce prošla kontrolou kvality.
• Kód je součástí hlavní vývojové větve.
• Funkce je nasazená v produkci.

Kontrola plnění plánu a nástrojová podpora

V samotném plánování jsou dvě místa, která můžou být problematická: plánování kapacity a odhad pracnosti jednotlivých úkolů. S naplánovanou kapacitou mohou zatřást neočekávané události, jako kritická chyba, nemoc či práce na jiných urgentních projektech. Odhady pracnosti by měly vycházet z reálné úrovně týmu. Pokud je provádí nejlepší seniorní programátor, nepřekvapí nás, že nováček ve zkušební době má problém plnit plán. Když je plán hotový a úkoly rozdělené, nastává fáze, kdy je nutné tým kontrolovat a koordinovat, abychom uhlídali jeho plnění.

Přitom se už neobejdeme bez nástrojové podpory. Potřebujeme systém na řízení úkolů s podporou našeho pracovního postupu, který dokáže evidovat čas odpracovaný na úkolu. Bez těchto dat se nemůžeme posunout dále. K tomu, abyste viděli, zda celý projekt probíhá podle plánu, se pak výborně hodí Burndown graf. Ten vám v každém okamžiku ukazuje, zda se přibližujeme, či vzdalujeme stanovenému cíli, jinými slovy: zda je naplánovaný termín reálný, nebo se nám plán zvolna vymyká kontrole. Operativní řízení je nutné i v případě, že jde o projekt dodávaný třetí stranou.

Obr. 1: Zdravý Burndown graf

Zdravý graf nám průběžně ukazuje, zda dokončujeme jednotlivé úkoly takovým tempem, které stačí na dokončení celého projektu nebo sprintu v požadovaném termínu. Předpokládaný termín dokončení je 21. den, tj. v místě, kde červená osa trendu protíná časovou osu X. Vypovídající hodnotu grafu bude ovlivňovat struktura práce.

„Burndown graf funguje pouze, pokud je úkolů hodně, jsou malé a výkazy se dělají často. V opačném případě může nastat situace, kdy se z grafu zdá, že tým nestíhá, ale jakmile se splní jeden větší úkol, rázem se dostaneme do zdravého stavu,“ doplňuje Aleš Kruczek, Information Technology and Project Office Director ve společnosti ALD Automotive.

Obr. 2: Nemocný Burndown graf

Nemocný graf nám ukazuje, že tímto tempem projekt nezvládneme za 21 dní. Červená osa protíná osu X někde v daleké budoucnosti. Je pravděpodobné, že s prací se začalo později. Zároveň v průběhu projektu roste objem plánované práce (šedá plocha). Tým nyní musí analyzovat příčiny tohoto stavu: objevují se další chyby, nebo se rozšiřuje rozsah projektu?

Následně bude nutné zvážit, zda posílíme tým a pokusíme se to zvládnout nebo změnit plánovaný termín na realistický. To však obvykle nebude možné u kratších projektů nebo sprintů. Zde bohužel tento sprint již nedopadne dobře. Bude potřeba poučit se z nalezených chyb a ty v dalším sprintu eliminovat.

„Pomocí Burndown chart sledujeme reálný vývoj projektů v čase. Nevyužíváme jen jeho elektronické podoby, ale čerpáme i z výhod klasických ručně kreslených grafů na velkých zdech a tabulích. Jejich hlavní předností je fakt, že jsou vždy dostupné všem. V kterýkoliv okamžik se tedy kdokoliv může přijít podívat, jak si projekt vede, a predikovat i jeho budoucí vývoj,“ doplňuje osobní zkušenost Milan Kalinka, Embedded SW Manager ze společnosti ComAp.

Pokud chceme vidět probíhající práci více v detailu, je dobré sledovat, v jakém stavu jsou jednotlivé úkoly. Nepřekvapí nás, když na začátku sprintu většina programátorů pracuje na návrzích. Ke konci by naopak většina úkolů měla být ve fázi testování.

Tento report bude tým sledovat na pravidelných týdenních poradách. K získání hlubšího porozumění je nutné pohled doplnit o další údaje. Jak jsou na tom jednotliví členové týmu? Na kolik procent mají splněný aktuální plán (odhad pracnosti vs. počet aktuálně odpracovaných hodin)? Které úkoly jsou v ohrožení? Komu je nutné pomoci, aby byl celý plán splněný včas?

Výhodou vizualizací je možnost sdílet stav s celým týmem a každým, kdo je v projektu nějakým způsobem zainteresovaný. Všichni tak mají přehled o situaci a nedochází ke zbytečnému komunikačnímu šumu. K tomuto účelu dobře slouží i metoda kanban, oblíbená u řady agilních týmů. Princip je jednoduchý: Na tabuli máme svislé sloupce, z nichž každý představuje fázi vývojového cyklu (backlog, plánování, realizace, testování, …). Na papírových kartičkách máme popsané jednotlivé úkoly a tak, jak je tým posouvá do dalších fází, posouváme je i na týmové nástěnce, takže každý vidí aktuální stav.

„Kanban board obrovsky vypovídá o stavu projektu. Pokud jej nemáte v nástroji, tak se dá skvěle udělat i pomocí papírků na zdi,“ zmiňuje Aleš Kruczek.

Opakované řízení realizace a plánování SW projektu

Jedna věc je uhlídat konkrétní sprint, druhou je dosahovat sprint za sprintem stabilních výsledků a zlepšovat se v plnění plánů. Šéf vývoje potřebuje uvažovat v širším horizontu než jeden sprint. Představme si například oddělení, které rozvíjí ERP systém a vydává (releasuje) pravidelně novou verzi, například jednou za rok. Vedoucí vývoje si bude klást následující otázky:

• Jakou máme kapacitu pro roční plán? Kolik změn mohu slíbit?
• Nakolik se naše plánovaná kapacita liší od reálně odpracovaného času? Zlepšujeme se v plánování kapacity?
• Jaká je kvalita práce? Kolik děláme chyb? Nakolik nás to brzdí?

Scrum master se v této souvislosti bude ptát, na kolik se skutečná pracnost liší od původních odhadů. Jsou naše odhady stále přesnější nebo naopak? V ideálním světě se každý sprint splní na 100 %. Realita však většinou nebude tak zářná. Proto je nutné neustále sledovat trendy a analyzovat příčinu, proč se nedaří realizovat sprinty dle plánu.

Příčin může být celá řada, některé z nich jsme nastínili výše. Chyba může být ve fázi plánování nebo v realizaci. Na místě je kontrolovat plnění plánu dle jednotlivých vývojářů a zjistit, proč se nepodařilo plán splnit. V tom nám pomůžou osvědčené nástroje jako root cause analýza (5x Proč). V každém případě platí, že je potřeba dát si pozor na zbytečný multitasking a raději plánovat kratší sprinty s menším množstvím realisticky zvládnutelných úkolů.

Úkolem šéfa vývoje je rovněž hlídat týmový fokus na splnění společného plánu, nikoliv pouze individuální splnění vlastního plánu. Tzn. je dobré sledovat, zda daný programátor po splnění vlastních úkolů pomohl někomu dalšímu s jeho úkoly. Realita bývá taková, že ve dvou třetinách sprintu jsou programátoři stále optimističtí a mají tendenci si úkoly nechávat u sebe. Právě zde je nutný vedoucí vývoje, aby identifikoval, že individuální plán není reálný, a přesunul úkol na někoho jiného.

Ať už tým pracuje na jakémkoliv projektu, dobře připravená sada reportů pomůže šéfovi vývoje práci řídit tak, aby netrpělivě očekávané funkce byly v produktu přesně, jak slíbil.

	Jan Škrabánek Autor článku je konzultantem ve společnosti ALVAO, kde zajišťuje zákazníkům technickou podporu.
	Ing. Aleš Studený Druhý autor článku je ředitelem služeb ve společnosti ALVAO. Jeho tým konzultantů zlepšuje IT v českých i zahraničních firmách. Je aktivní v publikaci odborných článků na téma řízení IT (ITSM) a tuto problematiku přednáší na vysokých školách.