Az élet minden területén az egyik leginkább vágyott dolog a kiszámíthatóság. Ezt keressük, amikor a vonat menetrendjére nézünk, és csalódunk ha késés van. Ezt várjuk a párkapcsolatunktól, a munkahelyünkön és a boltban is amikor kenyeret szeretnénk venni. Számítunk valamire, és örülünk, ha minden úgy volt ahogy gondoltuk és csalódunk, ha nem úgy lett, ahogy elképzeltük.
Ugyanez a helyzet a szoftverfejlesztéssel is. A megrendelő várja az alkalmazást, ami majd segít a munkájában, a fejlesztő pedig a megismert igények mentén igyekszik mindent kielégíteni, hogy az ügyfél boldog legyen. Ez lehetne is egy gyönyörű együttműködés, de sajnos a legtöbbször mégsem az. A 90-es években a klasszikus vízesés jellegű fejlesztések mellett is már felmerült a probléma, hogy a világ gyorsabban változik, mint ahogy a szoftverek készülnek. A megrendelő csalódott volt, mert mire megkapta a kész megoldást, addigra már megváltoztak a követelmények és bizonyos funkciók már nem bírtak jelentőséggel, de fizetni meg kellett, mert ugye a szerződés kötött. Aztán jött a következő fejlesztési iteráció, majd az azt követő és így tovább. A fejlesztők egy rögzített scope alapján dolgoztak, amit az ügyfelek szerettek volna felülírni, de viszonylag kicsi volt a mozgástér.
„Régi szép idők”, mondhatnánk, de helyzet koránt sem ennyire fekete vagy fehér. Az internet megjelenésével a 2000-es évek elejétől az életünk is még jobban felgyorsult. Mindenki elérhető mindenhol, a jogszabályok, az együttműködések a feje tetejére állnak egyik napról a másikra. Egyre kevésbé kiszámíthatók a dolgok hosszabb távon és ebben a környezetben még inkább igény van új szoftveres megoldásokra mint régen. A megrendelők szempontjából teljes mértékben érthető, hogy egyfelől nem akarják magukat nagyon szigorú keretek közé szorítani, másfelől pedig a megrendelt szoftvert szeretnék minél gyorsabban megkapni. Igazából csak három dolgot szeretnének. Jó minőséget, olcsón és gyorsan. Mint mindannyiunk.
Felismerve a vízesés jellegű vagy a hosszú iterációkkal és fix terjedelemmel dolgozó módszertanok merevségét, a szoftver ipar is egy gyorsan változtatható fejlesztési irányt vett fel. Ezek lettek a ma agilis módszertanoknak hívott megoldások. Ilyen a Scrum, az XP vagy éppen a Kanban, hogy csak a legismertebbeket említsem. Az első kettőben az is közös, hogy iterációkba vagy úgynevezett sprintekbe szervezik a munkát. Ez azt jelenti, hogy a legfontosabb fejlesztési feladatok komplexitását megbecsüli a csapat és a fejlesztési iteráció kezdetekor annyi elemet vállal be, amennyit nagy biztonsággal le is fog tudni szállítani. Fontos kifejezés itt a vállalás, ugyanis a csapat az érintettek és különösképpen a megrendelő felé tesz egy ígéretet, hogy amit az iterációba felvesz azért mindent megtesz, hogy le is szállítsa. Ez kiszámítható a fejlesztő csapatnak is, mivel tudják előre, hogy a következő 1-2 hétben min fognak dolgozni és mit kell elérni. Jó a megrendelőnek is, hiszen pontosan tudja, hogy mire számítson és mit fog kapni 1-2 hét múlva.
A probléma akkor merül fel, amikor megjelenik az ügyfél vagy a product owner vagy a product manager és elhangzik a bűvös mondat: „Csak ezt még húzzuk be a sprintbe!” Oda a kiszámíthatóságnak. Persze lehetnek nyomós érvek, mint pl jogszabályi változások, amiket gyorsan le kell követni vagy olyan üzleti változások, amikhez a lehető legrövidebb időn belül alkalmazkodni kell. A fejlesztő csapat nem csak hogy kapott egy új témát, de annyi az ígéretnek is, hiszen így már nagy valószínűséggel nem jut majd idő minden fejlesztésre. Újra kell hát tervezni az iterációt, ami időt visz el, ezért már nem csak azzal kell számolni, hogy amennyi plusz munkát kap a csapat, annyit engedjen is el, hanem ennek még van rengeteg egyéb időbeli vonzata is. Az új feladatot ugyanúgy meg kell tervezni, más feladatokat ki kell szedni az iterációból, le kell egyeztetni az érintettekkel, hogy a változtatás mindenkinek elfogadható és csak utána mehet tovább a fejlesztés. Jól látszik, hogy akár egy kis feladat is borzasztó sok egyeztetéssel és tervezéssel járhat, ezért nem praktikus gyakran változtatni, mert roppant költséges is.
Oda tehát a kiszámíthatóság, de fontos változtatás volt, mondhatnánk. Aztán ez megismétlődik a következő iterációban is. Erre már mérgelődnek a fejlesztők, hogy folyamatosan felborítják a terveket, így nem igazán lehet dolgozni. Kezd a fejlesztés és az üzleti érintettek közti bizalom is meginogni. Aztán a harmadik alkalommal is megjelenik az iteráció közben egy új igény. Itt már gyanakodhatunk, hogy valami hibás a folyamatokban. Az ugyanis szinte lehetetlen, hogy az igények megjelenése és a szükséges fejlesztés között ennyire rövid idő telhet csak el. Legnagyobb valószínűséggel az üzleti érintettek aki a változtatást kérik nincsenek teljesen tisztában azzal, hogy ezzel a fejlesztés alapszabályait feszegetik és rombolják a bizalmat saját maguk és a fejlesztés között, a kiszámíthatóság pedig elvész a változtatásokban. A legfontosabb feladat, hogy az üzleti érintettek lássák, hogy pontosan milyen problémák származnak az ad-hoc jellegű fejlesztési kérésekkel és egy egészséges egyensúly alakuljon ki az üzleti területek és a fejlesztés között, amelyben megvan mind a bizalom, mind pedig a vágyott kiszámíthatóság.
Összességében kijelenthető, hogy az agilis működés nem elégséges, ha csak a fejlesztői szervezetre alkalmazott. Ha a többi szervezeti egység nincsen tisztában azzal, hogy a fejlesztők hogyan dolgoznak, akkor folyamatos konfliktus forrás alakul ki az üzleti érintettek és a fejlesztő csapatok között. Az üzleti területnek, de még a management-nek is az lehet a benyomása, hogy a fejlesztés túl lassú, holott az sem biztos, hogy értik annak működését vagy bármikor egyeztettek volna, hogy hogyan lehet együtt dolgozni.
Ezekben a problémás helyzetekben jön jól egy Scrum Master vagy egy Agile Coach segítsége, akik nem csak azt hivatottak elősegíteni, hogy a fejlesztők hatékonyan és minél jobb minőségben szállítsanak, hanem fontos megteremteniük az összhangot az üzleti megrendelők és a fejlesztő csapatok között is. Ez sok módon történhet, de a kiindulási alapot legtöbbször a backlog jelentheti. A backlog mutatja meg mind a fejlesztőknek, mind pedig az üzleti területnek, hogy milyen prioritások szerint és várhatóan milyen ütemben tud haladni a munka. Ha ezzel minden érintett tisztában van, akkor azt is érteni fogják, hogy egy esetleges új kérés milyen módon befolyásolja a terveket. Azt is fontos az üzleti érintetteknek látni, hogy egy ad-hoc kérés általában nem tisztázott a legapróbb részletekig, mert általában sem az üzleti elemzők, sem pedig product owner nem kap elég időt erre. A munkát viszont nem lehet megúszni, ebben az esetben a fejlesztők fogják közösen elvégezni a refinement-et sajnos nem biztos, hogy csak technikai szinten, ami jelentősen meg is növelheti a feladat megoldásának az idejét, mivel az nincsen megfelelően előkészítve. Így lesz egy egészen apró feladatból egy viszonylag sok időt felemésztő probléma.
A hasonló helyzetek elkerülése érdekben rendszeresen egyeztetni kell a backlog mentén az üzleti területtel és azt is fontos tisztázni, hogy ugyanaz a kérés azonnal „megoldva” a sok bizonytalanság miatt a végén jóval többe is kerülhet annál, mintha megfelelően elő lenne készítve a fejlesztés. Ha ez az információ átmegy és az üzleti oldal is figyelemmel kíséri legalább magas szinten a fejlesztési prioritásokat, akkor sokkal többször elkerülhetők az ad-hoc feladatok és a rendszeres prioritás változtatások.
