Sokat beszélgettem mostanában tapasztalt, és általam tisztelt tanárokkal és vezetőkkel az agilis fejlesztési módszerekről. Ezek hatására egyértelműen az a kép alakult ki bennem, hogy az agilis "mozgalom" valahol félresiklott. A napokban tartottam egy előadást a JUM-on (http://jum.javaforum.hu) amit ezzel a jelenséggel indítottam. Arra gondoltam, hogy az előadás mondanivalóját a következő néhány bejegyzésben felelevenítem.
Az agilis kiáltvány félreértelmezve...
Az agilis kiáltvány indította útjára az agilis fejlesztési mozgalmat. Az üzenetei egyrészről egyértelműek és világosak: koncentráljunk azokra a tevékenységekre a fejlesztés során, amik a majdani rendszer felhasználói számára közvetlenül valódi értéket teremtenek és helyezzük ezeket a másodlagos, közvetett tevékenységek elé.
Ezek szerint fontosabb:
Az egyetlen probléma az agilis kiáltvánnyal, hogy a fázisolt termékfejlesztési módszertanokban (vízesés modell) nevelkedett vezetők és mérnökök egy részében azt az érzetet kelti, hogy az agilis fejlesztés egyfajta fejlesztői "munkásforradalom", akik előrébb helyezik a hobby szerű fejlesztést a professzionális, minőségorientált munkával szemben. Értelmezhetjük így is az agilis kiáltványt: nem igazán fontosak a módszertanok, nem akarjuk dokumentálással tölteni az időt, nem vállalunk felelősséget a tevékenységünkért ezért nem kötünk szerződést, sőt még a tervezést sem tartjuk fontosnak! Nyilván nem ez húzódik meg az irányzat mögött.Az agilis kiáltvány félreértelmezve...
Az agilis kiáltvány indította útjára az agilis fejlesztési mozgalmat. Az üzenetei egyrészről egyértelműek és világosak: koncentráljunk azokra a tevékenységekre a fejlesztés során, amik a majdani rendszer felhasználói számára közvetlenül valódi értéket teremtenek és helyezzük ezeket a másodlagos, közvetett tevékenységek elé.
Ezek szerint fontosabb:
- az egyén és a személyes kommunikáció, a módszertanoknál és az eszközöknél
- a működő szoftver, az átfogó dokumentációnál
- a megrendelővel való együttműködés, a szerződéshez való ragaszkodásnál
- a változásra való reagálás, a tervek rigorózus követésénél.
Tévhit: az agilis fejlesztés csak véget nem érő projektekben, dobozos termékek fejlesztése esetén alkalmazható
Ezt a hiedelmet még agilis fejlesztési módszertanokkal foglalkozó portálon is olvastam és jelentős projektmenedzsment fórumokon is elhangzik, mint következtetés. Ha az agilis kiáltvány félreértelmezéséből indulunk ki, akkor ez logikus következmény. Az is igaz, hogy főként azok a vállalatok alkalmazzák az agilis módszereket, akik dobozos termékeket fejlesztenek (pl. Google, Apple, Microsoft stb.) Másrészt viszont ha megvizsgáljuk ezeknek a módszereknek a gyökereit, akkor észrevehetjük, hogy a Scrum vagy a Toyota Product Development System olyan közegben alakult ki, ahol a szigorú véghatáridőre leszállított eredmény alapvető követelmény! Nehéz elképzelni a Toyotáról, hogy egy autókiállításra beharangozott típussal nem készül el határidőre... Igaz, hogy az agilis fejlesztési projektek más megközelítést igényelnek, mint a vízesés projektek, ugyanakkor a meghatározott időpontra, meghatározott célokat kielégítő, magas minőségű eredmény talán még sokkal nagyobb hangsúlyt is kap!
Tévhit: az agilis fejlesztői teamek felelősségmentes, laza közösségek
A féleértés másik hibás következtetése. Az agilis pl. Scrum teamek felelőssége lényegesen nagyobb, mint az erős projektmenedzser által irányított fejlesztési projekteken, ahol a felelősséget végsősoron egy személyben a projektvezető viseli. (Hasonló szerepet vállal a product owner a Scrum-ban, vagy a chief architekt a Toyotánál.) A különbség abban áll, hogy az agilis módszertanok belátják, hogy a szoftverfejlesztés nem más, mint ezernyi kisebb-nagyobb döntés együttese. Minden fejlesztő, minden órában döntéseket hoz, amiket nem lehet előre megtervezni, sem irányítani. A komplex rendszereknek (mint amilyen a szoftverfejlesztői team is) bizonyos fokú önállóságot kell biztosítani, a folyamatos vezetői kontrollt pedig egyértelmű, transzparens, a valós előrehaladást mindenki számára világosan megjelenítő visszajelző mechanizmusokkal kell helyettesíteni. A tervektől való eltérést pedig azonnal ki kell értékelni és a team tudását felhasználva, közösen kell kitalálni a lehetséges megoldásokat. Az agilis módszereknek ez a mechanizmusa könnyen keltheti azt az érzetet, hogy az irányítást a menedzsment kiadta a kezéből. Az eredeti agilis környezetekben az elkövetett hibákért a team tényleges felelősséget vállal, a folyamatosan rosszul teljesítő csapatokat pedig megszüntetik vagy átszervezik. A csapatoknak ennek tudatában kell teljesíteniük. A valóságban tehát a menedzsment a felelősséget nem megszünteti, hanem kiterjeszti azokra, akik valóban hatással vannak a projekt sikerére: a projekt teamre.
