Jira munkafolyamatai a legjobb gyakorlatok és tipikus hibák

Ról ről

tartalom

  • itthon
  • Vita
  • hitelesítő adatok
  • Tanácsadói szolgáltatások
  • Házon belüli képzés
  • Nyitott edzések
  • Kapcsolatba lépni
  • lenyomat

Jira munkafolyamatai: Legjobb gyakorlatok és tipikus hibák

Amikor vállalathoz megyek, mindig van egy listám Jira legjobb gyakorlatairól és a Jira tipikus kezdő hibáiról. Ezt a listát vásárlóim nagyon értékelik, mivel a hibák gyakran elkerülhetők, és minden hibát kritikusan értékelnek, különösen egy új rendszer kezdeti szakaszában. A következő cikksorozatban megosztom a lista egy részét a Jira közösséggel, és várom az új javaslatokat és észrevételeket.

jira

Túlmérnöki tervezés

A Jira munkafolyamatok tipikusan a vállalat valós munkafolyamataiból készülnek. Ez a megközelítés eddig helytálló - de ésszerű egyensúlyt kell teremteni a valódi munkafolyamat feltérképezése és a jira végső felhasználóbarát jellege között. Ez a lépés az egyik legösszetettebb, és némi tapasztalatot igényel Jira lehetőségeiről és korlátairól. Tapasztalataim szerint a jirai munkafolyamatok aranyszabálya:

Amennyire szükséges, a lehető legkevesebbet!

(Vagy a „KISS” elv is: legyen rövid és egyszerű.) Ez azt jelenti: a lehető legtöbb munkafolyamat-lépés, de a lehető legkevesebbet. A Jira munkafolyamat-lépéseként előírt valós munkafázisok közül melyikre nem lehet elvileg válaszolni, mivel mindig figyelembe kell venni a vállalat és az alkalmazottak sajátos körülményeit. Néhány kérdés azonban felhasználható annak ellenőrzésére, hogy szükséges-e egy lépés:

  • Változik a felelősség?
  • Csak bizonyos emberek vagy felhasználói csoportok hajthatják végre ezt a lépést?
  • Az értesítéseket el kell küldeni?
  • Képesnek kell lennem szűrni ezt a lépést követően, vagyis képesnek kell lennem áttekinteni az összes folyamatot a kapcsolt állapotban?

Minél több ilyen kérdésre válaszolunk igen, annál biztonságosabbá kell tenni ezt a lépést Jirában is. Gyakran túl sok lépés épül be a munkafolyamatba a fogantatás fázisában, ami az elején említett túlmérnöki munkát eredményezi. Egy ilyen munkafolyamat technikailag helyes, de összetettsége értetlenséget okoz a felhasználók körében - ennek eredménye az új eszköz helytelen működése és elutasítása. Negatív példa:

A fiktív RequirementsUnlimited vállalat szeretné a belső követelmények kezelését megvalósítani Jirával. Ezért létrehoz egy munkafolyamatot, amely tükrözi a műszaki folyamatot, amikor egy követelmény rögzítésre kerül. A „Követelmény” tevékenységtípus első 4 lépése a következő: Nyitott, Koordinált, Jóváhagyott, Ütemezett.

Nagyon jól hangzik eddig. Azonban: egy új követelmény elfogadásához 4 munkafolyamatra van szükség, amelyeken keresztül a felhasználónak kétség esetén „át kell kattintania”. Tehát itt ellenőriznie kell, hogy minden lépés valóban szükséges-e. A RequirementsUnlimited alkalmazással például a "Jóváhagyott" és az "Ütemezett" státusz között csak annyi a különbség, hogy az állapotátmenet folyamatát egy adott kiadáshoz rendelik (Jira-ban egy megoldási verziót). Arra a kérdésre, hogy miért van szükség ehhez külön állapotra, a projektmenedzser így válaszol: "Szeretném szűrni, hogy mely folyamatok vannak felismerve, de még nincsenek megtervezve!". Ezekkel az információkkal most tiszta lelkiismerettel javasolhatja az "Ütemezett" lépés törlését: Szűrővel megjelenítheti az összes olyan folyamatot is, amelyek "Jóváhagyva" állapotúak, és nincsenek hozzárendelve egyetlen megoldás verzióhoz sem. Ha a szűrő opció volt az egyetlen követelmény az "Ütemezett" lépésnél, akkor ezt törölni lehet, és a meglévő szűrőket ki lehet igazítani.

A példában eleinte triviálisnak tűnhet, függetlenül attól, hogy a munkafolyamatnak van-e több vagy kevesebb lépése - nagyobb és összetettebb munkafolyamatokban azonban minden további lépés új bonyolultsági és függőségi szinteket hoz létre. Ennek az alacsony szinten tartása a tiszta és felhasználóbarát munkafolyamat célja.

Rossz elnevezés az állapotátmenetnél

A munkafolyamatok rossz használhatóságának egyik népszerű forrása az állapotátmenetek megnevezése. Funkcionális munkafolyamat létrehozásakor hajlamos a státuszátmeneteket a legutóbbi állapotban történtek megnevezése helyett a következő állapotban bekövetkező események szerint. Tudnia kell, hogy az állapotátmenetek nevei elérhető munkafolyamat-lépésekként jelennek meg a felhasználó számára:

A legtöbb esetben a Jira felhasználói tudják, hogy mi történt éppen a folyamattal, és ehelyett a rendelkezésre álló lépések kijelzőjén szeretnék látni, hogy az adott lépés melyik későbbi állapothoz vezet. Negatív példa:

A "Szavazás befejeződött" állapotátalakítás elkerülhetetlenül a "Mit jelent ez?", "Mi történik, ha most rákattintok?" Kérdésekre vezeti a felhasználót. Az eredmény ismét bizonytalanság és helytelen működés. Ebben a példában az állapotátmenetnek inkább a következőknek kell lennie:

A „Process process” megnevezéssel a felhasználó azonnal láthatja a későbbi állapotot, amelyben a cselekedete vezeti. Az állapotátmenetek elnevezésének szabálya tehát: Az állapotátmenet nevének meg kell mutatnia a folyamat későbbi állapotát.

Ez csak kettő volt a számos példa közül, amelyeket figyelembe kell venni a Jira munkafolyamatok megtervezésekor és beállításakor (többek között: a megoldott és zárt állapot használata, globális állapotátmenet, munkafolyamat-feltételek hozzárendelése és még sok más). Ezen a ponton természetesen az utolsó kérdésem: Milyen hibákkal vagy problémákkal találkozott a munkafolyamatok létrehozásakor? Várom kommentjét!

Hasonló cikkek

2012. november 28-án Sebastian Höhne
Kategóriák: Jira | Címkék: Legjobb gyakorlatok, Jira, munkafolyamat | 7 megjegyzés