Oldalak

csütörtök

Issue tracking - alapok

A feladatok kiosztásának több módja is van. Ma már azért elvárható, hogy legalább a software fejlesztésben támogassuk meg ezt a folyamatot. A piacon kismillió issue tracker névre hallgató online és desktop alkalmazás van. Nem térnék ki a desktop alkalmazásokra, az idő bebizonyította életképtelenségüket.
Mire használunk egy issue tracker alkalmazást?
Elsősorban a feladatok kiosztására. Másodsorban bizonyos szinten ügyfélkezelésre is - főképp, ha ezen a felületen keresztül jelenthetik be az észlelt hibákat és követhetik azok életútját.
Mik az alapvető funkciók?
Fel kell tudni venni issue-kat, vagy nevezhetjük ticketeknek. Ki kell tudni osztani adott emberre. Adott embernek tudni kell kommunikálni, státuszt állítani, csatolni doksikat, és esetleg másik embernek átadni a feladatot.
Mik a kevésbé alapvető funkciók?
Az alapfunkcionalitást érdemes kibővíteni egy idő-kezelési modullal. Ez alapján lehet megmondani, hogy egy adott ember mennyi ideig dolgozott egy feladaton. Maga a feladat, embernél, adott státuszban eltöltött ideje könnyen logolható. Ezekből az egyszerű adatokból a managerek nagyon szép és hasznos kimutatásokat tudnak készíteni. Teszem hozzá, a fejlesztői hatékonyság vizsgálatára és javításokat célzó új módszertanok/metódusok bevezetésének visszamérésére is jól használhatóak.
A feladatok csoportosítása átláthatóbb és strukturáltabb megjelenítést tesz lehetővé.
In progress.... Ha a fejlesztő magára tudja rántani a feladatot és ezt a rendszer jelezni is képes az azért jó, mert folyamatában látjuk, hogy éppen ki, min dolgozik.
Verzió/build/sprint.. alapú csoportosítás. Ez már a tervezéshez közeli funkció. 
Becslés. Szerintem lényegi elem. Lehetővé teszi, hogy a terhelést jobban elosszuk. Például ha van sprint alapú csoportosítás, akkor ezzel együtt pontosan be tudjuk osztani a fejlesztők idejét és lehetőség szerint annyi feladatot oszthatunk ki, amennyi az adott (rész)határidőbe belefér. A becslés vs valóságban a feladattal töltött idő szintén fontos metrika. Hatékonyságnövelést csak akkor tudunk elérni, ha van egy olyan alapunk amihez képest szeretnénk jobbak lenni.
Code repository összeköttetés. Elsősorban több ágon történő, vagy szétosztott fejlesztési csapatoknál kihasznált funkció.
Non plus ultra: build/deploy folyamattal való összekötés. Milyen egyszerű lehetne az élet: pár klikk és összeáll a release levél, hogy pl. adott sprint alatt milyen feladatok készültek el, azok melyik ágon és milyen státuszban vannak. Majd újabb egy mozdulattal azt mondhatnánk: Mehet!

Tehát jóval több, mint első látásra gondolnánk.
És akkor még nem néztük meg az alapegységektől elvárt működést, illetve a teljes workflowt... Ami késik, nem múlik. Lesz még erről post.....
Mint ahogy a nagyobb online elérhető alkalmazásokról is.

Nincsenek megjegyzések:

Megjegyzés küldése