Folyamatok a Scrumban

Sprint tervezés

A sprint tervezése a Scrum sprint kezdeti szakasza. Meghatározza a sprint során végzett munka terjedelmét és módjait. A teljes Scrum csapat részt vesz a tervezésben.

A sprint egy egyértelműen meghatározott időtartam, amely alatt egy meghatározott munkát el kell végezni. A sprintet meg kell tervezni, mielőtt elindulna. Először is meg kell határoznia a sprint időtartamát és célját.

A tervezési workshopon egyeztetik a feladatsort és a sprint célját. Fontos, hogy a csapatot megfelelő motivációval töltsük fel a munkához, hogy minden tag a sikerre koncentráljon.

Ha a sprint rosszul van megtervezve, ez a csapatot kudarchoz vezethet. A fejlesztők nem fognak tudni megbirkózni a velük szemben támasztott elvárásokkal, mert a feladatok irreálisnak bizonyultak.

A sprint tervezésekor figyelembe veendő kérdések:

• Az ügyfél vagy a szoftver tulajdonosa bejelenti a sprint célját, és közben elmagyarázza, hogyan érheti el azt. A Scrum csapata kideríti, milyen feladatokat lehet elvégezni egy jövőbeli sprint során e cél elérése érdekében.
• A fejlesztők munkatervet osztanak ki egymás között, amelyet a szoftver megrendelőjével egyeztetnek.
• A sprintterv elkészítésében minden esetben a termék megrendelője (tulajdonosa) vesz részt. Kitűz egy célt, és a programozó csapatnak ki kell derítenie, hogy ez sprintben elérhető-e.
• A tervnek termékhátralékot kell használnia, amelyből információkat lehet hozzáadni a tervhez.
• A csapattagoknak úgy kell befejezniük a tervezési értekezletet, hogy világosan megértsék, mire van szükségük az eredmény eléréséhez. A jövőbeli műveletek sorrendjét a sprint hátralékban jelenítheti meg.

A tervezés nem haladhatja meg a heti két órát. A Scrum Masternek el kell magyaráznia mindenkinek, hogy vannak időkorlátok. Ha minden munkaprobléma gyorsan megoldódik, akkor az értekezlet a szokásosnál korábban is véget érhet. Egy ilyen találkozónak nincs minimális időtartama.

Feladat értékelése

A munka összetettségének értékelését nem kell túlzásba vinni. A tervezési folyamat nem pontos, de legalább közelítő értékelést igényel a fejlesztés összetettségéről. A csapatnak nemcsak meg kell értenie a sprint célját, hanem össze is kell hasonlítania a célt csapata képességeivel.

A bonyolultság felméréséhez használhatja a mindenki számára szokásos ruhaméreteket (L, XL, XXL). Ez persze nem ad garanciát a pontosságra, de mégis.

Ahhoz, hogy a komplexitás értékelése pontosabb legyen, kölcsönös megértésre van szükség. A csapat tagjai nyíltan mondják el véleményüket, és ne féljenek kérdéseket feltenni a termék tulajdonosának.

A munka befejezése után a csapattal szembeni kritikák oda vezethetnek, hogy a következő sprint tervezésekor az előrejelzések kevésbé lesznek optimisták. Ez segít a csapatnak elkerülni a hiba megismétlését, és megóvja azt attól, hogy a jövőben negatív értékelést kapjon.

Nehézségi értékelés pontokban, pontokban és órákban

A fejlesztőcsapatok általában idővel becsülik meg munkájuk összetettségét. De néhány Agilis csapat úgy dönt, hogy pontokban vagy pontokban értékeli a nehézséget. Ez jobban jelzi a hátralékos elem vagy más hozzárendelt feladat megvalósításához szükséges teljes költséget.

A pontokat a munka összetettsége és mennyisége alapján ítélik oda. Ezenkívül figyelembe veszik a lehetséges kockázatokat. Az ezzel a módszerrel végzett pontozás segít a munka hatékony apró lépésekre bontásában.

A pontozási módszer (pontok) rendszeres használatával a tervezés során a csapatok jobban és pontosabban megértik, mennyi időre lesz szükségük a munka elvégzéséhez. Ezen kívül vannak más előnyök is.

• Az időbecslés nem veszi figyelembe azokat a munkákat, amelyek nem közvetlenül kapcsolódnak a projekthez, bár biztosan megjelennek. Munkaügyi kérdések megbeszélése messengeren keresztül, értekezletek tartása – mindez a csapattagoknak is időt vesz igénybe.
• Az érzelmek befolyásolhatják a dátumválasztást. A munka értékelése során végzett pontozás ezt a tényezőt kiküszöböli.
• A munka összetettségének megítélése és ennek megfelelően a feladatok elvégzésének sebessége csapatonként eltérő lehet. A megtett pontokkal végzett munka nem tekinthető a sebesség semmilyen mutatójának. Vagyis nincs lélektani nyomás a csapaton.
• A munkaerőköltségek és a bonyolultság helyes elosztásával gyorsan és konfliktusmentesen oszthat fel pontokat az elvégzett munkára a résztvevők között.
• A feladat elvégzéséért kapott pontok száma a feladat összetettségétől függ, és nem a ráfordított időtől. Ezért a programozók a hatékonyságuk javításán fognak gondolkodni, nem pedig azon, hogy ez mennyi ideig tart.

A komplexitásbecslés hátránya, hogy gyakran visszaélnek vele. Ez a módszer például nem használható az alkalmazottak értékelésére.

A csapatoknak pontozási rendszert kell használniuk, hogy jobban megértsék a rájuk rendelt munka mennyiségét és helyesen rangsorolják.

Napi Scrum Találkozó

Fontosak a workshopok: ezeken a csapattagok elmondják véleményüket, kommunikálnak és megállapodnak a további teendőkben. Napi scrum találkozókra is szükség van a csapatszellem növeléséhez és az aktuális hírek bejelentéséhez.

A Stand-up egy rövid találkozó a projekt kulcsfontosságú résztvevőivel: a szoftver tulajdonosával, a programozókkal és a scrum mesterrel. A stand-up felépítése három kérdésből áll.

• Mit csinálhattunk tegnap?
• Min dolgozunk ma?
• Mi akadályoz bennünket abban, hogy eredményeket érjünk el?

Ezeknek a kérdéseknek a feltevése serkenti a fejlődést és segít azonosítani a csapaton belüli problémákat. Amikor minden résztvevő elmondja, hogyan segíti elő egy közös cél elérését, ez javítja a csapaton belüli kölcsönös megértést.

Fontos megjegyezni, hogy nincs egyetlen sablon a stand-upok lebonyolítására. Minden csapat a saját modellje szerint, a csapat adottságai alapján tart üléseket.

Most pedig beszéljük meg, mi kell a tökéletes stand-uphoz, és ismerkedjünk meg a hatékony stand-up példákkal.

Először is olyan időpontot kell kiválasztania, amely mindenkinek megfelel. Általában a munkanap elején – reggel 9 és 10 óra között – tartanak stand-upokat ugyanazon iroda csapatai számára. Ez időt ad arra, hogy jobban megtervezze napirendjét. Ha a csapattagok különböző régiókban dolgoznak, akkor mindenki számára megfelelő időpontot választanak. Például, ha néhány csapattag Kaliforniában és Sydneyben él, akkor a stand-up kaliforniai idő szerint 15:30-kor kezdődik. A vacsora utáni stand-up persze nem mindenkinek kényelmes, de lehetővé teszi a kapcsolattartást az óceán túlpartján lévő kollégákkal.

Kövesse nyomon a stand-up termelékenységet. Ne tartsa túl sokáig a találkozót – a figyelemkoncentrációnak a lehető legjobbnak kell maradnia. Ha lehetséges, ne tartsa felállást 15 percnél tovább.

Használd a labdát. Sorra egymásnak lehet dobni. Tehát mindenki részt vesz a vitában. Ez a játék segít fenntartani a figyelmet a csoportban. Használja a csapat visszatekintését. A stand-upokat számos Agilis módszertan alkalmazza, ez nem akadályoz meg bennünket abban, hogy retrospektíven megvitassuk a stand-upok hatékonyságát. Valaki minden nap találkozik, más csapatok - hetente néhányszor. Ha a csapatnak nehéz hasznot húznia a stand-upból, keresse meg ennek okait, és változtasson valamit.

Sprint áttekintés

A tavaszi felülvizsgálatra a sprint utolsó szakaszában kerül sor. Szükséges a terméknövekmény ellenőrzése és a lemaradás testreszabása. A teljes scrum csapat és minden érdekelt fél részt vesz a sprint eredményeinek áttekintésében. A találkozót nyugodt formában tartják a projekt résztvevői közötti interakció javítása érdekében.

A Sprint Results Review a következő elemeket tartalmazza:

• A szoftver tulajdonosa megmutatja, hogy a lemaradásból mi készült el és mi nem.
• A programozók megbeszélik, mi ment jól, hol jelentek meg a nehézségek, és hogyan hárították el azokat.
• A fejlesztő csapat megmutatja a sprint során végzett munkájuk eredményét, és azt, hogy milyen terméknövekményt kaptak.
• A terméktulajdonos megosztja gondolatait az aktuális lemaradásról. Előrejelzést ad a következő célról és a megvalósítás határidejéről is.
• Mindenki megbeszéli, mi a legjobb a következő lépése a piac értékelése és a felhasználói érdekek alapján.
• Eszmecsere folyik az elmaradás növelésének ütemezéséről, költségvetéséről és kilátásairól.

Az eredmény egy frissített lemaradás új célokkal a következő sprintekre. A lemaradás módosítható, ha a helyzet úgy kívánja.

Sprint retrospektív

A Sprint Retrospective egy workshop, amely megvitatja, hogyan javíthatja munkafolyamatát. Egyben fejlesztési tervet is készít a következő sprintre. A találkozóra általában a sprint felülvizsgálata után kerül sor, és nem tart tovább három óránál. A találkozót a Scrum Master vezeti.

A Sprint Retrospective fő céljai a következők:

• Sprint elemzés (a résztvevők munkája, eredmények és problémák).
• Beszélje meg a lehetséges megoldásokat a munkafolyamat javítására a következő sprintekben.
• Terv készítése a projekt végrehajtása során a csapattagok által végzett fejlesztések végrehajtására.

A Scrum Master felkéri a csapat tagjait, hogy tegyenek javaslatokat a fejlesztés hatékonyságának javítására. A csapat megvitatja a javaslatokat, és javaslatokat tesz a megvalósításukra.

A Sprint Retrospektíva végén a csapatnak kiemelnie kell néhány fejlesztési javaslatot, amelyeket a következő sprintben végre kell hajtani. A javaslatokat bármikor meg lehet valósítani, de a Sprint Retrospective lehetőséget ad arra, hogy a csapat szemszögéből mélyebben áttekintsük azok lehetséges adaptációját.

Itt fejezzük be a Scrum módszertanról szóló vitát. Erről többet megtudhat a tematikus dokumentációban vagy az első munkahelyén.