V prvním článku ze série Agilita pomocí Atlassian produktů jsme popsali, co to znamená vyvíjet software podle principů agility. Principy jsme následně rozdělili do tří oblastí, ve kterých mohou Atlassian nástroje pomoci, a na které se v této sérii postupně podíváme.

• Plánování a vyhodnocení.
• Vývoj a doručení.
• Spolupráce.

V dnešním článku se zaměříme na oblast plánování a vyhodnocení požadavků.

Principy Agility při plánování a vyhodnocení

Připomeňme si, že mezi principy agility ze skupiny plánování a vyhodnocení požadavků jsme zařadili následující:

1. Umět jednoduše maximalizovat množství nevykonané práce je klíčové.
2. Vítáme změny v požadavcích vedoucí ke zvýšení konkurenceschopnosti zákazníka, a to i v pozdějších fázích vývoje.
3. Hlavním měřítkem pokroku je fungující software.
4. Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a přizpůsobuje tomu své chování a zvyklosti.
   

Zatímco maximalizace množství nevykonané práce a podpora změn souvisí s plánováním požadavků, fungující software jako měřítko pokroku a pravidelné zamýšlení se nad efektivitou je věcí vyhodnocování požadavků. Pojďme se postupně na tato témata z hlediska Atlassian nástrojů a ve světle zmíněných principů podívat.

Plánování požadavků

Abychom maximalizovali množství nevykonané práce, je potřeba si dobře uvědomit, které požadavky na výsledný produkt jsou nezbytné pro naplnění jeho očekávaného přínosu, a které nikoli (např. při tvorbě nového produktu jde o specifikaci MVP – Minimum Viable Product). K tomuto účelu dobře poslouží nástroje, které dokáží požadavky vizualizovat tak, aby bylo možné jejich význam snadno posoudit a zařadit je do plánu vývoje dle potřeby.

Pro podporu změn je zase třeba, aby nástroje umožňovaly jednoduché a rychlé přidávání či odebírání požadavků i v průběhu vývoje. Všechna následující doporučení tyto potřeby reflektují.

Sběr požadavků

Aby bylo vůbec možné vývoj plánovat, je třeba nejdříve posbírat všechny požadavky. Pro sběr požadavků dobře poslouží samotná Jira. Lze využít jak Jira Software, tak Jira Service Desk, pokud je cílem umožnit zadávání požadavků i uživatelům, kteří nemají přiřazenou Jira licenci.

V závislosti na velikosti týmu, definovaném procesu a rozsahu projektu lze přistoupit k dvěma nejběžnějším řešením:

1. Požadavky je možné sbírat přímo v rámci Jira projektu, ve kterém je tým případně také rovnou zapracuje. To je typické pro malý projektový či produktový tým.
2. V případě sběru požadavků napříč celou organizací (např. jako součást Demand managementu, Idea managementu, či tvorby celofiremní roadmapy) je možné využít samostatný Jira projekt, ve kterém jsou požadavky nejdříve zhodnoceny, teprve pak roztříděny a zařazeny k dalšímu zpracování jednotlivým týmům.

Ať už jsou požadavky sbírány ve vývojovém, nebo samostatném Jira projektu, díky vlastním definovaným atributům (custom fields) navíc zajistíte, že budou k dispozici všechny potřebné informace pro evaluaci požadavku a jeho další zpracování.

Schválení požadavků

Posbírané požadavky je následně třeba zhodnotit a rozhodnout se, zda mají být zařazeny do plánu, nebo ne. To typicky vyžaduje bližší popis požadavku, hrubý odhad pracnosti, vyhodnocení jeho přínosu, příp. provedení dopadových analýz či studie proveditelnosti. Podklady potřebné pro všechny zmíněné činnosti lze dobře evidovat v podobě atributů u jednotlivých Jira issues. Podrobný popis pak může být vypracován v podobě delšího textu na provázané Confluence stránce. Pomocí dalších návazných Jira issues lze přiřazovat jednotlivé úkoly různým členům týmu, kteří dodají informace potřebné k rozhodnutí o daném požadavku.

Pro samotné schválení je pak možné využít workflow požadavku. V případě Jira Service Desk je navíc k dispozici nativní funkcionalita, která umožňuje jednoduše definovat schválení v konkrétním stavu workflow.

Plánování a sledování průběhu požadavků

Plánování požadavků může probíhat na více úrovních. Podívejme se na dvě základní – plánování v rámci jednoho týmu a plánování napříč organizací.

Plánování v týmu

Plánování požadavků pro samostatný tým nemusí být složité a můžeme si vystačit pouze s Jira Core. Díky základní funkcionalitě filtrů zobrazených pomocí dashboardů můžeme vytvořit jednoduchý pohled na aktuální úkoly všech členů týmu, na vyřešené úkoly za určité období, či na zatím nepřiřazené úkoly. Pro základní přehled to může být dostatečné, pro sofistikovanější přípravu plánu a sledování jeho plnění je ale vhodné se poohlédnout dále. Jira Software rozšiřuje základní funkcionalitu podporující vývoj software dle metodik SCRUM a Kanban. Jira Software přidává tzv. agilní boardy jako je Backlog, kde je možné požadavky prioritizovat, přidávat jim odhady, případně je řadit do nadcházejících sprintů. SCRUM board následně zobrazuje stav jednotlivých požadavků zařazených v aktivním sprintu a vytváří tak pohled na aktuální průběh sprintu.

Plánování v organizaci

Zatímco při plánování požadavků pro samostatný tým si často vystačíme se základními funkcionalitami Jira Core či Jira Software, v případě plánování na vyšší úrovni (napříč více agilními týmy nebo celou organizací) již začneme narážet na některá omezení. Mezi ty nejpalčivější patří chybějící možnost vytvoření závislostí mezi požadavky napříč týmy, absence grafického znázornění plánu požadavků v časové ose či nemožnost sledování alokovaných a dostupných kapacit týmů a jejich členů.

Vývoj software dle principů agility na úrovni velké organizace je rozsáhlé téma samo o sobě a v budoucnu se k němu určitě vrátíme. Pojďme se ale zatím podívat na nástroje, které doplňují výše zmíněné chybějící funkcionality Jira, a které prakticky podpoří plánování a sledování stavu požadavků napříč organizací. Mezi nejčastěji používané patří:

• Advanced Roadmaps for Jira (dříve Portfolio for Jira) [Atlassian],
• BigPicture – Project Management & PPM [SoftwarePlant],
• Structure – Project Management at Scale a Structure.Gantt [ALM Works],
• EasyAgile (Roadmaps, User Story Map, Programs) [EasyAgile],
• CycleControl [Botron Atlassian Apps (an Appfire company)],
• Aha! roadmaps for Jira [Aha! Labs Inc].

Uvedené nástroje pracují na principu rozšíření hierarchie požadavků (ať už pevně dané, nebo uživatelem definované). To umožňuje seskupovat požadavky do větších celků (iniciativ), projekty do programů a programy do portfolií. Požadavkům lze typicky nastavit další sadu atributů souvisejících s plánem, jako je předpokládaný začátek a konec, závislost na jiných požadavcích apod. Požadavky lze také přiřazovat týmům (na rozdíl od Jira issues, které lze přiřadit pouze konkrétnímu uživateli) a sledovat jejich vytíženost. Na základě těchto informací lze jednotlivé úrovně vizualizovat na časové ose. Tím vzniká grafická reprezentace plánu, který tak lze jednodušeji přizpůsobovat časovým a kapacitním možnostem týmu.

Všechny zmíněné nástroje nemusí sloužit jen pro plánování, ale také pro real-time sledování stavu požadavků (za předpokladu, že mají k dispozici aktuální data z odpovídajících issues). Díky možnosti sledování stavu na všech úrovních (od jednotlivých požadavků po portfolio) představují uvedené nástroje jednotný „zdroj pravdy“ o stavu projektů – nejen pro vývojový tým, ale také pro celou organizaci.

Vyhodnocení požadavků

Pro pravidelné vyhodnocování efektivity týmu a následnou korekci zvyklostí slouží jedna z nejdůležitějších agilních ceremonií – retrospektiva. Kromě vstupů od členů týmu lze v rámci retrospektivy využít pro vyhodnocení efektivity i tvrdá data získaná z různých reportů. Na základě reportů a zpětné vazby od zákazníka lze rovněž měřit, nakolik je dodaný software funkční.

Pro tyto typy činností je od podpůrných nástrojů vyžadována zejména možnost tvorby přehledných reportů s relevantními daty. Nástroje však také mohou vytvořením vhodného prostoru podpořit sběr informací od členů týmu a uživatelů.

Reporty

Kromě základního přehledu požadavků vytvářených pomocí issues filtrů a JQL (Jira Query Language) a jejich zobrazení na dashboardu nabízí Jira i vlastní sadu reportů nad issues, které pomáhají dokreslit obrázek o stavu projektu. Jira Software dále doplňuje tuto sadu o další agilní reporty. Jde například o burndown chart, sprint report, či velocity chart, tedy reporty primárně související s metodikou SCRUM, o kterou se Jira Software opírá. Díky těmto reportům můžete na pravidelné bázi sledovat výkonnost týmu a přizpůsobovat další iterace/sprinty tak, aby tým jako celek dosáhl vyšší efektivity.

V případě vývoje napříč více týmy lze pro pravidelné vyhodnocení kombinovat Jira agilní reporty s reporty dalších nástrojů, které dodávají obdobné přehledy, ale na vyšší úrovni. Pro přípravu komplexních reportů lze využít některou z aplikací na Atlassian marketplace zaměřenou čistě na reporting. Mezi ty nejznámější patří eazyBI Reports and Charts for Jira [eazyBI] a AIO Reports and Timesheets for Jira [Navarambh Software Pvt. Ltd.]. Při zohlednění výstupů z těchto reportů je docíleno vyšší efektivity nejen samostatného týmu, ale také organizace jako celku.

Šikovnou vlastností některých nástrojů pro portfolio management (např. Advanced Roadmaps, BigPicture) je sdílení reportů uživatelům bez přístupu k Jira. Toho je možné dosáhnout buď pomocí odkazu vedoucího na stránku s vygenerovaným reportem, nebo zobrazením pomocí makra přímo na stránce v Confluence. Takto lze dobře sdílet přehled o stavu projektu i uživatelům, kteří běžně s Jira nepracují (např. business týmy či top management ve velkých korporacích).

Retrospektiva a zpětná vazba

Pro přípravu zpětné vazby si běžně vystačíte s výchozími funkcemi Jira či Confluence. Předem připravené Jira issue může sloužit jako upomínka pro přípravu zpětné vazby. Díky funkci automatizace, která je dostupná již v základní verzi Jira Cloud, je možné issue nechat generovat na pravidelné bázi a zajistit si tak průběžnou zpětnou vazbu. V rámci daného issue pak může zároveň být připravena struktura informací, které chceme v rámci zpětné vazby sbírat. Pro automatizaci v serverové verzi Jira je třeba využít některou z aplikací na Atlassian Marketplace. Oblíbenými aplikacemi jsou např.

• ScriptRunner [Adaptavist]
• JSU Automation Suite for Jira Workflows [Beecom Atlassian Apps (an Appfire company)]

Pro záznam zpětné vazby lze využít také Confluence, kde lze požadovaný obsah generovat pomocí blueprints šablon.

Pro přípravu a moderování retrospektivy pak doporučujeme aplikaci Agile Retrospectives for Confluence [Nearsoft Inc]. Ta umožňuje v rámci jedné Confluence stránky nechat sepsat přípravu celého týmu tak, aby se jednotliví členové navzájem neovlivňovali (vidí jen svoje poznámky). Moderátor pak může body seskupit a zpřístupnit všem členům týmu, kteří provedou nad seskupenými body hlasování. Jako výstup z retrospektivy lze pak ke každému bodu vytvořit rovnou návazný akční bod.

Stejná aplikace je dostupná také pro Jira, vizte Agile Retrospectives for Jira [Nearsoft Inc].

Na co se můžete těšit příště

Článek stručně nastiňuje možnosti využití Atlassian nástrojů a doplňujících aplikací při plánování a vyhodnocování požadavků jak na úrovni jednoho týmu, tak na úrovni celé organizace. Každé ze zmíněných témat je ale poměrně komplexní a situace každé organizace vyžaduje individuální posouzení, se kterým pomůže např. certifikovaný Atlassian Solution Architect.

V příštím příspěvku se podobnou optikou podíváme na nástrojovou podporu v Atlassian světě v dalších oblastech vývoje software dle agilních principů.

Miroslav Suchopar

Atlassian Solution Architect

Mirek se jakožto bývalý IT projektový manažer věnuje primárně oblasti řízení projektů a portfolia. Navrhuje a implementuje související procesy pomocí Atlassian nástrojů s důrazem na efektivitu a uživatelskou přívětivost. V poslední době se zaměřuje zejména na oblast řízení projektů dle principů agility.

miroslav.suchopar@morosystems.cz