Régóta magas prioritással szerepel a Visual Studio Online Wish List-en a felhasználók azon igénye, hogy ne csak az egyedileg telepített TFS-n legyen mód a folyamat és az egyes elemek testreszabására, kiigazítására. 2014 decemberében a fejlesztői csapat jelezte, hogy a problémát napirendre tűzte és a megoldáson dolgozik.

Az idő előrehaladtával 2015 májusában napvilágot látott egy blogbejegyzés ami a Visual Studio Online Process Customization címet viselte, és azt írták le, miképp gondolkodnak a dologról. Ez már bizakodással töltött el, hisz látszott, hogy lesz valami megoldás. Ez a megoldás most július végével kiadásra került új blogbejegyzésben frissítésre került, és azóta elérhető már számos változás is a Visual Studio Online felhasználói számára. Nézzük mi is történt, miképp lehet a felületet saját igényeinkhez igazítani…

Kezdjük az elején avagy a nem látható változások

(ezen változásokat még nem vehetjük kézbe, de a “motorháztető alatt” már elindultak a változások)

Megosztott folyamat
Jelentős elvárás a felhasználó szervezetek felől, hogy az egyszer egyedileg kialakított folyamatot ne kelljen mindig újra és újra módosítani a rendszerben. Ennek biztosítása érdekében a kialakított folyamatainkat megoszthatjuk “házon belül”. Az egész folyamat ráadásul öröklési logikán alapul, azaz ha a forrást módosítjuk, akkor minden leszármaztatott folyamat is módosításra kerül, így megkönnyítve a mindennapos munkát.

Örökölt (gyári) folyamatok
Azoknak akik nem akarnak igazán módosítani a folyamatokon, mindössze egy-két kiegészítést eszközölnének rajta, azok számára a beépített folyamat template-k is rendelkezésre állnak, amelyeket a projekt létrehozását követően tetszőlegesen kiegészíthetnek a saját igényeik szerint szükséges mezőkkel, állapotokkal.

Egyszerűsített testreszabás
A testreszabás elvégzéséhez mostantól nem kell kézzel matatnunk a leíró XML fájlokat és a Process Template Editor-ra, hanem a változtatásokat kényelmesen a webes felülethez alkalmazkodó képernyőkön végezhetjük el.

Látható változások

Annak érdekében, hogy több ponton a dolgokat egyenesbe lehessen hozni, májusban a VSO process template frissítésre került. Ennek keretében bekerült a rendszerbe a Scaled Agile Framework támogatása.

Epic Work Item

Első lépésben tegyük helyre az Epic elemet, mire is szolgál ez a valóságban? Amikor az ember kellően nagy projekttel dolgozik, akkor szükségessé válik, hogy az eddig egy elemként kezelt termék képességeket is gyűjtőkbe, önálló story leírásokba szervezhessük. Erre szolgál az epic elem.

A változás keretében bevezetésre került az Epic work item typte. Ez az elem mindhárom template-be felvételre került (Scrum, Agile, CMMI). Az Epic mint új elemtípus, saját backlog/board megjelenítést is kapott.

Az új elem viszont nem látszik sehol magától, annak használatát a rendszerbe nekünk kell engedélyezni. Ez nem egy túlbonyolított dolog, mindössze a Team Settings lapra kell elmennünk, bekapcsolni és a fenti panel ezt követően jelenik meg. (A lustábbak kedvéért megjegyzem, hogy az eredeti cikk óta, ezt a beállítást a felületről közvetlenül elérhetővé tették a többi testreszabással együtt, használjátok bátran a lista jobb felső sarkában lévő fogaskereket).

Üzleti (Business) vagy Arhitektúra (Architectural) besorolás

Számos esetben hiányzott nekünk is – és nem tudtuk a template-t módosítani -, hogy egy-egy elemről megadható legyen, hogy az miért is kerül felvételre. Az MSFT végre megemberelte magát, és az Epic, Features és a Product Backlog elemeknél előkerült egy választó mező, ahol megadhatjuk, az adott elem megjelenését milyen igény mentén vettük fel. Annak érdekében, hogy ez ne okozzon problémát, alapértelmezésben minden elem Business elemnek kerül felvételre, amit ha szükséges átállíthatunk Architectural-ra.

A kapcsoló első nem tűnik nagy jelentősségűnek, de nagyobb időtávon nagyban megkönnyíti a fejlesztett rendszerben az arhitektúra változási igények megjelenésének és megoldásának nyomonkövetését.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük

*