Délibábok-helyett
Kinek ne jönne elő rémálmaiban egy elégedetlen ügyfél, egy félrecsúszott fejlesztés, egy kommunikációs hiba okozta határidő-csúszás? Az Agilis Kiáltvány aláírói másfél évtizede lefektették egy új szoftverfejlesztési megközelítés alapjait. A módszer tapasztalataink szerint is remekül működik.
Képzeljünk el egy nagy, komplex projektet. Másfél évig dolgozik a fejlesztő csapat, szóról szóra követik a szerződésben foglaltakat. Határidőre le is szállítják a szoftvert, és meggyőződésük: mindenben az ügyfél kívánságai szerint jártak el.
Csakhogy a várt ováció elmarad. Nem arat sikert a regisztrációs felület. QR kódot kell használni azonosításra, holott a megbízó – bár ezt nem nevesítette a szerződésben – vonalkódra gondolt. Meg sem fordult az ügyfél részéről aláírók fejében, hogy más megoldás is létezhet. A projekt elkészült a megcélzott határidőre, de mindkét fél csalódott. A rengeteg energia nem a várt eredményt hozta. Ismerős a sztori? A szoftverfejlesztés világában dolgozó szakemberek nagy része átélt már effélét. Sokan tudják is, mi áll a háttérben.
A visszatérő problémát ugyanis a Vízesés modell (Waterfall) alkalmazása jelenti.
A tradicionális módszertanok közül máig legjelentősebb megközelítést az amerikai Winston W. Royce írta le egy tanulmányában. A végcél hosszas egyeztetése után induló projekt, pontos határidővel és büdzsével; állandó tagokból álló teamek; a fejlesztés ideje alatt minimális interakció az ügyfél és IT team között – röviden és sommásan ez jellemzi a Vízesés modellt.
És noha Royce már a hetvenes években felhívta a figyelmet a metódus hiányosságaira, nem hittek neki. A hosszas előkészítés és a méretes dokumentáció azt a csalfa érzést keltette, hogy mindent nagyon jól előkészítettünk, mindent tudunk és ismerünk, pontosan látjuk az előttünk álló feladatokat. Bár valójában csak egy délibábban gyönyörködtünk.
Vannak persze olyan iparágak, ahol nem nagyon van mód más logika és projektmenedzsment módszer alapján dolgozni. Tipikusan ilyen az állami cégek és közbeszerzések világa vagy a banki szektor. Itt nincs mese: „pontosan” meg kell mondani, hogy a fejlesztők mit, mikorra szállítanak, és persze mennyiért. A hierarchikus szervezetek és a pályáztatás logikája miatt szorosra van kötve minden érintett keze – és ez nemcsak a hazai viszonyok közt igaz.
Az üzleti életben, a saját termék fejlesztésben, a „laposabb”, decentralizáltabb szervezetekben azonban rendkívül kevés feladat olyan, ami indokolja a Vízesés modell alkalmazását, ha létezik másik lehetőség is.
Márpedig létezik.
1986-ban két japán szervezeti kutatással foglalkozó szakember a modell hátrányait kiküszöbölendő javaslatot tettek néhány újításra: önszerveződő, rugalmas csapatok felállítását szorgalmazták, és a folyamatos tanulás fontosságát hangsúlyozták a szervezeteken belül.
A ’90-es évek második felére aztán ezeket a javaslatokat több szoftverfejlesztési úttörő már a gyakorlatban is sikeresen használta, mint Kent Beck az Extreme Programming megálmodója. Sőt: Jeff Sutherland és Ken Schwaber arra vállalkoztak, hogy az addigra már megjelent gyakorlati elemeket rendszerbe foglalják – amiből megszületett a Scrum. Rugalmasan kell válaszolni az ügyféligényekre! – vallották. Ennek nyomán született meg 2001-ben 17 szoftverfejlesztési guru egyetértésével az Agilis Kiáltvány (Agile Manifesto).
A legritkább esetben fordul elő, hogy egy ilyen akció mögött nem történelmi-politikai okok, hanem üzleti, szakmai indíttatás rejlik.
Az Agile Manifesto e szempontból is kivétel.
Legfontosabb ajánlásai a megrendelővel történő szoros együttműködésre, hatékony kommunikációra és a változás iránti nyitottságra vonatkoznak. Az agilis módszertan szoftverfejlesztési problémákból nőtt ki, ezért kulcseleme a rugalmasság: a fejlesztés egymásra épülő fázisokra osztva zajlik, minden etapot az ügyféllel történő egyeztetés előz meg, követ és sző át. Az alapokat itt is részletes átbeszélés során fektetik le, ám menet közben – az 1-3 hetes fázisok során – van mód a változtatásra, módosításra, finomhangolásra. Nem ritka, hogy maga az ügyfél kéri eredeti koncepciója megváltoztatását. Fontos elem még a fejlesztési fázisok végi retrospektív, azaz a folyamat áttekintése annak fényében, mit lehetne legközelebb másként, jobban csinálni.
Volt cég, amely korán felismerte az agilitás erejét, mások az elmúlt években fokozatosan térnek, tértek át a modellre.
Vannak persze, akik számára máig idegen ez a megközelítés.Az averzió mögött pedig jellemzően két ok húzódik meg. Egyfelől a tény, hogy nem lehet a projektekhez kőbe vésett végső határidőt és kapcsolódó forrásigényt sem rendelni, sokak számára nehezen kezelhető. Másrészről pedig visszatartó erő lehet a felismerés: a folyamatos egyeztetések a megrendelő cég erőforrásaira is igényt tartanak. Azaz az ügyfélnek időről időre foglalkoznia kell az éppen futó informatikai projekttel, jóvá kell hagynia, vagy éppen meg kell változtatnia annak menetét. Ez figyelmet, energiát kíván. Ráadásul nemcsak a fejlesztésnek, de az abban részt vevő szervezeteknek is agilisaknak kell lenniük, amely lényege: rugalmas vállalat, gyors döntéshozatal, hatékony kommunikáció. Ez megint csak nem mindenütt adottság.
Ezzel szemben áll a mérleg másik serpenyője.
Ebben hajszálpontos végeredmény szerepel: olyan informatikai megoldás, amelyet a megbízó megálmodott. A hibalehetőségek minimálisak, az ügyfél pontosan azt kapja, amit várt. Nincs fölöslegesen kidobott pénz. Ha valahol, itt száz százalékig megáll a „Jó munkához idő kell” igazsága.
Összességében úgy vélem, azok a szervezetek, amelyek már „megégették magukat”, azaz ahol megérett a helyzet a változtatásra – előállt a „sense of urgency” – nagy eséllyel soha többé nem szeretnének visszatérni a Vízesés korszakába. Nem véletlen, hogy tőlünk nyugatabbra az agilis módszertan elterjedtsége sokszorosa az itthoninak.
Jóllehet az átállás sosem fájdalommentes, tapasztalatom szerint a befektetett munka minden esetben meghozza a gyümölcsét.
És a megérdemelt ovációt is.
