Göngyölt folyamat, átfutási idő és ciklusidő útmutatója

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Halmozott folyamatábrákat (CFD) használ a munka folyamatának figyeléséhez a rendszeren keresztül. A két elsődleges metrika, amely nyomon követhető, ciklusidő és átfutási idő, kinyerhető a diagramból. A CFD-diagramok konfigurálásához vagy megtekintéséhez lásd : Kumulatív folyamatdiagram konfigurálása.

Vagy hozzáadhatja az átfutási idő és a ciklusidő vezérlőelem-diagramokat az irányítópultokhoz.

Mintadiagramok és elsődleges metrikák

A folyamatos folyamat CFD-je biztosítja a sovány folyamatot követő csapatok által leginkább kedvelt diagramot.

Azonban sok csapat elkezdte kombinálni a lean gyakorlatokat a Scrum-tal vagy más módszertanokkal, ami azt jelenti, hogy a leant az iteráció vagy a futamok során gyakorolják. Ebben a helyzetben a diagram kissé eltérő megjelenést mutat, és két további, nagyon értékes információt biztosít a következő diagramon látható módon.

Folyamatos folyamat

Az itt látható rögzített időszak CFD egy befejezett futamhoz tartozik.

A felső sor a futamhoz beállított hatókört jelöli. Mivel a munkát a futam utolsó napjára kell befejezni, a Zárt állapot meredeksége jelzi, hogy egy csapat készen áll-e a futam befejezésére. Ennek a nézetnek a legegyszerűbb módja az írási diagram.

Az adatok mindig a folyamat első lépésével jelennek meg bal felső, a folyamat utolsó lépése pedig a jobb alsó sarokban.

Rögzített időszak CFD egy befejezett futamhoz

Diagrammetrikák

A CFD-diagramok az állapot/Kanban oszlop szerint csoportosított munkaelemek számát jelenítik meg az idő függvényében. A két elsődleges metrika, amely nyomon követhető, ciklusidő és átfutási idő, kinyerhető a diagramból.

---

Metrika

Definíció

---

Ciklusidő¹

A munka egyetlen folyamat vagy munkafolyamat állapoton keresztüli áthelyezéséhez szükséges időt méri. A számítás az egyik folyamat kezdetétől a következő folyamat elejéig tart.

Átfutási idő¹

Folyamatos folyamat esetén: Azt méri, hogy mennyi időt vesz igénybe a kérés (például egy javasolt felhasználói történet hozzáadása) a kérés befejezéséig (lezárva).

Futam vagy rögzített időtartamú folyamat esetén: Azt az időpontot méri, amikor a kérelemen végzett munka megkezdődik a munka befejezéséig (azaz az aktívtól a lezártig).

Folyamatban lévő munka

Az aktív munkamennyiséget vagy a munkaelemek számát méri.

Hatókör

Az adott időszakra lekötött munka mennyiségét jelöli. Csak a rögzített időtartamú folyamatokra vonatkozik.

---

¹ A CFD widget (Elemzés) és a beépített CFD-diagram (munkakövetési adattár) nem biztosít különálló számokat az átfutási idő és a ciklusidő alapján. Az átfutási idő és a ciklusidő widgetek azonban ezeket a számokat adják meg.

Jól meghatározott korreláció van az átfutási idő/ciklusidő és a folyamatban lévő munka (WIP) között. Minél több wip, annál hosszabb a ciklusidő, ami szintén hosszabb átfutási időt eredményez. Az ellenkezője is igaz – minél kevesebb wip, annál rövidebb a ciklus és az átfutási idő. Amikor a fejlesztői csapat kevesebb elemre összpontosít, csökkentik a ciklust és az átfutási időket. Ez a korreláció kulcsfontosságú oka annak, hogy miért lehet és kell beállítania a folyamatban lévő munkakorlátokat a Kanban táblán.

A munkaelemek száma az adott nap teljes munkamennyiségét jelzi. Egy meghatározott időszak CFD-jében ennek a számnak a változása egy adott időszakra vonatkozó hatókörváltozást jelez. Egy folyamatos folyamat CFD-jében az üzenetsor teljes munkamennyiségét jelzi, és egy adott napon befejeződött.

A munka adott Kanban-táblaoszlopokba való felbontásával megtekintheti, hogy hol tart a munka. Ez a nézet bemutatja, hogy hol mozog zökkenőmentesen a munka, hol vannak blokkolások, és hol nem végeznek semmilyen munkát. Nehéz megfejteni az adatok táblázatos nézetét, a vizuális CFD-diagram azonban azt mutatja, hogy valami történik egy adott módon.

Problémák azonosítása, megfelelő műveletek végrehajtása

A CFD több konkrét kérdésre is választ ad, és a válasz alapján intézkedéseket lehet tenni a rendszeren keresztüli munka áthelyezésének folyamatának módosítására. Tekintsük át ezeket a kérdéseket.

A csapat időben befejezi a munkát?

Ez a kérdés csak a határozott idejű CFD-kre vonatkozik. A Kanban-tábla utolsó oszlopában található munka görbéjének (vagy előrehaladásának) áttekintésével megértheti.

Ebben a forgatókönyvben célszerű lehet csökkenteni a munka hatókörét az iterációban, ha egyértelmű, hogy a munka állandó ütemben nem fejeződik be elég gyorsan. Ez azt jelezheti, hogy a munkát alábecsülték, és a következő futamtervezésbe kell belevetni.

Lehetnek azonban más okok is, amelyeket a diagram más adatainak megvizsgálásával lehet meghatározni.

Hogyan halad a munka folyamata?

A csapat egyenletes ütemben végzi a munkát? Ennek egyik módja, ha megvizsgáljuk a diagram különböző oszlopai közötti térközt. Hasonló vagy egységes távolságra vannak egymástól az elejétől a végéig? Úgy tűnik, hogy egy oszlop több napos időszakon keresztül sík vonalú? Vagy úgy tűnik, hogy "dudor"?

Mura, a sovány kifejezés sík vonalak és dudorok, azt jelenti, egyenetlenség, és azt jelzi, egyfajta hulladék (Muda) a rendszerben. A rendszer egyenetlensége miatt a CFD-ben dudorok jelennek meg.

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 nevezzük, és a munka tervének része.

Két probléma jelenik meg vizuálisan a sík vonalak és a dudorok.

Lapos vonalak jelennek meg, ha a csapat nem frissíti a munkáját rendszeres ütemben. A Kanban tábla biztosítja a leggyorsabb módot a munka egyik oszlopról a másikra való áttűnésére.
Egysíkú vonalak akkor is megjelenhetnek, ha egy vagy több folyamat munkája a tervezettnél hosszabb időt vesz igénybe. Az egysíkú vonalak a rendszer számos részén megjelennek, mert ha a rendszernek csak egy vagy két része problémába ütközik, akkor egy dudor jelenik meg.

Sík vonalak

A hibák akkor fordulnak elő, ha a munka a rendszer egy részén épül fel, és nem halad végig egy folyamaton.
Előfordulhat például, hogy a tesztelés hosszú ideig tart, míg a fejlesztés rövidebb időt vesz igénybe, ami miatt a munka a fejlesztési állapotban halmozódik fel (a dudorok azt jelzik, hogy egy sikeres lépés problémába ütközik, nem feltétlenül az a lépés, amelyben a dudor végbemegy).

Dudorok

Hogyan oldható meg a folyamatproblémák?

Az időről időre történő frissítések hiányának problémáját a következő módon oldhatja meg:

• Napi stand-upok.
• Egyéb rendszeres értekezletek.
• Napi emlé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 sík vonalak azt jelzik, hogy a rendszer egészében leállt a munka. A kiváltó okok a következőek lehetnek:

• Folyamatszintű dugulások.
• Hosszú ideig tartó folyamatok.
• A munka más lehetőségekre vált, amelyek nincsenek rögzítve a táblán.

Egy példa a rendszerszintű síkvonalasságra a CFD funkciókkal is előfordulhat. A szolgáltatásokkal végzett munka sokkal 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 az esetekben vagy a meredekség várható (mint a fenti példában), vagy a probléma jól ismert, és a csapat már problémaként kezeli. Ismert probléma esetén a probléma megoldása nem tartozik a jelen cikk hatókörébe.

A Teams proaktív módon meg tudja oldani a CFD-ként megjelenő problémákat. Attól függően, hogy hol fordul elő a dudor, a javítás eltérő lehet. Tegyük fel például, hogy a dudor a fejlesztési folyamatban fordul elő. Előfordulhat, hogy a probléma azért fordul elő, mert a tesztek futtatása sokkal tovább tart, mint a kód írása. A tesztelők nagy számú hibát is megtalálhatnak. Amikor folyamatosan áttérnek a fejlesztőkre, a fejlesztők öröklik az aktív munka egyre bővülő listáját.

A probléma megoldásának két lehetséges módja: 1) A fejlesztők váltása a fejlesztési folyamatról a tesztelési folyamatra, amíg a bulge megszűnik, vagy 2) megváltoztatják a munka sorrendjét, hogy a gyorsan elvégezhető munka összefonódjon a hosszabb ideig tartó munkával. Keressen egyszerű megoldásokat a dudorok kiküszöbölésére.

Feljegyzés

Mivel számos különböző forgatókönyv fordulhat elő, amelyek miatt a munka egyenetlenül halad, kritikus fontosságú a probléma tényleges elemzése. A CFD azt fogja mondani, hogy van egy probléma, és körülbelül hol van, de meg kell vizsgálni, hogy eljut a kiváltó ok(ok). Az itt található útmutatás olyan javasolt műveleteket jelez, amelyek konkrét problémákat oldanak meg, de amelyek nem feltétlenül vonatkoznak az Ön helyzetére.

Megváltozott a hatókör?

A hatókör módosításai csak a rögzített időszak CFD-kre vonatkoznak. A diagram felső sora a munka hatókörét jelzi. A futam előre be van töltve az első napon elvégzendő munkával. A felső sor módosításai azt jelzik, hogy a munka hozzá lett adva vagy el lett távolítva.

Az egyetlen olyan eset, amikor nem tudja nyomon követni a hatókör változásait a CFD-vel, akkor történik, ha ugyanazon a napon ugyanannyi munkaelemet adnak hozzá, mint az ugyanazon a napon eltávolítottak. A vonal továbbra is lapos marad. Több diagram összehasonlítása egymással. Az adott problémák monitorozása. A futamok leírásának megtekintése/konfigurálása a hatókör változásainak monitorozásához.

Túl sok wip?

Könnyedén ellenőrizheti , hogy túllépték-e a WIP-korlátokat a Kanban táblából. A CFD-ből is figyelheti.

Általában nagy mennyiségű WIP jelenik meg függőleges dudorként. Minél tovább van nagy mennyiségű WIP, annál nagyobb lesz a dudor, hogy oválissá váljon. Ez azt jelzi, hogy a WIP negatívan befolyásolja a ciklust és az átfutási időt.

Íme egy jó ökölszabály a folyamatban lévő munkákhoz. Csapattagonként legfeljebb két elem lehet folyamatban egy adott időpontban. A két elem és a szigorúbb korlátok fő oka az, hogy a valóság gyakran behatol bármilyen szoftverfejlesztési folyamatba.

Néha időt vesz igénybe az érdekelt felektől származó információk lekérése, vagy több időt vesz igénybe a szükséges szoftverek beszerzése. A munka leállásának számos oka lehet. Ha egy második munkaelemet szeretne kimutatásra, hogy némi mozgásteret biztosítsunk. 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 nagy számú elem van folyamatban, az ezen elemeken dolgozó személynek nehézséget okoz a környezetváltás. Valószínűbb, hogy elfelejtik, hogy mit csináltak, és hibák léphetnek fel.

Átfutási idő és ciklusidő

Az alábbi ábra bemutatja, hogy az átfutási idő miben különbözik a ciklusidőtől. Az átfutási idő a munkaelem-létrehozástól a Befejezett állapot megadásáig lesz kiszámítva. A ciklusidő a Folyamatban vagy a Megoldott állapot kategória első beírásától számítható ki, hogy befejezett állapotkategóriát adjon meg.

Az átfutási idő és a ciklusidő illusztrációja

Ha egy munkaelem befejezett állapotba kerül, majd újraaktiválódik, a javasolt, folyamatban vagy megoldott állapotban töltött minden további idő hozzájárul az átfutási/ciklusidőhöz, amikor másodszorra befejezett állapotkategóriát ad meg.

Ha a csapat a Kanban táblát használja, tudnia kell, hogy a Kanban-oszlopok hogyan lesznek megfeleltetve a munkafolyamat állapotainak. A Kanban-tábla konfigurálásáról további információt az Oszlopok hozzáadása című témakörben talál.

Ha többet szeretne megtudni arról, hogy a rendszer hogyan használja az állapotkategóriákat (Javasolt, Folyamatban, Megoldott és Befejezve), tekintse meg a munkafolyamat-állapotokat és az állapotkategóriákat.

Tervezés az átfutási/ciklusidők alapján becsült szállítási idő alapján

A szállítási idő becsléséhez használhatja az átlagos átfutási/ciklusidőket és szórásokat.

Munkaelem létrehozásakor a csapat átlagos átfutási ideje alapján megbecsülheti, hogy a csapat mikor fogja elvégezni a munkaelemet. A csapat szórása megmutatja a becslés variabilitását. Hasonlóképpen használhatja a ciklusidőt és annak szórását a munkaelem befejezésének becsléséhez, amint a munka elkezdődött.

Az alábbi diagramon az átlagos ciklusidő nyolc nap. A szórás +/- hat nap. Ezekkel az adatokkal megbecsülhetjük, 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.

Példa ciklusidő vezérlőre

Folyamatproblémák azonosítása

Tekintse át a csapat ellenőrzési diagramját a kiugró értékekről. A kiugró értékek gyakran egy mögöttes folyamatproblémát jelentenek. Várjon például túl sokáig a pr-felülvizsgálatok elvégzéséhez, vagy ne oldjon fel gyorsan egy külső függőséget.

Ahogy az alábbi diagramon is látható, amely több kiugró hibát mutat, több hiba is tovább tartott, mint a csapat átlaga. Ha megvizsgálja, hogy ezek a hibák miért tartottak hosszabb ideig, segíthet feltárni a folyamatokkal kapcsolatos problémákat. A folyamatproblémák kezelése segíthet csökkenteni a csapat szórását, és javítani a csapat kiszámíthatóságát.

Példa ciklusidejű vezérlőre, amely több kiugró értékeket jelenít meg

Azt is láthatja, hogy a folyamat változásai hogyan befolyásolják az átfutási és a ciklusidőt. Május 15-én például a csapat összehangoltan igyekezett korlátozni a WIP-t, és elhárítani az elavult hibákat. Láthatja, hogy a szórás a dátum után szűkül, és jobb kiszámíthatóságot mutat.

Következő lépések

Az összesített folyamatdiagramok konfigurálása vagy átfutási idő vagy ciklusidő diagram konfigurálása