A SCRUM-ban a gyors és iteratív átadási ciklusok eszköze a sprintekre bontott fejlesztés. A sprint rövid, jellemzően 2 hetes fejlesztési ciklusokat takar. A sprint egy, a fejlesztő csapattal közösen végzett tervezéssel kezdődik, ahol átbeszéljük és priorizáljuk a soron következő eredménytermékeket. A sprint demózással ér véget, ahol a megrendelő megtekinti és használatba veszi a leszállított fejlesztéseket. Így a tesztelés nem a projekt végén történik, hanem tulajdonképpen folyamatosan.
Fontos szabály, hogy a sprinteknek mindig önmagukban is teljes értékű terméknövekményt kell leszállítaniuk. A sprint eredményeit a megrendelőnek azonnal használatba kell tudni vennie. Vagyis ha a sprintben a feladatunk például egy hitelkalkulátor fejlesztése, akkor azt a sprint végére kompletten le kell szállítanunk, minden komponensével együtt letesztelve, demózásra kész állapotban.
Másik fontos szabály, hogy az éppen futó sprinten menet közben nem változtatunk. Egy agilis release ciklus gyors, ám ehhez az kell, hogy a fejlesztő csapat azon zavartalanul tudjon dolgozni. A folyamatban levő sprint egy olyan időszak, ami alatt nem módosulhatnak a célkitűzések, a fejlesztők védettek a külső behatásoktól, így eredményesebbek.
A sprintek kulcsfontosságú momentuma a sprintforduló, amely scrum master szervezésével zajlik. Ezen az eseményen a megrendelő Product Owner-e személyesen is találkozik a fejlesztő csapattal, így közösen tudják értékelni a projekt előrehaladását. A sprintfordulón történik az előző sprint eredményeinek bemutatása, amelyet maguk a fejlesztők demóznak a megrendelőnek, tehát nem egy projektvezető ismerteti az elkészült fejlesztéseket, hanem közvetlenül azok, akik alkották azokat. Ugyancsak a sprintforduló az az esemény, ahol eldöntésre kerül, hogy a következő 2 hétben min dolgozzunk.
A sprintforduló egy nagyon fontos esemény az agilis szoftverfejlesztésben, hiszen sokkal egyszerűbb csak a soron következő sprint funkciókészletét jól megtervezni mint a teljes projektet annak indulásakor. Megrendelőként pedig sokkal könnyebb az előző sprintben leszállított terméknövekményt átvenni, megismerni és használatba venni, mintha a teljes projektet egy az egyben, egészben “zúdítaná ránk” a fejlesztőcég tesztelésre. A rendszeres személyes találkozó az egész csapattal továbbá segít megteremteni a projekt transzparenciáját és kiépíteni a felek közötti bizalmat. Ennek a ceremóniája a sprintforduló.
A backlog a projekt elvárt eredménytermékeinek lelke, tulajdonképpen egy üzletileg priorizált igénylista, amely tartalmazza a user story-kat. A jövőbeli elvégzendő igényeket tároljuk benne, annak érdekében, hogy a termék versenyképes maradjon és folyamatosan fejlődni tudjon. A backlogban szereplő elemek változó kidolgozattságban vannak. Itt gyülekeznek azok a feladatok, amelyek már szállításra elő vannak készítve, megtalálhatók benne a tervezés vagy kidolgozás alatt álló fejlesztési teendők, de megjelennek benne azok az igények is, amik még csak ötlet szintjén merültek fel. A backlogban jelöljük azt is, hogy mely feladatra milyen előbecsléseink vannak, illetve, hogy az adott feladat sprint ready-e, azaz kezdhető állapotban van-e. Vagyis a backlog ad egy átfogó képet arról, hogy aktuálisan min dolgozunk, min tervezünk dolgozni a következő sprintben és milyen további igények vannak az előkészítés különböző stádiumaiban.
A backlog természetéből adódóan folyamatos változásban van. Mindig kerül be új elem, más pedig kikerül belőle vagy hátrébb sorolódik. Tehát folyamatosan változnak a prioritások. Tartalmáról, prioritásairól a Product Owner dönt. A backlog azon elemei, amelyek kezdhető állapotban vannak és a legmagasabb prioritást élvezik a product owner döntése alapján kerülnek be a következő sprintbe.
A SCRUM-ban a leszállítandó fejlesztéseket mindig igyekszünk a végfelhasználó szemével megfogalmazni, amit User Story-k formájában készítünk el. Ezek hétköznapi nyelvezettel megfogalmazott követelmények a szállítandó termékkel kapcsolatban, amely teljes mértékben érthető olyan személyeknek is, akik nem jártasak az adott szakterületen. Így biztosítható, hogy a megrendelő is tökéletesen ugyanazt értse a szállított terméknövekmény kapcsán, mint a fejlesztők, továbbá ennek révén a fejlesztő csapat is könnyebben megérti az igény “miértjét”. A szállítás során az elfogadott user story-t már a fejlesztő csapat forgatja át konkrét fejlesztési feladatok formájába.
A user story akkor teljes, ha sikerkritériumok is tartoznak hozzá. A sikerkritériumok olyan feltételek halmaza, amelyek megerősítik, hogy ha egy User Story elkészült, ezek alapján egyértelműen eldönthető, hogy sikeres-e az implementáció.
A példa kedvéért nézzük egy taxi rendelő applikáció User Story-ját:
Utasként szeretném, hogy az úticél kiválasztását követően különböző elérhető sofőrök legyenek megjelenítve a képernyőn, azért hogy ki tudjam választani a számomra legmegfelelőbb lehetőséget.
Sikerkritériumok:
- az applikáció mutatja azokat a sofőröket, akik online voltak az elmúlt 20 percben, és nincsen éppen folyamatban lévő szállításuk
- az applikáció csak 5 sofőrt mutat, akik a legközelebb vannak a felhasználóhoz
- a felhasználó minden sofőrnek a profilját meg tudja tekinteni, hogy milyen értékeléseket kaptak, képpel ellátva
- az egyes sofőröknél kijelzésre kerül a felhasználóhoz való megérkezés várható ideje
Szorosan kapcsolódik a User Story-hoz. Az egyes fejlesztési feladatok nemcsak előbecsléssel (óraszám előrejelzéssel) rendelkeznek, hanem mindegyik, a backlog-ban szereplő feladat kap egy-egy SP-t is. A Story Point egy a SCRUM által használt mérőszám, ami az órabecslést egészíti ki. Ez az érték egy komplexitási szintet jelöl, amely azt határozza meg, hogy mennyire összetett fejlesztésről beszélünk. Egy indiktátor arra vonatkozóan, hogy mekkora a valószínűsége a becsült óraszám tartásának, illetve hogy a jövőben - ha a fejlesztés nem kezdődik el a becslés készítésekor, de közben a rendszer a modulra potenciálisan kiható egyéb további fejlesztésekkel bővül - milyen valószínűséggel igényel újrabecslést. Minél komplexebb egy feladat, annál magasabb az SP értéke, és minél jobban kidolgozott egy igény a becslés pillanatában, az pedig éppen fordítva hat rá, lefelé mozgatja az SP értéket.
A legfontosabb dolog, ami befolyásolja a módszertan sikerességét az igény maga, ami minden szállított érték minőségének alapja. Ha az nem megfelelő minőségű, ha nincs ott időben, ha nincs priorizálva, ha nincs alaposan megértve, ha nincs a sikeresség egyértelműen és mindenki számára érthetően definiálva, akkor ez már a kiindulási ponttól kezdve kihat a végeredményre és annak minőségére. Tehát a legfontosabb, amellyel szabályozni lehet az agilis szoftverfejlesztésben zajló munka minőségét, az az igényeket priorizáltan tartalmazó backlog minősége. Ezért miközben a csapat fejleszti az éppen futó sprint feladatait, a Product Owner és az őt támogató tanácsadói stáb a következő sprintek user story-jain dolgozik.
Bizony sokszor előfordul, hogy egy-egy igény megfogalmazásában, a mikéntjének kitalálásában a fejlesztőkre is szükség van, valamint ahhoz, hogy dönteni lehessen a prioritásokról, ismerni kell az egyes feladatok várható bekerülési költségét. Továbbá egy specifikáció attól lesz jó, ha azt a csapattal még a munka elkezdése előtt átbeszéljük, közösen megértjük, minél kisebb darabokra szedtük és mindenki ugyanazt érti alatta.
Ezen információk megszerzésére és az igény pontos átbeszélésére szolgál a refinement, amelyen a PO és a fejlesztő csapat közösen egyeztetnek az igényekről. Tehát ez egy közös találkozó a csapattal, ahol a következő sprintekbe szánt feladatokról zajlik egyeztetés, és amelyet követően a Product Owner - a kapott visszajelzések alapján - frissíti a backlog elemeket és aktualizálja azok prioritását.
Minimum Viable Product, azaz egy működő prototípus. Az agilis szoftverfejlesztés célja a minél korábbi piacra lépés egy lecsupaszított, de stabilan működő termékkel, hogy korán elkezdjünk valós felhasználói visszajelzéseket gyűjteni, illetve a termék minél korábban elkezdjen pénzt termelni. Az agilis fejlesztésben ennek a prototípusnak a továbbfejlesztése zajlik az ügyfél által kijelölt és a valós felhasználók visszajelzései alapján, ezzel biztosítva, hogy a műszaki tartalom a ténylegesen üzletileg hasznos irányba haladjon egy kezdetben elképzelt, de nem validált terv szolgaszerű követése helyett.
A SCRUM-ot alkalmazó fejlesztőcégeknél, így az OANDER-nél is keresztfunkcionális (cross-functional) csapatok dolgoznak a projekteken. Ez azt jelenti, hogy nincsen külön backend divízió, külön sitebuild team, külön rendszerintegrációs gárda vagy éppen tesztelői team, hanem csapaton belül elérhető az összes kompetencia és szerepkör, amely a sikeres szállításhoz szükséges. A csapat tagja a projektvezető is és a scrum master is. Vagyis a megrendelő egy olyan csapattal dolgozik együtt, amely összeszokott és komplett szállítási szaktudást alkot. Ezek a teamek önszerveződők, vagyis ők osztják be, hogy a sprintben elvállat fejlesztéseket miként és milyen sorrendben valósítják meg és az elkészült terméknövekményeket ők maguk demózzák a sprintfordulón a megrendelőnek.
A sikeres fejlesztés fontos feltétele, hogy a megrendelő bevonjon a projektbe egy olyan Product Owner-t, aki a fejlesztési stratégia prioritásai mentén haladva, technikai rálátással menedzseli a teljesítéseket és veszi át azokat. A megrendelő oldali Product Owner együtt dolgozik a tervező és fejlesztő csapattal, dönt az egyes sprintek tartalmáról és kezeli a backlog-ot. Legfontosabb feladatai:
- Felelős a projekt üzleti sikeréért
- Képviseli a projektet a stakeholderek felé
- Kezeli és priorizálja a backlogot üzleti érték alapján
- Dönt arról, hogy mi lesz leszállítva
- Megfogalmazza az igényeket és a sikerkritériumokat
- Dönt arról, hogy a demón látott fejlesztés élesbe mehet-e
Nemcsak az agilis módszertanban, de minden szoftverfejlesztési kezdeményezésnél égetően fontos, hogy megrendelő oldalon jelen legyen egy olyan projektvezető, aki döntési kompetenciával rendelkezik, aki képviseli a projektet a stakeholderek felé, felelősen megfogalmazza az igényeket és akinél összegyűlnek a projekttel kapcsolatos információk. Ennek hiánya a projekt törvényszerű kudarcát eredményezi. A SCRUM ezt a szerepet hívja Product Owner-nek.
A SCRUM működtetése nem egyszerű feladat, egy olajozottan működő csapat és egy közös értésen alapuló munkafolyamat szükséges hozzá. Ebben segít a Scrum Master, aki felel a fejlesztési szabályok és folyamatok betartatásáért és biztosítja azt, hogy a csapattagok emlékezzenek a játékszabályokra, vállalásokra, ígéretekre. Elhárítja az akadályokat, zavaró tényezőket és azt segíti elő, hogy a csapat hatékonyan dolgozzon. A Scrum Master erősíti a projekt szervezet tagjai közötti kapcsolatot, kommunikációt, ugyanakkor coach szerepe is van: mentorál és segít a konfliktusok megoldásában. Nem utolsó sorban pedig ő facilitálja a scrum ceremóniákat (mint például a sprintforduló, refinement, standup, stb.)
