Agilis projektmódszertan: bullshit vagy csodafegyver?

2012. március 03. - Kriminalhauptmeister Harry

Imádom ezt a képet. Tudjátok mit ábrázol? Egy vágyálmot. Egy utolsó, sosem volt szalmaszálat. Egy olyan valóságot, ami sosem létezett, csak a kétségbeesés és elkeseredett remény által táplált fantáziák világában. Bármiben tudunk hinni, ha elég sok forog kockán és eléggé nagy a baj, ez pedig nem csak a projektekre, hanem a háborúra is igaz volt.

Németország 1944-ben tudta, hogy újra el fog veszíteni egy világháborút. Ezzel azonban szembenézni, ezt elfogadni egyenlő volt a teljes megsemmisüléssel, annak a lázálomnak a szertefoszlásával, amiért egy generáció élt, harcolt és meghalt: eljött hát a pont a náci Németországban is, amikor a való világot tömegek hagyták maguk mögött, és fejben átléptek a csodák világába, hiszen már csak abban bízhattak.

Az angolok, amerikaiak, szovjetek már a kapuknál dübörögtek és nem segíthetett semmi, csak a Csodafegyver, a Wunderwaffe. A Csodafegyver egy mágikus eszköz, ami varázserejénél fogva legyőzhetetlenné teszi használóját, és átsegíti minden nehézségen, segítségével legyőzhető bármilyen ellenség. A valóságtól addigra elszakadt német vezetés utolsó ötletként ilyen csodafegyverek legendáival tartotta a lelket a katonáiban: elhitették velük, hogy már csak néhány nap, és bevetik azt a fegyvert, ami egy csapásra megváltoztatja a háború menetét, és elsöpri az ellenséget. Amint tudjuk, ez persze sosem történt meg: a sors fintoraként a háború menetét leginkább megváltoztatni tudó csodafegyvert (az atombombát) az egyébként is győztes amerikaiak fejlesztették ki, majd vetették be nem éppen humánus módon.

Az informatika tele van állítólagos csodafegyverekkel. Évről évre felbukkan egy új eszköz, technológia, módszertan, amitől azt várjuk: végre futószalagon, garantált sikerességgel végezhetjük a projektjeinket! Ilyen volt az objektum orientált programozás, a SOA, a Model Driver Architecture, most jön a Test Driven Development, a korábban istenített vízesés modell és azok oldalhajtásai (pl. SSADM) és persze az agilis módszertanok. (Kismillió cikk van ezekről az internetet, ha nem tudod, mi az agilis módszertan, itt kezdhetsz olvasni róla.) Aztán ha próbáltad ezeket alkalmazni, és enyhén szólva nem arattál osztatlan sikert a projekteddel, akkor hamarosan előkerült egy tanácsadó, aki megmagyarázta, hogy nem a módszerrel van a baj, hanem veled, mert rosszul használtad! A vízesés modell egyik alaptézise, hogy részletes tervezés során pontosan meg kell tervezni a megvalósítandó rendszert: jahhh kérem, ha később folyton új igények merülnek fel, akkor nem lesz sikeres ám a projekt! De kérdem én: a módszernek kell alkalmazkodnia a valósághoz, vagy a valóságot próbáljuk a módszertanhoz görbíteni?

Nem csoda hát, ha sokan megcsömörlöttek az újabb és újabb világmegváltó termékektől és azok kudarcától, és már hányniuk kell, amikor valamelyik szállító megjelenik az újabb világmegváltó technológiájával vagy módszertanával, és tudja a tutit. Amit persze már két éve is tudott. Meg négy éve is. Csak akkor valami más volt a tuti. De EZ, a MOSTANI, ez aztán már tényleg az, ez tényleg a Kánaán maga. Nyilván mindannyiunkban bekapcsol ilyenkor a bullshit alarm.

 Az igazság persze valahol a kettő között van. Én most fejezek be egy majd' másfél éves, több százmilliós banki agilis projektet, és garantálom neked: ez sem csodafegyver. Az informatika hatalmas fejlődésen ment keresztül az elmúlt két évtizedben, de ez a fejlődés folyamatos, kis lépésekkel történik: ennek egy nagyon fontos állomása az agilis módszertanok megjelenése. Agilisan dolgozni számomra azt jelenti, hogy természetesnek veszel néhány alaptézist, amit a korábbi módszertanok nem kezeltek, vagy csak nagyon hézagosan:

  • Legfontosabb, hogy eredmény orientáltan működünk: a működő, üzleti eredményt mielőbb termelő szoftver elkészítése, és nem annak körbedokumentálása, koncepcionálása képvisel számunka értéket
  • Nem hiszünk többé abban, és nem várjuk el, hogy a megrendelő pontosan megmondja a fejlesztés kezdete előtt, hogy milyen rendszert akar. 1500 oldalas tökéletes logikai rendszerterv: ilyen csak a mesében van, ott, ahol a terülj-terülj asztalkám, meg a mindentvágó lézerkard.
  • Természetesnek vesszük a változást és a változtatást, és a projekt alapjaként kezeljük, szabályozott részévé tesszük azt.
  • Elhisszük, hogy kellően motivált és szakképzett projekttagok folyamatos baszogatás nélkül (már elnézést, de direkt nem írok "menedzsmentet") is önállóan megoldják a feladataik legnagyobb részét: a megfelelő embereket nem irányítani kell, hanem célt kijelölni és biztosítani a feltételeket ahhoz, hogy értéket termeljenek.

Mindezeket persze agilitás meg SCRUM meg mindenféle köret nélkül is lehet biztosítani, a módszertan csak eszközöket kínál a célok eléréséhez. Igaz lesz itt is, hogy projektvezetőként saját magadnak kell megtalálnod az adott helyzetre értelmesen alkalmazható felállást: közelről láttam monstre telkos agilis projektet is, teljesen máshol vannak a problémás pontjai, mint egy bankinak.

Sokan kóstolgatják manapság az agilis módszertanokat, és állnak a döntés előtt: váltsanak, vagy maradjanak a régi (és be NEM vált) módszereknél? Ne így közelítsétek meg a kérdést! Először fontos megérteni, mit üzen az agilis hozzáállás, aztán gondold végig: mi az, amit reálisan tudsz ebből használni, minek van valódi haszna a helyzetedben, mi az, amit át tudsz nyomni a szervezeten, amiben dolgozol. Esélytelen abban reménykedni például, hogy egy banki beszerzési osztály megértő lesz azzal az elvvel kapcsolatban, hogy az agilis projekt kezdetén nem tudjuk pontosan megmondani, mi is lesz a végtermék.

Nem is kell az elején agilisnek nevezned, egyszerűen csak finomíts az eddigi működésen! Emelj át elemeket: bármilyen, klasszikus fix áras projektben bevezetheted például, hogy feldarabolod a fejlesztést iterációkra, és néhány hetente demot tartatsz a fejlesztőkkel! Vagy próbáld meg a napi SCRUM meetingeket, minden reggel tíz perc igazán nem fáj senkinek. A közös projekthelyiség ugyancsak könnyen és fájdalommentesen átvehető módszer lehet.

Ha leteszitek a voksot az agilis módszerre váltás mellett, akkor is haladj lépésenként, ne akarj mindent egyszerre ráerőltetni a csapatodra. Magyarázd el nekik, mi fog történni, tarts elméleti gyorstalpalót! Alakítsátok ki közösen a működési modellt, folyamatosan vizsgáld felül a folyamatokat, finomítsátok iterációról iterációra, hogyan működjetek! Nekem a négy- majd kéthetes iterációk váltak be, a kéthetes ciklusok csak akkor tudtak működni, amikor olajozottá vált a gépezet. A betanulási időszak 6-8 iteráció volt, azaz több, mint fél év! Ne féljetek belátni, ha valami nem megy: keressetek tovább, kísérletezzetek! És végül a legfontosabb: projektvezetőként ne hagyd, hogy elveszítsék az emberek a lelkesedésüket az új működési modellel kapcsolatban, de azért mondd el nekik a Wunderwaffe történetét is! :)

A bejegyzés trackback címe:

https://derrickesharry.blog.hu/api/trackback/id/tr164286779

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

MeMyselfAndI 2013.04.12. 09:49:13

igy, igy :D el kene olvastatni minden szupermenedzserrel, projektvezetovel!

Kriminalhauptmeister Harry 2013.04.12. 11:48:40

@MeMyselfAndI: kötelező tananyag lesz, amit beindul a Derrick és Harry féle projektakadémia :)

Valaki2 2017.09.03. 23:06:54

Azt hiszem most fel is iratkoztam a blogodra :)