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.

Sestavování týmu

Ideálně byste měli podpořit soutěživost. Je-li to možné, sestavte týmy dva. Neměly by být ani moc malé – to by omezovalo znalosti a spolupráci v rámci týmu, ale na druhou stranu ani moc velké. Ideálně tak asi 5-10 lidí. Podaří-li se Vám sestavit týmů více, nezapomeňte na komunikaci mezi nimi. Jednou z dobrých praktik je pozvat vždy zástupce druhého týmu na Scrum. Tím se zajistí kontinuita informací mezi týmy, a zároveň umožní sdílení zkušeností a znalostí mezi týmy.

Koho do týmu? Tak určitě někoho na úrovni systém engineera/architekta, několik vývojářů a testera. Aby to fungovalo, nechte testery spolupracovat už na návrhu funkcionality a od počátku procesu připravovat test designy a automatické testy aby se funkcionalita mohla nezávisle vyzkoušet hned, jak ji vývojáři napíšou.

Komunikace v týmu – osmotická komunikace

Angličtina má pěkný výraz na vnímání komunikace na pozadí – Osmotic communication. Je to velmi efektivní způsob jak udržet všechny v obraze co se děje, a jak zajistit aby si vzájemně nabízeli radu bez formálního požadavku. Je to způsob, jak se informace šíří samy na pozadí a lidé si z nich zapamatují jen to co je pro ně důležité bez toho aniž by nad tím přemýšleli a informace analyzovali. Časté řešení – globální openspace zajistí maximálně to, že lidé přestanou vnímat co se kolem nich děje. Stanou se imunní k hluku kolem, neboť se jich většinou vůbec netýká.

Posaďte tým pokud možno do jedné místnosti. Nechte sedět vedle sebe lidi, co spolu pracují. Samozřejmě každý se nerad stěhuje jinam, všichni si už nějak zvykli tam, kde jsou. Ale žádným formálním meetingem nedocílíte efektu toho, že lidé spolu soustavně mluví a poslouchají, co se kolem nich odehrává. To co se děje kolem, se týká do jisté míry všech. A zeptat se nahlas „Nevíte někdo jak na to…?” je o mnoho jednodušší než obejít několik spolupracovníků sedících z historických důvodů kdoví kde ve firmě. Navíc často vám pomůže ten, od kterého byste to ani nečekali.

Jen tak že dáte lidi dohromady, se z nich opravdu stane tým.

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.

Proč něco měnit?

Tak samozřejmě důvodů může být hned několik. Začněme zvýšením efektivnosti. Nicméně s tím je úzce spojená firemní kultura, konkrétně týmová spolupráce. Jak přesvědčit své zaměstnance aby jednali jako tým a ne jako jednotlivci a individuality? Aby sdíleli informace, pomáhali si a učili se navzájem? Jak týmy nechat soutěžit ale přesto spolu spolupracovat? To je jen několik prvních otázek které člověka napadnou, když začne přemýšlet o efektivnosti.

Dalším z častých problémů je jak zajistit aby projekt byl dokončen včas. Podíváte-li se na svůj tým SW engineerů a designerů, kolik z nich umí odhadnout náročnost úlohy a v jaké granularitě a jak přesně? Kolik z nich úlohu nadhodnotí klidně na dvojnásobek, aby pak měli klid, a kolik z nich zapomene na polovinu aktivit, takže ve výsledku je práce ‚hotová‘ několik týdnů ale pořád se na ní ještě pracuje?

Agile a SCRUM jsou jen jedny z mnoha metod jak předcházet těmto problémům už v počátku jejich vzniku. Obsahují soubor metodik jak pracovat s lidmi na projektu jak je motivovat a zapojit do plánování projektu, jak docílit kvalitnějšího výstupu a jak zapojit zákazníka do vývojového procesu.

Řízení projektů v outsourcingu, Agile a SCRUM

Hlavní motivací tohoto blogu bylo podělit se o své zkušenosti v oblasti řízení projektů a lidí v SW outsourcingu a zavádění metodologií Agile (Agilní metody) a SCRUM v praxi. Softwarový outsourcing business je velmi různorodý, projekty se liší jeden od druhého jak prostředím a procesy, tak technologiemi, takže metody řízení musí být dostatečně flexibilní vzhledem k požadavkům konkrétních zákazníků.

Podle Standish Group Study více než 70% IT projektů končí neúspěchem, vezmeme-li jako kritérium úspěchu dokončení včas, v rámci budgetu a s požadovanou funkcionalitou. V rámci tohoto blogu, bych se ráda zaměřila na metodologie, které se nám v praxi osvědčily nejvíce – Agile a SCRUM. Vzhledem k poměrně malé rozšířenosti těchto metodik v rámci České Republiky je mým cílem se o své zkušenosti s Vámi podělit a touto cestou soustředit komunitu lidí zajímajících se o tyto metody.