Daraboljunk, avagy mi fán terem az inkrementális fejlesztés?

A témakör fontosságát mi sem bizonyítja jobban, mint hogy az agilis szoftverfejlesztés alapelveinek a fele ezt a működést próbálja megfogalmazni:

• „Legfontosabbnak azt tartjuk, hogy az ügyfél elégedettségét a működő szoftver mielőbbi és folyamatos szállításával vívjuk ki.”
• „Elfogadjuk, hogy a követelmények változhatnak akár a fejlesztés vége felé is. Az agilis eljárások a változásból versenyelőnyt kovácsolnak az ügyfél számára.”
• „Szállíts működő szoftvert gyakran, azaz néhány hetenként vagy havonként, lehetőség szerint a gyakoribb szállítást választva.”
• „A működő szoftver az elsődleges mércéje az előrehaladásnak.”
• „Az agilis eljárások a fenntartható fejlesztést pártolják. Fontos, hogy a szponzorok, a fejlesztők és a felhasználók folytonosan képesek legyenek tartani egy állandó ütemet.”
• „Elengedhetetlen az egyszerűség, azaz az elvégezetlen munkamennyiség maximalizálásának művészete.”

De nézzük meg részletesebben, hogy miről is van szó pontosan.

Inkrementális fejlesztés az agilis modellben

„Ami cselekvés: – mind erő
ami erő – az mind feszültség
ami feszültség – súrlódás
ami súrlódás – szenvedés”

Pontosan ugyanezt a szerepet tölti be az agilis szoftverfejlesztésben az inkrementális fejlesztés. Egy adott funkcionalitást fejlesztünk, gazdagítunk sprintről-sprintre, ciklusról-ciklusra, egészen addig, amíg el nem érjük azt a szintet, ahol a további fejlesztések idő- és energiaráfordításai már nem állnak arányban a végfelhasználó számára teremtett értékkel.

Az inkrementális szoftverfejlesztés alapvető feltételei

Ehhez az alábbi feltételeknek kell teljesülniük:

• A felhasználóknak el kell fogadniuk, hogy az általuk támasztott igények több lépcsőben kerülnek majd megvalósításra és minden egyes részfunkcionalitás mellé üzleti értéket kell definiálniuk. Olyan konkrét értéket, amely pontosan visszamérhető.
• A menedzsmentnek (Product Owner) pontosan meg kell határoznia, hogy az egyes részfunkcionalitások megvalósítása milyen prioritási sorrendben történjen, figyelembe véve azok logikai összefüggéseit és üzleti értékeit. Ezeket a prioritásokat pedig minden sprint tervezésekor újra és újra felül kell vizsgálnia.
• A csapatnak pedig meg kell tanulnia feldarabolni egy-egy üzleti igényt olyan értelmezhető és értéket teremtő egységekre, amelyek minél sűrűbb ciklusonként szállíthatók.

Miben különbözik a klasszikus és az inkrementális szoftverfejlesztési megközelítés?

A hagyományos szoftverfejlesztési megközelítés szerint elkészül egy minden részletre kiterjedő üzleti igény, amely meghatározza a harminc adatelem típusát, a rögzítésükre szolgáló beviteli mezők fajtáját, az egyes adatelemek rögzítési sorrendjét, egymáshoz való viszonyát, ezen adatok későbbi felhasználási módját és így tovább.

Ezt követően megtörténik a feladat felmérése, részletes tervezése, ütemezése, majd jó esetben egy-két hónap múlva megkezdődik a tényleges szoftverfejlesztés. Menet közben felmerülnek módosítási igények, esetleg a szoftvertesztelés során derül fény koncepcionális problémákra, amelyekre megoldást kell találni, így, ha minden jól megy, 4-6 hónap múlva a felhasználók megkapják a kért képernyőt. Ami ugyan korántsem olyan, mint amilyet szerettek volna, de legalább minden kért funkció benne van, még akkor is, ha azok közül egy-kettő már okafogyottá vált, vagy kiderült róluk, hogy valójában csak a végfelhasználók egy nagyon szűk csoportja számára volt fontos. Feladat letudva, jöhet a következő, az adatrögzítő képernyő pedig a következő 10-15 évre úgy marad, mert ugyan nem túl felhasználóbarát, felesleges funkciókkal terheli a rendszert és lassítja a folyamatot, de végül is működik és együtt lehet vele élni.

Ha azonban ugyanezt a feladatot egy érett agilis squad-nak kell megvalósítania, akkor az az alábbi inkrementumokban is megvalósításra kerülhet.

1. sprint: Folyamatba illesztett adatrögzítési képernyő 30 adatbeviteli mezővel és egy mentés gombbal, amely a manuálisan rögzített adatokat lementi egy adatbázisba.
2. sprint: Adatbeviteli mezők struktúrába rendezése a képernyőn, hogy az egyes adatok rögzítése logikus sorrendben történjen. Az egyes adatbeviteli mezők értékvalidációja az adatbázisba történő mentés előtt.
3. sprint: Adatbeviteli mezők típusainak kialakítása, előre definiált értékkészletes mezők létrehozása, automatikus kitöltési lehetőségek kialakítása. Adatbeviteli mezőkbe rögzített értékek egymáshoz viszonyított értékellenőrzése az adatbázisba történő mentés előtt.
4. sprint: Adatdúsítás kialakítása, a korábban már rögzített, vagy a más adatbázisokban már megtalálható adatok beolvasása a képernyőre. Rögzített adatok négy szem elv alapján történő ellenőrzésének kialakítása.
5. sprint: Korábban kiadott funkciók módosítása, finomhangolása a felhasználói visszajelzések alapján.
6. sprint: Rögzített adatok elhelyezése formanyomtatványra, ami menthető, nyomtatható és emailhez csatolható.
7. sprint: Adatstatisztikai funkciók kialakítása, keresés meghatározott adatértékekre és kombinációkra, találati lista megjelenítése és fájlba történő exportálása.
8. sprint: Vezetői riporting kialakítása, adatrögzítési mennyiség, adatrögzítőnként, csoportonként, meghatározott időszakra.
9. sprint: Korábban kiadott funkciók módosítása, finomhangolása felhasználói visszajelzések alapján.

Az eredmény pedig egy olyan felület, amelynek minden funkcionalitása valós felhasználói igényeken alapul, és amelyek mindegyike valós értékkel bír a szervezet számára. Az adatok rögzítése már a második sprinttől lehetségessé vált. Az inkrementumok folyamatos szállításával pedig a felhasználókban kialakul a megbecsülés érzése, míg a szállítói csapat a folyamatos visszajelzések hatására sikerélményekkel gazdagodik. Az újabb és újabb inkrementumok fejlesztése előtt folyamatosan alakítható az üzleti igény és sprintről sprintre módosítható a következő sprintekben megvalósítandó funkcióhalmaz prioritása. Mindig bekerülhetnek új inkrementumok, vagy akár el is lehet vetni korábban definiált, de még meg nem valósítottakat. Ez pedig nem más, mint az elvégzetlen munkamennyiség maximalizálásának művészete, hiszen arra kell törekedni, hogy csak a valóban értéket jelentő feladatokkal foglalkozzunk.

Minimum Viable Pruduct, avagy az MVP jelentése

Az MVP, azaz a minimálisan életképes vagy elfogadható termék tapasztalatom szerint az egyik leginkább félreértelmezett fogalom az agilitás kapcsán. A legtöbb esetben a könnyebb érthetőség kedvéért általában valami hasonló ábrával szokták érzékeltetni, hogy miben tér el az MVP megközelítés a hagyományostól.

forrás: storiesonboard.com

Tehát önmagukban értéket nem jelentő részegységek helyett szállítsunk sprintről-sprintre mindig valamilyen önállóan életképes egységet.

Ezt a gondolatmenetet tökéletesen bemutatja a fenti ábra, azonban véleményem szerint van vele egy óriási probléma, mégpedig az, hogy valójában a fenti sor sem tekinthető MVP-nek! Mégpedig két okból sem:

1. Az MVP kialakítása során soha nem hagyhatjuk figyelmen kívül a valódi üzleti igényt! Ha ugyanis az a user story, hogy egy termelő vállalatnak (kinek), járműre van szüksége (mit), hogy a megtermelt árut eljuttassa a gyárból a nagykereskedőhöz (milyen célból), akkor viszonylag könnyen belátható, hogy ha MVP gyanánt biztosítunk számára egy gördeszkát, egy rollert vagy egy kerékpárt, akkor azzal nem igazán fog tudni mit kezdeni. Ez ugyanis olyan lenne, mintha a korábbi inkrementális fejlesztést szemléltető példánkban az első sprint eredményeként szállítanánk egy adatbeviteli képernyőt mondjuk mentés nélkül, vagy lenne ugyan mentés gomb, de az adatbázisban a harminc adatpont helyett csak tíznek lenne kialakítva a helye.
2. Az MVP-ként kialakított terméknek mindig figyelembe kell vennie a végső célt! Azaz az MVP-nek minden esetben egy olyan alapnak kell lennie, amelyre a további sprintekben építkezni lehet. Ha az MVP termék kidobásra kerül, mert az csak egy átmeneti (quick and dirty) megoldásként funkcionált, akkor tulajdonképpen kidobtuk az ablakon azt az időt és energiát is, amelyet a megvalósítására fordítottunk. A fenti illusztrációban tehát egy gördeszkára hiába szerelünk motort vagy plusz kerekeket, az valójában soha nem lesz nyerges vontató.

De hogy tiszta vizet öntsünk a pohárba, az eredeti definíció szerint az MVP nem más, mint egy új termék azon változata, amely lehetővé teszi a fejlesztési csapat számára, hogy a lehető legkevesebb erőfeszítéssel a lehető legtöbb tudást gyűjtse össze az ügyfelek igényeiről, annak érdekében, hogy a termékfejlesztés során a lehető legmagasabb értékkel bíró terméket alakíthassa ki.

Tehát valójában egy ellenőrzött tanulási folyamat alapja, és mint ilyen kapcsolódik az inkrementális szoftverfejlesztéshez. Tehát az MVP valójában a termékfejlesztés szempontjából az alap, az egyes inkrementumok pedig azok a lépcsőfokok, amelyeken keresztül elérhető maga a végcél.

Sajnos azonban igen gyakori további hiba, hogy az eredetileg MVP-nek szánt megoldás marad maga a végtermék. Ez pedig általában arra vezethető vissza, hogy az MVP további inkrementumokkal történő bővítéséhez hiányoznak a megfelelő és visszamérhető üzleti értékek. Valamint arra a hibás menedzsment attitűdre, amely szerint az egységnyi idő alatt megvalósított fejlesztések száma még mindig fontosabb, mint a tényleges felhasználói élmény.

Definition of Done

A DoD az, amelyben az MVP, majd azt követően az egyes inkrementumok elfogadási kritériumai megfogalmazásra kerülhetnek. Ez az a definíció, amely megteremti az átláthatóságot és a közös megértést a csapaton belül, vagy az egyes agilis csapatok között, ha közösen dolgoznak ugyanannak a terméknek a megvalósításán.

Egy megfelelően működő agilis szoftverfejlesztő csapat esetében tehát egy adott inkrementumhoz kapcsolódó DoD jellemzően azokból a visszajelzésekből táplálkozik, amelyek az adott termék MVP-jére érkeztek.

Összefoglalás

A termékfejlesztési folyamatban a Minimum Viable Product biztosítja a csapat számára a megfelelő információszerzést, annak érdekében, hogy a végtermék kialakítása valós felhasználói visszajelzések alapján történhessen.

Ha szeretne többet megtudni az agilis projektmenedzsmentről, kövesse a MINDSPIRE közösségi média profiljait!

Amennyiben támogatásra van szüksége az agilis projektmenedzsment kialakításában és működtetésében, forduljon hozzánk bizalommal!

Munkatársaink többéves tapasztalattal rendelkeznek az agilis működés terén banki és biztosítói környezetekben. Az elmúlt években sikeresen vettek részt hagyományos projektszervezetek agilis transzformációjában, valamint agilis projektek leszállításában.