Az Agile tervezés lényege az, hogy öt, jól definiált stratégiai szinten folyamatosan dolgozunk a termék alakításán.
Az Agilitás 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. Már csak ezt kell legyártani”.
Az Agile termékfejlesztés végső célja az üzleti érték folyamatos maximalizálása.
Ezt 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, értékesebb fejleszthető feladat, validálandó ötletünk, elképzelésünk.
Ha ez utóbbiak bámelyiké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 szintig többnyire érdemes is befejezni..
Az öt szint
- Product Vision: termékvízió
- Product Roadmap: az az út, ami mentén a termék létrejön, a főbb mérföldkövek kapcsolata
- Release: ami egy nagyobb üzleti logikai egységet jelent, néhány sprint fejlesztési idővel
- Iteration: Iteráció, ami scrum csapatokban szigorúbb sprinteket jelent
- Daily Planning: a napi szintű koordináció és tervezés, 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.
Ahhoz, hogy egy felső vezető döntéseket tudjon hozni a projektről, többnyire nincs szüksége arra, hogy bármely időpillanatban tisztában legyen azzal, hogy éppen milyen funkciókat, milyen megoldásokat fejlesztünk.
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. Többek között ennek feloldásában segít az Agile tervezés öt szintje.
Nitro Agile Planning
A Nitro Agile Planning során mi is az 5 szintű agilis tervezés eszközeit alkalmazzuk, melynek során az első 3 szintet tervezzük meg termékével kapcsolatban, valamint előkészítjük a az első egy vagy két sprint user story-jait, hogy ha megvan a kiválasztott fejlesztőcég, azonnal el tudja kezdeni a szoftverfejlesztést.
Érdekli szolgáltatásunk? Kattintson a képre, és tudjon meg többet!
1. 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.
2. 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. Waterfall esetében compliance és kockázatkerülés (áthárítás) tud lenni a siker mércéje, amiben nincs akkora potenciál, mint az Agile megközelítésében.
A Roadmap még kényelmes lehetőséget ad a vezetői beavatkozásra. A Roadmap alatti szintek azonban már ritka, hogy egy felső vezetői aktív érdeklődésre számot tartsanak. 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 zöld vagy piros.
3. 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észleteibe 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, amiket 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! Ha van is, a szervezet teszi félig lehetetlenné, hogy Product Ownerségében kiteljesedhessen.
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 hogyan nézzenek ki.
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 a 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.
4. 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. Ha ezt nem kapja meg a csapat, akkor valójában fényévekre vagyunk az agile-tól. Igazában már a Roadmap környékén jó, ha teret kap a csapat.
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”-t.
5. 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 pontjait. Ki, mit, hogyan, miért fog csinálni, és ezt az érintett csapat tagok értik is. 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.
Az agilis módszertani átállás során a szervezetek egységnyi időre vetített termelő képessége átlagosan 150-300%-kal nőtt. A HVG Akadémia, Agile Recruiter sorozatának módszertani vezetője.