Jak vytvořit co nejlepší workflow - část 2.

27.01.2016 |  Praktické ukázky z tvorby

 

Vítejte v druhém článku o workflow v JIRA. Pokud jste nečetli první díl, doporučujeme vám začít s ním - tento příspěvek navazuje na v něm zmíněné pojmy praktickými ukázkami.

 

Mnoho každodenních prací probíhá cyklicky. Knihovna půjčuje knihy, dokud jsou v dobrém stavu, a pak dojde k jejich odpisu. Bugy v programu jsou zapsány, zkontrolovány, opraveny, testovány a uzavřeny. Pokaždé workflow pomůže nějak jinak; zopakujme si jeho čtyři hlavní části:

 

  • Stav (status) – Kde
  • Řešitel (assignee) – Kdo
  • Řešení (resolution) – Proč
  • Přechod (transition) – Jak

 

Jak vytvořit vlastní stav

 

Každý stav odráží jinou fázi životního cyklu úlohy. Nástěnka v JIRA Agile to ukazuje ve velkém.

 

 

Úkoly jsou roztřízené do sloupců po stavech a workflow je zde ústřední prvek. V každém sloupci si můžete nastavit maximální počet úloh, aby nevznikaly nepřeberné kopce práce. Jeden sloupec také může odpovídat více stavům: pokud např. tabulku ukážete kolegům nevývojářům, úkoly ve stavu in progresscode review uvidí oboje ve sloupci „In Progress“.

 

V miniaplikaci „Two dimensional filter“ si můžete vytvořit např. přehled stavů a jejich priorit. Status vložíte na osu X, prioritu na osu Y a zaškrtnete „Show totals – Yes“. Vznikne přehledná tabulka a kliknutím na nějaké číslo se zobrazí všechny úkoly, kterých se cifra týká.

 

Nastavení miniaplikace

 

Výsledek

 

Jak si nastavit a používat pole „Assignee“

 

Smyslem workflow je usnadnit spolupráci. Nepoužíváte-li v JIRA profilová fota, doporučujeme! Více o tom píše tento článek. V miniaplikaci "Two dimensional filter" si můžete i zobrazit, kdo dělá na čem, když na osu Y umístíte „Assignee“. To se hodí, pokud vás např. zajímá, kolik má který zaměstnanec kritických úloh.

 

 

Kdy je úkol skutečně hotov?

 

Každý workflow má „bod obratu“, radikální změnu v úloze - v knihovně to je vyřazení díla. V SW vývoji programátor dokončí kód, zadá úlohu jako vyřešenou, a kód jde ke kontrole. Ale to, že má požadavek řešení, ještě neznamená konec práce: úloha, která má "resolution", není hotová. Knihu sice vyřadíme, protože je poškozená, ovšem může zůstat ve stavu čekání na náhradu (order pending), než přijde náhradní.

 

Knihovní workflow

 

Modře zvýrazněný přechod přesune knihu do stavu, v němž čeká na náhradu. Až přijde náhradní kniha, vznikne i nová úloha. Když vývojář opraví bug, zadá, že je „opravený“ a předá ho k testu – úloha je ale stále otevřená a ve stavu “resolved”. Jakmile jsou testy dokončeny, až pak lze bug uzavřít.

A opět, gadget „Two dimensional filter“ vám zobrazí jak typy řešení, tak kolik úloh je vyřešeno, ale neuzavřeno.

 

S čím ještě přechody (transitions) pomohou?

 

Z prvního článku víte, že přechody provádí zásadní změny. JQL (JIRA’s query language) vám vyfiltruje, jak k nim došlo, např. kolik úloh neprošlo poslední měsíc testy. Zadejte si toto do vyhledávání v JIRA:

 

1
2

Project = TIS AND STATUS changed FROM „Quality Review“ TO „In Progress"
after -4w

 

Nebo: Kolik chyb bylo za poslední měsíc vyřešeno, ale nemají řešení "opraveno" ("fixed")?

 

1
2

project = TIS AND STATUS changed TO Resolved after -4w AND
resolution NOT IN (Fixed)

 

Nebo: Kolik úloh vytvořili lidé mimo určitou skupinu? To zjistíte funkcí membersof(). Pokynem níže se podíváte, kolik požadavků zadali členové mimo tým „product-engineering“.

 

1
2

project = TIS AND reporter NOT IN membersof(product-engineering)
AND created > -4w

 

Znalost o tom, kolik a jakých přechodů bylo vykonáno, může zlepšit váš workflow. Máte-li v určitém stavu až příliš úloh, ptejte se:

 

  • Jsou všechny úlohy, které přijdou do tohoto stavu, jednoznačně definované?
  • Kolik požadavků v tomto stavu se vrací do stavu předchozího?
  • Jak dlouho zde issues zůstávají? Je to tak úmyslně?
  • Proč se úlohy do tohoto stavu vrací?

 

A to vše zjistíte v JQL vyhledávání.

 

Workflow graf

 

JIRA Agile poskytuje „Cumulative flow diagram“, mapující počet úkolů po stavech. Vypadá takto:

 

 

Ukazuje vám, jak se časem mění množství úloh po stavech. Když je jeden stav plný, jiný je často vyprázdněný. V ukázce je stav „In progress“ modrý a úlohy, čekající na testy, jsou fialové. Mezi 15. a 21. 4. narostlo množství požadavků pro testery – může to znamenat, že tým úlohy dost netestuje, někdo je na dovolené nebo práce trvají déle, než se čekalo. Pravidelnými kontrolami tohoto grafu zjistíte, kde má vaše oddělení ještě rezervy.

 

Ať workflow pracuje pro vás – ne vy pro něj

 

Největší výhodou workflow je, že zpřehlední vaši spolupráci a neobětujete přitom své pracovní postupy. Heslo agilního vývoje praví: použijte místo, kde jste, jako základ, definujte si jasné metriky, zaznamenejte si výsledky a jejích pomocí se přizpůsobte.

Podívejte se také na prezentaci plnou zajímavých infografů.

 

Pozn. (Kamil Beer) – článek je z roku 2013, kdy měla JIRA jednu verzi (nikoli Software, Core, Service Desk)

Zdroj: http://blogs.atlassian.com/2013/10/using-workflow-awesome/

 

Pro lokální podporu neváhejte kontaktovat odborníky na produkty Atlassian ve společnosti Onlio.

Pro další informace o novinkách Atlassian a JIRA sledujte web www.myJIRA.cz.

Jsme na LinkedIn – sledujte nás www.linkedin.com/company/onlio nebo skupinu Atlassian komunita CZ & SK na url https://goo.gl/uZXYTX.

V případě dotazů se obraťte na obchod_zavináč_onlio.com nebo

na tel. ČR +420222744766 / tel. SR +421233889033 / atlassian_zavináč_onlio.com.

 

 

Za team Atlassian v Onlio,

Kamil Beer,

JIRA Consultant

 

 

Zpět