Mérje a szoftverszállítási rendszert

Induljon ki a meghozandó döntésből

A csapat tudni szeretné, javítja-e az AI a szállítást. A generált sorok számlálása más kérdésre válaszol. Metrika választása előtt határozza meg a hasznos eredményt és a minőségi feltételeket.

Egy fiktív exportszolgáltatásnál a kívánt eredmény az elfogadott módosítások megbízható szállítása kisebb teljes ráfordítással. Rögzítse az előkészítést, a megvalósítást, a review-t, a javítást és a várakozást. Vegye fel a sikertelen vagy félbehagyott módosításokat is.

Egyetlen, világos határú szolgáltatást használjon. Kísérleti weboldal és kritikus fizetési szolgáltatás összevonásával olyan szám keletkezhet, amely egyiket sem magyarázza. Időszakok vagy csapatok összehasonlítása előtt írja le a kontextust.

Használjon aktuális definíciókat

A DORA jelenlegi szállítási modellje öt metrikát tartalmaz. A hatókörük a szállítási teljesítmény, nem az egyes funkciók értéke vagy az egyéni hozzájárulás. A DORA-metrikák definíciói.

Egy dashboard más definíciót is használhat. Az eredmény értelmezése előtt olvassa el. A Taiga jelenlegi telepítési dokumentációja négy jelentett metrikát ír le, amelyeket a szolgáltató telepítési rekordjaiból vezetnek le. A helyreállítási mérőszáma egy későbbi sikeres telepítést használ. Ez nem minden éles incidens teljes nyilvántartása. A Taiga definíciói.

Vizsgáljon meg egy fiktív módosítássorozatot

Tegyük fel, hogy egy szolgáltatás egy hónapban tizenkét telepítést végez. Nyolc tervezett módosítást szállít. Négy korábbi kiadások problémáit javítja. A darabszám tizenkettő, de az összetétel számít.

A következő hónapban a csapat tíz telepítést végez: kilenc tervezett módosítást és egy javítást. Kevesebb telepítés mellett is lehet több hasznos munka. Ezek a számok az értelmezést szemléltetik; nem viszonyítási alapok a teljesítmény értékeléséhez.

Az eloszlást is vizsgálja meg. Egy hosszú review-várakozás eltűnhet az átlagban. Egyetlen hibából számított helyreállítási mérőszám gyenge bizonyíték a jövőbeli megbízhatóságra. Jelentse a megfigyelések számát és a lényeges kivételeket.

A folyamatot a következményekkel együtt értékelje

Szolgáltatásjelzésekkel ellenőrizze, hogyan hatnak a szállítás változásai a felhasználókra. A gyorsabb pipeline nem elég, ha az exportok gyakrabban sikertelenek. Használjon megfelelő SLO-t vagy más, egyértelműen meghatározott eredménymutatót. SLO-útmutató.

A review-ráfordítás és az újramunka segít megmagyarázni az eredményt. Ha az AI csökkenti a megvalósítás idejét, de nagy diffeket készít, a review válhat szűk keresztmetszetté. Ha a környezetek beszerzése napokig tart, a gyorsabb kódolás alig befolyásolhatja a teljes szállítási időt.

Válasszon egy fejlesztést, amely a megfigyelt korlátot kezeli. Például biztosítson támogatott tesztkörnyezetet, vagy csökkentse a módosítás méretét. Határozzon meg ellensúlyozó minőségi metrikát, hogy a csapat észlelje a gyengébb ellenőrzésekből eredő látszólagos gyorsulást.

A mérés maradjon hasznos

Kerülje a PR-darabszámra vagy generált kódra épülő egyéni rangsorokat. Ezek mesterséges munkafelosztást, a nehéz karbantartás elkerülését vagy a review-ráfordítás kollégákra hárítását jutalmazhatják.

A teljes szolgáltatásért felelős emberekkel vizsgálja meg az eredményt. Rögzítse az eszköz, a munkaösszetétel, a csapat és a környezet változásait. Az előtte-utána összehasonlítást korlátokkal rendelkező bizonyítékként kezelje, ne automatikus ok-okozati igazolásként.

A cél egy jobb következő döntés. Egy kicsi, megbízható mérés, amely ellenőrzött fejlesztéshez vezet, hasznosabb az egyeztetett jelentés nélküli nagy dashboardnál.

Gyakoroljon tíz módosítással

Ez a különálló, fiktív adatkészlet tíz tervezett módosítást rögzít. Minden időpont UTC szerint, a megadott napon értendő. Az üres javítási mező azt jelenti, hogy ebben az adatkészletben nem rögzítettek javítást.

Hasonlítsa össze a kód elkészültétől a review kezdetéig, majd az elfogadástól a kiadásig eltelt időt. Azonosítsa a leghosszabb látható várakozást. Mielőtt elkerülhetőnek nevezné, vizsgálja meg az okát. Ezek az időbélyegek nem mérik az aktív ráfordítást, és nem azonosítják az incidens kezdetét. Egy javító kiadás önmagában nem igazolja a sikertelen telepítés utáni helyreállítási időt.

A fiktív adatkészlet letöltése (CSV)