Redmine: Stručný život tiketu

Tiket, task, úkol, issue. Stejné označení pro jednu věc – zadání minimálního úkolu k řešení. Aby mohlo efektivně dojít k jeho vyřešení, měl by mít nějaké minimální a optimální vlastnosti. Mezi ty minimální řadím parametry SMART. V případě softwaru, jako je Redmine, má ale ještě další vlastnosti.

Standardní vlastnosti úkolu v systému Redmine

Redmine používá ve výchozím nastavení několik parametrů, které slouží jednak k přesnějšímu zadání úkolu a k předání (uchování) potřebných informací ve struktuře (tj. nikoliv pouze popisem) a jednak ke kategorizaci úkolu pro potřeby pozdějšího vyhodnocování a archivace. Budu konkrétní.

Fronta

redmine-ukol-frontaJedná se o řadu úkolů stejného typu, patřících do jedné řady. Odlišení mezi frontami spočívá v charakteru úkolu. Já například používám tyto fronty:

  • Obecný požadavek – jakýkoliv úkol, požadované řešení je v něm popsáno.
  • Hlášení chyby – hlášení chyby v našem programu (např. EviKonu), na webové stránce, řešením má být oprava chyby.
  • Zpracovat článek – výstupem má být napsaný článek.
  • Instalace – zadání k instalaci třeba WordPressu na doménu, výstupem je funkční instalace.

Fronty lze přidávat pro všechny, nebo jen vybrané projekty.

Předmět

Stručné zadání úkolu. Musí z něj být jasné, co je samotným úkolem. Dle mého je ideální používat akční slovesa a naopak špatné je používání podstatných jmen. Příklady:

Chyba fotogalerie
Ve fotogalerii se nezobrazuje obrázek, opravit nastavení pluginu

Jsem toho názoru, že předmět by měl popisovat cíl, kterého chci jako zadavatel dosáhnout, nikoliv jen stav. Popis stavu používám v případě, kdy neznám řešení a zcela ho očekávám od řešitele. Jde sice o popis stavu, ale reálně vzato není jasné, jestli popisujeme stav chybný (současný), nebo stav budoucí (žádoucí). Proto pomocí sloves ten čas popíšu. Obvykle. Srovnejte:

Opravit detail fotogalerie na střední velikost, nyní malá
Moc malý náhled fotogalerie

V různých přehledech úkolů jsou vidět jen názvy tiketů, nikoliv jejich obsah, mělo by tedy být jasné, o co jde. Vzhledem k tomu, že tikety jsou organizované v rámci projektu, nemá smysl do předmětu uvádět jméno projektu znovu. Vždycky jde ve výpisu zobrazit nějakým polem – o tom další článek.

Popis

Pole s editorem, kam se vkládá zadání úkolu a kontextové informace včetně příloh (obrázky, dokumenty). Tady je vhodné se rozepsat, je možné používat formátování, seznamy a další členění.

redmine-ukol-prilohy

Stav

Klíčová věc celého systému, stav, ve kterém se úkol právě nachází. Reálnost je rozhodující pro správné řízení projektů a organizaci času (nejen lidí v týmu – z pozice vedoucího projektu, ale i vlastní – z pozice každého člověka). Stav se přepíná ručně a má standardně šest možných fází (lze změnit). Jejich posloupnost (workflow) se dá nastavit v matici s ohledem na fronty, uživatelské role a další parametry. Základní flow tedy vypadá – stručně lineárně – takto:

  • Nový – tiket byl vytvořen a přidělen uživateli (viz dále parametr Přiřazeno) k vyřešení.
  • V řešení – na tiketu jeho řešitel pracuje.
  • Provedený – řešitel práci ukončil, předal tiket zpět zadávajícímu jako vyřešený.
  • Uzavřený – zadávající ověřil správnost provedení a tiket uzavřel jako vyřešený, nyní v archivu.
  • Čeká se – jedna větev z různých stavů – řešitel na tiketu nepracuje, ale práci plánuje nebo čeká na jiné vstupní informace.
  • Odmítnutý – řešitel tiket z nějakého důvod odmítá, nebo zadavatel tiket ruší.

Tento postup jsem si stanovil já ve svém systému, osvědčil se mi, ale není to pochopitelně svatá kráva. Lze to vymyslet jinak.

Typický (ideální) cyklus bývá: Nový – V řešení – Provedený – Uzavřený
Ale klidně to může být taky: Nový – Čeká se – Odmítnutý – V řešení – Provedený – V řešení – Provedený – Uzavřený (neuvádím zde lidi, ale střídá se zadavatel a nějaký řešitel).

redmine-novy-ukol

Priorita

Sám mám někdy problém rozlišit mezi prioritou a uzávěrkou. Stručně řečeno – priorita je důležitost (a naléhavost) úkolu, uzávěrka je množství času, které mám na jeho splnění. Nejzazší bod ukončení. Vznikají tady problémy při zadávání i přijímání tiketů:

  • Potřebuji, aby byl tento úkol vyřešen nejpozději zítra – mám dát vysokou prioritu, nebo stačí uzávěrka?
  • Mám zadáno více úkolů a některé mají uzávěrku zítra a některé mají vysokou prioritu. Které mám řešit jako první?

Osobně to chápu tak, že uzávěrka je nezbytný parametr úkolu podle metodiky SMART. Úkol bez uzávěrky není úkol, je defektní. Oproti tomu priorita – hlavně ta vyšší – je snaha o získání více prostředků a je to nástroj výjimečný. Všechny úkoly mají běžně stejnou prioritu, řekněme střední. Zvýšenou prioritu dostávají pouze výjimečné situace jako havárie nebo neočekávané situace, u nichž je uzávěrka v řádu hodin (takže de facto ztrácí smysl).

Občas používám prioritu, abych upozornil na úkol, který není řešen s ohledem na uzávěrku. Priorita totiž svítí červeně. 🙂

Začátek

Začátek řešení úkolu. Používám občas pro plánování, aby bylo jasné, že řešení nemá začít hned. Třeba proto, že jiné úkoly jsou přednější.

Uzavřít do

Termín dokončení úkolu, uzávěrka, deadline. Přesněji řečeno, termín, kdy má být tiket předán zpět jako vyřešený (může být opět vrácen, ale to už je věc zadavatele). Pro mě jsou uzávěrky klíčovým parametrem pro práci s celým systémem. Jednak chodí každý den e-mail s tikety, které je potřeba v dohledné době 2-3 dnů vyřešit, jednak se uzávěrkami řídím v různých přehledech.

Přiřazeno

Řešitel úkolu, jeho aktuální majitel, držitel, vlastník. Aby systém fungoval, měl by s tiketem pracovat – měnit jeho stav podle reálné situace, psát k tiketu komentáře nebo poznámky a hlavně tiket v termínu předat jako vyřešený. Smyslem práce je zbavit se všech tiketů, nikoliv je sbírat.

Změnit vlastníka má smysl jen v případě změny stavu. Pokud jako řešitel potřebujete reakci zadavatele, napište komentář. Zadavateli přijde e-mail, takže by měl vědět o tom, že se čeká jeho reakce. Taktéž lze k tiketu přizvat sledující uživatele, těm budou také chodit e-maily, aby věděli, co se v diskuzi děje. Chování e-mailů lze různě nastavit.

Odhadovaná doba

Nepoužívám, slouží k odhadu doby, kterou je třeba strávit prací na tiketu.

% Hotovo

Tímto přepínačem lze od oka nastavit, kolik procent práce už bylo odvedeno. V případě rodičovských úkolů se množství času sčítá z podúkolů. Zobrazuje se to v Ganttově diagramu.

Sledování

Kromě zadavatele a řešitele mohou být v tiketu aktivní i další lidé. Například chtějí být informováni o diskuzi. Lze je tedy přidat do sledování. Mohou se pak sami odstranit, pokud je e-maily začnou obtěžovat.

Další pole

Díky možnostem Redminu lze také k tiketu přidat další políčka. Protože to hodně používám a je to skvělá věc, nechávám to na další článek.

[label type=“warning“ icon_position=“left“ size=“md“]Další článek[/label] Pohled na data v Redminu