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.
GO TO FULL VERSION