Konstantní rychlost práce

Dalším z klíčových prvků plánování je rychlost, kterou tým pracuje. Měří se samozřejmě na body, které si tým započítává za dokončené úlohy. Na začátku každého projektu budete mít pozvolný náběh, kdy se tým seznamuje s úkolem, specifikací, technologií a architekturou. A učí se. Učící křivka bude stoupat po dobu cca 1-3 sprintů v závislosti na projektu. Pak tým najede na svůj limit a pracuje konstantní rychlostí až do konce projektu.

Konstantní rychlost a pravidelnost odevzdávání dílčích výsledků je jedním z klíčových prvků Agile metod, takže jen shrnu, co chceme docílit. Pravidelnost jde spolu s předvídatelností. Jen tak že tým odevzdá každý sprint konstantní počet bodů, bude datum dokončení projektu dostatečně důvěryhodné číslo. Z pohledu týmu je účelem udělat plánování jednodušší, když se to tak na začátku nezdá a oprostit jednotlivé členy týmu od stresu, ale zároveň je na výsledku motivovat. Tým naplánuje jen to, co věří, že stihne udělat. Ostatně úlohy jsou obodovány a tým ví, že je schopen udělat 20 bodů za sprint, a tedy že stihne zase 20 bodů. Samozřejmě může se stát, že se to ve vyjímečných případech nepodaří, ale troufám si říct, že je pak pravděpodobné, že něco nefunguje úplně ideálně a stálo by to za Vaši pozornost. Pracuje tým opravdu týmově? Jak probíhá plánování? Rozumí pojmu bod? …

Zavádíte-li s Vašimi lidmi první Agile projekt, je velmi pravděpodobné že se to budete nějakou dobu učit. Můj odhad je tak 5-8 sprintů. Tým se musí naučit chápat a vnímat co je to bod, jak dělat plán a jak spolupracovat opravdu týmově. Na začátku bylo obvyklé, že tým vykazoval naprosto nerovnoměrné výsledky v rozmezí od 0 do 2.5 násobku plánovaných bodů. Jedním z velmi důležitých pravidel je tým nechat samostatně pracovat po dobu sprintu, a neorganizovat ho zvenku, ale na konci sprintu věnovat čas na reflexi a vysvětlení.

Na závěr ještě jednu radu. Vaším cílem je být efektivní. A platí, že dobrý tým je vždy efektivnější než samostatní jedinci. Proto neporovnávejte a nehodnoťte jednotlivé lidi podle toho, kolik dokončili úloh a za kolik bodů ty úlohy byly, ale hodnoťte vždy jen tým jako celek. Motivujete tím tým na výsledku a tedy i jeho jednotlivé členy na vzájemné spolupráci. Navíc máte-li týmy dva a více, vzbudíte tím zdravou soutěživost, a vytvoříte dobrou referenční soustavu.

Krátké vývojové cykly – Sprinty

Podíváte-li se na software development projekty, dost část se Vám stane, že nejsou dostatečně dobře časově odhadnuty. Samozřejmě částečně je to dáno špatnými odhady vývojářů. Často je ale hlavním problémem nejasná specifikace na začátku, která se v průběhu stále upravuje a designe a architektura se pak neustále předělává. V tom úplně nejhorším případě na konci máte něco úplně jiného, než se zpočátku myslelo.

V této sekci se zaměřím na to jak včas odhalit, že vám vůbec hrozí problém nedokončení v daném termínu. Začneme kvalitním produkt backlogem. Ten zdaleka nemusí být rozpracován do detailů, ale musí obsahovat všechny aktivity – Story – které musí být hotovy, aby byl se projekt mohl odevzdat. Např. pro implementaci nějaké funkcionality asi musíte udělat návrh, designe testu, implementaci, integraci, otestování a napsat dokumentaci. Tyto highlevel Story ohodnotíte body a v průběhu projektu detailněji rozpracujete.

Tým nechte pracovat v pravidelných cyklech – Sprintech. Na konci každého Sprintu jednoduše odečtete body za již hotové úlohy z celkového backlogu. Porovnáním hodnoty s plánem velice rychle vidíte, jestli je vše v pořádku či ne. Použijete-li pro vizualizaci burndown graf, automaticky víte, jak jste na tom a to pravidelně každý sprint. Úkolem sprintu je naučit tým naplánovat to co opravdu zvládne a odevzdávat pravidelně stále stejný objem práce a tak zvýšit důvěryhodnost odhadů a spolehlivost data dokončení.

Sprint by měl být krátký, obecně by asi neměl být delší než měsíc. Při zavádění Agile a sprintů se nebojte na začátku změnit délku sprintu, když se ukáže pro váš projekt nevhodná. Nám se nakonec osvědčily 14 denní sprinty. Začínali jsme s týdnem, ale to se ukázala být moc krátká doba. Dobrá pomůcka je že musíte být za sprint schopni ukončit běžnou úlohu. Ale úlohy se dají vcelku neomezeně dělit, takže jde spíš o to si to vyzkoušet přímo ve Vašem prostředí.

Ohodnocení úloh body

Jedním z těžko uchopitelných praktik Agilu je ohodnocení body. Ze zkušeností vím, že pochopení toho ‘co to vlastně ten bod je‘ a jak můžu ohodnotit úlohu něčím, co vlastně nemá pevnou jednotku, patří k nejsložitějším úkolům při zavádění Agile.

Ale vezměme to popořádku. Na začátku projektu máte seznam oblastí (Story) na kterých budete pracovat v Backlogu. Vezměte tým složený z project managerů, architektů a technical leaderů a udělejte odhady náročnosti tak, jak jste byli zvyklí. Pak převeďte odhady na body: 1bod=1man/day. A teď to přijde. V tom to momentě zapomeňte rozměr bodu a pracujte už jen a pouze s bodem. Jeho hodnota bude v začátku projektu, zvlášť bude-li to první Agile projekt, jistě měnit svou hodnotu, obvykle devalvovat. My jsme měli po cca dvou prvních měsících hodnotu bodu 0.6man/day. Nicméně od té doby se drží stabilní a to i na dalších projektech.

Co chcete docílit:
  • Zlepšit/zpřesnit odhady lidí v týmu
  • Zvýšit důvěryhodnost plánu vzhledem k managementu
  • Aktivně zapojit tým do plánování
  • Motivovat lidi na výsledku a včasném ukončení projektu
  • Zapojit tým do hry

Ohodnocení body je jen jeden střípek do mozaiky, sám o sobě toho moc nezmůže, ale je to dobrý začátek pro zkvalitnění odhadů náročnosti jednotlivých úloh. Jestli jste někdy zkoušeli nechat vývojáře odhadnout kdy práce bude hotová, jistě se Vám často stalo, že při odhadu zapomněli na část aktivit, např. testování, nebo Vás přesvědčovali, že práce odhadnout nejde, protože nikdo neví, co se může ještě objevit za problém.

Prvním krokem pro učení ohodnocení jednotlivých členů týmu je ohodnotit Story zkušeným týmem a pak nechat tým jen jednotlivé Story rozpadnout na menší úlohy ohodnocené body v rámci původního odhadu. Ohodnocení body zbaví jednotlivé vývojáře přímé vazby na čas, nicméně časem vytvoří bodu jakýsi ‘rozměr složitosti‘ který tým vstřebá a naučí se automaticky používat.

Každou další novou úlohu či Story nechte ohodnotit už přímo tým, který na ní bude pracovat. Tím tým zapojíte do hry a budete-li správně prezentovat výsledky (Burndown), zajistíte si tím správnou motivaci.

Produkt Backlog a ohodnocení úloh

Na začátku každého projektu je nutné nějak formálně popsat požadavky na systém. Co se má vlastně udělat a jak. Přepsat uživatelské požadavky do trochu techničtějšího popisu, takže mu budou vývojáři rozumět. Agile v tomto kontextu pracuje s pojmem Backlog.

Jak by měl takový backlog vypadat a do jakých detailů by měly úlohy zacházet? Řekněme, že to záleží na fázi projektu. Na začátku je nutné identifikovat high-level oblasti – Story, přidat odhad ohodnocení a základ backlogu je hotov. V průběhu projektu, jak budete vědět více, se Story budou postupně rozpadat na jednotlivé konkrétnější úlohy ohodnocené v rámci původního odhadu a backlog získá více detailů. Samozřejmě se může stát, že některé Story se budou muset přidat a některé se ukážou nadbytečnými.

Takto nadefinovaný backlog tedy pokrývá veškeré aktivity na projektu, spolu s ohodnocením je základním vstupem pro odhady celkové náročnosti. Zároveň je to prvním kamínkem do mozaiky Burndownu, ale o tom až později.

V této podobě (tabulka v Excelu) se nám vyplatilo sledovat jen relativně high-level úlohy. Pro popis detailů jednotlivých úloh či jejich stavu je vhodné použít některý z online trackovacích systémů – jako je třeba Mantis. Pro větší názornost a zpětnou kontrolu odpracovaných bodů jsme posléze přidali pravou část tabulky znázorňující, v kterém sprintu se pracovalo na které úloze.

Jak z individualit udělat tým

Také se Vám už stalo, že máte skupinu vzájemně nekomunikujících jedinců a potřebujete, aby se z nich stal tým v pravém slova smyslu, aby spolupracovali, radili si a učili se jeden od druhého? Metod jak toho docílit je mnoho, určitě pomůže team building a jiné společné aktivity, či firemní kultura. Jednou z technik jak stmelit skupinu lidí dohromady a udělat z nich tým je Scrum či Stand-up meeting.

Podstata je velmi jednoduchá. Zorganizujte pro svůj tým každodenní pravidelný meeting. Scrum (Stand-up meeting). Meeting musí být krátký, každý den ve stejný čas na stejném místě. Dost pomůže zvolit neformální prostor, klidně bez židlí, aby vše nutilo čas strávený Scrumem co nejvíce zkrátit. Udržte meeting na 5min maximálně 10min. Nikdy víc. Docházka musí být povinná pro všechny členy týmu, jinak to nebude fungovat. Můžete zvážit přítomnost zástupce z jiných týmů, se kterými máte spolupracovat.

Někde jsem se dočetla, že ideální je začít Scrum nějakým vtipem či historkou. Asi je to dobrá rada zvláště na začátek, ale v praxi je asi dost těžké mít na každý den něco nového. Ale i tak to stojí za zamyšlení. Pomůže Vám to odlehčit situaci a setkání udělat více společenské a ne pouze pracovní.

Takže přeskočme společenský aspekt a podívejme se na ten pracovní. Každý člen týmu by měl stručně nastínit, na čem pracoval včera a co bude dělat dnes. Součástí je samozřejmě i identifikace případných problémů s danou úlohou či žádost o radu od kolegů. Jedním z cílů takového meetingu je tedy vzájemná informovanost v rámci týmu o tom na čem kdo pracuje a prostor k větší kooperaci. Na začátku spolupráci budete muset pomoct, po čase bude stačit nechat lidi mluvit a sami si o radu řeknou či jí nabídnou. Mě se osvědčilo mít Scrum dopoledne, tak aby se všichni pokud možno sešli včas a začali pracovat.

Nezapomeňte využít času Scrumu pro propagaci úspěchů a to jak jednotlivců, tak projektu jako celek. Scrum by neměl být jen prostor pro řešení problémů. A na závěr, nezabíhejte do technických detailů. Pojmenujte problém, sestavte skupinu, co pomůže s jeho řešením a vraťte se k detailům po skončení Scrumu. Scrum musí být krátký a rychlý.

Začínáme s Agile (Agilní metody)

Jedním z nejoblíbenějších Agilních přístupů je Scrum proces. Scrum proces se snaží škálovat velké a komplexní softwarové projekty, které je těžké najednou obsáhnout a pochopit, na menší celky a stanovit priority jednotlivých úloh. Od běžného požadavku „Chci všechno a hned“ zapojuje Scrum proces různé zájmové skupiny do procesu plánování a tím je zaváže na výsledku.

Dobrým výchozím bodem bude proces zobrazený na následujícím obrázku:

Jak to celé funguje? Máte nějaké zadání, vizi, požadavky. Z toho sestavíte Produkt Backlog – což v praxi znamená relativně high-level seznam úloh. V průběhu projektu ho můžete rozšiřovat či upřesňovat. A teď už začíná cyklus. Pravidelný. Pokaždé stejně dlouhý. Říká se mu Sprint. Na začátku je seznam úloh z backlogu co se mají za daný časový úsek dokončit a na konci hotová práce, prezentace výsledků zákazníkovi a případně update backlogu o nové úlohy.

Jednotlivým krokům a pojmům se budu detailněji věnovat v dalších příspěvcích, ale co to má vlastně celé za smysl? Takže naučit tým pracovat konstantní rychlostí, každý sprint pravidelně dodávat stejný objem práce. Dodat vývoji SW rytmus. A tím získat lepší či chcete-li kvalitnější odhady od engineerů. Současně zajistit pravidelný feedback od zákazníků a zainteresovat je na vývoji. Propojit je s týmem vývojářů a dát tak developerům větší motivaci na jinak často příliš abstraktním projektu.