Reporting a SpiraTeamre

• 

Körülbelül egy éve keresett meg egy cég minket azzal, hogy az általuk bevezetés alatt álló SpiraTeam tesztmenedzsment eszközükre készítsünk riportokat, sőt már az elképzeléseiket is megküldték excel-formátumban.

A riportigényeik teljesen észszerűek voltak, olyanok, amiken szívesen dolgozik egy fejlesztő, a megvalósításra szánt reporting eszköz viszont sajnos nem a kedvencünk. De természetesen az ügyfelet is megértettük, hiszen ez egy pilot volt csupán, így ez volt a legkézenfekvőbb (legköltséghatékonyabb) a meglévő licenceik mellett. Ha pedig beválik és cégszerte megbarátkoztak az új fejlesztéssel, akkor még mindig lehet költeniük egy korszerű üzleti intelligencia szoftvercsomagra a lehetőségek jobb, szerteágazóbb és megjelenésében is nagyságrendekkel szebb kiaknázása végett, anélkül, hogy az eddig elkészített reporting alapjai kárba vesznének.

Mivel addig csak hallomásból ismertem ezt a tesztmenedzsment eszközt, természetesen az volt az első, hogy elkezdtem utána olvasni a képességeiről, használatáról, hogy az ügyféllel az első közös egyeztetésre egy kicsit már felkészültebben érkezzek.

Meglepődve olvastam és tapasztaltam, hogy az eszköz rendelkezik belső riportokkal, melyek egész testreszabhatónak és csinosnak néztek ki, sőt, némelyik grafikon alapvetően az ügyfél által megvalósíttatani kívánt vizualizációkra hasonlított. Ekkor merült fel bennem a kérdés: Miért is akar az ügyfél riportokat készíttetni, ha erre a lehetősége adott?

Nos, a kérdésemre bizony hamar fény derült: A Spira egy rendkívül jól paraméterezhető eszköz és széles körűen tudja támogatni a tesztelési folyamat összes érintettjét, de belső reportingja csak nagyon alapszintű riportigényeket tud kiszolgálni és néha még félrevezető információk is vannak benne.

Mivel már építettünk reportingot más tesztmenedzsment eszközre, így a múltbeli tapasztalataink alapján a félelmünk a projekttel kapcsolatban a Spira alatti adatbázis-struktúra volt, hiszen egy reporting-projekt esetében ezen rengeteg múlik, többek között az is, hogy a projektre milyen arányban delegáljunk adatbázis szakértőt illetve BI-ost.

A riportigények és reporting eszköz ismeretében arra jutottunk, hogy adatbázis-nézetekre és ütemezett tárolt eljárásokkal töltött, napi szintű hisztorikus adatokat tartalmazó táblákra építjük az ügyfél által elvárt vizualizációkat.

Egy projekten egy ismeretlen adatbázis struktúra feltérképezése, megértése leírással vagy leírás nélkül is igen időigényes és bonyolult feladat, így izgatottan vártuk az adatbázisos kollégával az első projekt-napot, amikor először szembesülhettünk vele.

A projekten töltött első pár nap célja az volt, hogy valamelyest átlássuk a rendszer adatbázis-struktúráját, próbáljuk feltérképezni a táblákat, a táblák közötti kapcsolatokat, illetve, hogy mely táblákra lesz szükségünk a riportok megvalósításához.

Ezzel szemben már az első nap (!) tudtunk egy riportkezdeményt mutatni az ügyfélnek, ami egyrészt az ügyfelet is megnyugtatta, hogy ez egy sikeres projekt lehet, nekünk pedig olyan lendületet adott, ami egészen az élesítésig kitartott. Ez természetesen nem csak azért történhetett meg, mert értünk ahhoz, amit csinálunk, hanem azért, mert a Spira adatbázis-struktúrája az egyik legátláthatóbb, amivel valaha is találkoztunk „dobozos termék” esetében. Az egyértelmű tábla és mezőelnevezések, joinok, előre gyártott nézetek hihetetlenül megkönnyítik az egyedi igények kivitelezését.

Az egyedi igényekből pedig nem volt hiány: Céges szintű projekt-áttekintő, Top X hiba, napi státuszváltozások, státuszokban eltöltött átlagos idők stb. stb. Ezek a fejlesztések pedig lehetővé tették, hogy kiváltsunk olyan cégszintű standard kimutatásokat, melyeket eddig kézzel-lábbal, fáradtságos és időigényes munkával gyűjtöttek össze excelekbe és készítettek PowerPoint prezentációkat. Így, hogy ma már pár kattintással előállnak a riportok, az ezáltal megspórolt időt „értelmesebb” tevékenységre lehet fordítani.

Természetesen az, hogy egy projekt sikeres legyen, nagyban függ a megrendelő elhivatottságától és szakértelmétől is és szerencsére ebben a projektben ebben sem volt hiány: mindig, minden felmerülő kérdést szinte azonnal tisztázni tudtunk, így a fejlesztés zökkenőmentesen haladt a maga útján.

A projekt végül sikeresen zárult, sőt azóta is folyamatosan érkeznek a riportigények, módosítások, finomítások, sőt, a cégen belül is kezd terjedni az „ige” és már az általunk gyártott riportokat tekintik a Spira hivatalos reportingjának.

Remélhetőleg az „ige” elterjedésével egyre nagyobb igény (és ezzel párhuzamosan rá allokált budget) fog mutatkozni arra, hogy egy modernebb riportáló eszközzel minél jobban ki tudják és ki is akarják használni a lehetőségeket.

Gondolok itt például arra, hogy egy szemantikus réteg bevezetésével (ez teremti meg az adatbázis és az üzleti réteg közötti kapcsolatot) egy adatbázishoz egyáltalán nem értő üzleti felhasználó önmaga, IT-s segítség nélkül is képes lenne riportokat, vezetői dashboardokat létrehozni (önkiszolgáló BI), így külső segítséget csak a bonyolultabb igények megvalósításakor kellene igénybe venni. Ezen szemantikus réteg biztosítaná cégen belül az egységes fogalomtár bevezetését is, például, hogy az egyes riportokban a cég minden felhasználója ugyan azt értse a nyitott vagy éppen egy adott napon belül módosított incidensek számán.

De annak kivitelezése sem okozna problémát, hogy minden projektvezető, tesztmenedzser e-mail címére megadott időközönként érkezzen egy pdf, ami kizárólag csak a saját projektjeiről adna kulcsfontosságú információkat, illetve egy sor szintű adathozzáférési jogosultság bevezetésével megoldható lenne, hogy a webes reporting-portálon ugyanaz a riport az egyes felhasználóknak csak a saját projektjeikről mutasson információkat, ennek az az óriási előnye, hogy csak egy riportot kell karbantartani.

A lehetőségeknek csak a riportáló eszköz képességei, a képzelet és a budget szab határt.