Munka a Scrummal

Felhasználói történet

A felhasználói történetek hatékony módja a fejlesztés alatt álló szoftverekkel szemben támasztott követelmények megfogalmazásának. Az ilyen történetek rövid tanácsokat tartalmaznak a szoftver felhasználója nevében.

Mivel a Scrum módszertanban a célok kitűzése általában az ügyfél vagy a szoftvertulajdonos előjoga, ezeket tekintik a fejlesztési folyamat befolyásolásának fő módjának. Minden felhasználói történet korlátozza a szöveg mennyiségét és a megjelenítés összetettségét. A történelmet legtöbbször egy kis lapra írják, ami önmagában is korlátozza a terjedelmet.

A felhasználói történeteknek köszönhetően dokumentálhatja az ügyfél kívánságait, és gyorsan reagálhat a piaci igényekre.

A User Story-t a követelmények leegyszerűsített mértékének kell tekinteni, mert nem tartalmaz átvételi tesztelési eljárást. A felhasználói történet összeállításának meg kell felelnie a felvételi eljárásnak. Ez biztosítja, hogy a felhasználói történet elérje célját.

A történet felépítése a következőképpen néz ki: „Felhasználóként <felhasználótípus> <műveletet szeretnék végrehajtani az <eredmény> elérése érdekében” (Terméktulajdonosként szeretnék ...). Egy ilyen szerkezet nemcsak egyszerű, hanem mindenki számára érthető is.

A felhasználói történetek használatának előnyei:

• A történetek kicsik és könnyen létrehozhatók.
• Segítsen minden érdekelt felet megvitatni a projekttel kapcsolatos munkát és annak támogatását.
• Nem igényel állandó karbantartást.
• Csak használat esetén releváns.
• Az ügyféllel való interakció javítása.
• Nekik köszönhetően a projektet kis szakaszokra oszthatja.
• Megkönnyíti a rosszul értelmezett követelményeket támasztó projekteken végzett munkát.
• A feladatkiértékelés egyszerűsítése.

A felhasználói történetek hátrányai:

• Előzetes megállapodás nélkül az eljárások megnehezíthetik a megállapodás alapjaként való felhasználását.
• Használatuk szoros kapcsolatot igényel az ügyféllel a teljes projekt során, ami néha megnehezíti a munkafolyamatot.
• Hátrányuk van a nagy projektek méretezésekor.
• Közvetlenül a fejlesztők szakmai szintjéhez kapcsolódik.
• Vita indítására szolgál, de nem zárhatja le a vitát, és nem használják rendszerdokumentációhoz.

Hátralék

A termékhátralék az aktuális feladatokat jelenti lista formájában, prioritási sorrendben összeállítva. A lista a projekt útiterve (roadmap) és az abban rögzített pontok alapján kerül kialakításra. A legfontosabb feladatok általában a lista elején vannak. Ez szükséges annak megértéséhez, hogy melyik munkát kell először elvégezni.

A fejlesztőcsapat az ügyfél kívánságaitól függetlenül, de képzettsége és korábbi sprintjei tapasztalatai alapján választja meg a lemaradási feladatok teljesítésének sebességét. Rendkívül nem kívánatos a programozók „beállítása”. A csapat maga választja ki a feladatokat a lemaradásból saját szempontjai és lehetőségei szerint. A végrehajtás megszakítás nélkül (Kanban) vagy több iteráció (Scrum) nélkül megy végbe.

Két fontos lemaradási feltétel

A termékhátralék magja egy ütemtervből, javaslatokból és végrehajtási feltételekből áll. Az epikák feltételeket és felhasználói történetet tartalmaznak. Nézzünk meg közelebbről egy tipikus ütemterv-példát.

A „Teams in Space” weboldal létrehozása az útiterv első javaslata. Eposzokra kell osztani (az ábrán ezek zöld, kék és türkiz színnel vannak feltüntetve), és mindegyik eposzhoz egy felhasználói történetet.

A szoftver vásárlója egy listát alkot több felhasználói történetből. Szükség esetén módosíthatja a történetek végrehajtásának sorrendjét, így a fejlesztők először az egyik legfontosabb eposzkal foglalkoznak (balra), vagy ellenőrizhetik, hogyan működik a kedvezményes jegyfoglalás. Ehhez meg kell valósítania az epikus történeteket (jobbra). Mindkét lehetőség megtekinthető alább.

Milyen tényezők alapján kell prioritást adnia az ügyfélnek?

• Relevancia a felhasználók számára.
• A visszajelzés jelenléte.
• A fejlesztés összetettsége.
• A feladatok közötti kapcsolat (a "B" teljesítéséhez először meg kell tennie az "A"-t).

A munka prioritásait a megrendelő határozza meg, de erről más felek is elmondhatják véleményüket. A lemaradás sikere többek között az ügyfelek és a programozók véleményén múlik. Együtt jobb eredményeket érhetnek el, és biztosíthatják a késztermék időben történő szállítását.

Hogyan lehet lemaradást tartani

Ha a lemaradás már létrejött, akkor ezt követően a további munka során rendszeresen módosítani kell. A szoftvervásárlónak minden új iteráció tervezése előtt meg kell győződnie arról, hogy a hátralékot megfelelően összeállította. Ez segít tisztázni a prioritásokat, vagy megváltoztatni valamit az utolsó iteráció elemzése után. A lemaradás módosítását az Agilis programban néha „ápolásnak”, „finomításnak” vagy „hátralék karbantartásnak” nevezik.

Ha már viszonylag nagy a lemaradás, akkor az ügyfélnek rövid és hosszú távú végrehajtás szerint kell csoportosítania a feladatokat. A rövid távú megbízásokat alaposan meg kell vizsgálni, mielőtt megkapják ezt a státuszt. Meg kell alkotnia egy felhasználói történetet, meg kell találnia a csapaton belüli összes árnyalatot.

Ami a hosszú távú feladatokat illeti, nagyon kívánatos, hogy a fejlesztők értékeljék őket. Így könnyebb lesz a rangsorolás. Talán valami megváltozik, de a csapat jobban megérti a feladatokat, és gyorsabban végzi el a munkát.

A lemaradás fontos elem az ügyfél és a programozó csapat között. Az ügyfél mindig módosíthatja a prioritásokat az ügyfelek visszajelzései, előrejelzései vagy új követelmények alapján.

Javasoljuk, hogy kerülje a változtatásokat közvetlenül a működés közben. Ez rossz hatással van a programozók munkafolyamatára és érzelmi állapotára.

Sprintel

A sprint egy rövid időszak, amely alatt előre egyeztetett mennyiségű munkát kell elvégezni. A sprintek Scrum és Agile módszertanon alapulnak. A megfelelő sprintek kiválasztása segít egy agilis csapatnak minőségi szoftver fejlesztésében.

„A Scrum használatával több iterációban, egyértelmű időtartammal fejleszthet egy terméket – sprintekben. Segít a nagy projekteket kisebb feladatokra bontani” – mondja Megan Cook, az Atlassian Jira vezetője.

Hogyan tervezi és hajtja végre a sprinteket a Scrum?

A Scrum módszertan készítői szerint a leendő sprint megtervezéséhez mindenkinek külön megbeszélésen kell találkoznia. Ezen az eseményen a csapattagoknak két fő kérdésre kell választ találniuk: mit kell tenni ebben a sprintben, és hogyan lehet a legjobban megtenni?

A munkafeladatok listájának meghatározásában a szoftver megrendelője, a Scrum master és a programozók vesznek részt. Az ügyfél ismerteti a sprint célját és a hátralékos feladatokat.

Ezután a csapat kidolgoz egy tervet, amely szerint a sprintben a feladatokat teljesítik. Ezt a tervet a kiválasztott munkaelemekkel együtt sprint hátraléknak nevezzük. A tervezési értekezlet után a csapat munkához lát. A fejlesztők a lemaradásból választják ki a feladatokat, a munka befejeztével az egyes feladatok állapota „Folyamatban”-ról „Kész”-re változik.

A sprint során a csapat napi Scrum megbeszéléseket (stand-up) tart, hogy megvitassák az aktuális kérdéseket és az előrehaladást. Az ilyen találkozókra azért van szükség, hogy azonosítsák azokat a nehézségeket, amelyek befolyásolhatják a sprint teljesítését.

Ha a sprint befejeződött, akkor a csapat az eredmények áttekintésén (demó) mutatja be munkája eredményét. Az eredményekkel a projekt minden résztvevője megismerkedhet. Az ismerkedést meg kell tenni, mielőtt a kész kódot egyesítené az éles környezetbe.

A retrospektív a sprintek ciklusát zárja be. Ezen a csapat azonosítja azokat a területeket, amelyeken javítani kell egy jövőbeli sprint során.

Mire kell figyelni és mit nem

A legtöbb fiatal csapat nehezen tudja először bevezetni a sprinteket a munkafolyamatába. A problémák elkerülése érdekében javasoljuk, hogy tekintse át a kiemelt figyelmet igénylő műveletek listáját.

Mit kell csinálnunk:

• Ellenőrizze, hogy a csapat megértette-e a sprint célját és a sikerét. Ez szükséges ahhoz, hogy mindenki együtt haladjon a sikeres eredmény felé.
• Tiszta és érthető lemaradásra van szükség. Ha a lemaradást nem karbantartották megfelelően, ez olyan problémává válhat, amely károsíthatja a munkafolyamatot.
• Győződjön meg arról, hogy a munka ütemére vonatkozó becslése helyes, figyelembe véve a nyári szabadságokat és egyéb tényezőket.
• Aktívan vegyen részt a sprint tervezésében. Bátorítsa a csapat tagjait a történetek, hibák és feladatok tervének bővítésére.
• Ne utasítsa el azokat a feladatokat, amelyek során a fejlesztők nem tudják megoldani a függőségi problémákat.
• A terv jóváhagyása után jelöljön ki egy alkalmazottat, aki a projektmenedzsment programba történő adatbevitelért (Jira kártyák stb.) lesz felelős.

Mit kell elkerülni:

• Ne használjon túl sok történetet, józanul mérje fel a munkatempót, és ne jelöljön ki olyan feladatokat, amelyeket nehéz lesz sprintben teljesíteni.
• Ügyeljen munkája minőségére. Ellenőrizze, hogy van-e elég ideje a minőségellenőrzésre és a kódhibák kijavítására.
• Győződjön meg arról, hogy a csapat minden tagja egyértelműen megértette a sprint tartalmát. Ne hajszold a sebességet. Az egész csapatnak együtt kell mozognia.
• Ne terhelje túl a fejlesztőket többletmunkával. Hamarosan jön az újabb sprint.
• Ha a csapat aggodalmát fejezi ki a munkaterhelés vagy a határidő miatt, akkor vegye figyelembe a véleményét. Kezelje a problémákat, és szükség esetén javítsa ki azokat.

scrum board

A Scrum Board egy olyan eszköz, amely megmutatja, hogyan történik a Scrum Team munkája. Egy ilyen táblán megjelenítheti az információkat papíron, falon vagy elektronikus formában (JIRA, Trello).

A Scrum táblának legalább három oszlopa van: To Do, In Progress és Done. Itt van egy példatábla:

A Scrum tábla tartalmazza a lemaradásból származó összes információt, korábban tervezésre jóváhagyva. Az üzleti feladatkártyákat általában felülről lefelé prioritás szerint rögzítik a táblára. Feloszthatja őket meghatározott típusú munkákra (kóddal, tervezéssel és egyebekkel kapcsolatos munka).

Miután a munka egy része elkészült, a kártya átkerül a táblán a következő oszlopba. A csapatmunka előrehaladásának láthatóságát a Burndown Chart-on a napi „fennmaradó munka” segíti.

Használhat flipchart táblát is. Rajta a művek neveit papírmatricákra írják és a táblára rögzítik. A munka befejeztével a matricák egy másik oszlopba kerülnek.

leégési diagram

A leégési diagram az elvégzett munka mennyiségét és a hátralévő munka mennyiségét mutatja. Minden nap frissül, és minden érdeklődő számára elérhető. A grafikonra azért van szükség, hogy megmutassa a sprintben végzett munka előrehaladását.

Kétféle diagram létezik:

• Leégési diagram, amely a munka előrehaladását mutatja sprintben.
• Leégési diagram, amely a munka előrehaladását mutatja a termék megjelenéséig (az adatok több sprintből vannak összefoglalva).

Példa diagramra:

Ez a példa pszichológiát használ: a diagram nem az elvégzett feladatok számát mutatja, hanem a hátralévő (nem elvégzett) feladatok számát.

Vagyis ha a csapat 100-ból 90 feladatot végzett el, akkor lehet az a hamis érzés, hogy minden készen áll. Végül is a 90-ről 100-ra való haladás valójában semmit nem változtat.

Ha megjeleníti a hátralévő feladatok számát, nem tud segíteni, de észreveszi, hogy minden alkalommal egyre kevesebb lesz. Ez tudat alatt arra sarkallja a projekt résztvevőit, hogy gyorsabban érjék el a célt – ne legyenek befejezetlen feladatok a táblán.