Egy korábbi Agile Meetup-on volt szó erről a témáról, és akkor számomra addig ismeretlen technikával találkoztam, amiről érdemes pár szót írni.

A technika neve "The Big Wall", és induló nagyobb projektek becsléséről és kezdő tervezéséről szól. Egyébként erről volt egy előadás is az Optional Conference-en is. Illetve az eredeti itt is elérhető. 

Előfeltételek

• már volt egy nagy megbeszélés, amikor is megszülettek a user story-k, és ebből akár több száz is lehet
• ezek ki vannak nyomtatva, le vannak írva pl. post it, vagy valahogy fizikailag rendelkezésre állnak (esetleg kivetítőn)
• van egy elég nagy felületünk, mondjuk egy fal :)
• vannak íróeszközök, ragasztó, ami a munkához kell
• minden résztvevő ki van értesítve / személyesen el van neki mondva, hogy mi fog történni (agenda), így nincs kérdés

Első félidő - becslés

• résztvevők: Fejlesztők, PO, Scrum Master
• időtáv reggeltől mondjuk ebédig
• fal felépítése
  • vízszintes tengely: story-k mérete
  • függőleges tengely: prioritás
  • szürke: mondjuk egy referencia cetli, amihez a többit lehet méret szerint viszonyítani (na honnan ismerős? :)
• első lépés:
  • ötösével felpakoljuk a cetliket egymáshoz viszonyítva, míg mindegyik el nem fogy
    • ha valahol kérdés van, akkor azt megjelöljük valamivel
    • itt kérdésként merült fel a függőségek kérdése, de erre nem kaptam teljesen kielégítő választ azon kívül,hogy érdemes ezeket valahogy úgy szétbontani, hogy ne legyen függőség (lehet ezen gondolkodni)
    • tovább érdemes valahol egy park részt is kialakítani, ahová olyan cetlik kerülnek, amiről senkinek lövése sincs, ezeket később offline meg kell vizsgálni

• második lépés
  • felkerülnek a becslési számaink
  • és szépen elkezdjük a cetliket közelíteni a számokhoz

• majd meghúzunk egy vonalat, amivel elválasztjuk az egyes becslési számokat, és megkérjük a fejlesztőket, hogy a határvonalon lévő cetliket igazítsák el ide vagy oda. Ezzel eljutunk oda, hogy minden feladat el van helyezve és meg van becsülve (ami túl nagy az lehet később szét kell bontani kisebb feladatokra)

Második félidő - priorizálás

Első lépés - megjönnek a stakeholderek, és a függőleges tengely mentén elkezdik a cetliket priorizálni:

• legfelül a legfontosabbak, alul a kevésbé fontosak
• ha több stakeholder is van, akkor egymás között le kell rendezni az igény ütközéseket
• fontos, hogy csak a sávon belül mozgathatnak, sávot nem lehet váltani :)
• tovább megkérdeztem, és a technikai cetlik is szerepelnek a táblán pl. tesztrendszerrel kapcsolatos cetlik, és ennek a stakeholdere is jelen van, ugyanolyan jogosultsággal
• itt van lehetőség megkérdezni azokat a cetliket, amelyeknél kérdés merül fel az első félidőben (egyébként a fejlesztők elsősorban megfigyelők ezen a megbeszélésen, és figyelik, értelmezik és tanulják az üzleti szempontokat)

Második lépés - négyfelé osztjuk a táblát, ezzel meghatározva a következőket:

• bal felső sarok: fontos és apróbb feladatok --> lényegében az első sprint
• bal alsó sarok: kevésbé fontos, de apróbb feladatok
• jobb felső sarok: fontos, de nagyobb feladatok
• jobb alsó sarok: kevésbé fontos és nagyobb feladatok

• persze ezzel kapcsolatosan merülhetnek fel kételyek, mint ahogy azt a fejlesztőim is felvetették, amikor elmeséltem nekik a dolgot például:
  • függőségek
  • nem biztos, hogy a legfontosabb és apróbb feladatok között vannak ott a core funkciók
  • mi van olyan projektekkel, amiknél még nincs meg az összes igény, mert csak a jövőben derülnek ki az első pár sprint után stb.
  • ezekkel érdemes foglalkozni, utánanézni, egyedileg kitalálni a megoldást
    
    

"Harmadik félidő"

• szóval tudjuk azt, hogy hány storypoint van, hiszen csak össze kell adni őket --» total scope
• azt is tudhatjuk akár, hogy mennyi a csapat velocity-je (ha mérjük, és ha egyáltalán úgy dolgozunk)
• a kettőből egy kisebb ráhagyással megalkotható egy release date intervallum egy burn up chart segítségével, ahol
  • a függőleges tengely a scope
  • a vízszintes lehet többféle
    • lehet egyrészt a sprintek száma, ahol a zöld vonal az optimista becslés vagyis a sprintek száma és a velocity alapján ahol metszi a scope vonalat, ott lehet vége a projektnek +-10%, a piros pedig vonal a pesszimista becslés
    • lehet akár egy költség is, vagyis az előző alapján, ha lebontjuk költségre a storypoint-okat, akkor ki lehet számolni, hogy melyik sprintnél fog elfogyni a pénz, és ez mennyi story-t fog jelenteni elkészülve

Összefoglalva:

• remélem jól írtam le emlékezetből :D
• nekem tetszik, hiszen kb. 1 nap alatt egy olyan projektet, ahol nagyrészt megvannak az igények tényleg be lehet lőni, és akár egy release estimation-t is kaphatunk
• volt még szó a "story-mapping"-ról is

Lássuk a gyakorlatban mit mutatott

Összesen kétszer próbáltam ki a technikát, és meglepő módon nem projektekkel kapcsolatosan. Mindkét alkalom vezetői negyedéves stratégiai meeting volt. Mi terméket fejlesztünk, így zömében mi határozzuk meg a projektjeinket. Ez szerencse vagy sem, nézőpont kérdése (én annak tartom).

Szóval a lista alapján kinyomtattam az igényeket, és facilitáltam a megbeszélést. Meglepő módon működött a dolog. Relatív gyorsan sikerült átbeszélni, elrendezni és priorizálni az igényeket. Ebből fel is tudtam állítani a negyedéves projekt listát. 

Legutóbb pedig úgy bővítettem, hogy:

• már kivetítettem a falra a kis táblázatomat, amibe előzetesen mindenki beledobálta az igényeit (úgy kértem meg a PO-kat, hogy írják be mennyi időt hajlandóak rá szánni (fejlesztői becslés nélkül)
• majd a riportjaim alapján a táblázat tetejére beírtam, hogy az előző negyedéves adatok alapján mennyi idő használható 1">
• amíg zöld volt a képlet értéke, addig maradhatott az igény, miután piros, akkor indulhatott az alkudozás, hogy mi kerüljön ki

Azt mondom hasznos eszköz, érdemes kipróbálni.