Osvedčené postupy a typické chyby v pracovných postupoch Jira

O

obsah

  • Domov
  • Vita
  • poverovacie listiny
  • Poradenské služby
  • Vnútorné školenie
  • Otvorené školenia
  • Kontakt
  • odtlačok

Pracovné postupy Jira: Osvedčené postupy a typické chyby

Keď idem do spoločnosti, vždy mám so sebou zoznam najlepších postupov a bežných chýb začiatočníkov pre Jira. Tento zoznam moji zákazníci veľmi oceňujú, pretože chybám sa dá často vyhnúť a každá chyba je kriticky vyhodnotená, najmä v počiatočnej fáze nového systému. V nasledujúcej sérii článkov budem zdieľať časť tohto zoznamu s komunitou Jira a teším sa na nové návrhy a komentáre.

chyby

Overengineering

Pracovné postupy Jira sú zvyčajne modelované na základe skutočných pracovných procesov v spoločnosti. Tento prístup je zatiaľ správny - malo by sa však dosiahnuť rozumné vyváženie medzi mapovaním skutočného pracovného toku a maximálnou užívateľskou prívetivosťou v Jire. Tento krok je jedným z najkomplexnejších a vyžaduje určité skúsenosti s možnosťami a obmedzeniami programu Jira. Podľa mojich skúseností je zlatým pravidlom pre pracovné postupy v Jire:

Pokiaľ je to potrebné, tak málo, ako je to možné!

(Alebo tiež princíp „KISS“: Snažte sa byť stručný a jednoduchý). To znamená: toľko krokov pracovného toku, koľko je potrebné, ale čo najmenej. Na ktoré zo skutočných pracovných krokov sa vyžaduje krok pracovného toku v Jire, sa v zásade nedá odpovedať, pretože je vždy potrebné brať do úvahy konkrétne okolnosti spoločnosti a zamestnancov. Existuje však niekoľko otázok, pomocou ktorých môžete skontrolovať, či je potrebný krok:

  • Dochádza k zmene zodpovednosti?
  • Tento krok môžu vykonať iba určití ľudia alebo skupiny používateľov?
  • Je potrebné odoslať oznámenia?
  • Musím byť po tomto kroku schopný filtrovať, t. J. Vidieť prehľad všetkých procesov v prepojenom stave?

Čím viac z týchto otázok bude zodpovedaných „áno“, tým bezpečnejšie by mal byť tento krok mapovaný aj v Jire. Vo fáze koncepcie je do pracovného toku často zabudovaných príliš veľa krokov, čo vedie k nadmernému inžinierstvu spomenutému na začiatku. Takýto pracovný postup je technicky správny, ale jeho zložitosť spôsobuje medzi používateľmi nepochopenie - výsledkom je nesprávna obsluha a odmietnutie nového nástroja. Negatívny príklad:

Fiktívna spoločnosť RequirementsUnlimited by chcela implementovať interné riadenie požiadaviek so spoločnosťou Jira. Vytvára preto pracovný tok, ktorý odráža technický proces, keď sa zaznamená požiadavka. Prvé 4 kroky pre typ aktivity „Požiadavka“ sú: Otvorené, Koordinované, Schválené, Naplánované.

Znie to zatiaľ celkom dobre. Avšak: aby sme prijali novú požiadavku, sú potrebné 4 kroky pracovného toku, cez ktoré musí užívateľ v prípade pochybností „kliknúť“. Tu by ste mali skontrolovať, či sú všetky kroky skutočne potrebné. Napríklad v prípade RequirementsUnlimited je jediný rozdiel medzi stavom „Schválené“ a „Naplánované“ v tom, že proces v tomto prechode stavu je priradený konkrétnemu vydaniu (v Jira, verzia riešenia). Na otázku, prečo je na to potrebný samostatný stav, odpovedá projektový manažér: „Chcem mať možnosť filtrovať, ktoré procesy sú rozpoznané, ale ešte nie sú naplánované!“. S týmito informáciami môžete teraz s čistým svedomím odporučiť vymazať krok „Naplánované“: Môžete tiež použiť filter na zobrazenie všetkých procesov, ktoré majú stav „Schválené“ a nie sú priradené k žiadnej verzii riešenia. Ak bola voľba filtra jedinou požiadavkou pre krok „Naplánované“, je možné ju odstrániť a upraviť existujúce filtre.

V príklade to môže znieť spočiatku triviálne, či má pracovný tok jeden alebo viac krokov - pri väčších a zložitejších pracovných tokoch však každý ďalší krok vytvára novú úroveň zložitosti a závislostí. Udržiavanie tohto minima je cieľom čistého a užívateľsky príjemného pracovného toku.

Zlé pomenovanie pri prechodoch stavu

Populárnym zdrojom zlej použiteľnosti pracovných postupov je pomenovanie prechodov stavu. Pri vytváraní funkčného pracovného toku sa niekto prikláňa k pomenovaniu prechodov stavu podľa toho, čo sa stalo v poslednom stave, namiesto toho, čo sa stane v ďalšom stave. Musíte vedieť, že názvy prechodov stavu sa používateľovi zobrazujú ako dostupné kroky pracovného toku:

Vo väčšine prípadov používatelia Jira vedia, čo sa práve stalo s procesom, a chcú na displeji vidieť dostupné kroky, ku ktorým následnému stavu bude daný krok viesť. Negatívny príklad:

Zmena stavu „Hlasovanie ukončené“ nevyhnutne vedie k otázkam „Čo to znamená?“, „Čo sa stane, keď na neho kliknem teraz?“ Výsledkom je opäť neistota a nesprávna obsluha. V tomto príklade by mal byť prechod stavu lepší, a to takto:

S označením „Proces procesu“ môže užívateľ okamžite vidieť následný stav, v ktorom ho jeho akcia povedie. Pravidlo pre pomenovanie prechodov stavu je preto: Názov prechodu stavu musí ukazovať následný stav procesu.

Boli to len dva z mnohých príkladov, ktoré by sa mali brať do úvahy pri navrhovaní a nastavovaní pracovných tokov v Jire (okrem iného: použitie vyriešeného a uzavretého stavu, globálne prechody stavu, priradenie podmienok pracovného toku a oveľa viac). V tejto chvíli samozrejme prichádza na rad moja posledná otázka: s akými chybami alebo problémami ste sa stretli pri vytváraní pracovných postupov? Teším sa na váš komentár!

Podobné články

28. novembra 2012 - Sebastian Höhne
Kategórie: Jira | Štítky: Najlepšie postupy, Jira, Workflow | 7 komentárov