A product backlog, ahogy mi szoktuk (Scrum-sorozat 2. rész)
A Scrum-ról szóló cikksorozatom első részében egy rövid összefoglalást adtam arról, hogy mik a Scrum alapszabályai. Ígéretemhez híven folytatom azzal, hogy mi hogyan alkalmazzuk a Scrum-ot.
A product backlog nálunk akkoriban kb. 100 sztorit tartalmazott. Először elvégeztünk egy gyors "vágást", és kizártunk minden olyan sztorit, aminek nem kell még működnie a 2009. január 1-jei éles indulásra. Ezeket elláttuk a 100-as prioritással. Ezzel a vágással a sztorik egy nagy részét sikerült a hatókörünkből eltávolítani. Minden sztorit, ami nem 100-as prioritást kapott, 1000-es prioritással láttunk el.
Ez a post a product backlog-ról szól.
Mi a product backlog?
Az összes hátralévő funkció listája. Semmi "cicó", egy sima lista. Semmi hierarchikus fastruktúra vagy az elemek között ide-oda mutató hivatkozások, függőségek. (Mint ahogyan egyesek szeretik a követelménykezelést emígyen túlbonyolítani.)
A product backlog célja, hogy priorizálva tartalmazza, hogy mik azok a funkciók, amelyek a szoftver fejlesztéséből még hátra vannak. A Scrum nem is a funkció, hanem igazából a sztori kifejezést használja. Ennek a célja az, hogy rámutasson, hogy a product backlog-nak üzleti szempontból kell tartalmaznia a hátralévő feladatokat, funkciókat. (Story = mese, történet.) Tehát a product backlog nem tartalmaz olyan sort, hogy "admin felület szerveroldala", lehetőség szerint olyat sem, hogy "admin felület" (helyette inkább pl. felhasználók és jogosultságaik adminisztrálása). Olyan sor sincs benne, hogy "telepítés" vagy "XY funkció tesztelése". A product backlog egy banki webes rendszernél például ilyen sorokból (sztorikból) állhat:
- Átutalás,
- Számlatörténet lekérdezése,
- ...
Jó kérdés, hogy a szoftverben talált hibák bekerüljenek-e a product backlog-ba. Valakik szerint igen, valakik szerint nem. Én azok táborába tartozom, akik azt mondják, hogy általában ne kerüljenek be a hibák a product backlog-ba, kivéve akkor, amikor új sztoriról van szó. (Erről külön blogbejegyzés fog szólni.)
A product backlog a Scrum stratégiai mozgatórugója. Ez jelöli ki, hogy a következő sprintben milyen sztorikat kell megvalósítani, ill. az azt követő sprintekben várhatóan milyen sztorik következnek. Ha a csapat már rutinos, és az adott projekt is zökkenőmentesen halad, akár pár hónappal előre is tervezhetünk a segítségével. (Mi meg tudjuk mondani, hogy a product backlog-ból milyen sztorikkal leszünk kész fél évvel később.)
Mi Excelt használunk. Sok programozó utálja (én szeretem). Soha nem akartam célszoftvert a product backlog szerkesztéséhez. Meggyőződésem, hogy nem lehet semmi sem olyan rugalmas erre a feladatra, mint maga az Excel.
Mi van pontosan a product backlog-ban?
A product backlog nálunk a következő oszlopokat tartalmazza:
- (A) azonosító: S-001-től indultunk ("S", mint sztori). A következő felmerülő sztori a következő sorszámot kapja.
- (B) sztori megnevezése: a sztori rövid megnevezése (pl. "számlatörténet lekérdezése"),
- (C) prioritás: egy szám (súly), ami minél nagyobb, annál fontosabb a sztori, (OK-t írunk be, ha elkészültünk vele)
- (D) sprint: melyik sprintben készült el a sztori (ha már kész van),
- (E) becsült sztoripont: egy becslés, hogy az adott sztori mennyi ráfordítással készül el,
- (F) megjegyzés: bármilyen szabad szöveges információ.
(A) Az azonosító
Minden sztorinak van egy egyedi azonosítója. Ez igen hasznos:
- mert könnyen megtalálhatunk bármit, ha később újrapriorizáljuk a táblázatot;
- a sprint során is hasznos a sztorik azonosítására;
- amikor commit-álunk, feltüntetjük a sztori azonosítóját is a logban, hogy szükség esetén könnyebben összegyűjthetőek legyenek az egy sztorihoz tartozó commit-ok;
- az ügyfél is megkapja a product backlog-ot, a sztorik azonosítói segítik a nagy táblázatban történő eligazodást.
A sztorik azonosításához az első felmerülő sztorihoz az S-001-et, a következőhöz az S-002-et s.í.t. használjuk. A sorszám nem utal a prioritásra, csak egy "buta" egyedi azonosító minden egyes sztorihoz.
(B) A sztori megnevezése
Teljesen nyilvánvaló, hogy szükséges egy rövid megnevezés minden sztorihoz. Az elnevezéskor vegyük figyelembe, hogy úgy adjunk nevet a sztorinak, hogy - lehetőség szerint - az ügyfél külön magyarázat nélkül is megérthesse.
(C) A prioritás
Valakik azt mondják, hogy úgy priorizáljuk a sztorikat, hogy ne legyen két olyan sztori, amely ugyanazt a prioritást kapja. A szándékuk érthető, mert azt szeretnék hangsúlyozni, hogy adott helyzetben mindig el lehessen dönteni két sztori közül, hogy melyik a fontosabb. Az én tapasztalatom viszont az, hogy ha sok elemű a product backlog (több tucatnyi sztori van benne), igencsak macerás egyedi prioritást adni minden sztorinak, mert a product backlog folyamatosan változik.
Hogyan kezdjük a priorizálást, amikor épp egy nagy számosságú sztorihalmaz előtt ülünk? Az első sztori, ami szembe jön, legyen - mondjuk - 1000 prioritású. Jöjjön a következő. Hát, ez kevésbe fontos, mint az előző, legyen ennek a sorszáma 900. A harmadik sztori vajon milyen prioritású legyen? Az elsőnél nem fontosabb, viszont a másodiknál igen. Akkor legyen - mondjuk - 950.
Látható, ahogy egyre több sztorit priorizáltunk, egyre nehezebben találjuk meg az éppen vizsgált sztori helyét a sorban, mert mindig végig kell néznünk az összes már bepriorizált sztorit. Ezért célszerű inkább mérföldkövek alapján priorizálni. (Mi legalábbis erre jutottunk.) Ld. esettanulmány a cikk végén.
(D) Sprint (mint product backlog táblázat oszlop)
Amikor egy sztori elkészül, beírjuk a táblázat megfelelő oszlopába, hogy melyik sprintben készült el. Ezáltal utólag is látható, hogy milyen ütemben készültek el az egyes sztorik. (Pl. ügyféllel történő találkozáskor.)
(E) Becsült sztoripont
A sztorikat előzetesen "besztoripontozzuk", azaz minden sztorihoz megbecsüljük, hány sztoripontot ér. (A sztoripontról majd a tervezési részben írok részletesen.) A csapat teljesítménye a sprintek során nagyjából állandó, de legalábbis előre tervezhető (szabadságolás, új ember kerül a projektre, valaki elmegy stb.) Ha tudom, hogy az elmúlt sprintek alatt hány sztoripontot teljesített a csapat, akkor elvileg kiszámíthatom, hogy - a prioritások alapján - az elkövetkezendő sprintekben milyen új sztorik fognak elkészülni.
A sprint tervezéssel ellentétben, ahol a csapat közösen becsli meg, hogy az adott sprintre betervezett sztori hány sztoripontot ér, a product backlog priorizálása közben a sztoripontozást én magam végeztem. (Mivel elég stabil volt a projekt és a csapat is, ezért viszonylag egyszerűen (és gyorsan!) ment a dolog. Utólag visszanézve stabilan 20%-kal felé lőttem a valóságnak, de ez annak is tudható volt, hogy mindig biztonságosan próbáltam előre több hónapra becsülni.)
Az angol szakirodalomban a becslés ezen módszerét Yesterday's weather-nek hívják, azaz ha tudom, hogy az előző sprintben mennyit teljesített a csapat, akkor azzal számolva jól becsülhetem, hogy a közeljövőben hogyan fogunk tudni újra teljesíteni.
(F) Megjegyzés
Ezt az oszlopot csak időnként töltjük, ha úgy látjuk, hogy egy sztori kapcsán felmerült valamilyen releváns információ, amit célszerű feljegyezni. Akkor használjuk pl. ha a sztori megnevezése nem elegendő, vagy pl. azt is beleírjuk, ha az ügyféllel előre egyeztetni kell a sztori kapcsán.
Hogyan készül a product backlog?
Ha elkezdjük a Scrum-ot, csináljunk egy hozzávetőleges listát. Nem kell félnünk soha: a product backlog arra teremtetett, hogy változzon. Ha elszúrunk valamit, bármikor javíthatunk. Csináljuk kövspec alapján, csináljuk emlékezetből, nézzük a szoftver elkészült képernyőit, esetleg képernyőterveket, ami eszünkbe jut, és még nincs kész, jegyezzük fel. Ha terméket fejlesztünk, akkor különösképpen érdemes vizionált funkcionalitásokat is bele írni. Így lesz már egy jó kis listánk.
Pár jótanács:
- A nagyméretű sztorikat próbáljuk több kisebbé alakítani! Ezáltal külön is fogjuk tudni priorizálni őket, és adott határidőre valójában kevesebb feladattal kell végezni (mert a nagy sztori egyik fele általában későbbre is elég).
- Próbáljuk végig gondolni reálisan azt, hogy mi a tényleges(!) hatása annak, ha nem készül el időre egy sztori! Amin ilyenkor el szoktam gondolkozni: tényleg olyan nagy gond? Meglepően sokszor nem az, csak mindenki túldramatizálja a helyzetet. Járjuk körbe a témát, ne dőljünk be senkinek elsőre!
- Végezzül el a priorizálást az ismert határidők, mérföldkövek alapján! (Ld. esettanulmány a cikk végén)
- Ha már minden kötél szakad, és tényleg az látszik, hogy teljesíthetetlen határidőre a dolog, azonnal jelezzük az ügyfélnek a dolgot! A saját projektünkben az volt a tapasztalat, hogy a problémákat már idejekorán fel lehetett ismerni. (Nem két héttel a határidő előtt derül ki, hogy abszolut teljesíthetetlen a dolog.)
A product backlog állandóan változik. Mik a tipikusak?
- Ha az ügyfélnek menet közben jön ötlete: semmi gond, bele rakjuk a listába, és bepriorizáljuk. Ha valóban fontos, akkor sorra fog kerülni, ha nem, akkor elsínylik. Sokkal jobb annak az optikája, hogy mindent, amit mond, betervezünk, és majd az idő (és pénz!) függvényében meglátjuk közösen, hogy tényleg belefér-e, mintha egyből figyelmen kívül hagynánk, amit mond.
- Nagy sztorik vannak a product backlog-ban, amiket később lebontunk. Előbb-utóbb ki fog derülni, hogy vannak-e ilyenek, mert túl nagyok: nehezebben becsülhetőek, és hogyha mind megcsinálnánk őket, kicsúsznánk az időből.
- Sprint (implementáció) közben kiderül, hogy van valami, amire nem gondoltunk. Ilyenkor két döntésünk van: vagy beleértjük a sprintbe az előre nem tervezett dolgot, és ezzel a sikeres sprintet kockáztatjuk, vagy pedig új sztoriként bevesszük a kérdéses elemet a product backlog-ba.
- A későbbiekben a tesztelés során is kiderülhet, hogy valamire nem gondoltunk. Nem arra gondolok, hogy a programozó hibázott, hanem arra, hogy egy probléma hátterében valójában üzleti probléma áll. Mi rengeteg ilyennel találkozunk.
A product backlog és az ügyfél
A product backlog-ot az ügyféllel történő státusz egyeztetésekre is használjuk. Minden sprint végén el szoktunk látogatni az ügyfél megfelelő vezetőjéhez, és elmondjuk, miket csináltunk meg az elmúlt sprintben, és mik várhatóak az elkövetkezendőkben. Amikor az ügyfél szakmai embereivel beszélgetünk, akkor közösen egyezünk meg a sztorik prioritásáról. Magunktól végezzük el a sztorik priorizálását, és nekik ezt már csak "tálaljuk". Így nekik nem kell sokat dolgozni, viszont ha valamivel nem értenek egyet, akkor azon közösen változtathatunk.
A product backlogot A3-as lapra nyomtatjuk, és úgy adjuk át az ügyfélnek. A közös megbeszélésen mindenkinek van egy saját példánya. Nagyon szokták szeretni. Be szoktuk rajzolni a táblázatba a mérföldköveket is.
Esettanulmány (prioritás meghatározása)
Mi a következőképpen gondolkoztunk 2008 év elején, amikor átnéztük a product backlog-ot:
- (A) az ügyfélnek májusban oda kell adni a szoftvert, hogy az ügyfél kulcsoktatói (3 fő) felkészülhessenek az oktatásra,
- (B) júniusban kezdőnek az oktatások és egész nyáron át tartanak (a rengeteg szabadságolás miatt), kb. 90 főt kell oktatni,
- (C) október 1-jétől indul egy kéthónapos próbaüzem, amelynek célja, hogy a felhasználók megállapíthassák, hogy alkalmas-e a szofver az éles használatra, és kiderülhessenek valós felhasználás közben a szoftver hiányosságai,
- (D) következő év (2009) január 1-jétől indul az éles üzem.
Ügyfél mondása 2008. januárjában: "a júniusi oktatásokig _mindennel_ el kell készülni!"
Szeretem ezt a mondatot. Annyiszor hallottam már. A háttérben arról van szó, hogy mindenki a saját s*ggét védi. A valóság persze ennél sokkal árnyaltabb. Ha a dolgok mögé nézünk, és ügyesek vagyunk, a mission impossible szituációkat is megoldhatjuk.
Minden 1000-es prioritású sztorit megbecsültünk. Ez alapján kijött, hogy az éles induláshoz (D) lefejlesztendő funkciókkal nem tudunk májusra (A) végezni, sőt, az összes funkció lefejlesztése nagyjából a teljes évet igénybe veszi (vö. ügyfél mondása). Kényszerhelyzetben voltunk, ezért tovább kellett gondolni a dolgot.
A következő lépés az volt, hogy meghatároztuk, hogy mik azok a funkciók, amik az (A) ill. (B) mérföldkőhöz kellenek (azért így párban, mert viszonylag közel voltak egymáshoz, és hasonlóak voltak az elvárások a két mérföldkőnél). A cél az volt, hogy azokat a sztorikat valósítsuk meg addigra, amiket a felhasználók túlnyomó többsége a leginkább használ. (Az nem annyira baj, ha van egy ritkán használt funkció, és nincs kész. Hiába oktatnák le a felhasználóknak, mire október lesz, addigra úgyis elfelejtik, és úgyis meg kell nézni a felhasználói kézikönyvet, vagy meg kell kérdezni a kulcsoktatót.)
A próbaüzemig (C) nagyjából mindennel készen kellett lenni. Ha egy funkciót nem tudtak leoktatni (mert az oktatások során készültek el, vagy idő közben megváltoztak), azokról készítettünk egy külön doksit a felhasználóknak.
Az időzítés nagyon fontos volt. Nem lehetett egy olyan rendszert oktatni, ami a használatba vételig (próbaüzem) a felhasználók zöménél jelentősen megváltozik. Sokat osztottunk-szoroztunk, sztorikat bontottunk fel kisebb sztorikra, abban a reményben, hogy az egyik része fontos, a másik nem annyira, végül sikerült egy olyan prioritást megalkotnunk, amely a mérföldkövekkel egybevágott. Az egyes mérföldkövekhez tartozó prioritások nagyjából a következők voltak:
- A: 1000,
- B: 900,
- C: 500,
- D: 300,
- egyéb: 100.
Az érdekesség az volt, hogy még tudtunk játszani azzal is, hogy az oktatások során milyen sorrendben készüljenek el az újabb funkciók, ugyanis a felhasználók jól elkülöníthetően 3 csoportba tartoztak:
- ügyintézők (kb. 75 fő),
- vezetők (kb. 10 fő),
- "admin jellegű" felhasználók (kb. 5 fő).
Tehát az oktatások elejéig az ügyintézői funkciókkal kellett meglennünk, és az oktatások végére kellett csak a vezetői ill. az "admin jellegű" felhasználók által használt funkciókkal elkészülnünk. Ígyhát a B és C közötti mérföldkövek között is fel tudtunk állítani plusz mérföldköveket, ill. prioritásokat.
Így sikerült megoldanunk azt a helyzetet, amikor az ügyfél kijelentette, hogy júniusra minden funkció kell.
A cikksorozat részei:
3/1. A sprinttervezés
3/2. A sprinttervezés
4. A sprint (jövőben)
5. Retrospective (jövőben)
6. Hogyan induljunk? (jövőben)
7. A Scrum és az agilitás (jövőben)
8. A Scrum sötét oldala (jövőben)
9. Scrum szótár (jövőben)
10. Scrum összefoglalás (jövőben)
bejegyezte: Marhefka, István , bejegyzés időpontja:
2:05
11 megjegyzés
