Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019
A kumulatív folyamatábrák (CFD-k) segítségével figyelheti a rendszeren keresztüli munkafolyamatot. A ciklusidő és az átfutási idő a nyomon követéshez használt két elsődleges mérőszám. Ezeket a mutatókat kivonhatja egy CFD-ből.
Ez a cikk bemutatja, hogyan használhatja a CFD-ket, a ciklusidőket és az átfutási időket a munkafolyamat problémáinak azonosítására, és hogyan segíthet a munka áthelyezésében a rendszeren keresztül.
- CFD konfigurálásához vagy megtekintéséhez lásd: Kumulatív folyamatábra megtekintése és konfigurálása.
- Átfutási idő vagy ciklusidő-vezérlő diagram irányítópulthoz való hozzáadásához lásd: Átfutási idő és ciklusidő widgetek.
Mintadiagramok és elsődleges metrikák
A folyamatos áramlású CFD azt a diagramot biztosítja, amelyet a lean folyamatot követő csapatok a legjobban kedvelnek.
Sok csapat azonban kombinálja a lean gyakorlatokat a Scrummal vagy más módszertanokkal. Ennek eredményeként egy iteráció vagy sprint során lean gyakorlatokat alkalmaznak. Ebben a helyzetben a diagram kissé más megjelenést kap. Két extra és nagyon értékes információt nyújt, amint azt a következő diagram, a fix periódusú CFD mutatja.
Folyamatos áramlású CFD
Ez a fix idejű CFD egy befejezett sprintre vonatkozik.
A felső sor a futamhoz beállított hatókört jelöli. Mivel a munkát a futam utolsó napjáig be kell fejezni, a Zárt állapot meredeksége azt jelzi, hogy a csapat jó úton halad-e a futam befejezése felé. Ennek a nézetnek az egyik legegyszerűbb módja annak, hogy erre a nézetre gondoljunk, az égetési diagram.
A diagramon a folyamat első lépése a bal felső területként jelenik meg. A folyamat utolsó lépése a jobb alsó területként jelenik meg.
Fix futamidejű CFD egy befejezett sprinthez
Grafikonmutatók
A CFD-k állapot vagy oszlop szerint csoportosítva jelenítik meg a munkaelemek számát az idő múlásával. A nyomon követéshez használt két elsődleges mérőszám a ciklusidő és az átfutási idő. Ezeket a metrikákat kinyerheti a diagramból.
Metrika
Definíció
Ciklusidő1
A munka egyetlen folyamaton vagy munkafolyamat-állapoton való áthelyezéséhez szükséges idő. A hosszt az egyik folyamat kezdetétől a következő folyamat kezdetéig mérik.
Átfutási idő1
Folyamatos folyamathoz: A kérés benyújtásától (például egy javasolt felhasználói történet hozzáadásától) a kérés befejezéséig (lezárásáig) eltelt idő.
Futam- vagy határozott időtartamú folyamat esetén: A kérelemmel kapcsolatos munka megkezdésétől a munka befejezéséig eltelt idő (például az Aktív állapottól a Lezárt állapotig tartó idő).
Folyamatban lévő munka (WIP)
Az aktívan használt munka mennyisége vagy munkaelemeinek száma.
Hatókör
Az adott időszakra lekötött munka mennyisége. Ez a metrika csak a rögzített időszakú folyamatokra vonatkozik.
1 Az Analytics-adatokat használó CFD-vezérlő és a csapat hátralékából vagy táblájából megtekinthető beépített CFD nem biztosít különálló átfutási időt és ciklusidő-értékeket. Az Átfutási idő és a Ciklusidő vezérlők azonban megadják ezeket az értékeket.
Jól meghatározott összefüggés van az átfutási idő vagy a ciklusidő és a WIP között. A több WIP hosszabb ciklusidőket eredményez, ami hosszabb átfutási időt eredményez. Ennek az ellenkezője is igaz – a kevesebb WIP rövidebb ciklust és átfutási időt eredményez. Amikor a fejlesztői csapat kevesebb elemre összpontosít, csökkentik a ciklust és az átfutási időket. Ez a korreláció az egyik fő oka annak, hogy miért kell WIP-korlátokat beállítani a munka nyomon követésére és kezelésére használt táblán.
A munkaelemek száma az adott nap teljes munkamennyiségét jelzi. Rögzített időtartamú CFD-k esetén ennek a számnak a változása egy adott időszakra vonatkozó hatókör változását jelzi. Folyamatos áramlású CFD-k esetén a várólistában lévő és egy adott napon befejezett munka teljes mennyiségét jelzi.
A munka adott táblaoszlopokba való kategorizálása megmutatja a folyamat egyes területein elvégzett munka mennyiségét. Ez a nézet betekintést nyújt abba, hogy hol halad zökkenőmentesen a munka, hol vannak akadályok, és hol nem történik munka. Nehéz megfejteni az adatok táblázatos nézetét. A vizuális CFD azonban segít megérteni, hogy mi történik a munkafolyamatban, és miért történik.
Azonosítsa a problémákat és tegye meg a megfelelő lépéseket
A CFD a következő kérdésekre ad választ. A válaszok alapján beállíthatja a folyamatot, hogy a munkát a rendszeren keresztül mozgassa.
A csapat időben befejezi a munkát?
Ez a kérdés csak a fix idejű CFD-kre vonatkozik. Megértést nyerhet, ha megnézi a munka görbéjét (vagy előrehaladását) a tábla utolsó oszlopában.
Ebben a forgatókönyvben érdemes lehet csökkenteni az iteráció munkakörét. Ez a művelet akkor megfelelő, ha egyértelmű, hogy a munka nem fejeződik be elég gyorsan, feltételezve, hogy egyenletes ütemben folytatódik. Ez a forgatókönyv azt jelezheti, hogy a munkát alábecsülték, és figyelembe kell venni a következő sprint tervezésében.
Azonban más okai is lehetnek annak, hogy a munka nem fejeződik be elég gyorsan. Ezeket az okokat a diagram egyéb adatainak megtekintésével határozhatja meg.
Hogyan halad a munka folyamata?
A csapat egyenletes ütemben végzi a munkát? Ennek egyik módja a diagram különböző oszlopai közötti távolság megtekintése. Hasonló vagy egységes távolságra vannak egymástól az elejétől a végéig? Úgy tűnik, hogy az oszlopok több napon keresztül laposak? Vagy úgy tűnik, hogy bármelyik kidudorodik?
A mura vagy egyenetlenség a lapos vonalak és dudorok sovány kifejezése. A Mura a hulladék egy formáját (Muda) jelzi a rendszerben. A rendszer bármilyen egyenetlensége dudorokat okoz a CFD-ben.
A CFD monitorozása egysíkú vonalak és dudorok esetében támogatja a kényszerelmélet projektirányítási folyamatának kulcsfontosságú részét. A rendszer leglassabb területének védelmét dob-puffer-kötél folyamatnak nevezik, és ez a munka tervezésének része.
Két probléma láthatóvá válik mint sík vonalak és mint dudorok.
Lapos vonalak akkor jelennek meg, ha a csapat nem frissíti a munkaelemeik állapotát rendszeres ütemben. A munka nyomon követésére és kezelésére használt tábla a leggyorsabb módja a munka egyik oszlopból a másikba való áthelyezéséhez.
Egysíkú vonalak akkor is megjelenhetnek, ha egy vagy több folyamat munkája a tervezettnél hosszabb időt vesz igénybe. A rendszer számos részén lapos vonalak jelennek meg, mert ha csak egy vagy két résznek van problémája, akkor kidudorodást lát.
Sík vonalak
Kidudorodások akkor fordulnak elő, amikor a munka a rendszer egyik részében halmozódik fel, és nem halad át egy folyamaton.
Például kidudorodás akkor fordulhat elő, ha a tesztelés hosszú időt vesz igénybe, de a fejlesztés kevesebb időt vesz igénybe. Az eredmény az, hogy a munka felhalmozódik a fejlesztési állapotban. A kidudorodások azt jelzik, hogy a következő lépésnek problémája van, nem feltétlenül az a lépés, amelyben a dudor előfordul.
Dudorok
Hogyan oldható meg a folyamatproblémák?
Az időben történő frissítések hiányának problémáját a következő lépésekkel oldhatja meg:
- Napi stand-upok tartása
- Egyéb rendszeres ülések tartása
- Napi csapatemlékeztető e-mail ütemezése
A rendszerszintű síkvonalas problémák nagyobb kihívást jelentenek, bár az ilyen problémák ritkán fordulnak elő. A lapos vonalak azt jelzik, hogy a rendszer teljes munkája leállt. A mögöttes okok a következő problémák lehetnek:
- Folyamatszintű eltömődések
- Hosszú időt igénylő folyamatok
- A munka áthelyezése más lehetőségekre, amelyek nincsenek rögzítve a táblán
A szisztémás laposodás egyik példája előfordulhat egy jellemző CFD-ben. A funkciókkal kapcsolatos munka lényegesen tovább tarthat, mint a felhasználói történeteken végzett munka, mivel a funkciók több történetből állnak. Ezekben a helyzetekben vagy a lejtés várható (mint egy korábbi példában), vagy a probléma jól ismert, és a csapat már felvetette. Ismert probléma esetén a probléma megoldása nem tartozik a jelen cikk hatókörébe.
A csapatok proaktívan meg tudják oldani a CFD kidudorodásként megjelenő problémákat. A megfelelő javítás attól függhet, hogy hol fordul elő a kidudorodás. Tegyük fel például, hogy a kidudorodás a fejlesztési folyamat során következik be. A kidudorodás azért történhet, mert a tesztelés lényegesen tovább tart, mint a kódírás. A tesztelők nagy számú hibát is megtalálhatnak. Amikor folyamatosan visszaadják a munkát a fejlesztőknek, a fejlesztők egyre bővülő listáját öröklik az aktív feladatoknak.
A probléma megoldásának két lehetséges egyszerű módja van:
- Helyezze át a fejlesztőket a fejlesztési folyamatról a tesztelési folyamatra, amíg a dudorodás meg nem szűnik.
- Módosítsa a munka sorrendjét. Pontosabban, a gyorsan elvégezhető munkát összefonja a hosszabb ideig tartó munkával.
Keressen alapvető megoldásokat a dudorok kiküszöbölésére.
Feljegyzés
Mivel különböző forgatókönyvek fordulhatnak elő, amelyek miatt a munka egyenetlenül halad, kritikus fontosságú, hogy tényleges elemzést végezzen a problémáról. A CFD jelezheti, hogy probléma áll fenn. Azt is megmondhatja, hogy megközelítőleg hol van a probléma, de meg kell vizsgálnia, hogy eljusson a kiváltó okokhoz. Ez az útmutató olyan javasolt műveleteket tartalmaz, amelyek konkrét problémákat oldanak meg, de előfordulhat, hogy a megoldások nem vonatkoznak az Ön helyzetére.
Megváltozott a hatókör?
A hatókör-változások csak a rögzített idejű CFD-kre vonatkoznak. A diagram felső sora a munka hatókörét jelzi. A sprint előre be van töltve az első napon elvégzendő munkával. A felső sor változásai a munka hozzáadását vagy eltávolítását jelzik.
Egy adott esetben nem követheti nyomon a hatókör változásait CFD-vel. Ez a forgatókönyv akkor fordul elő, ha ugyanazon a napon ugyanannyi munkaelemet ad hozzá és távolít el. A vonal ebben az esetben lapos marad.
Ebben az esetben a hatókör változásainak nyomon követéséhez hajtsa végre a következő műveleteket:
- Több diagram összehasonlítása egymással.
- Figyelje a konkrét problémákat.
- A sprint előrehaladásának használatával figyelheti a hatókör változásait.
Túl sok a WIP?
Könnyen figyelheti a táblát, hogy megállapítsa, túllépték-e a WIP-határértékeket. A WIP szinteket a CFD segítségével is nyomon követheti.
Általában nagy mennyiségű WIP jelenik meg függőleges dudorként. Minél hosszabb ideig van nagy mennyiségű WIP, annál inkább ovális alakúvá tágul a dudor. Ez a viselkedés azt jelzi, hogy a befejezetlen munka negatívan befolyásolja a ciklust és az átfutási időt.
Íme egy jó ökölszabály a WIP-hez: Csapattagonként egyszerre legfeljebb két elem lehet folyamatban. A két elemből álló korlát használatának fő oka az, hogy a valóság gyakran beavatkozik a szoftverfejlesztési folyamatba.
Néha időbe telik, amíg információkat kap az érdekelt felektől, vagy megszerzi a szükséges szoftvereket. Számos oka lehet annak, hogy a munkát le lehet állítani. Egy második munkaelem, amelyre elfordulhat, némi mozgásteret biztosíthat. Ha mindkét elem le van tiltva, itt az ideje, hogy egy piros jelölőt emeljen fel, hogy feloldjon valamit – ne csak váltson egy újabb elemre. Amint nagyszámú elem van folyamatban, az ezeken az elemeken dolgozó személynek nehézségei lehetnek a kontextus váltásával. Valószínű, hogy elfelejtik, mit csináltak, ami hibákhoz vezethet.
Átfutási idő és ciklusidő
Az alábbi ábra bemutatja, hogyan tér el az átfutási idő a ciklusidőtől. Az átfutási idő a munkaelem létrehozásakor kezdődik, és akkor ér véget, amikor a munkaelem belép a Befejezett állapot kategóriába. A ciklusidő akkor kezdődik, amikor egy munkaelem először belép egy Folyamatban vagy Feloldott állapot kategóriába. A ciklusidő akkor ér véget, amikor a munkaelem Befejezett állapot kategóriába kerül.
Ha egy munkaelem Befejezett állapot kategóriába kerül, majd újra aktiválja, az hatással van az átvezetési és ciklusidőkre. A Javasolt, Folyamatban vagy Feloldott állapotkategóriában eltöltött többletidő hozzájárul az átfutási és ciklusidőkhöz.
Ha a csapat táblát használ a munka nyomon követésére és kezelésére, az segít megérteni, hogy az oszlopok hogyan illeszkednek a munkafolyamat-állapotokhoz. A tábla konfigurálásával kapcsolatos további információkért lásd: Oszlopok kezelése a táblán.
További információ arról, hogy a rendszer hogyan használja az állapotkategóriákat – Javasolt, Folyamatban, Megoldva és Befejezve – lásd: Tudnivalók a munkafolyamat-állapotokról a hátralékban és táblákban.
Becsülje meg a szállítási időket az átfutási és ciklusidők alapján
Az átlagos átfutási és ciklusidők, valamint a szórások segítségével megbecsülheti a szállítási időt.
Munkaelem létrehozásakor a csapat átlagos átfutási idejével megbecsülheti a munkaelem befejezési dátumát. A csapat szórása megmutatja a becslés variabilitását. Hasonlóképpen, a ciklusidő és annak szórása segítségével megbecsülheti a munkaelem befejezését a munka megkezdése után.
Példa ciklusidő vezérlőre
Az alábbi diagramon az átlagos ciklusidő nyolc nap. A szórás hat nap. Ezen adatok felhasználásával megbecsülheti, hogy a csapat a munka megkezdése után körülbelül 2–14 nappal befejezi a jövőbeli felhasználói történeteket. Minél keskenyebb a szórás, annál kiszámíthatóbb a becslése.
Folyamatproblémák azonosítása
A kiugró értékek gyakran egy mögöttes folyamatbeli problémára utalnak. Ilyen például a lekéréses kérelmek áttekintésének túl sokáig való várakozása, vagy a külső függőségek gyors feloldása. Tekintse át a csapat ellenőrzési diagramját, hogy azonosítsa a kiugró értékeket.
Példa ciklusidejű vezérlőre, amely több kiugró értékeket jelenít meg
Az alábbi táblázat több kiugró értéket mutat be, mert számos hiba végrehajtása az átlagosnál tovább tartott. Ha kivizsgálja, hogy ezek a hibák miért tartottak tovább ezeknél a hibákért, az segíthet feltárni a folyamatproblémákat. A folyamatproblémák megoldása segíthet csökkenteni a csapat szórását, és javíthatja a csapat kiszámíthatóságát.
Azt is láthatja, hogy a folyamatváltozások hogyan befolyásolják az átvezetési és ciklusidőt. Például május 15-én a csapat összehangolt erőfeszítéseket tett a WIP korlátozására és az elavult hibák kezelésére. Láthatja, hogy a szórás a dátum után szűkül, és jobb kiszámíthatóságot mutat.