Innomedio Kft Scrum módszertan 1.0 Verzió Érvényes: 2012. április 1-től Alapfogalmak: 1. hiba: egy már meglévő, funkcionalitásban hibás működést eredményező programrész hibás működésének leírása konkrét példával. A hiba javítása új képességekkel nem ruházza fel a szoftvert. Hibát leadni kizárólag az ügyfélkapu hibajelentő lapjának kitöltésével lehet 2. valódi hiba: olyan hiba, amely az ügyfél által hibának jelzett működés belső tesztelése után megállapítható, hogy valóban a rendszer hibás működéséből ered. A valódi hibákat a valódi hibalistára kell tenni és sorszámmal kell ellátni 3. fejlesztési igény: egy új vagy egy már meglévő funkció kifejlesztésére / továbbfejlesztésére szolgáló feladat pontos leírása, meghatározva a funkció pontos célját, a szoftverben elfoglalt helyét és kifejlesztésének hatását a már meglévő funkciókra. Fejlesztési igényt kizárólag a termékmenedzserek, az ügyféllel egyeztetve adhatnak le 4. sprint: egy olyan, dátum szerint meghatározott időszak, amely alatt a fejlesztő csapat előre meghatározott fejlesztési igényeket próbál megvalósítani 5. vezető fejlesztő: egy adott részleg fejlesztőcsapatának vezetője 6. termékmenedzser: egy adott szoftver, honlap, webáruház képviselője. Feladata a kapcsolat tartása a vezető fejlesztő és az ügyfelek között 7. ügyfél: a szoftvert megrendelő cég vezetősége és azok alkalmazottai 8. fejlesztő: a fejlesztő cég azon munkatársai, akik szoftver kódolásában részt vesznek, a fejlesztők a termékmenedzsereken keresztül tartják a kapcsolatot az ügyféllel 9. fejlesztési pontérték: megegyezés szerint: 1 pont = 1 aktív fejlesztési óra Alapelvek: 1. a fejlesztők egy aktív sprint alatt csak olyan fejlesztési igényen dolgozhatnak, amely benne van az aktív sprint ütemtervében, vagy egy olyan valódi hibán, amely a hibalistára felkerült 2. cég scrum fejlesztési módszertana minden ügyfél számára publikus. A termékek értékesítésekor a termékmenedzsereknek kötelessége a módszertan ismertetése az ügyféllel. 3. a fejlesztő szemszögéből a valódi hiba minden esetben magasabb prioritással bír, mint a futó sprintben lévő fejlesztési igény A módszertan módosítása: 1. a módszertant csak a vezető fejlesztők és az ügyvezető közös döntései alapján lehet módosítani 2. a módosítások aktív sprint alatt nem léphetnek érvénybe 1. oldal
Előnyök: - prioritás felállítása a valódi hibák és fejlesztési igények között - értékelhető fejlesztési időszakok: sikerélmény a fejlesztők részéről, prémium rendszer felállítása a zöld sprintek alapján - tartható várható kifejlesztési határidő az ügyfél felé - az ügyfél folyamatosan nyomon tudja követni, hogy egy adott fejlesztési igénye várhatóan mikor fog teljesülni - az ügyfél minden őt érintő megvalósult fejlesztésről automatikusan értesül az adott sprintet lezáró dokumentáció alapján - az elkészült fejlesztési igények több ideig tesztelhetőek az éles rendszerbe kerülés előtt - előfordulhat, hogy mire egy fejlesztési igény kidolgozásra és sprintindító találkozóra kerül, úgy addigra már el is veszíti a létjogosultságát Hátrányok: - a fejlesztési igények elkészítésének üteme lassulni fog az ad-hoc rendszerhez képest, ám a sokkal stabilabban tartható határidők kárpótolni fogják az ügyfeleket Prioritások: 1. egy valódi hiba bármilyen magas prioritású fejlesztési igénynél magasabb prioritást élvez 2. a fejlesztési igények prioritásának meghatározása a sprintindításkor történik 3. a valódi hiba prioritásának meghatározása a valódi hibának a fejlesztők felé, a vezető fejlesztő által történő feladásakor történik 2. oldal
Hibakezelési folyamat [1. ábra]: 1. hiba beérkezése a hibakezelő rendszerbe az ügyfél által, leadva az ügyfélkapun vagy a termékmenedzser által leadva közvetlenül a megfelelő projekthez 2. az arra jogosult szinten található ember (termékmenedzser, vezető fejlesztő) eldönti, hogy a leadott hiba valódi hiba-e, vagy csak az adott funkció működésének nem ismeréséből ered 3. valódi hiba esetén az a valódi hibalistára kerül, amelynek a fejlesztők egy adott saját feladat lezárása után a prioritási sorrendnek megfelelően nekikezdenek a. a fejlesztő megismeri a valódi hibát, kipróbálja annak működését b. szükség esetén kommunikál a valódi hiba leadójával c. elkészíti az ennek megfelelő hibajavítást d. a hibajavítás módjának ismertetésével lezárja a hibajavítási folyamatot 4. nem valódi hiba esetén a termékmenedzser felveszi az ügyféllel a kapcsolatot és segít a hiba felhasználó oldali elhárításában 1. ábra: Hibakezelési folyamat 3. oldal
Fejlesztési folyamat[4. ábra]: 1. Sprintindító találkozó: Egy adott sprint mindig a sprintindító találkozóval kezdődik. A találkozó időpontja a sprint első napjának délelőttje. A sprintindító találkozó terv szerint kb. 3 óra. 1.a. A vezető fejlesztő a találkozóra felkészül a sprintidőszakra várható fejlesztési kapacitást kiértékelő lappal [2. ábra]. Ezt tartalmazza a sprintidőszakban elvégezhető fejlesztések pontértékét. 2. ábra: Fejlesztési kapacitást kiértékelő lap 1.b. A termékmenedzserek felkészülnek azokkal fejlesztési igényekkel, amelyek az előző sprintekben nem készültek el, vagy az előző sprint futása közben lettek az ügyfelek által leadva 1.c. A fejlesztők és a vezető fejlesztő a termékmenedzserekkel együtt közösen értelmezik a fejlesztési igényeket 1.d. A fejlesztők pontozótábla felmutatásával egy időben határozzák meg a fejlesztési igény elkészítéséhez szükséges pontértéket. A fejlesztési igény tervezett pontértéke a fejlesztők által felmutatott pontértékek átlaga. 1.e. A vezető fejlesztő a fejlesztési igények prioritásának, majd pontértékének megfelelően meghatározza az adott sprintbe beleférő fejlesztési igényeket a sprintre tervezett fejlesztői kapacitásnak megfelelően [3. ábra] 3. ábra: Fejlesztési igény prioritási sor 4. oldal
1.f. A vezető fejlesztő és a termékmenedzserek közösen lezártnak tekintik a sprintindítást, majd a termékmenedzserek tájékoztatják az ügyfeleket az őket érintő fejlesztések sprintbekerüléséről. 2. Sprintidőszak: a. Napi fejlesztői munkafolyamat: 1. A valódi hibalista áttekintése és a hibák javítása a prioritási sorrendnek megfelelően 2. A futó sprint fejlesztési igényeinek elvégzése a prioritási sorrendnek megfelelően 3. A munkanap végén az adott napot kiértékelő munkalap kitöltése a következő napi Daily Scrumra 4. A fejlesztő az adott napon elkészült fejlesztési igényeket a projektkezelő rendszerben elkészült állapotra állítja 5. A termékmenedzser és a vezető fejlesztő köteles az elkészül állapotú fejlesztési igényeket tesztelni: 1. ha a tesztelés során úgy találják, hogy a fejlesztés nem a leírásnak megfelelően lett elkészítve, vagy hibás működést mutat, akkor visszaállítják a fejlesztési igény állapotát folyamatban -ra 2. ha a tesztelés során úgy találják, hogy a fejlesztés az elvárásoknak megfelelően viselkedik, úgy valóban elkészült állapotra állítják a fejlesztési igényt, amelyről az ügyfél automatikus értesítést kap b. Daily Scrum: 1. A részvétel a minden munkanap 13:00-kor található daily scrumon minden az adott napon dolgozó fejlesztő részére kötelező 2. A daily scrumről történő késés büntetést von maga után (kivétel: szabadság, betegség) 3. A daily scrumon az adott időpontban az irodában dolgozó termékmenedzsereknek is részt kell venni 4. A daily scrumokon a résztvevők állnak, felgyorsítva ezzel a megbeszélés menetét 5. A daily scrum során felvázolt problémákat a termékmenedzserek az ügyféllel kommunikálva kezelik 6. A vezető fejlesztő labdadobással választja ki az aktuálisan jelentő fejlesztőt 3. Sprintzáró találkozó: a. A találkozóra a sprintidőszak utolsó napján kerül sor. Időtartama várhatóan 1-1,5 óra b. A találkozón a fejlesztők, a vezető fejlesztő és a termékmenedzserek vesznek részt. c. A találkozón résztvevők közösen átnézik az adott spritbe került fejlesztési igényeket, ellenőrzik azok állapotát 1. Ellenőrzik az elkészült feladatokat és módosítják azok állapotát valóban elkészültre 2. Átnézik az aktuális sprintbe tervezett, de nem teljesült feladatokat és megbeszélik, hogy milyen akadályozó tényezők miatt nem valósult meg az adott fejlesztési igény. Ezt követően növelik azok prioritását, így a következő sprintben ez fontosabb helyen lesz. d. A résztvevők közösen értékelik sprintet. A sprintet a benne szereplő fejlesztési igények teljesítésének függvényében az alábbi három csoportba sorolják: 1. Zöld sprint: a sprintbe sorolt fejlesztési igényeknek több mint 90%-a lett megvalósítva 2. Sárga sprint: a sprintbe sorolt fejlesztési igények több mint 60%-a, de kevesebb mint 90%-a lett megvalósítva 3. Piros sprint: a sprintbe sorolt fejlesztési igények kevesebb, mint 60%-a lett megvalósítva e. A találkozót követően a termékmenedzserek értesítik az ügyfelet a sprintbe került fejlesztések állapotáról, valamint a sprint értékeléséről 5. oldal
4. ábra: Fejlesztési folyamat 6. oldal