Az Agile 5 szintű tervezése

Az Agile tervezés lényege az, hogy öt, jól definiált stratégiai szinten, folyamatosan dolgozunk a termék fejlesztésén.

Az Agile minden idegszálával szembe megy az a megközelítés, hogy “mindent végiggondoltunk, mindent megterveztünk, és íme a specifikáció, amit mindebből írtunk. Gondolkodni nem kell, már csak ezt kell legyártani”.

Az Agile termékfejlesztés végső célja az üzleti érték folyamatos maximalizálása.

Ez utóbbit mindenki szereti.
Amit senki sem szeret, és ebben az Agile sem kivétel, az a feladatok felesleges elnyújtása. 

Üzleti értéket maximalizálni akkor lehet, ha a fejlesztés minden időpillanatában képesek és  hajlandóak vagyunk érdemben reagálni az üzleti környezet változásaira. A friss információkat, tudást be tudjuk építeni a termékbe. Ehhez szükséges, hogy a tervezés szintjein, a termékfejlesztés minden fázisában, folyamatosan gondolkodjunk arról (azaz tervezünk), hogy az éppen aktuális ötletünk a legértékesebb-e, vagy van esetleg annál hasznosabb fejleszthető feladat, validálandó elképzelés.

Ha ez utóbbiak bármelyikére a válasz igen, akkor érdemes azt beemelni a fejlesztésbe. Természetesen ez nem azt jelenti, hogy kapkodhatunk! Ha valamit elkezdtünk, azt legalább egy minimális piaci készültségi szinten többnyire érdemes is befejezni..

Az öt szint

  1. Product Vision: termékvízió
  2. Product Roadmap: az az út, ami mentén a termék létrejön, a főbb mérföldkövek üzleti logikai kapcsolata
  3. Release: ami egy nagyobb üzleti logikai egységet jelent, néhány sprint fejlesztési idővel
  4. Iteration: Iteráció, ami scrum csapatokban a szigorúbb sprinteket jelenti
  5. Daily Planning: a napi szintű koordináció és tervezés, ahol törekszünk a nap végéig a definition of done szerint kész állapotra hozni maximális mennyiségű feladatot

Az öt szintű bontás jelentősége

A tervezés öt szintjének bontása rengeteget segít a szervezeti hierarchiában a különböző szereplőknek. Lehetővé teszi, hogy ne kelljen egy projektben mindenkinek mindennel tisztában lennie ahhoz, hogy a saját hierarchia szintjének megfelelő súlyú döntéseket tudjon hozni.

Sokszor azért akadozik a kritikus vezetői involvement, mert túl sok felesleges információt kellene feldolgoznia ahhoz, hogy a döntést a megalapozottság érzetével tudja meghozni. 

  A termékvízió

A termékvízió egy műfaji sajátosságokkal és szabályokkal rendelkező artifact, amit elő kell állítani ahhoz, hogy a projektek egymáshoz képest összehasonlíthatóak legyenek.

A termékvízió részletes szabályait egy másik Blog bejegyzésben fogjuk elmondani. Itt most elég annyi, hogy hogyan és mire lesz jó. A termékvíziónak a haszna az, hogy magáról a termékről többek között az üzletileg “miért fontos”, “hogyan fog hasznot hajtani”, kérdésekre válaszol. A Product Visionök rendkívül rövidek, általában egy A4es oldalra elférnek. Alkalmasak arra, hogy több termékvíziót egymás mellé téve a stratégiai szint dönteni tudjon, hogy melyik termékre akar fókuszálni és melyikre nem. Amire nem akarunk épp fókuszálni, az nem azt jelenti, hogy azt eldobtuk. Azt jelenti, és csak azt, hogy később fogjuk megcsinálni.

Akkor végeztük jól a munkát, ha sorrendbe tudtuk állítani a projekteket valamilyen szempontrendszer szerint. Így segítjük a  portfólió szintű priorizálást.

Product roadmap, az út

A Roadmap akkor jön,  amikor már legalább egy stratégiai szinten azt mondtuk, hogy a projektet meg akarjuk csinálni. Hogy milyen módon, és milyen nagyobb lépésekben, ez a Product Roadmap. Teljesen klasszikus artifact. Azonban az Agile szemléletet magunkévá téve nem kell, hogy túl részletes legyen. Szükségünk van arra, hogy kellően lazán írjuk meg a Roadmapet ahhoz, hogy tudjunk alakítani a projekten belüli prioritásokon. Ha itt bemerevedünk, akkor gyakorlatilag egy Waterfall típusú feladattá alakítjuk a működésünket, ami egyenlő azzal, hogy nem fogunk tudni üzleti értéket maximalizálni. 

A Roadmap még kényelmes lehetőséget ad a vezetői beavatkozásra. A Roadmaptől lefele már nem kell, hogy a stratégiai szint bevonódjon egy termék fejlesztésébe. Ezen a ponton legtöbbször elég a Roadmap szintű riporting: a projekt egésze zöld vagy piros.

 Release

A Roadmap után jön a Release. A Release már részletes technológiai és üzleti logikai tervezést kell, hogy tartalmazzon. Egy Releaseben már sok mindent le kell tisztázni részletekbe menően. Milyen funkciókra lesz szükség, ezek miképp függenek egymástól, mikor tekintem késznek… Hogy csak párat említsünk. Ezek olyan kérdések, amikhez elengedhetetlen egy Product Owner és egy architect segítsége.

Figyelem! Ritka, hogy legyenek valódi Product Ownerek egy szervezetben! Főleg hozzáértők! Helyesen a Product Owner lesz az, aki a termék, az üzleti logika, és a domain tudás birtokában képes lesz folyamatosan döntéseket hozni arról, hogy a Roadmap és az onnan származtatott tervezési szinteken a prioritások és a termék részletei hogyan alakuljanak.

A Product Owner feladata azért is különösen nehéz, mert neki az összes tervezési szintet át- és be kell látnia. Az összes tervezési szinten működő stakeholdert kezelnie kell.

A Release tervezés már csapatközeli történet. A Product Owner a Roadmap, vagy afölötti szinteket tájékoztatja a Release várható tartalmáról, költségéről, erőforrás szükségleteiről. De a döntéseket itt már a Product Ownernek kell meghoznia, tájékoztatási kötelezettség mellett.

Iteráció (sprint, a scrum csapatban)

A Sprintek tervezése szintén megér egy külön blogbejegyzést, és fogunk is vele foglalkozni. Itt most csak annyit kell róla tudni, hogy a sprintek tervezése már a csapat bevonásával kell hogy történjen. Ez a minimum. 

A Product Ownernek maximálisan ott kell lennie, hisz a Sprint tervezés forrását jelentő backlogot az ő felelőssége feltölteni, és rendelkezésre kell állnia ahhoz, hogy a szállító csapat kérdéseire a tervezés során válaszolni tudjon. A Product Owner az, aki a termékoldalon döntéseket hozhat. Ugyanakkor a csapat dönt és tervezi meg a “hogyan készítjük el”-t.

A napi koordináció

A Napi Koordináció az a tervezési esemény, amikor a csapat tagjai, azok, akik egy adott terméken egy adott pillanatban egészen biztos, hogy szükséges, hogy együtt dolgozzanak, megbeszélik a következő 24 óra főbb lépéseit. Ki, mit, hogyan, miért fog csinálni, és ezt az érintett csapat tagoknak érteni is kell. Teszik ezt azért, hogy az tevékenységük koordinált legyen és ennek eredőjeként növeljék a napi szintű értékszállítást.

 Melyik szintre koncentráljunk

Természetesen mindegyik szintnek meg kell lennie. És mindegyik szinten folyamatosan javítani kell a működést ahhoz, hogy egyre jobb termékeink lehessenek egyre fentarthatóbb működés mellett.

A tervezési szintek között folyamatosan kell, hogy mozoghassanak az érintett emberek. A szinteket nem szabad silókba szervezni, és department jelleggel hermetikusan elválasztani. Az Agile tervezés öt szintje akkor és csak akkor működik, ha az agilemanifesto.org szellemében a tudás, az információ és az emberek szabadon mozoghatnak az üzleti- és projektcél érdekében.