A sprinttervezés (Scrum-sorozat 3/1. rész)

A Scrum-ról szóló cikksorozatomat egy gyorstalpalóval kezdtem, aztán arról írtam, hogy mi a célja a product backlog-nak, és hogy hogyan készül. Most a sprinttervezésről lesz szó. Először a tervezés filozófiájáról írok és felsorolom az eszközeit. A következő részben a tervezés forgatókönyve kerül ismertetésre.

A cikk végén egy kis kitérőt tartok: arról a csapatról és projektről írok, amelyben sikerült a Scrum-ot meghonosítanunk.

Mi a sprinttervezés?

A sprintet megelőzően egy tervezésre kerül sor, ahol a csapat elkötelezi magát az éppen legfontosabb sztorik lefejlesztésére. Az elkötelezés közös becslés alapján történik. A csapat a product backlog elejéről kiválasztja azokat a sztorikat, amik a sprintbe beleférnek.

Minek a sprinttervezés?

Ahhoz, hogy egy sprintnek neki gyűrközhessen a csapat, megfelelő tervezés szükséges. A tervezés során érti meg a csapat, hogy miket fog megvalósítani a sprint során, és a tagok közösen becslik meg, hogy az egyes lefejlesztendő sztorik mekkora méretűek (szándékosan nem azt írtam, hogy ráfordítást becsülnek). Ez alapján a becslés alapján határozzák meg, hogy a fix hosszúságú sprint alatt (ami a szakirodalom szerint tipikusan 1-4 hét) mi kerülhet be a sprintbe a product backlog-ból.

A legtöbb szakirodalom csupán a tervezés lebonyolításával foglalkozik. A saját tapasztalatunk szerint ahhoz, hogy egy tervezés és a későbbi sprint hatékony lehessen, bizonyos előkészítést kell elvégezni. Az előkészítésnek két kulcsfontosságú elemét azonosítottuk.

Előkészítés 1. fázisa: “Legyen a product backlog up-to-date!”

A sprinttervezést jó eséllyel megelőzte egy korábbi sprint (kivéve, ha épp az első sprinttervezésünknél tartunk), ez alatt az idő alatt is változhatott a product backlog. Miért?

1. Változhattak a körülmények (külső tényezők hatására). Pl. a határidő vmi miatt korábbra vagy későbbre került, esetleg kiderült, hogy a szoftvert egy másik szervezetnél vezetik be először (ahol esetleg más funkciók fontosabbak a teljes szoftverből).
2. Az előző sprinttervezés, ill. az utána következő sprint közben a csapat tanult, és jobban megismerte az üzleti problémát. Pl. rájött a csapat, hogy egy sztori szétbontható több – eltérő prioritású – kisebb sztorira, vagy pl. sprint közben “előjött” egy megbújó üzleti probléma (amely új sztoriként beillesztésre kerül a product backlog-ba).

A product backlog-ot célszerű a következő sprint elejére (tervezés előtt) frissíteni, hogy a tervezés az aktuális prioritások alapján mehessen.

Előkészítés 2. fázisa: “Tudjuk, hogy mit jelentenek az egyes sztorik!”

Az a tapasztalatunk, hogy hiába van egy aktualizált product backlog, sokszor ennyi nem elégséges a tervezéshez. Ennek az oka az, hogy általában nem mindenki számára világos, hogy valójában mi is az, amit meg kell valósítani az egyes sztorikban. Elég kínos a tervezéskori “improvizálás”, amikor ott derül ki, hogy az egész csapatnak fogalma sincs arról, hogy pontosan mit is jelent egy-egy sztori. Ilyenkor egy jó adag bizonytalanság települhet rá a csapatra, ami a további tervezés és az utána következő sprint bukását eredményezheti.

Tegyük fel, hogy a következő legfontosabb sztorink a product backlog-ból a következő: “felhasználók és szervezeti egységek összerendelése”. Hogyan fogja tudni megérteni a csapat, hogy mit is kell itt csinálni? Hol van az a tudás, hogy ez mit is jelent valójában?

A saját csapatunkban én vagyok a felelős azért, hogy a következő sprinttervezésre a product backlog priorizálva legyen, és elkészüljön minden egyes sztoriról egy olyan minimális leírás, amelyből a csapat megérti, hogy mi a feladat. Ezt a rövid (1-2 oldalas) doksit mindenki a tervezés előtt elolvassa, hogy képben legyen. (Ha valami annyira triviális, hogy írni sem kell róla, akkor kihagyom a doksiból.) A dokumentum közvetlenül a sprinttervezés előtt készül el (ez nem a követelményspecifikáció), ezért mindig a legaktuálisabb tudást reprezentálja. Informális, pont annyi van benne, amennyi szükséges. Nincsenek benne UML-ábrák, rendszerint nincsenek benne implementációs, technológiai részletek.

Felmerülhet a kérdés, hogy mi alapján írom meg én önkényesen a sztorik leírását.

A projekt kezdetekor az ügyfél oldaláról áthívtunk a csapatba egy olyan személyt, aki értett az üzleti problémához. (Őt nem is az ügyfél, hanem a mi cégünk foglalkoztatta tovább.) Hívják Őt Albertnek. Ő az üzleti szakértőnk (business expert). Bármilyen kérdésünk van, ő azonnal válaszol. Nem kell az ügyféltől időpontot kérnünk, felkészülnünk az interjúkra, mert ott van Albert.

Kezdetben Albertet közösen “zaklattuk”. Az üzleti probléma elég bonyolultnak bizonyult, a csapat részéről felmerülő rengeteg kérdésből megismert válaszok lassan formálódtak csak egy konzisztens modellé. Igazán kemény dió volt kibogozni, hogy mi is a feladat, mit is jelentenek az egyes üzleti fogalmak. Mivel engem érdekelt az üzleti probléma, úgy alakult, hogy én lettem az, aki a legtöbbet kezdett beszélgetetni Alberttel. Én lettem a probléma üzleti elemezője (business analyst). Megértettem a gondolkozását, megértettem az üzleti problémát. Rendszereztem a gondolatait, és egy nagyvonalú modellé gyúrtam a fejemben. A beszélgetések során Albertnek a saját gondolatai is rendszereződtek. Ezek az elsődleges beszélgetések határozzák meg a mai napig is a csapat továbbhaladásának az irányát.

A munkafolyamat tehát a következő: Albertből kiszedem a következő sprinthez a sztorikhoz szükséges összes információt, közösen megrágjuk a témát, én röviden leírom egy doksiban az infókat, és a csapattal közösen átbeszélünk mindent a tervezésen.

Mi ilyen módon adaptálódtunk a környezetünkhöz. Nem gyártunk tonnaszám haszontalan dokumentációkat, előnyben részesítjük a szóbeli kommunikációt, a tudás a csapattagok fejében és a jól megírt kódban található.

Ez nem kifejezetten a Scrum-módszertan része, de szükséges tudatosítani azt, hogy egy Scrum-folyamat megvalósításakor (is) számos egyéb problémára kell odafigyelni és megoldani.

Idő helyett becsüljük a sztori méretét!

A Scrum ajánlásai alapján ahhoz, hogy a projektünket valahogy az időskálára helyezzük, nem célszerű közvetlenül az idővel becsülni. Érdemes elvonatkoztatni, és a lefejlesztendő sztorikat, elvégzendő feladatokat pontokban meghatározni. A pontot másképpen sztoripontnak is nevezik, hiszen egy sztori relatív méretét (esetleg komplexitását) adja meg.

Mekkora méretű feladatot is jelöl 1 sztoripont? A válasz: mindegy, a lényeg, hogy a csapat ugyanazt értse 1 sztoripont alatt.

1. példa: mi úgy kezdtük a Scrum-ot, hogy 1 sztoripont alatt azt a feladatmennyiséget értettük, amennyit 1 ember 100%-os hatékonysággal 1 nap alatt el tud végezni (1 “biorobot” nap). Nehéz elképzelni, mégis megpróbáltuk: vajon hogyan dolgoznánk, ha a székünk egy WC lenne, és a szükséges tápanyagokat intravénásan vezetnénk a testünkbe, hogy a szükséges anyagcserére, táplálkozásra fordítandó időt is megspóroljuk? Döcögősen indult az elején a becslés, mindenki kétkedve és bizonytalanul becsült, de pár sprint után, kialakult mindenki fejében egy közel egységes elképzelés, hogy mit is értünk 1 sztoripont alatt.

2. példa: más csapatnál úgy rögzítették a sztoripont fogalmát, hogy kiválasztottak egy olyan korábbi “egészséges méretű” feladatot, amiről a csapat tudta, hogy mennyi idő alatt készítette el. Tudták, hogy kb. 5 napot vett igénybe a feladat, pontosan ismerték a feladat nehézségét, komplexitását is. Azt mondták, hogy legyen ez a feladat 5 sztoripont méretű. Minden később felmerült feladatnál ehhez a feladathoz képest becsültek: vajon kisebb vagy nagyobb méretű az új feladat az etalonhoz képest? Mennyivel?

Kapacitástervezés, a fókuszfaktor

A tervezés elején először meghatározzuk, hogy az elkövetkezendő sprintben hány sztoripontot tud teljesíteni a csapat. A mi csapatunk esetében (fenti 1. példa) – definíció szerint – 1 sztoripont 100%-os hatékonysággal pontosan 1 napot jelent, ezért egy ember elvileg pont annyi sztoripontot tud megcsinálni, mint ahány napos a sprint.

A valóságban mi 70%-os hatékonysággal számolunk. Ezt a hatékonysági tényezőt a Scrum-ban fókuszfaktornak (focus factor) nevezik. Ha valaki leterheltebb, és más feladatai is vannak, mint a projektben történő új sztorik fejlesztése, a fókuszfaktorát csökkentjük. Ha valamely napokon szabin lesz, akkor azokon a napokon nem “termel” sztoripontot.

Példa:

2 hétig (10 munkanapig) tart a következő sprint, és 2009. január 4-én kezdődik. Van egy 4 fős fejlesztői csapatunk a következő tagokkal:

• Jónás: a sprint első két napján szabin lesz, a default 70%-os fókuszfaktorral számolunk rá,
• Döme: junior fejlesztő, 2 hónapja dolgozik a projekten, az ő fókuszfaktorát 50%-ban állapítottuk meg, az első héten szabin lesz,
• Zalán: teljes mellbedobással tud a sprintben dolgozni, a default 70% fókuszfaktorral számolunk rá,
• Iván: bizonyos support feladatokat is ellát a projekten, ha bejelentés érkezik az ügyféltől, kivizsgálja, és megoldást talál rá. Az ő fókuszfaktorát 30%-ban állapítottuk meg.

Egy táblázatot készítünk a fentiek összegzésére (Excelt haszálunk). Azokon a napokon, amikor valaki nem dolgozik, 0-t írunk a megfelelő mezőbe, egyébként 1-et. (Előfordul, hogy a 0.5-öt is használjuk, ha valaki pl. csak fél napig van.)

A példában szereplő csapat a kéthetes sprint alatt 18.1 sztoripontot tud teljesíteni.

Téli időszakban vagy H1N1-fertőzés idején is – a fennálló kockázat miatt – csökkenthető a csapat fókuszfaktora. Csökkentett fókuszfaktorral számolunk egy csapattagnál akkor is, ha hosszú szabadságról tér vissza.

A fókuszfaktorok Scrum-ban történő alkalmazása nem egzakt tudomány, tapasztalati alapon kell őket “belőni”. Ha sikeres egy sprint, meg lehet kísérelni a fókuszfaktorok növelését (ergo több feladatot vállalhat a csapat). Ha elbukik egy sprint, és a bukás oka az volt, hogy sok feladatot vállalt a csapat, akkor csökkenthető a fókuszfaktor. Ne feledjük, hogy más tényezőket is figyelembe kell vennünk, amikor a fókuszfaktorokat megállapítjuk, vagy változtatni kívánjuk:

• Sprintről sprintre más és más feladatokat csinál a csapat, ezért a becslések egyfajta bizonytalanságot visznek a rendszerbe. Például: lehet, hogy az egyik sprintben túlbecsültük a feladatokat, a másikban alulbecsültük.
• Változhat a sztoripont jelentése: fél év múlva ugyanazt jelenti-e a csapat számára 1 sztoripont?

Cél, hogy meghatározzuk, mennyi sztoripontot tud a csapat egy sprint alatt megcsinálni (ezt hívják sebességnek, angolul velocity-nek). Ehhez leginkább az kell, hogy a csapatban fixálódjon a sztoripont fogalma, ismerjük a fókuszfaktort, és jól menjen a becslés. Pár sikeres sprint után ezek elérhetőek. Ha megismertük a csapat sebességét, középtávú becslésekre lehetünk képesek a product backlog alapján.

Planning poker

Amikor a csapat becsül, sztoripontokat alkalmaz az éppen becsülendő feladat méretének meghatározásához. A Scrum-ban mindenkinek saját kártyái vannak, amiken a következő számok találhatók:

(Mi a kártyákat magunk nyomtattuk, de lehet rendelni online is kártyapaklit.)

A számok nagyjából Fibonacci-sorozatot követnek (azaz a sorozat egy eleme az őt megelőző két szám összege). Azért választották így a kártyákon lévő számokat, hogy a becslések során megkönnyítsék a döntést. Minél nagyobb méretű egy sztori, annál nehezebb megmondani, hogy pontosan hány sztoripontot is ér. Másfelől nem is érdemes túlbonyolítani: ha nagyméretű a feladat, ne is álmodjunk róla, hogy pontosan meghatározzuk, mennyi idő/sztoripont a megvalósítása.

Megjegyzések:

• Azért vannak a kártyák, hogy ne befolyásoljanak a többiek becsléskor (és magunk se befolyásoljuk őket). Egyszerre kell mindenkinek felemelnie a saját választott kártyáját.
• Az gyanús, ha tervezés közben nagyméretű sztoripontok röpködnek (mondjuk 5-nél nagyobbak). Az azt jelenti, hogy a sztorit több kisebb sztorira lehet bontani. Ilyenkor gyakran előfordul, hogy a széteső alsztorik nem is egyforma prioritásúak (ld. előző írásomat a product backlog-ról). Ha létrejön egy ilyen kevésbe fontos alsztori, rakjuk be a product backlog-ba, ne csináljuk meg ebben a sprintben.
• A nagyméretű sztoripontokat rendszerint a product backlog-ban történő becslésnél alkalmazzuk (ld. szintén az előző írásomat).
• A 0 méretű feladatok a pár perces feladatokat jelentik (max. 10-20p).
• A ? azt jelzi, hogy a csapattagnak fogalma sincs, mennyi sztoripontra becsülje az aktuális feladatot. A tapasztalat az azért, hogy egy idő után mindenkinek van valami elképzelése, tehát érdemes felemelni egy számot. Ha van új csapattag, természetesen nála érthető a bizonytalanság.
• A kávé jelzés mutatja, hogy a csapat elfáradt a tervezés közben. Érdemes egy szünetet tartani.

Megismertük a tervezés eszközeit. Most már minden adott ahhoz, hogy a tervezés forgatókönyszerűen ismertetésre kerüljön. A sorozat következő része ezzel folytatódik.

Egy kis kitérő: a csapat, a projekt

Fontos egy rövid áttekintést adnom a szóban forgó projekt hátteréről. Így talán közelebb hozhatom az Olvasót ahhoz, hogy nálunk hogyan is épül fel a csapat, és miről is szól a projekt.

• technológia:
  • egyedi fejlesztés, webes alkalmazás,
  • RIA, kliens oldalon Javascript-framework: SmartClient,
  • Java 1.6, Hibernate, Spring,
  • MS SQL 2005,
  • Apache Tomcat,
  • Domain Driven Design,
  • Continuous Integration (először Hudson majd TeamCity),
  • automatizált tesztek (end-to-end/funkcionális/integration tesztek – kinek mi tetszik, a szükséges részekhez unit tesztek is),
  • IDE: Intellij IDEA,
  • verziókövető: Subversion,
  • hibakövetés: Jira majd Axosoft OnTime.
• üzleti oldal:
  • állami szektor,
  • üzleti probléma: elektronikus iratkezelés, irodai környezet,
  • ügyfél szervezet mérete: 15.000 fő,
  • az üzleti probléma igen komplex.
• a csapat (az összetétele változott az idők során, ez egy fél évvel ezelőtti állapot):
  • 5 fejlesztő (ebből 2 junior fejlesztő),
  • 1 tesztelő,
  • 1 üzleti szakértő (korábban az ügyfél oldalon dolgozott, áthoztuk a projektre),
  • 1 ScrumMaster,
  • a teljes csapat (a ScrumMastert leszámítva) egy szobában dolgozik,
  • velocity: kb. 30 sztoripont/sprint (12 nap).
• a projekt:
  • zöldmezős egyedi szoftverfejlesztés,
  • 2007-ben indult a fejlesztés,
  • azóta is tart, a vége még jó pár év múlva várható (a 15.000 fős szervezet egyes részeinek bevonása éves ütemezéssel történik meg).