JIRA addon Portfolio
•Download as PPTX, PDF•
0 likes•466 views
Addon Portfolio for JIRA - plánování a řízení iniciativ v rámci více týmů a projektů: - Plánování nejvyšší úrovně iniciativy a rozpad do nižších úrovní - Monitorování alokací napříč strategickými tématy - Real-time zobrazení odbavování iniciativ - Nástroje na přesné a realistické plánování kapacit - Rychlé stanovení priorit - Minimalizace ztrát produktivity
Recommended
More Related Content
What's hot
Similar to JIRA addon Portfolio
Similar to JIRA addon Portfolio (20)
More from Onlio
More from Onlio (20)
JIRA addon Portfolio
- 1. Portfolio for JIRA Prezentace pro uživatele
- 2. 2 Obsah O vývojářích Best practices: Produktový správce Vedoucí vývoje Projektový / Account manager Q & A
- 3. 3 Atlassian – založeno 2002 Vývojář aplikací pro SW inženýry a projektové manažery Objem přes 40 000 klientů, z toho 85 z Fortune 100 JIRA Software JIRA Core JIRA Service Desk Představení firmy
- 4. 4 S čím Portfolio pomáhá? Dlouhodobé plánování prací Podporuje JIRA Cloud, JIRA Server 6.x, JIRA 7 Poloviční cena pro školy, zdarma pro neziskové Vhodné pro projektové a týmové vedoucí
- 7. 7 Best practice – Produktový správce Backlog
- 8. 8 1. 2. Best practice – Produktový správce Časové odhady a milníky
- 9. 9 1. 2. Best practice – Produktový správce Týmy
- 10. 10 Dělení času: Sprinty Dělení práce: Stories Mapa milníků Best practice – Produktový správce Roadmap
- 11. 11 Best practice – Produktový správce Tip
- 12. 12 Best practice - Vedoucí vývoje (dev lead) Pracovní fáze (1/2)
- 13. 13 Best practice - Vedoucí vývoje (dev lead) Pracovní fáze (2/2) 1 2
- 14. 14 Best practice - Vedoucí vývoje (dev lead) Kanban
- 15. 15 Best practice - Vedoucí vývoje (dev lead) Kapacity
- 16. 16 Best practice - Vedoucí vývoje (dev lead) Tracking (1/2)
- 17. 17 Best practice - Vedoucí vývoje (dev lead) Tracking (2/2) Backlog Roadmap
- 18. 18 Best practice - Vedoucí vývoje (dev lead) Update plánu
- 19. 19 Best practice – Produktový správce Priority a hotové práce
- 20. 20 Best practice - Vedoucí vývoje (dev lead) Tip Iniciativa, Epic, Story
- 21. 21 Best practice – Projektový manažer Závislosti 1. 2. 3. 4.
- 22. 22 Best practice – Projektový manažer Témata
- 23. 23 Slovníček pojmů Backlog Sekce Portfolio, kde je možné vidět všechny náležitosti našeho plánu. Calculate Po nastavení hodnoty „Calculate“ u verze úlohy nám Portfolio tuto úlohu automaticky naplánuje do volného místa v nějaké verzi. Dovednosti U členů týmu si můžeme nastavit dovednosti pro lepší rozložení práce. Epic Typ úlohy, označující velký celek sjednocující podobné práce. Typ klasifikace požadavků v systému Scrum. Estimate Časový odhad určité úlohy, epicu a iniciativy. Lze ho uvádět v hodinách, dnech i story points. Fáze Práce na úlohách se může dělit do různých fází, které si lze v Portfoliu nastavit včetně jejich délky. Např. design, implementace, test… Iniciativa (Initiative) Celek prací, nacházející se o úroveň nad Epicy. Initiative > Epic > Story. Issue link Úloha v JIRA, se kterou je synchronizována virtuální úloha v plánu. Synchronizovat můžeme název, popis, a odpracovaný čas. Kanban Systém agilních metod pro vizualizaci kontinuálního pracovního procesu. People Sekce Portfolio, kde můžeme různě nastavovat členy a jejich dovednosti. Percentage Procento času, který strávíme v určité fázi práce na úloze (např. 20% Design, 50% Implementace, 30% Testing) Release Sekce portfolio nebo jiný název pro verzi – balík prací, co mají být hotovy k určitému datu. Reports Sekce Portfolio, kde vidíme poměr práce podle témat a další metriky. Scheduling Způsob rozvržení verze. Verze může být fixní (datum se nemění) nebo dynamická (obsahuje pouze úlohy, co do ní manuálně přiřadíme) Sprint Neboli Iteration je krátký časový úsek (cca. tři týdny), během kterého pracuje vývojářský tým na nových funkcích programu. Story Typ úlohy a požadavek na program, který se vejde do několika laických vět. Story point Odhad složitosti úlohy „Story“. Scrum Systém agilních metod pro vizualizaci práce, probíhající po cyklech, tzv. sprintech Synchronizace Portfolio umožňuje synchronizaci plánů s projekty, úloh s úlohami, verzí s releases a další. Téma (Theme) Nástroj, kterým si můžeme barevně kategorizovat práci podle jejího typu. Tradiční plánování Plánování mimo agilní metodiky.
Editor's Notes
- Smysl add-onu je dlouhodobé plánování práce s ohledem na všechny faktory jako jsou různé specializace, priority, kapacity, dovolené a další. Z těchto detailů vypracuje plán, který se s jakoukoli změnou přizpůsobí. Hodí se hlavně tam, kde je hodně projektů a týmů a projektový manažer se v tom chaosu snadno ztratí.
- Po krátkém představení programu se podíváme na způsoby, jak portfolio využijí různé typy vedoucích: produktový správce, dev lead neboli hlavní vývojář a nakonec projektový a account manager. Na těchto praktikách také uvidíme, jak v Portfoliu vše vystavět od základů.
- Australský vývojář Atlassian byl založen v roce 2002 v Sydney a mezi jeho nejznámější produkty patří JIRA nebo Confluence. Nyní má pobočku v Amsterdamu, v USA a v Tokyu. Společnost se zabývá zejména programy pro projektové manažery, pro vývojáře, pro vedení firemní wiki a mnohé další. Jeho nástroj JIRA lze pořídit ve třech mutacích: jedna je JIRA Software, která má do základní funkcionality JIRY zabudovanou funkci agilního vývoje v podobě add-onu JIRA Agile. Druhou je JIRA Service Desk, nástroj zákaznické podpory, který zase spojuje JIRA s add-onem Service desk. Atlassian vydává i samostatné add-ony jako Portfolio for JIRA, o kterém je tato prezentace, nebo JIRA Capture, která se používá v testingovém prostředí.
- Jak už jsem zmiňoval, JIRA Portfolio je add-on k automatickému plánování dlouhodobých prací s ohledem na všechny detaily a podmínky. Vznikl proto, aby si vedoucí vypočítal a vytvořil rozvrh celofiremní práce, podle kterého se pak bude řídit. Zbavuje vedoucího nejistého experimentování s plánem a vytváří prostor pro výpadky: když třeba někdo onemocní, hned uvidíte upravený postup. Add-on je určen hlavně projektovým nebo produktovým manažerům, kterým už nestačí základní plánování v JIRA, ale potřebují dlouhodobý, ale flexibilní plán.
- Plány jsou základní jednotkou Portfolio – jeden náš plán pod sebe zahrne procesy v celé firmě. Ze všeho nejdřív si tedy musíme vytvořit plán, kde budeme vše sledovat. Portfolio nám při tvorbě nového plánu nabídne několik šablon: pro agilní plánování (scrum, kanban) nebo tradiční plánování formou waterfall. Tyto šablony obsahují určité předvolby, např. plánování ve story points nebo určité fáze práce. Můžeme také vytvořit plán bez předvoleb nebo s vzorovými daty.
- Než se pustíme do další práce s plánem, je třeba definovat několik termínů, se kterými Portfolio pracuje. Addon klade úlohy do třech úrovní. Nejvyšší jsou iniciativy, velké pracovní celky, které pod sebou mají několik epiců. Mohou to být např. klienti nebo velké zakázky. Pod nimi jsou Epicy, balíčky tématicky podobných úkolů, např. „Design webu“, „Animace“ a pod nimi jsou stories – jednotlivé pracovní úkony a úlohy. Vedle toho Portfolio pracuje s Tématy. To jsou barevná označení oblastí práce firmy: mobilní aplikace, webdesign a podobně.
- Podívejme se nejprve na práci produktového správce, který bude chtít mít 1) přehled veškeré práce a 2) produktovou mapu. Po vytvoření plánu musíme nejprve zaplnit backlog: seznam úloh, ze kterých pak bude plán. Obrázek už obsahuje několik Iniciativ (nejvíce vlevo) – červené, tyto pod sebou mají epicy – zelené, a tyto epicy mají pod sebou úlohy (modré). Čísla vlevo od epiců (1 až 5) označují priority – jaký epic se musí plnit co nejdříve. My ale před sebou budeme mít prázdný plán: zaplnit ho můžeme manuálně nebo importem existujících úloh z JIRA. Důležité je, že pracovní úkony, co jsou v backlogu, totiž nejsou JIRA úlohy – dokud je s nimi nespojíme.
- Pak chceme vytvořit projektovou mapu. Pro tu potřebujeme tři věci: Seznam prací – to jsou úlohy v backlogu. Musíme jim ještě zadat trvání (estimate) – stačí kliknout a zadat do políčka. Můžeme plánovat na celou úlohu nebo na jednotlivé její fáze, o nichž si řekneme dál. Hodiny se sčítají nahoru do epiců a iniciativ. Zadat milníky s daty dokončení. Milníky se řadí pod tzv. streamy, pod jimiž si představíme např. jednotlivé produkty. Příklad: Stream je náš add-on Faraway a milníky jsou jeho verze 1.0, 1.5. K každému úkonu můžeme zařadit milník manuálně (obrázek) nebo portfolio nechat práci rozdělit do milníků automaticky. Milníky mohou být fixní (s začátkem a koncem) nebo dynamické (čím víc toho do verze dáme, o to se release date posune dál). Ke každému streamu lze také přiřadit týmy, které na něm budou pracovat.
- A zatřetí je třeba zadat zaměstnance, kteří na našich úkolech budou pracovat. Vytvoříme si tým, přiřadíme do něj uživatele JIRA a napíšeme, kolik hodin týdně pracují a jakým způsobem – jestli scrumově nebo kanbanově.
- A když tohle máme, vznikne v dolním panelu projektová mapa. Můžeme si v ní naše práce zobrazit mnoha způsoby - po týmech, po členech; milnících nebo sprintech; iniciativách, epicech i po stories. Tady vidíme mapu časově dělenou po sprintech a pracovně po jednotlivých stories. Níže je na projektové mapě zobrazená mapa milníků, kdy začínají a končí. Když se změní nějaký údaj, zásadní pro plánování, třeba časový odhad úkolu, Portfolio for JIRA zobrazí tlačítko Recalculate a počet změn. Když na něj klikneme, tak se vzhledem k těmto změnám celý plán upraví. Toto si můžeme zapnout automaticky (tedy bez klikání na recalculate) nebo manuální.
- Část o produktovém správci bych zakončil jednou specialitou: když si nastavujeme kapacity pracovníků, lze využít ještě dvou přihrádek: General availability a Availability in team. V první z nich máme tlačítko „Add limited presence“, které využijeme, když má pracovník neobvyklý pracovní rozvrh, např. pracuje na částečný úvazek. Sem zapíšeme dny, co nepracuje. Nebo pokud je ve firmě třeba na měsíc na stáži. Tlačítkem add absence přidáme období dovolené, ve kterém se na toho člověka neplánuje. Availability in team značí počet hodin, které pracovník dělá v různých týmech: pokud ve firmě pracuje 40 hodin a chceme jeho práci dělit, tak můžeme např. v Týmu 1 dát 20 hodin, v Týmu 2 10 hodin a v Týmu 3 také 10. A opět sem zde zadávat různé absence a výjímky.
- Projekt postupuje dál: produktový správce vymyslel roadmap a teď ji předal vedoucímu vývoje. Vedoucí vývoje potřebuje vědět, kolik má kdo ještě kapacit a co se ještě dá a co už nedá stihnout. Taky potřebuje informovat nadřízené o tom, jak se projektu daří. Pojďme na to. V první řadě musíme znát fáze, kterými úkony prochází. Na obrázku je základní rozdělení: Počítáme se scrumem, kde v první fázi produktový vlastník napíše story – co je třeba udělat – a v druhé fázi to zpracují vývojáři, kteří mají patřičné technické dovednosti. Fáze na sebe bezprostředně navazují a každá trvá určitou část odhadovaného času na story; v příkladu máme 25% na design (nebo story writing) a 75% na implementaci. Těchto fází může být libovolný počet a mohou být libovolně rozdělené.
- V každé fázi dělá na úkonu někdo jiný: například manažer neumí kódovat. Ke každému členovi týmu si přiřadíme jeho dovednosti. Smyslem je, aby se nestalo, že budeme prioritně potřebovat našeho jediného kodéra, aby projekt šel dál, ale ten už by dělal něco, co za něj svedou další tři lidé. Dělbu vidíme na prvním obrázku: Product owner umí story writing a implementaci, ale nikdo jiný za něj story nenapíše: všichni ostatní dělají jen implementace. V reálu vývojáři sice také neumí každý všechno - někdo píše, někdo testuje – a jde to i tak, že bychom měli pět, deset dovedností. Pro zjednodušení jsem zvolil ale jen dva typy dovedností: psaní úloh a technické práce. Na mapě projektu (2) potom vidíme barevně rozlišené fáze, kde story writing vždy předchází implementaci (vyznačeno červeně).
- Tohle je zase příklad Kanbanu. V horní části obrázku vidíme dost rozdrobené dovednosti do tří fází. Dole máme projektovou mapu po členech. Všimněme si, že protože nemáme sprinty, práce rovnou navazuje. Portfolio hledá: ok, tehdy a tehdy skončí design úlohy. Je dostupný někdo s dovednostmi z fázi implementace? Přířadí je a tak to dál navazuje. Cílem je vždy dokončit jednu úlohu, než se Portfolio vrhne na další.
- Druhá věc je, aby vedoucí vývoje viděl kapacity zaměstnanců. U projektové mapy vidíte tabulku nahoře. Přepínáme si v ní různé typy zobrazení mapy, o tom si povíme za chvíli, teď nás zajímá jen tlačítko poslední, kapacitní. Po jeho vybrání uvidíme využité a volné kapacity všech pracovníků. V příkladu je zobrazení kapacit celého týmu po sprintech. Světlezelená jsou volné kapacity a tmavozelená využité (120). Kanban zobrazí kapacity po týdnech a můžeme si je prohlížet jak po týmech, tak po pracovnících.
- No a chceme také vidět, jak se vůbec úlohám daří, jak se plní. To uvidíme v backlogu. Ale jak se portfolio dozví, jak na tom úlohy jsou? Propojením s JIRA. V obrázku vidíte export dosud virtuálních položek v našem backlogu na JIRA úlohy v projektu. Opět nám Portfolio nabízí spoustu možností, jako jestli chceme v úlohách nechat estimate, jestli chceme číslo milníku v Portfolio nastavit jako pole „Fix version“v JIRA a podobně.
- No a jakmile začneme na těchto úlohách logovat čas, v backlogu se nám zobrazí vpravo klasické „Cigáro“ – zelené je kolik je odpracováno a bílé kolik ještě chybí. Na mapě uvidíme něco podobného. Zobrazení na slidu je opět po sprintech a po jednotlivých stories.
- Ale pozor: Portfolio se s hodinami v JIRA automaticky nesynchronizuje. Že tu takové výkazy jsou musíme Portfoliu oznámit. To uděláme, když nastavení plánu vybereme „Update from date“. Potom vybereme datum, ke kterému se Portfolio aktualizuje. To znamená, že všechny hodiny, co si pracovníci vykázali do JIRA před tímto datem se automaticky odpočítají od „Estimate“ v Portfolio. Příklad: Měli jsme úkol s estimate 60 hodin a v JIŘE na něm vykázali 20. Po updatu nám Portfolio ukáže nový estimate 40 hodin. Atlassian doporučuje aktualizovat scrum k začátku nového sprintu a v kanbanu třeba každé ráno. Tabulka vpravo nám ukazuje nový stav backlogu, kde jsou modře zvýrazněné položky, kterým se změnil estimate – nebo které jsou dokonce hotovy. Předtím, než tuto novou podobu backlogu odsouhlasíme, si můžeme nové údaje manuálně změnit – třeba zvýšit hodinovou dotaci na úkolu, na kterém se ještě bude pracovat. Kdyby nás pro srovnání zajímal původní estimate, který úkoly měly ještě než na nich začaly práce, zapneme si v Portfoliu sloupec Original estimate.
- S jednotlivými úkoly samozřejmě můžeme dělat spoustu věcí. Kromě vytváření JIRA úloh z úkolů v backlogu můžeme také měnit prioritu jednotlivých epiců, což portfoliu naznačí, co by mělo začít plánovat dřív a co později. To děláme metodou drag and drop. No a když chceme úkoly vyřadit, buď je smažeme nebo dáme „mark complete“ v detailech. Tehdy se jeho estimate srazí na 0 a plánovací algoritmus už s tímto úkolem nebude pracovat.
- Když jsme se dostávali na kapacity, pracovali jsme s tabulkou v pravém dolním rohu Portfolio. Tu vidíme většinu času a lze si na ní různě měnit zobrazení projektové mapy. První položka s kuličkami zobrazí pouze jednoduchou řadu milníků, kdy by měly být splněny a kdy reálně budou splněny. Druhá položka zobrazí rozepsané všechny milníky a sprinty. Kolik je na ně plánováno hodin? Kolik je ještě volných kapacit? A tak dále. Třetí, čtvrtá a pátá položka zobrazí projektovou mapu po iniciativách, po epicech a po stories. A poslední položka zobrazí kapacity. Portfolio ale může jít ještě do většího detailu – možností je spousta.
- Třetí a poslední funkce, na kterém si předvedeme JIRA Portfolio, je projektový manažer. Pro něj portfolio hlídá deadliny a jestli vše postupuje podle plánu včetně závislostí mezi úlohami. První krok spočívá v tvorbě backlogu, zadání časových odhadů prací, sledování odpracované práce a tvorba milníků. To jsme si představili dříve, tak přejdu rovnou k závislostem mezi pracemi. Závislost si vytvoříme tím, že u úkonu zaškrtneme details, v okně se závislostmi vybereme editaci. Dostaneme se na seznam úkolů, na kterých – nebo ze kterých – lze závislost vytvořit. Vybereme si úkol, typ závislosti – a zadáme „recalculate“. V projektové mapě úlohy, které jsou na sobě závislé, mají světlejší „ouška“. Kliknutím na ně uvidíme, jak jsou propojené.
- No a hlavní projektový manažer zase využije pomůcku pro mapování oblastí firemních aktivit. Je to funkce „Themes“, témat. Pod nimi si můžeme představit oblasti, ve kterých firma podniká. Každé téma má svou barvu, a podle ní každý úkol v backlogu obarvíme. Témata jsou k tomu, aby bylo jasné, kde strávíme nejvíce času a jaký poměr našich zaměstnanců kde pracuje. Každé story může mít jedno téma. Epicy pak mohou mít víc, podle stories pod nimi. Dole vidíme koláče, kde vidíme, jak se dělí témata: buď "Target" (Jaké chce mít firma rozdělení), "Estimate" (Poměr úkolů v backlogu) a "Actual" (již zalogovanou práci v hodinách v JIRA). Můžeme si dokonce filtrovat, odkud chceme data v koláčích Estimate a Actual získat, třeba jen z jednoho milníku, nebo jen z práce jednoho týmu.
- Slovníček aplikace Portfolio.
- Pro shrnutí JIRA Portfolio umožňuje automaticky plánovat bez ohledu na rozsah projektů ale s ohledem na všechny faktory a pomůže i s experimentování s plánem, aby nám poté v praxi fungoval a neúspěšné pokusy nás moc nestály. Q + A.