JIRA használata

A projektjeinken a ticketek menedzseléséhez JIRA-t használunk. Épp ezért a JIRA helyes és következetes használata minden csapattagtól kötelezően elvárt feladat, melynek alapelveit a következő pontok taglalják.

1. Részfeladatokra bontás és státuszkezelés

Fejlesztői feladat, hogy a JIRA ticketet, legalább felsorolás szinten taskokra bontsa, majd a fejlesztés során a taskoknál állítsa is azok státuszát.

Ennek előnyei:

• A fejlesztő is jobban átlátja, hol tart az adott ticket fejlesztésével, és milyen feladatok vannak még hátra.
• A PA-nak a ticketet megnyitva és átnézve is lesz egy benyomása annak előrehaladásáról.
• A review-erek/tesztelők is könnyebben át tudják nézni, mi készült el a ticketben.

Elvárt formátum a ticketek részfeladatokra bontásához és státuszkezeléséhez

2. Evidence-ek hozzáadása az elkészült ticketekhez

Amennyiben egy fejlesztési feladat reviewzható állapotba került, akkor amennyiben az üzleti szempontból is releváns, pl.: módosul a felület, változik az üzleti folyamat, (tehát demozható), akkor úgynevezett evidence-t is szükséges csatolni a tickethez.

Fontos persze, hogy nem csak az üzleti, hanem a technikai fejlesztéseknél is fontos az evidence csatolása. Pl.:

• Nagyban segíti a megértést, ha az AuditLogból request/response JSON-t tudunk csatolni.
• Ugyanilyen hasznos lehet a logrészlet(ek) csatolása.
• De akár videó(narrált)/screenshot is praktikus lehet, amiben elmagyarázzuk mit valósít meg technikai szempontból a fejlesztésünk.

Ez a gyakorlatban azt jelenti, hogy mielőtt még Waiting For Review státuszba tennénk a jegyet, kötelező a fejlesztést bemutató képernyőkép és/vagy videó (request/response JSON, logrészlet) feltöltése is a tickethez.

Hová töltsük fel a screenshotot/videót

Fontos, hogy a fejlesztést bemutató screenshotokat/videókat kommentben csatoljuk a tickethez, ezáltal nyomonkövethetővé válik, hogy ki és mikor töltötte fel. Ezáltal nem keveredik például a tesztelő által hibajegyekhez csatolt képernyőképekkel vagy a nagyobb fejlesztésekhez csatolt design tervekkel stb.

Videók narrálása

A nagyobb fejlesztések esetén, ahol egy összetettebb üzleti folyamatot mutat be az evidence videónk célszerű a videót narrálva felvenni (mintha demoznánk), így a review-er vagy a tesztelő is sokkal könnyebben megérti az adott fejlesztés üzleti aspektusát is.

Képernyőkép/Videó készítése

WindowsmacOS

Windows operációs rendszer esetén, teljes képernyőkép, képmetszet és videó készítéséhez a ShareX ingyenesen elérhető szoftvert ajánlatos használni.

macOS rendszeren képernyőkép és videó készítésére használhatjuk a beépített eszközöket:

• Képernyőkép (Teljes képernyő): Cmd + Shift + 3
• Képernyőkép (Képrészlet kimetszése): Cmd + Shift + 4
• Videó: Cmd + Shift + 5

3. Időlogolás a ticketekhez

A fejlesztésre szánt idő nyomonkövetéséhez, és annak érdekében, hogy becsléseink egyre jobbak legyenek, kritikus fontosságú, hogy a ticketekben logoljuk, hogy mennyi időt foglalkoztunk velük.

Épp ezért minden fejlesztőnek kötelező a ticket fejlesztésére szánt időt vezetni a JIRA ticket Time tracking mezőjében.

Fontos, hogy a fejlesztők ezt minden nap végén tegyék meg.

Időlogolás kikényszerítése

A SEMI-ből örökölt workflow-nak köszönhetően, addig nem tehető „Waiting for review“ státuszba egy ticket, amíg nem logoltunk hozzá időt.

Ez a gyakorlatban a következőképp néz ki:

1. A fejlesztő „Waiting for review“ státuszba húz egy ticketet és megjelenik Request for code review felugró ablak.

2. Itt adjuk meg a Time Spent mezőben, hogy mennyi időt töltöttünk a ticket fejlesztésével.

   Mivel az elvárás az, hogy a fejlesztők minden nap végén töltsék a JIRA ticketnél a Time tracking mezőt, így ilyenkor jó esetben csak az előző nap vége óta eltelt (a tickettel töltött) időt kell megadni.

3. Végül kattintsunk a Request for code review gombra.

Az időlogolás kikényszerítése JIRA funkciót célszerű a saját workflow-val rendelkező projekteken is használni.

4. Az „Actual Release“ és a „Future Release“ gyorsfilterek

A SEMI boardokból másolt projekt boardjainkon alapértelmezetten szerepelni fognak az „Actual Release“ és a „Future Release“ gyorsfilterek.

• Az „Actual Release“ filtert használva, le tudjuk szűrni a boardunkat, hogy csak azokat a ticketeket lássuk, amelyek az aktuálisan fejlesztés alatt álló releasehez vannak rendelve. (Az utolsó releaselt verzió utáni verzióhoz rendelt ticketek.)
• A „Future Release“ filtert használva, le tudjuk szűrni a boardunkat, hogy csak azokat a ticketeket lássuk, amelyek az aktuális utáni releasekhez vannak rendelve.

Ezek a filterek valójában csak akkor fognak tudni érdemben működni, ha:

• mindig létrehozzuk a megfelelő verziókat,
• a technikai release során a megfelelő JIRA releaset/verziót is releaseljük,

• és a JIRA ticketeknél is beállítjuk a megfelelő verziókat a Fix versions mezőben.

  

5. A „TechDept“ gyorsfilter

A SEMI boardokból másolt projekt boardjainkon alapértelmezetten szerepelni fog a „TechDept“ gyorsfilter.

A „TechDept“ filtert használva, le tudjuk szűrni a boardunkat, hogy csak azokat a ticketeket lássuk, amelyek el vannak látva a techdebt labellel.

Fontos, hogy a techdebt labelt csak olyan ticketekre rakjuk rá, ahol valamilyen technika problémát, hiányosságot oldunk meg, és ezek a ticketek üzleti szempontból nem feltétlenül relevánsak.

Az ilyen JIRA ticketeknél állítsuk is be a Labels mezőben a techdebt labelt, hogy használni tudjuk a „TechDept“ gyorsfiltert.

6. Bugok kezelése

6.1 Amennyiben a Story átadása előtt, belső tesztelés során találtunk hibát

Amennyiben egy „Internal testing in progress“ státuszú Story „Internal test failed“ státuszba kerül:

1. A tesztelőnek kötelezőn létre kell hoznia egy „Internal Bug“ típusú Sub-task-ot a tesztelt Story-hoz.

   

2. Az Internal Bug Sub-taskban a tesztelő igyekezzen a lehető legrészletesebb leírást adni a hibáról.

3. Ezután a csapat dolgozza ki technikailag is a ticketet, és adjon rá becslést.
4. Ezt követően ez „Internal Bug“ Sub-task ugyanazt a workflow-t járja végig, mint bármelyik Story Sub-task.

6.2 Amennyiben már átadtuk a Storyt

Azoknál a hibáknál amik azután estek ki, hogy a Story teljesítette az „Definiton of Done“ feltételt, azoknál normál „Bug“ ticket felvétele szükséges.

• Amennyiben a Story-t tartalmazó Iniciatívát még nem adtuk át, úgy vegyük fel a „Bug“ ticketet ehhez az Iniciatívához.
• Amennyiben már a Story-t tartalmazó Iniciatívát is átadtuk, akkor egy különálló „Bug“ ticketet vegyünk fel.