Megosztás a következőn keresztül:

Scrum és ajánlott eljárások

  • Cikk

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

Futamtervezési értekezletek

A sprinttervezés nagy része a termék tulajdonosa és a csapat közötti egyeztetést foglalja magában, amely meghatározza a közelgő futam fókuszát és kezelését. Hasznos, ha a tervezési értekezletet időkeretbe foglalja, és legfeljebb 4 órára korlátozza.

Az értekezlet első részében a termék tulajdonosa találkozik a csapatával, hogy megbeszélje a sprintben esetleg szereplő felhasználói történeteket. A termék tulajdonosa információkat oszt meg, és választ ad a csapatának a történetekkel kapcsolatos kérdéseire. Ez a beszélgetés olyan részleteket fedhet fel, mint az adatforrások és a felhasználói felület elrendezése. Vagy felfedheti a válaszidőre vonatkozó elvárásokat, valamint a biztonság és a használhatóság szempontjait. A csapatnak ezeket a részleteket a hátralékelemek űrlapon kell rögzítenie. Az értekezlet ezen részében a csapat megtanulja, mit kell felépítenie.

A futamok tervezésekor más követelményeket is felfedezhet, hogy rögzítse és hozzáadja a hátralékot. Győződjön meg arról, hogy jól definiált és prioritási sorrendben van.

A sprint célnak a tervezési erőfeszítések részeként történő beállítása segíthet a csapatnak abban, hogy az egyes futamok legfontosabb elemeire összpontosíthasson.

Miután megtervezte a futamot, érdemes lehet megosztani a tervet a főbb érdekelt felekkel.

Az alábbi forrásokból tudhat meg többet:

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ükö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 az alapvető célcsoporton belül. A sprintcél segíthet a csapat irányításában is, ha ütközések merülnek fel a prioritások körül.

Tippek a lövészárkokból: Futamcélok 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 olyan hátralékelemek véletlenszerű kiválasztása, amelyek nem igazán rendelkeznek kapcsolattal, hanem egy rövid szöveg, amely rögzíti, hogy a csapatnak mit kell elérnie. Általában a termék tulajdonosa hozza létre a sprint célt, mielőtt számos elemet kiválaszt a következő futamhoz. A futam elemeinek el kell férnie a közös célhoz.

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élda:

  • Ebben a sprintben egy egyszerű felhasználói történetre összpontosítunk. Ezzel bizonyítjuk, hogy a javasolt megoldás működik.
  • Ez a futam a webhely adminisztrációs szakaszának megfelelő biztonsági funkcióinak implementálásával kapcsolatos.
  • Ez a futam a legfontosabb fizetési átjárók integrálásáról szól, hogy megkezdhessük a pénzgyűjtést.

A sprintcélok beállítása segít a csapatnak a koncentrálásban. Megkönnyíti a feladatok prioritásának meghatározását egy futamon belül, és valószínűleg segít korlátozni az érintett résztvevők és végfelhasználók számát.

A futam áttekintése során a legfontosabb kérdés, amit fel kell tennie magának, hogy sikerült-e elérnie a sprint célt. A befejezett történetek száma a második. Ha a cél megvalósul, a futam sikeres lesz, még akkor is, ha nem minden történet fejeződött be.

Közreműködött Jesse Houwing, a Visual Studio devops Ranger és az Avanade Hollandia vezető tanácsadója.

Tippek sikeres osztályozási értekezletekhez

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

  • Állapítsa meg a csapat kritériumait annak kiértékelésére, hogy mely hibákat javítsa ki, és hogyan rendelje hozzá a prioritást és a súlyosságot. A jelentős értékű funkciókkal (vagy jelentős késési költségekkel) vagy más projektkockázatokkal kapcsolatos hibákat magasabb prioritással és súlyossággal kell hozzárendelni. Tárolja a triage feltételeket más csapatdokumentumokkal, és szükség szerint frissítse.
  • 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.
  • Állítsa be a osztályozási feltételeket a fejlesztési ciklusban való helye alapján. Korai időben dönthet úgy, hogy kijavítja a legtöbb hibát, amelyet triage. A ciklus későbbi szakaszában azonban felvetheti az osztályozási feltételeket a kijavítandó hibák számának csökkentése érdekében.
  • Miután elvégezte a hiba osztályozását, rendelje hozzá egy fejlesztőhöz. A fejlesztő ezután megvizsgálhatja és meghatározhatja a javítás implementálásának módját.

Technikai adósság kezelése

Fontolja meg a hibasáv és a technikai adósság kezelését a csapat folyamatos fejlesztési tevékenységeinek részeként. Ezeket az érdekes erőforrásokat megtalálhatja:

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ás kezelése minden futamon

A csapat minden futamban megvizsgálja a hibaelmaradásban fennmaradó hibákat, és a kapacitást arra szánja, hogy az ismert hibakészletet nullára vagy nullához közelire állítsa le. Akár egy napról, egy hétről, akár az egész futamról van szó, először kijavítják a hibákat. A később, a futamon belül talált hibákat nem tekintjük a kezdeti kötelezettségvállalásnak. Hacsak nem kiemelt prioritást élveznek, a következő futam hibaelmaradási listájára kerülnek.

Számos csapat dolgozik egy kötelezettségvállaláson alapuló szervezetben. A vezetőség gyakran nagy értéket képvisel a csapat azon képességében, hogy teljesíteni tudja a kötelezettségvállalásait. A kapacitástervezés egy ismert hibakészlettel szemben determinisztikusabbá teszi a sprinttervezést, ami növeli a kötelezettségvállalások teljesítésének esélyé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

Egy olyan kultúrára áttérő szervezet, amelyben az adósságok folyamatosan megszűnnek, valószínűleg a következő kérdéssel foglalkozik: Hogyan lehet elérni, hogy a csapatok csökkentsék 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 csapatnak autonómiát ad annak meghatározásához, hogyan változnak. Az egyik lehetőség a hibakorlát használata.

Vegyük például egy mérnökenként három hibából álló hibakorlátot. Ezért 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átját, várhatóan leállítja az új funkciókon végzett munkát, és a hibakorlát alá kerül. Egy csapatnak mindig a korlátja alatt kell lennie, de a csapat dönti el, hogyan szeretné ezt megtenni. A hibakorlát biztosítja, hogy a csapatok ne viseljenek túl sokáig hibatartozást. A csapat megtanulhat azokból a hibákból, amelyek miatt a hibákat először be kell szúrni.

Ne feledje, hogy a hibakorlát a hibanaplóban szereplő hibákat jelöli. Nem tartalmaz olyan hibákat, amelyek abban a futamban találhatók és javítva vannak, amelyben a szolgáltatás ki van fejlesztve. Ezeket a hibákat visszavont munkának tekintik, nem pedig adósságnak.

Bár a hibák hozzájárulnak a technikai adóssághoz, előfordulhat, hogy 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 mind hozzájárulhatnak a technikai adóssághoz. A technikai adósság a fenti problémákból eredő további fejlesztési munkát tükrözi.

Nyomon követheti a műszaki adósságok pb-ként, felhasználói történetekként vagy hibákként való kezelését. A csapat technikai adósságok keletkezése és kezelése során elért előrehaladásának nyomon követéséhez érdemes megfontolnia, 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 a Scrum-folyamatok alkalmazásával segíti az egészséges csapatok összeállítását és karbantartását. Ők vezetnek, edzők, tanítanak és segítik a Scrum-csapatokat a Scrum-módszerek megfelelő alkalmazásá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 hogy a csapat jelentős termelékenységnövekedés felé vezessen.

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

  • Támogassa a csapatot a Scrum-folyamatok bevezetésében és követésében. Például nem szabad hagyni, hogy a Scrum napi értekezlete nyílt vitafórummá váljon, amely 45 percig tart.

  • Óvja a terméktulajdonost vagy a csapattagokat attól, hogy a futam kezdete után munkát vegyenek fel.

  • Törölje azokat a blokkolási problémákat, amelyek megakadályozzák a csapat előrehaladását. Ehhez a munkához kis feladatokat kell végrehajtania, 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 a felmerülő ütközések és problémák megoldásában, és tanuljon a folyamatból.

  • Olyan kérdéseket tehet fel, amelyek rejtett problémákat fednek fel, és megerősítik, hogy az emberek által kommunikált adatok jól érthetők az egész csapat számára.

  • Azonosítsa és védje meg a csapatot a fő problémákká váló lehetséges problémáktól. Ahogy a felfedezése után is egyszerűbb és kevésbé zavaró egy hiba kijavítása, ha kicsi és kezelhető a hiba.

  • Megakadályozza, hogy a csapat hiányos felhasználói történeteket jelenítsen meg egy sprint-felülvizsgálati értekezlet során.

  • Adatokat gyűjthet, elemezhet és bemutathat az üzleti érdekelt feleknek, hogy bemuhassa, hogyan fejlődik és fejlődik a csapat. Ha például a csapata növelte a kapott értéket, miközben kevesebb hibát generált, akkor az értéket láthatóvá teheti az üzleti érdekelt feleknek való rendszeres kommunikációval.

A Jó Scrum Masters kiváló kommunikációs, tárgyalási és konfliktuskezelési képességekkel rendelkezik vagy fejleszt. Aktívan hallgatják azokat a szavakat, amelyeket az emberek mondanak és írnak. Azt is figyelik, hogyan kézbesítik üzeneteiket, például a testbeszédüket, az arckifejezéseiket, a vokális ütemüket és más nemverbális kommunikációjukat.

Ahogy olcsóbb a hiba kijavítása a felfedezése után, a csapatproblémák kijavítása is egyszerűbb és kevésbé zavaró, ha kicsi és kezelhető, mielőtt nagyobb problémává válik.

Napi Scrum-értekezletek

A napi Scrum-értekezletek segítenek a csapatnak arra koncentrálni, hogy mit kell tennie másnap. A koncentráltság segít a csapatnak abban, hogy maximálisan teljesítse a sprinttel kapcsolatos kötelezettségvállalásokat. A Scrum-főkiszolgálónak érvényesítenie kell az értekezlet struktúráját, és gondoskodnia kell arról, hogy az időben kezdődjön, és legalább 15 perc múlva befejeződjön.

A sikeres Scrum-értekezletek három aspektusa:

  • Mindenki feláll. A felállás segít az értekezletek összpontosításában és rövidségében.
  • Időben kezdődnek és érnek véget, és minden nap ugyanabban a helyen fordulnak elő
  • Mindenki részt vesz, minden csapattag válaszol a három Scrum-kérdésre:
    • Mit értem el a legutóbbi Scrum óta?
    • Mit érhetek el a következő Scrum előtt?
    • Milyen blokkolási problémák vagy akadályok befolyásolhatják a munkámat?

Feljegyzés

A scrum-értekezletek középpontjában az a munka áll, amelyet át kell adni az egyik csapattagnak egy másik csapattagnak.

A csapattagok törekedjenek arra, hogy gyorsan és tömören válaszoljanak kérdéseikre. Példa:

"Tegnap frissítettem az osztályt, hogy tükrözze az új adatelemet, amelyet lekérünk az adatbázisból, és megkaptam, hogy megjelenjen a felületen. Ez a feladat befejeződött. Ma biztosítom, hogy az új adatelem megfelelően számítson a tárolt eljárással és a tábla többi adatelemével. Azt hiszem, ma el tudom végezni ezt a feladatot. Szükségem van valakire, aki áttekinti a számításaimat. Nincsenek akadályai és akadályai a problémáknak."

Ez a válasz azt jelzi, hogy a csapattag mit ért el, mit tervez elérni, és hogy a csapattag segítséget szeretne kérni a kód megtekintéséhez.

Kontraszt a következő példával:

Tegnap az osztályban dolgoztam, és működik. Ma dolgozom a felületen. Nincs blokkolási probléma."

A csapattag nem ad elég részletes információt arról, hogy milyen osztályon dolgoztak, és hogy milyen interfészösszetevőket fognak elvégezni. Valójában az elért szó soha nem jött létre.

Fontos, hogy senki ne szakítsa meg a jelentést. Minden személynek elegendő ideje van a három kérdés megválaszolására.

Az értekezlet után részletesebb és követő megbeszéléseket kell folytatni, amikor az emberek visszatérnek az asztalukhoz, vagy ha jelentős mennyiségű beszélgetésre van szükség, egy követő értekezleten.

Sok csapat késlelteti a megbeszéléseket a "virtuális parkoló" módszer használatával. Ahogy a témák előjönnek, hogy a csapattagok úgy vélik, hogy további megbeszélésre van szükségük, nyugodtan sétálhatnak egy rajztáblához vagy egy flipcharthoz, és felsorolhatják a tárgyat a parkolóban. Az értekezlet végén a csapat határozza meg, hogyan fogják kezelni a felsorolt elemeket.

Sprint felülvizsgálati értekezletek

A futam utolsó napján végezze el a sprint felülvizsgálati értekezleteit. A csapat bemutatja a futamban 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 megtekinteni kívánt módosításokat.

Az értekezlet alapján egyes felhasználói történetek teljesként lesznek elfogadva. A hiányos felhasználói történetek megmaradnak a termék-hátralékban. A rendszer új felhasználói történeteket ad hozzá a hátralékhoz. Mindkét történetcsoport rangsorolva lesz, és a következő futamtervezési értekezleten megbecsülheti vagy újra megbecsülheti.

Az értekezlet és a visszatekintő értekezlet után a csapat a következő futamot tervezi. Mivel az üzleti igények gyorsan változnak, a terméktulajdonossal, az ügyfelekkel és az érdekelt felekkel folytatott értekezlet előnyeit kihasználva újra áttekintheti a termékhátrallék prioritásait.

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ő értekezlete általában a futam utolsó napján, a futam felülvizsgálati értekezlete után következik be. Ebben az értekezletben a csapat megvizsgálja a Scrum végrehajtását, és hogy mi lehet szükség a finomhangolásra.

A megbeszélések alapján a csapat megváltoztathat egy vagy több folyamatot a saját hatékonyságának, termelékenységének, minőségének és elégedettségének 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.

Feljegyzés

A csapat retrospektív funkciójának támogatásához érdemes lehet telepíteni a Marketplace Retrospectives bővítményt . Ez a bővítmény támogatja a projekt mérföldköveivel kapcsolatos visszajelzések gyűjtését, a visszajelzések rendszerezését és rangsorolását, valamint a csapat időbeli fejlődését segítő végrehajtható feladatok létrehozását és nyomon követését.

Ezeket a területeket a csapatsprint retrospektívái során érdemes kezelni:

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

  • A csapat általános elégedettségét és projektfolyamatát 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, amely több olyan feladatot is el tudott végezni, amelyet csak egy személy végezhetett el a csapatban. Az elszigetelt szakértelem kritikus utat hozott létre, amely veszélyeztette a futam sikerét. Az egyes csapattagok több órát töltöttek, míg más csapattagok csalódottak voltak, hogy nem tudtak többet tenni a segítségért. A csapat a jövőben úgy döntött, hogy gyakorolja az eXtreme programozást a probléma idővel történő kijavítása érdekében.

Csapatként dolgozik annak meghatározásán, hogy egy vagy több folyamatot kell-e adaptálni, hogy minimalizálja a problémák előfordulását a futam során.

Előfordulhat, hogy a csapatnak némi munkát kell végeznie a fejlesztés végrehajtásához. Például egy csapat, amely úgy találta, hogy túl sok sikertelen build negatívan érintette magát, úgy döntött, hogy folyamatos integrációt valósít meg. Mivel nem akarták megzavarni a folyamatot, néhány órába telt a próba build beállítása, mielőtt bekapcsolták volna az éles buildben. Ennek a munkának a megjelenítéséhez létrehoztak egy csúcsot, és rendszerezték, amely a termék hátralékának többi része ellen dolgozik.