A sprint és a scrum ajánlott eljárásai

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

A Scrum egy agilis keretrendszer, amely segít a csapatoknak növekményes értéket nyújtani az időszeletelt futamokon keresztül. Ez a cikk a sprinttervezés, a napi Scrum-értekezletek, a futamértékelések, a visszatekintések, a hiba triage és a Scrum Master azure DevOps-szerepkörének ajánlott eljárásait ismerteti.

Futamtervezési értekezletek

A sprinttervezés során a termék tulajdonosa és a csapat közötti tárgyalások határozzák meg a közelgő futam fókuszát és munkáját. A tervezési értekezlet időkerete legfeljebb 4 óra.

Az értekezlet első részében a termék tulajdonosa ismerteti azokat a felhasználói történeteket, amelyek szerepelhetnek a futamban, információkat oszt meg és választ ad a kérdésekre. Ezek a beszélgetések olyan részleteket fedhetnek fel, mint az adatforrások, a felhasználói felület elrendezése, a válaszidőre vonatkozó elvárások, valamint a biztonsági vagy használhatósági szempontok. Rögzítse ezeket a részleteket a teendőlista-eleműrlapon. Az értekezlet ezen része tisztázza, hogy mit kell felépítenie a csapatnak.

Tervezés közben további követelményeket fedezhet fel, amelyeket hozzáadhat a hátralékhoz. Tartsa a hátralékot jól definiálva és prioritási sorrendben. A sprintcél beállítása segít a csapatnak az egyes futamok legfontosabb elemeire koncentrálni.

A futam megtervezése után megoszthatja a tervet a főbb érdekelt felekkel.

További információkért lásd:

Sprintcélok beállítása

A Scrum-csapatok sprint célokat használnak a sprinttevékenységek összpontosításához. Ezt a célt gyakran a futamtervezési értekezlet során tűzik ki. A cél összefoglalja, hogy a csapat mit szeretne elérni a futam végére. A cél explicit megjelölésével közös megértést hozhat létre a csapaton belül, és segít a döntések irányításában, amikor ütközések merülnek fel a prioritások körül.

Tippek a lövészárkokból: A futam céljainak meghatározása

A sprint cél határozza meg, hogy a termék tulajdonosa és a csapat mit tekint a végső célnak a futam elvégzéséhez. Ez nem a nem kapcsolódó hátralékelemek véletlenszerű kiválasztása, hanem egy rövid utasítás, amely rögzíti, hogy mit kell elérnie a csapatnak. Általában a termék tulajdonosa határozza meg a futam célját, mielőtt kiválasztja a következő futam elemeit. A sprint elemeinek bele kell férniük a közös cél eléréséhez.

A sprintcélok funkcióorientáltak lehetnek, de nagy folyamatösszetevővel is rendelkezhetnek, például az üzembe helyezés automatizálásával vagy a tesztelés automatizálásával.

Például:

  • Ez a sprint egy egyszerű felhasználói történetre összpontosít, amely bizonyítja, hogy a javasolt megoldás működik.
  • Ez a sprint olyan biztonsági funkciókat implementál, amelyek megfelelően védik a webhely adminisztrációs szakaszát.
  • Ez a sprint integrálja a legfontosabb fizetési átjárókat, hogy a csapat megkezdhesse a kifizetések gyűjtését.

A sprintcélok beállítása segít a csapatnak koncentrálni, egyszerűbbé teszi a feladatok rangsorolását egy futamon belül, és korlátozza az érintett résztvevők számát.

A futam áttekintése során a legfontosabb kérdés az, hogy elérte-e a futam célját. A befejezett történetek száma a második. Ha a cél teljesül, a futam sikeres lesz, még akkor is, ha nem minden történet befejeződött.

Tippek a sikeres triage-értekezletekhez

A hibák kijavítása kompromisszumot jelent más munkákkal. A triage értekezlettel meghatározhatja, hogy az egyes hibák mennyire fontosak a projekt hatókörével, költségvetésével és ütemezésével kapcsolatos egyéb prioritásokhoz.

  • A kijavítandó hibák kiértékelésére, valamint a prioritás és a súlyosság hozzárendelésére vonatkozó feltételek meghatározása. A nagy értékű funkciókkal (vagy jelentős késési költségekkel) vagy más projektkockázatokkal kapcsolatos hibáknak nagyobb prioritást és súlyosságot kell kapniuk. Tárolja a triage kritériumokat a többi csapatdokumentummal együtt, és szükség szerint frissítse őket.
  • Az osztályozási feltételek segítségével meghatározhatja, hogy mely hibákat kell kijavítani, és hogyan állíthatja be az állapotukat, prioritásukat, súlyosságukat és egyéb mezőiket.
  • Módosítsa a feltételeket annak alapján, hogy hol van a fejlesztési ciklusban. Kezdetben kijavíthatja azokat a hibákat, amelyeket előzetesen felmér. A ciklus későbbi szakaszában emelje meg a mércét, hogy csökkentse a kijavítandó hibák számát.
  • A hiba osztályozása után rendelje hozzá egy fejlesztőhöz a javítás kivizsgálásához és implementálásához.

Technikai adósság kezelése

A hibasáv és a technikai adósságok kezelése legyen a csapat folyamatos fejlesztési tevékenységeinek része. Az alábbi források hasznos útmutatást nyújtanak:

Tippek a lövészárkokból: Hibakezelés

Agilis Hibakezelés: Nem Oxymoron
készítette: Gregg Boer, a Visual Studio Cloud Services vezető programmenedzsere a Microsoftnál

Minden ismert hibatartozást minden sprint során kezeljünk.

A csapat minden sprintben áttekinti a hibajegy-nyilvántartásban fennmaradó hibákat, és a kapacitást arra szánja, hogy az ismert hibakészletet nullára vagy nullához közelire csökkentsék le. Függetlenül attól, hogy ez a folyamat egy napot, egy hetet vagy a teljes futamot vesz igénybe, a csapat először kijavítja a hibákat. A futam későbbi részében talált hibák nem részei a kezdeti kötelezettségvállalásnak. Hacsak nem kiemeltek, a következő futam hibaelmaradási listájára kerülnek.

Számos csapat olyan kötelezettségvállalásalapú szervezetekben dolgozik, ahol a vezetőség értékeli, hogy a csapat képes-e teljesíteni a kötelezettségvállalásokat. A kapacitás tervezése a meglévő hibák alapján determináltabbá teszi a sprinttervezést, és megkönnyíti a vállalt kötelezettségek betartását. A futam során felfedezett új hibák nem részei a kezdeti kötelezettségvállalásnak, és a következő futamot is meg lehet oldani.

Hibatartozás kezelése egy vállalaton belül

Azok a szervezetek, amelyek olyan kultúrára váltanak, ahol folyamatosan megszüntetik az adósságot, gyakran szembesülnek ezzel a kérdéssel: Hogyan lehet elérni, hogy a csapatok csökkentsek a hibaszámukat anélkül, hogy pontosan megmondanák nekik, hogy mit tegyenek? A vezetőség azt szeretné, hogy a csapat megváltozzon, de a csapat önállóságot ad annak meghatározásához, hogyan. Az egyik lehetőség a bogársapka használata.

Vegyük például egy mérnökenként három hibából álló hibakorlátot. Egy 10 fős csapatnak nem szabad 30-nál több hibával rendelkeznie a hibanaplójában. Ha a csapat túllépi a korlátot, leáll az új funkciók fejlesztése, amíg a korlát alá nem kerül. A csapatnak mindig a saját korlátja alatt kell maradnia, de maga dönti el, hogyan éri el ezt. A hibakorlát biztosítja, hogy a csapatok ne hordozzák túl sokáig a hibaadósságot, és tanuljanak az eredeti hibákból.

A hibakorlát csak a hibanaplóban szereplő hibákat fedi le. A sprintben talált és kijavított hibák, amelyekben egy funkciót fejlesztenek, visszavont munkának minősülnek, nem pedig adósságnak.

Bár a hibák hozzájárulnak a technikai adóssághoz, nem minden adósságot képviselnek. A gyenge szoftvertervezés, a rosszul megírt kód vagy a rövid távú javítások is hozzájárulnak a technikai adóssághoz – ez a problémákból eredő további fejlesztési munka.

Kövesse nyomon a műszaki adósság kezelését termékelemek, felhasználói történetek vagy hibák formájában. A technikai adósságok keletkezése és kezelése során elért előrehaladás nyomon követéséhez fontolja meg, hogyan kategorizálhatja a munkaelemet és a nyomon követni kívánt részleteket. Bármely munkaelemhez címkéket adhat hozzá, hogy a kívánt kategóriába csoportosítsa.

A Scrum Master szerepköre

A Scrum Masters Scrum-folyamatok alkalmazásával egészséges csapatokat hozhat létre és tart fenn. Ők vezetnek, edzők, tanítják és segítik a Scrum-csapatokat a Scrum-módszerek megfelelő használatában. A Scrum Masters emellett változásügynökként is működik, hogy segítsen a csapatoknak leküzdeni a nehézségeket, és jelentős termelékenységnövekedést eredményezni.

A Scrum Masters fő feladatai a következők:

  • Támogatja a csapatot a Scrum-folyamatok bevezetésében és követésében. Ne hagyja például, hogy a Scrum napi értekezlete nyílt vitafórummá váljon, amely 45 percig tart.
  • A futam megkezdése után akadályozza meg, hogy a terméktulajdonos vagy a csapattagok új munkát adjanak hozzá.
  • Törölje a haladást megakadályozó blokkolási problémákat. Ez a munka kis feladatok elvégzését igényelheti, például egy új buildelési számítógép megrendelésének jóváhagyását vagy egy ütközés feloldását a csapaton belül.
  • Segítsen a csapatnak megoldani a felmerülő ütközéseket és problémákat, és tanuljon a folyamatból.
  • Olyan kérdéseket tehet fel, amelyek rejtett problémákat fednek fel, és megerősítik, hogy a kommunikációt az egész csapat jól ismeri.
  • A lehetséges problémák azonosítása és kezelése, mielőtt súlyos problémákká válnának. Könnyebb és kevésbé zavaró megoldani a csapatproblémát, amikor az kicsi és kezelhető.
  • Akadályozza meg, hogy a csapat hiányos felhasználói történeteket mutasson be egy sprint áttekintő értekezleten.
  • Adatokat gyűjthet, elemezhet és jeleníthet meg az üzleti érdekelt feleknek, hogy bemuhassa, hogyan fejlődik a csapat. Ha például a csapata növelte az általa nyújtott értéket, miközben kevesebb hibát generált, akkor ezt a javulást láthatóvá teheti a rendszeres kommunikációval.

A Jó Scrum Masters kiváló kommunikációs, tárgyalási és konfliktuskezelési képességeket fejleszt. Aktívan hallgatják az emberek által mondott és írt szavakat, valamint az üzenetek kézbesítésének módját – testbeszédet, arckifejezéseket, vokális ütemet és más nemverbális kommunikációt.

Napi Scrum-értekezletek

A Napi Scrum-értekezletek segítségével a csapat a következő teendőkre összpontosíthat. A Scrum-főkiszolgáló kikényszeríti az értekezlet struktúráját, és biztosítja, hogy az időben indul, és legalább 15 perc múlva befejeződik.

A sikeres Scrum-értekezletek három aspektusa:

  • Mindenki feláll. Az álló helyzetben az értekezlet koncentrált és rövid marad.
  • Az értekezlet minden nap ugyanabban az időpontban és helyen kezdődik és fejeződik be.
  • Mindenki részt vesz a programban. Minden csapattag válaszol a három Scrum-kérdésre:
    • Mit értem el a legutóbbi Scrum óta?
    • Mit fogok elérni a következő Scrum előtt?
    • Milyen blokkolási problémák vagy akadályok befolyásolhatják a munkámat?

Megjegyzés

A Scrum-értekezletek középpontjában az a munka áll, amelyet át kell adni az egyik csapattagból a másikba.

A csapattagok gyorsan és tömören válaszolnak kérdéseikre. A jó válaszok azt jelzik, hogy mi fejeződött be, mi következik, és hogy szükség van-e segítségre vagy a letiltás feloldására. Kerülje az olyan homályos válaszokat, mint a "Dolgoztam az osztályon" – adja meg, hogy melyik munkaelem és mi marad.

Jelentések bemutatása során senki nem szakítja félbe. Az értekezlet utánra tartogassa a részletes megbeszéléseket. Sok csapat használ egy "gyűjtőtáblát" – egy rajztáblát vagy egy flipchartot, ahol az utánkövetendő témák megjelennek az értekezlet során, és utána foglalkoznak velük.

Sprint felülvizsgálati értekezletek

A futam utolsó napján sprint felülvizsgálati értekezleteket tart. A csapat bemutatja a sprint során befejezett termék-hátralékelemeket. A terméktulajdonos, az ügyfelek és az érdekelt felek elfogadják az elvárásaiknak megfelelő felhasználói történeteket, és azonosítják az új követelményeket. Az ügyfelek gyakran jobban megértik az igényeiket a bemutatók megtekintése után, és azonosíthatják a kívánt módosításokat.

Az értekezlet alapján fogadja el a felhasználói történeteket befejezettként. Őrizze meg a hiányos felhasználói történeteket a termék hátralékában, és adjon hozzá új felhasználói történeteket. Rangsorolja mindkét történetcsoportot, és becsülje meg vagy becsülje meg újra őket a következő futamtervezési értekezleten.

Az értekezlet és a visszatekintés után a csapat a következő futamot tervezi. Mivel az üzleti igények gyorsan változnak, ezen az értekezleten áttekintheti a termékhátrallék prioritásait a termék tulajdonosával, az ügyfelekkel és az érdekelt felekkel.

Sprint visszatekintő értekezletek

A visszatekintők, ha jól és rendszeres időközönként hajtják végre, támogatják a folyamatos fejlődést.

A futam visszatekintése általában a futam utolsó napján, a futam felülvizsgálati értekezlete után történik. Ebben az értekezletben a csapat megvizsgálja a Scrum végrehajtását, és azt, hogy mit kell módosítania.

A megbeszélések alapján a csapat megváltoztathat egy vagy több folyamatot a hatékonyság, a termelékenység, a minőség és az elégedettség javítása érdekében. Ez az értekezlet és az ebből eredő fejlesztések kritikus fontosságúak az önszervezés agilis alapelve szempontjából.

Megjegyzés

A csapat visszatekintő funkciójának támogatásához érdemes lehet telepíteni a Marketplace Retrospektívs bővítményt. Ez a bővítmény segítséget nyújt a projekt mérföldköveivel kapcsolatos visszajelzések gyűjtésében, a visszajelzések rendszerezésében és rangsorolásában, valamint végrehajtható feladatok létrehozásában, amelyek segítenek a csapatnak az időbeli fejlődésben.

A futamok visszatekintése során ezeket a területeket kell kezelnie:

  • A csapat hatékonyságát, termelékenységét és minőségét befolyásoló problémák.

  • A csapat elégedettségét és a projektfolyamatot befolyásoló elemek.

  • Mi okozta a hiányos teendőlista-elemeket? Milyen lépéseket tehet a csapat, hogy a jövőben megelőzze ezeket a problémákat?

    Vegyük például azt a csapatot, amelynek több feladata csak egyetlen személy által volt végezhető. Az elszigetelt szakértelem kritikus utat hozott létre, amely veszélyeztette a futam sikerét. Ez a csapattag több órát töltött, míg más tagok nem tudtak segíteni. A csapat úgy döntött, hogy eXtreme programozási gyakorolja a probléma időbeli megoldásához.

Csapatként határozza meg, hogy egy vagy több folyamatot kell-e igazítani a futam során felmerülő problémák minimalizálása érdekében.

Előfordulhat, hogy a csapatnak is dolgoznia kell a fejlesztés megvalósítása érdekében. A túl sok sikertelen build által negatívan érintett csapat például úgy döntött, hogy folyamatos integrációt valósít meg. Beállítanak egy tesztverziót, a művelet előtt éles környezetben kapcsolják be. A munka ábrázolásához létrehoztak egy "spike"-ot, és elrendezték a termék backlog többi részéhez képest.

Kapcsolódó tartalom

  • Last updated on