Az előző post kicsit hosszúra sikeredett, viszont megismerhettük a tervezés legfontosabb eszközeit: az előkészítést, a sztoripont fogalmát, a fókuszfaktort, a kapacitástervezést és a Planning Poker-t. Minden együtt van ahhoz, hogy a tervezés teljes forgatókönyvével tisztában lehessünk.
A tervezés forgatókönyve
0. Készüljünk elő: aktualizáljuk a Product Backlog-ot, készüljünk fel a sztorikból!
1. Tervezzük meg a csapat kapacitását: határozzuk meg, hogy az elkövetkezendő sprint alatt hány sztoripontot tudunk teljesíteni! (Ld. kapacitástervezés)
2. Vegyük a legfontosabb sztorit!
3. Bontsuk le közösen feladatokra!
4. Becsüljük meg az egyes feladatok méretét!
5. Menjünk vissza a 2. lépésre, amíg tudunk újabb sztorit választani, ami még befér a sprintbe.
A tervezést rendszerint a Scrummaster moderálja. (Nálunk a meeting request-eket is ő küldi ki a tervezésre.)
Előfeltétel, hogy a Product Owner priorizálja a Product Backlog-ot a tervezésre. A csapat ezt ne bírálja felül, fogadja el, hogy ez a prioritás. A csapat meg azt állapítja meg, hogy a rögzített hosszúságú sprintben mennyi sztorit tud elkészíteni.
Feladatokra bontás
A Product Backlog-ból a sztorikat prioritás szerint vesszük elő.
Először mindenkinek meg kell értenie, hogy miről szól a sztori. (A mi esetünkben ennek lehetőségét a korábban elkészített rövid, érthető dokumentáció, és az üzleti szakértő (Albert) jelenléte biztosítja.) Ha ez megvan, akkor a csapat közösen lebontja a sztorit kisebb feladatokra.
Pár dolog:
- A kártyákkal történő becslést (Planning Poker) akkor célszerű elvégezni, amikor az aktuális sztori feladatokra bontásán túl vagyunk (mindenki egyszerre emeli a kártyát!).
- Magukat a feladatokat becsüljük, nem a teljes sztorit.
- Nagyon fontos, hogy akkor vegyünk véglegesnek egy becslést, ha abban a csapat közösen egyetért. Ha véleménykülönbségek vannak, akkor azokat ütköztetni kell (Scrummaster feladata), meg kell vitatni, és konszenzusra kell jutni.
A feladatokra bontás több eredménnyel is jár:
- a csapat végiggondolja a sztori megvalósításának menetét,
- ezáltal még jobban megismeri a problémát (esetleg újabb kérdések is felszínre kerülnek),
- a kisebb méretű feladatokkal történő becslés pontosabbá teheti a teljes sztori becslését,
- ha kisebb méretűek az elvégzendő feladatok, akkor jobban követhetővé válik sprint közben a haladás. (Megszűnik a napokig, hetekig tartó “80-90%-ban kész vagyok, már csak…” probléma.)
Az alábbiakban összefoglalom azokat a tapasztalatokat, amiket a feladatokra bontásnál szedtünk össze. Figyelem, ezek nem Scrum-szabályok, hanem a saját megfigyeléseink és gyakorlatunk!
Ne válasszuk szét a munkafázisokat!
Példa: ha a sztori egy webshop alkalmazásnál a “Regisztráció”, akkor ne legyen két külön feladat az, hogy “Regisztráció fejlesztése” és “Regisztráció unit test írás”, hanem állapodjon meg a csapat, hogy egy sztori/feladat elvégzéséhez a unit-test-ek megírása is szükséges.
Mivel kisméretű a csapat (max. 7-9 fő), ezért nem szükséges a munkafázisok szerinti szájbarágos feladatrészletezés. Mindenki tudja, hogy mi a feladata. Ha mégis így teszünk, rengeteg függőséget viszünk be a feladatokba, ráadásul drasztikusan megemelkedik a feladatok száma, ami Micro Management-et eredményez.
Sok kicsi sokra megy!
Ha túl sok az apró feladat, akkor torzíthatják a becslést.
Ha túl sok a 0-s sztoripontú feladat, akkor ezek összege is 0. A valóságban ezek valószínűleg a 0-nál sokkal több idő alatt fognak elkészülni.
A másik eset, hogy ha a sok apró feladatot 0.5 sztoripontra túlbecsüljük (ez kb. fél-1 napos időtávot jelent a biorobot pontrendszerben), akkor a sok ilyen apró feladat együttesen tetemes ráfordítást jelent, pedig valójában lehet, hogy csak 1 nap kellene a fejlesztésükhöz.
Nem baj, ha egy feladat nem egységnyi ideig tart
Ugye milyen jó lenne, ha egységnyi idejű feladataink lennének (mondjuk, amik egy napig tartanak)? Ha valaki egy nap elkezd egy feladatot, a következő napra be is fejezné. Nagyon könnyen követhető lenne a haladás sprint közben. Ez sajnos a valóságtól elrugaszkodott feltételezés, nem árt azzal tisztában lennünk, hogy ez nem fog menni. Nem lehet úgy megerőszakolni a feladatokra bontást, hogy ez teljesüljön, és ezzel ráadásul elősegítjük a Micro Management-et.
Törekedni azonban lehet arra, hogy a feladatokra bontás során egy-egy feladat rövid idő alatt teljesíthető legyen (1-2 nap).
Felejtsük el az alkalmazás rétegeit!
Egy sztorit ne az alapján bontsuk feladatokra, hogy az alkalmazásban milyen rétegek vannak.
Pl. egyik feladat az X funkcióhoz felhasználói felület készítés, a másik ennek szerveroldalának elkészítése!
Itt már át is megyünk Micro Management-be. Kétszer annyi kártyánk lenne sprint közben a falon (ha még több rétegre bontanánk, akkor még több), amitől nehézkesebbé válik a haladás áttekintése, és előtérbe kerülhetnek a 0-0.5 sztoripontos feladatok (ld. fenn).
Azért nem kell a rétegekkel foglalkoznunk, mert legtöbbször az egyes rétegeket nem lehet függetlenül fejleszteni, közös munkára van szükség. Pl. a felhasználó felület helyességét nehéz tesztelni a meglévő szerver oldal nélkül, és a kettő közötti interfészt is közösen kell kialakítani.
Ne adott emberhez tervezzük a feladatokat!
Úgy gondolkozzunk, hogy nem tudjuk még, ki fogja csinálni a feladatot! (Merthogy sprint közben fog kiderülni.) Mivel elviekben keresztfunkcionális a csapatunk, és nem rétegek szerint vágjuk a feladatokat, ez teljesíthető.
Ne foglalkozzunk a függőségekkel!
Nem kell a feladatok közötti függőséggel törődni. Miért? Mert kevesen vagyunk a csapatban, egy sprint rövid ideig tart. Talán a csapat a sprint közben is el tudja dönteni, hogy milyen sorrendben célszerű haladni. (Micro Management, ismerős?)
Nem baj, ha egy feladatot nem egy ember végez
Az lenne az ideális, ha a sprint közben számonkérhetőek lennének az egyes emberek, hogy hogyan állnak a saját választott feladatukkal. Ha ketten dolgoznak egy feladaton, akkor már nem egyértelmű, hogy ki az, aki miatt nem halad a feladat elvégzése.
Az, hogy egy feladaton egyszerre csak egy ember dolgozhat, sajnos, ismételten Micro Management-hez vezet, mert a legtöbbször rétegek vagy munkafázisok szerint szerveznénk a feladatokat. Ezért célszerű belenyugodni abba, hogy nincs azzal baj, ha egy feladaton többen is dolgoznak.
How-to-demo írása
A Scrum egyik szabálya, hogy az elkészített feladatokat mindenki saját maga demózza az ügyfélnek (vagy a Product Owner-nek). Ezért – annak ellenére, hogy a csapat közösen tervez, fejleszt stb. -, minden fejlesztőn ott a személyes felelősség. Ha nem veszi komolyan a munkát, akkor beég az ügyfél előtt a demón.
Ahhoz, hogy ne csússzanak félre a dolgok (egyértelmű legyen, hogy mi a fejlesztendő funkció, valamint hogy hogyan lehet azt bemutatni az ügyfél előtt), meg kell határozni, hogy hogyan demózható egy-egy elkészítendő feladat. Ezt nevezik “How-to-demo”-nak.
Valakik azt javasolják, hogy tervezés közben határozzuk meg, hogy az egyes sztorikat (esetleg feladatokat) hogyan lehet majd demózni. Ez egyfajta specifikáció a fejlesztőnek a sprint idejére, másrészről pedig elfogadási kritérium (Acceptance Criteria). Mi nem ezt a módszert alkalmazzuk, több okból is.
- A mi esetünkben nagyon sok ideig tartana, ha egy-egy forgatókönyvet megírnánk, és a tervezés akár több napig is eltartana (annyira komplexek a sztorik).
- Megadjuk a lehetőséget arra, hogy ha az implementáció során a modellben valamilyen problémával szembesülünk, akkor korrigálhassuk a forgatókönyvet. Úgy gondoljuk, hogy nem érdemes túlságosan korán specifikálni a feladatot (még a sprint előtti tervezés is több esetben korainak bizonyult!). Helyette hagyjuk, hogy a fejlesztő sprint közben írja meg a forgatókönyvet. Miután elkezdi “felszívni”, beleásni magát a sztoriba, sokkal jobban átlátja a lehetőségeket, a lehetséges ellentmondásokat, és így jobb forgatókönyv tud készülni.
A How-to-demo-t egyébként egy rövid leírásnak kell elképzelni, amit a csapat tagjai megértenek. Nem kell olyan részletekig kidolgozni, hogy az az ügyfél számára is átadható legyen (nekik ott van a demó).
Egy How-to-demo, amit mi írtunk éles projektben. Egy teljes iratkezelési folyamatot mutat be. A TEST előtag jelzi, hogy az adott ponton ellenőrizhető a meglévő eredmény.
How-to-demo: Visszavárt irat érkeztése ügyvitelre leadott ügyiratba
|
Sprint Backlog
A Product Backlog tartalmazza az összes hátralévő sztorit. A Sprint Backlog ehhez képest azon sztorikat tartalmazza, amik beférnek az aktuális sprintbe. Nem csupán a sztorik neve, hanem a lebontott feladatok és azok becslései is szerepelnek benne.
A táblázatban a következő adatok találhatók:
- A oszlop: sztori azonosítója,
- B oszlop: sztori megnevezése,
- C oszlop: a lebontott feladat neve,
- D oszlop: prioritás (a sztorié a product backlog alapján, az összes feladat ezt örökli),
- E oszlop: a feladatra becsült sztoripontok száma,
- F oszlop: a taszk egyedi azonosítója a sprinten belül,
- 1. sor: hányadik sprintnél járunk, mikor van a demó,
- 2. sor: a sprint célja – mindig kitaláljuk, hogy miért is van ez a sprint. Pár szóban megfogalmazzuk a célját. Elvégre nem árt, ha tudja az egész csapat, hogy mi is a célja az aktuális munkának.
Timeboxing
A Scrum egyik alapvetése, hogy szigorú időkereteket (timebox) alkalmaz. A legalapvetőbb időkeret magának a sprintnek az időtartamára vonatkozik: ha egy sprint kéthetes, akkor egy nappal sem tart tovább. A timeboxing-ot lehet alkalmazni magára a tervezésre is: ha a Scrummaster 2 órát szán a tervezésre, akkor az egy perccel se lehet hosszabb. A csapatnak meg kell tanulnia, hogy hogyan tervezzen hatékonyan, mint ahogy azt is meg kell tanulnia, hogy hogyan szállítsa a sprintre betervezett sztorikat.
Habár az irodalomban szerepel a timeboxing alkalmazása a tervezésre, bevallom, mi ezt a szabályt nem alkalmaztuk. Nekünk nem voltak terjengősek a tervezések, ha a 2 óra után még kellett fél óra, akkor fél órával tovább tartottuk. A tervezés szigorú timeboxing-ja csupán egy módszer: ha a csapat nem képes megfelelően működni, akkor korlátok közé szorítjuk. Ezáltal megtanulhatja hatékonyan felhasználni a rendelkezésre álló időt.
Végezetül jöjjön egy képzeletbeli sprinttervezés párbeszéd részlete.
A fiktív sprinttervezés résztvevői az előző részben említett csapat tagjai: Albert (az üzleti szakértő), Jónás (junior fejlesztő), Döme (junior fejlesztő), Iván (senior fejlesztő), Zalán (senior fejlesztő), Csubi (Scrummaster).
[A fejlesztendő termék egy banki webes rendszer. Éppen megtörtént a kapacitástervezés az aktuális sprintre.] Csubi: Az első sztori a product backlog-ból az “Átutalás”. Albert, mesélnél róla egy kicsit? Albert: Ezt valószínűleg mindannyian ismeritek már. Egyszerűen arról van szó, hogy egy ügyfél egy meghatározott összeget átutal a saját bankszámlájáról egy másik bankszámlára. Miután bevitte az adatokat, kellene egy ellenőrző képernyő, ahol lecsekkolhatja a bevitt adatokat. Az egészet majd később lehessen időzíteni is, de az egy másik sztori. [Itt Albert arra utal, hogy ez is egy lefejlesztendő funkció, és benne is van a Product Backlog-ban, de kisebb prioritással, és majd egyszer meg kell azt is csinálni.] Csubi: Elég ennyi infó a feladatokra bontáshoz? Csubi körbenéz. Mindenki bólint. Csubi: Rendben. Érdemes szétbontani feladatokra? Döme [junior fejlesztő, nemrég érkezett a projektbe]: Lehetne az első az, hogy a funkció kiválasztása a főképernyőről. [Zalánnak felcsillan a szeme, már várta ezt a magas labdát.] Zalán: Ezt mindig úgy csináljuk, hogy beleértjük a feladatba. Tehát magától értetődik, hogy ahhoz, hogy egy funkció működjön, ahhoz kell lenni valahol egy linknek vagy gombnak, amivel a funkció elindítható. Ha valaki csinálja az átutalás felhasználói felületét, akkor felrakja ezt a gombot a főképernyőre. [Döme elbizonytalanodik.] Döme: Ja, bocs, nem tudtam. Csubi: Semmi gond. Akkor mi legyen az első feladat? Jónás: Szerintem legyen az adatok bevitele, utána jöhetne az átutalás. Iván: Várj, az ellenőrzés ne maradjon ki. Csubi: Tehát akkor: adatok megadása, ellenőrzés, átutalás. Jó így? [Senki nem válaszol, mindenki üveges csirkeszemekkel néz maga elé.] Csubi: Na, mi az? Nem túl fitt a csapat így kora reggel! Döme: Tegnap volt egy kis pókerparty, a végére kicsit sok lett a vodka. [Mindenki röhög egyet magában. Csubi is elmosolyodik.] Csubi: Ja, értem már. Na, jó, akkor úgy veszem, hogy mindenki igent mondott. Be is írom az Excelbe. [Egyetért a csapat. Csubi kezeli az Excelt: beírja a Sprint backlog-ba az első három feladatot.] Csubi: Rendben. Becsülhetünk? Az első feladat az adatok megadása. Ki mennyit becsül? [A kártyák a kezek ügyébe kerülnek, és elindul a gondolkozás. Valaki a kezében tartja az egész paklit. Az első kártyát hátra teszi, majd a következőt megint, és addig folytatja, amíg meg nem találja a kívánt pontszámú lapot. Iván mindig fejjel lefelé tartja őket az asztalon: bal oldalon a 0-ás kártya, utána következik jobbra növekvő sorrendben a többi: 0.5, 1, 2, 3, 5. A többi kártyát nem is rakja maga elé, mert olyan nagyságú feladat még sosem volt, és valószínűleg nem is lesz. Különben az már több sztorivá vagy még kisebb feladattá lenne bontható. Mindenki a kezébe fog egy kártyát, és közben a többieket figyeli, hogy vergődnek-e még a kártya kiválasztásán. Döme, akinek ez az első sprintje, meglehetősen hamar kiválasztotta a saját kártyáját, és mosolyog magában.] Csubi: Ok. Kérem a téteket! [Két 2-es, egy 1-es, és egy ?-t mutatnak fel a csapattagok. A ?-et Döme mutatja fel, nem igazán tudja még, hogy hány sztoripontot érhet a feladat.] Csubi: Na, látom, nincs egyetértés. Jónás! Te miért mutatsz 1-et? Jónás: Szerintem nem nehéz a feladat, felrakjuk a főképernyőre az új linket, aztán megjelenik egy sima űrlap, viszonylag kevés adattal. Zalán: Hát, azért szerintem kell a 2 nap. Meg kell írni a unit- és integrációs teszteket is. Jónás: Ó tényleg, mindig elfelejtem! Csubi: Rendben. Akkor lehet 2? [Mindenki bólint. Döme elfogadja a csapat döntését, és arra gondol, vajon mikor jut el ő is oda, hogy képes legyen jól becsülni. A csapat folytatja a következő feladattal.] |
Mick
Feb 13th, 2014Ilyenekből kellene könyvet írni. Vinnék, mint a cukrot.
Nagyon tetszett.