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 | Azure DevOps Server 2022 | Azure DevOps Server 2020
Az összegző folyamatábrák (CFD-k) segítségével nyomon követheti a munkafolyamatot a rendszeren keresztüli munka folyamatának vizualizációja révén. Ez a cikk bemutatja, hogyan használható CFD-k, ciklusidők és átfutási idők a problémák azonosítására és a munkafolyamat hatékonyságának javítására.
- CFD beállításához vagy megtekintéséhez tekintse meg az összegző folyamatábra megtekintését és konfigurálását.
- Á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.
- CFD beállításához vagy megtekintéséhez tekintse meg az összegző folyamatábra megtekintését és konfigurálását.
- Á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.
A folyamatos folyamatú CFD az a diagram, amelyet a legtöbb olyan csapat követ, amely a lean folyamatot részesíti előnyben.
De sok csapat kombinálja a sovány eljárásokat a Scrummal vagy más módszerekkel. Lean eljárásokat használnak egy iteráció vagy sprint során. Ebben az esetben a diagram kissé másképp néz ki. Két extra elemet mutat, A folyamatos áramlású CFD az a diagram, amelyet a legtöbb csapat, amely a lean folyamatot követi, preferál.
De sok csapat kombinálja a sovány eljárásokat a Scrummal vagy más módszerekkel. Lean eljárásokat használnak egy iteráció vagy sprint során. Ebben az esetben a diagram kissé másképp néz ki. Két további, értékes információt jelenít meg, amint az a következő diagramon, a rögzített időszakú CFD-ben is látható.
Folyamatos áramlású CFD
Ez a rögzített időtartamú CFD egy befejezett sprintet mutat.
A felső sorban a futam hatóköre látható. Mivel a munkát az utolsó napra kell befejezni, a Closed állapot meredeksége azt mutatja, hogy a csapat ezen az úton halad-e. Ezt a nézetet burnup diagramként tekintheti.
A diagramon a folyamat első lépése a bal felső részben található. Az utolsó lépés a jobb alsó területen található.
Fix futamidejű CFD egy befejezett sprinthez
Grafikonmutatók
A CFD-k az állapot vagy oszlop szerint csoportosított munkaelemek számát jelenítik meg az idő függvényében. A nyomon követés két elsődleges mérőszáma 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ő. Mérje meg az egyik folyamat kezdetétől a következő folyamat elejéig mért hosszt.
Átfutási idő1
Folyamatos folyamat esetén: A kérés teljesítésének időpontja (például egy javasolt felhasználói történet hozzáadása) a kérelem befejezéséig (lezárva).
*Futamhoz vagy folyamatos áramlású folyamathoz: A kérés leadásától számított idő (mint például egy javasolt felhasználói történet hozzáadása) a kérés lezárásáig (befejezése).
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)
A folyamatban lévő munkamennyiség vagy munkaelemek 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.
Egyértelmű korreláció van az átfutási idő vagy a ciklusidő és a WIP között. A több WIP hosszabb ciklusidőt és hosszabb átfutási időt eredményez. 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ó kulcsfontosságú oka annak, hogy a munka nyomon követéséhez és kezeléséhez használt táblán wip-korlátokat állítson be.
A munkaelemek száma az adott nap teljes munkamennyiségét jeleníti meg. Rögzített idejű CFD-ben az ebben a számban bekövetkező változás az adott időszakra vonatkozó hatókör-módosítást jelent. Egy folyamatos áramlású CFD-ben a sorban lévő és egy adott napra teljesített munka teljes mennyiségét jeleníti meg.
A munka adott táblaoszlopokra való kategorizálása a folyamat egyes területeinek munkamennyiségét mutatja. Ez a nézet betekintést nyújt abba, hogy hol mozog zökkenőmentesen a munka, hol vannak blokkolások, és hol nem történik munka. Nehéz megérteni az adatok táblázatos nézetét, de a vizuális CFD segít látni, hogy mi történik a munkafolyamatban és miért.
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
Egy példa a rendszerszintű stagnálásra előfordulhat egy CFD funkcióban. A szolgáltatásokkal végzett munka hosszabb időt vehet igénybe, 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 meredekség 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. Előfordulhat, hogy a probléma azért fordul elő, mert a tesztelés hosszabb időt vesz igénybe, mint a kód írása. 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. A második munkaelem karbantartása működési rugalmasságot biztosít váratlan késések esetén. 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, hogy miben különbözik az átfutási idő és a ciklusidő. 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 folyamatban vagy megoldott állapotkategóriába lép, és befejezett állapotkategóriába lép.
Ha a csapat egy táblát használ a munka nyomon követésére és kezelésére, az oszlopok munkafolyamat-állapotra való leképezésének megértése segít hatékonyabban kezelni a munkát. A tábla beállításáról a tábla oszlopainak kezelése című témakörben olvashat.
Ha meg szeretné tudni, hogy a rendszer hogyan használja az állapotkategóriákat –Javasolt, Folyamatban, Megoldott és Befejezett –, tekintse meg a munkafolyamat-állapotokról a hátralékokban és a táblákban című témakört.
Hogyan kezeli a ciklusidő az újraaktivált munkaelemeket?
Az újraaktivált ( befejezett állapotból folyamatban lévő állapotba áthelyezett) munkaelemek esetében a ciklusidő attól az időponttól kezdődik, amikor a munkaelem első alkalommal beír egy Folyamatban vagy Megoldott állapot kategóriát, és befejezett állapotkategóriába kerül. A ciklusidő magában foglalja a teljes aktív munkaidőszakot, beleértve az újraaktiválás utáni időt is.
Példaforgatókönyv:
- Új → Aktív → Feloldva → Lezárt → Új → Aktív → lezárva
- Ciklusidő kiszámítása: Az első áttűnéstől az Aktív állapoton át a záró áttűnésig
- Teljes ciklusidő: Az aktív munkaidőszakokat és az újraaktiválás előtti lezárt állapotban töltött időt is tartalmazza
Ez a számítási módszer teljes képet ad a munkaelem befejezéséhez szükséges teljes időről, beleértve az újraaktiválás utáni újramunkát vagy extra munkát. Az átfutási idő számítása ugyanezt az elvet követi – a munkaelem-létrehozástól a befejezésig tartó teljes időszakot lefedi, függetlenül a köztes befejezett állapotoktól.
Becsülje meg a szállítási időket az átfutási és ciklusidők alapján
Használja az átlagos átfutási és ciklusidőket és szórásokat a szállítási idők becsléséhez.
Munkaelem létrehozásakor használja a csapat átlagos átfutási idejét a befejezési dátum becsléséhez. A csapat szórása a becslés variabilitását mutatja. Hasonlóképpen használja a ciklusidőt és annak szórását annak becslésére, hogy egy munkaelem mikor fejeződik be a munka megkezdése után.
Példa ciklusidő vezérlőre
A következő diagramon az átlagos ciklusidő nyolc nap, a szórás pedig hat nap. Ezekkel az adatokkal becsülje meg, 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. A szűkebb szórás kiszámíthatóbbá teszi a becsléseket.
Folyamatproblémák azonosítása
A kiugró értékek gyakran azt jelentik, hogy van egy alapvető folyamatbeli probléma. Például túl sokáig kell várni a lekéréses kérelmek áttekintésére, vagy nem lehet gyorsan kijavítani egy külső függőséget. Ellenőrizze a csapat ellenőrzési diagramját kiugró értékekért.
Példa ciklusidő widget, amely több kiugró értéket mutat
Az alábbi diagram több kiugró értéket mutat, mert egyes problémák az átlagosnál hosszabb ideig tartottak kijavítani. Ha ellenőrzi, hogy ezek a hibák miért tartottak hosszabb ideig, segíthet megtalálni a folyamatokkal kapcsolatos problémákat. A folyamatproblémák kijavítása segít csökkenteni a csapat szórását, és javítja a csapat kiszámíthatóságát.
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 azon dolgozott, hogy korlátozza a WIP-t, és kijavítsa az elavult hibákat. A szórás a dátum után szűkül, és jobb kiszámíthatóságot mutat.