Agile

Kezembe került ez a felhívás. Lesz októberben egy konferencia az Agile módszertanról. Nekem személy szerint az egyik nagy kedvencem. Lényegében a módszertan arról szól, hogy:

• rövid időközönként adjunk át használható funkciókat az ügyfélnek
• az iteráció és a változtatás lehetősége legyen a projekt egész folyamatába beépítve
• az ügyféllel való szoros együttműködés/együttgondolkodás

"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more."
Agile Manifesto via Wikipedia

Bármennyire szeretem is ezt a módszertant megvannak maga korlátai és lehetőségei....

Dolgoztam egy cégnél nemrégiben, ahol az elsődleges feladatom a teljes fejlesztési process átgondolása, racionalizásása, illetve kiépítése volt. A csapat akkoriban a következő elvek szerint működött:

• nem definiált és dokumentált projectek voltak
• a fejlesztők a saját belátásuk szerint csináltak dolgokat, nem volt egy senior fejlesztő aki aként is viselkedett volna
• mivel baráti alapon jöttek a megrendelések, a scope hajlamos volt gyökeresen emgváltozni a fejlesztési folyamat akár legvégén is
• pont a baráti alap miatt a határidők -finoman fogalmazva- nem voltak betartva, sőt figyelembe se lettek véve
• nem volt egységes kódhasználat/open source software hasnzálat - mindig mindenki egyedül feltalálta a spanyol viaszt

Ráadásul a csapat főképp fiatalokból, még egyetemista, vagy épp kikerült programozókból állt, akik élén nem volt egy tapasztalt, öreg róka.

Ez tipikusan az a szituáció, amikor bármennyire is jó az agile módszertan, vagy a six sigma, mégsem szabad belevágni egy ilyesfajta project processbe.
Egy ilyen helyzetben az emberanyag az első kiindulási szempont. Amikor nincs öreg róka, akkor marad a dokumentáció. Meg kell találni azt a minimum és maximum szintet amit a szervezet elbír. Ha nincs semmi, akkor a minimális is borzasztó erőfeszítésekkel fog csak összejönni, nyilván....
Tehát első körben a projektról alkotott képet kellett komolyan kialakítani. Azt, hogy a projektnek van célja, határideje....

Lépjünk tovább, ez a példa csak szemléltetésnek van.Bár sajnos a mai napig sok közepes/kis fejlesztőscég dolgozik hasonló elvek alapján. És legtöbbször mind arra hivatkozik, hogy azért ilyen, mert "rugalmas", az "ügyfél akarata az első" ésatöbbi.

Visszatérve az agile módszertanhoz... Mikor jó használni?

• Amikor nem mission critical a szoftver amin dolgozunk 
• amikor tapasztalt, öreg rókákkal vagyunk körülvéve, akik önállóan tudnak gondolkodni és dolgozni
• amikro az ügyfél hajlandó a szoros együttműködésre - pl. biztosít helyet a fejlesztőknek a saját telephelyén és ad összekötő embert
• nagyon fontos: itt is kell dokumentáció. A mennyiségét és formáját a feleknek kell a projekt elején meghatározni, de olyan nincs, hogy abszolút semmit nem írunk le 
• a változtatásokat követni kell - version tracking kiemelten fontos!
• olyan környezet és emberek kellenek akik képesek egy kevéssé kontrollált környezetben hatékonyan működni

Ezek a peremfeltételek. És ez még csak a kezdet :)
Tapasztalatom alapján azonban Mo-n nagyon kevés fejlesztőcsapat és ügyfél alkalmas ezen módszertan szerint dolgozni. Mindenki másnak nem tudom elégszer hangoztatni, hogy dokumentációóóóó! :)

 ... to be continued .... :)

ja, és hogy jön ide a felhívás? Nagyon szívesen tartnék előadást arról, hogy az agile módszertanba hogyan fér bele az ergonómia, illetve hallgatnám meg kollegák beszámolóját, hogy ezt őnáluk hogyan valósították meg.