A visszajelzések

A szoftverprojektek szállítása egy komplex feladat, komplex rendszerként viselkedik. Ennek a rendszernek rengeteg összetevője van: maga a rendszer, a fejlesztők, tesztelők, az üzleti környezet, a futtató hardver, az infrastruktúra, a folyamatos bizonytalanság, a kockázatok stb. Hogyan biztosítható az (vagy hogyan csökkenthetőek a kockázatok), hogy egy fejlesztés alatt lévő komplex rendszer olyan irányba fejlődjön, hogy végül azt alkalmazni lehessen?

Az agilis szoftverfejlesztésben alkalmazott mérnöki(?) gyakorlatok egyik célja az, hogy minél korábbi visszajelzéseket kapjunk a munkánkról. Az agilis módszertanok egyszerűen “üdvözlik” a folyamat során bekövetkező hibákat, kudarcokat, mert fel vannak készülve arra, hogy ezek egy projektnek természetes velejárójuk.

Először egy korai előfeltevésből indulunk, utána pedig fel kell ismernünk, hogy hol hibáztunk. Egyszerűen tanulunk és javítunk.

Mik azok a módszerek, és hogyan járulnak hozzá ahhoz, hogy a komplex szoftvert végül kifejleszthessük, és az sikeres legyen? Ebben a cikkben megkísérlek áttekintést adni az általam megismert technikákról. Az egyes technikáknak az alkalmazása több előnnyel is szolgálhat, most csak a visszacsatolások szemszögéből jellemzem őket.

Prioritás alapú fejlesztés

Amikor egy szoftver elkészítése a fejlesztési szakaszába ér, folyamatos probléma az, hogy milyen funkciók kifejlesztése mentén haladjunk a cél felé. Sok esetben projekt ütemtervet készítenek. Mi is számtalanszor próbálkoztunk ezzel, de a következő problémákkal szembesültünk:

  • Lehetetlen előre jól megbecsülni a feladatokra fordítandó időt, ez hatványozottan jelentkezik az időben egyre távolabb lévő taszkokra.
  • Lehetetlen előre lebontani a projektet taszkokra, ennek több oka is van: az elején nem látjuk a lefejlesztendő rendszer képességeit, tudását, nem ismerjük az üzleti problémát, a követelmények(?) pedig állandóak változnak.
  • A projektterv figyelembe veszi az erőforrásokat is, mivel sem a feladatokra szánt időt nem tudjuk megbecsülni, sem a feladatokat magukat nem tudjuk megfogalmazni, az erőforrások figyelembevételével történő projekttervezés extrém bonyolítságúvá teszi az amúgy is bizonytalan projekttervet.
  • Az így felállított ütemterv általában pár hét alatt szétesik, és már képtelenség követni, annak megfelelni.

A Scrum szerint a lefejlesztendő funkciókat üzleti szempontból kell megfogalmazni, ezeket üzleti szempontból is kell priorizálni, és mindig a legnagyobb prioritású (azaz legfontosabb) sztorikkal haladni. A kérdés mindig az: ha az üzleti felhasználó szemével tekintjük a hátralévő funkciókat, akkor ezek közül melyik az, amelyik a legnagyobb hasznot hozza? Ha ezt kiválasztottuk, jöhet a következő sztori. Miért jó ez?

  • A megrendelőnek már igen korán visszacsatolási lehetősége nyílik, és az alapján korrigálhatunk.
  • A legfontosabb funkciók meghatározzák a szoftver alapvető működését, a felhasználói felületeket, a domain model-t, ezáltal a fejlesztő is a lehető legkorábban megtanulhatja az üzleti tudást, és megismerheti a fejlesztés alatt lévő rendszerének a lehetőségeit, képességeit. Tehát a fejlesztő számára a prioritás alapú fejlesztés a tanulásban jelent hatékony visszacsatolást.

Egyszer megrendelői oldalon ültem, és három szállítóval is tárgyaltunk. Mindegyik felvázolta a rendszerrel kapcsolatos elképzeléseit, a fejlesztési módszertanát. Az egyik szállító cég így kezdte: “először megcsináljuk az adminisztrációs felületeket”. Tipikus hiba. Az adminisztrációs felületek az ügyfélnek (legalábbis az üzleti megrendelőnek) kevés hozzáadott értéket képviselnek, ez csak egy “szükséges rossz” a programban. Ha elkészül az admin felület, semmit nem tudunk levonni a szoftver tényleges működésével kapcsolatban, a hozzáadott üzleti értékéről, nincs lehetőség a minél korábbi visszacsatolásra. (Ráadásul – megítélésem szerint – egy jó admin felületet csak akkor lehet megcsinálni, ha már a szoftverben “a dolgok a helyükre kerültek”, és tudjuk, hogy mit kell pontosan adminisztrálni.)

Pair programming

A páros programozás az XP módszertan részre. A lényege, hogy ketten ülnek a gép előtt, az egyik gépel, a másik figyeli. Az előnye, hogy a gépelő azonnali visszajelzést kap az őt figyelőtől. Ha valamit elront, azt azonnal lehet javítani. Ha egy junior fejlesztő ül a gépnél, és egy senior nézi, a junior fejlesztő a kapott visszacsatolások alapján gyorsabban is fejlődik.

Code review

A code review célja, hogy a fejlesztői csapat által készített kódokat a fejlesztői csapat közösen áttekinti, ellenőrzi. (Ezt sokféleképpen lehet megtenni, pl. mielőtt/miután update-elünk, megnézzük, hogy milyen változások történtek a szoftverben, vagy a vezető fejlesztő nézi át minden nap a commit-okat, vagy ha patch-et adunk ki egy élesben lévő rendszerhez, akkor mindig valaki más is megnézi, hogy milyen változások történtek a programban, és ezek okozhatnak-e újabb hibákat.)

A code review-k segítenek a hibák idő előtti megtalálásában, és az új kódbázisnak a csapattudásba történő hatékonyabb integrálásában.

Folyamatos integráció

Ha a kódunkhoz automatizált teszteseteket írunk, és ezen automatizált teszteseteket egy Continuous Integration (CI) szerveren minden commit után automatikusan lefuttatjuk, azonnali visszajelzést kapunk arról, hogy a kódbázisban történt változtatások nem okoznak-e hibákat a kód egyéb részeiben.

Ez hatalmas segítséget nyújt a hibák mihamarabbi megtalálásában. Ha új funkciót fejlesztünk vagy egy hibát javítunk, biztosíthatjuk, hogy nem (vagy minimális) hiba került a rendszerbe. Ha egy csapat ezzel a módszerrel dolgozik, véleményem szerint soha nem akarja ezt már kihagyni.

On-site customer

Ha a szoftverfejlesztői csapat részévé válik az üzleti szakértő, akkor ő nagyban hozzájárulhat ahhoz, hogy a fejlesztendő szoftver sikeres legyen. Az ügyfél folyamatosan velünk dolgozik, megismerjük a gondolkozását, az üzleti terület nyelvezetét, működését.

Mielőtt neki állunk egy új funkciót fejleszteni, van kitől kérdezni: hogy működjön, hogy fogják használni, milyen legyen a felhasználói felület? Az éppen a kezünk közül kiesett felhasználói felületeket, programrészek működését, azonnal ellenőriztethetjük az on-site customerrel.

Sztori alapú fejlesztés

A fejlesztendő funkciókat célszerű üzleti oldalról megközelítve megfogalmazni. Amikor egy sztorit fejlesztünk, írjunk hozzá egy forgatókönyvet konkrét példával, amin keresztül bemutatható az adott sztori (how-to-demo forgatókönyv). A forgatókönyv elkészítését mi a fejlesztőre bízzuk azért, hogy kikényszerítsük tőle az üzleti probléma megértését. Ha a forgatókönyvet meg tudja írni, tudja, hogy mit kell megcsinálnia. Általában az a jellemző, hogy nem tudja magától megírni (és ez nagyon jó!), ezért segítséget kell kérnie az üzleti szakértőtől, esetleg a csapattal közösen találják ki a részleteket.

A sztori alapú fejlesztés azonnal kikényszeríti a tanulást, a problémák azonnali felvetésével. Ha nem írunk ilyen forgatókönyvet, annak az eredménye az, hogy a fejlesztő elkezdi valahogy csinálni az adott funkciót, időnként kérdez (vagy nem), és az eredmény sokszor egy nem jól megvalósított funkció. (Nem előnyös felhasználói felület, üzletileg nem jól működő program.)

Daily stand-ups

A napi 10-15p-esre tervezett stand-up-ok lényege, hogy a teljes csapat egyénenként beszámoljon arról, hogy mit csinált előző nap, mit tervez az adott napra. Ha valami akadály merül fel, egyből orvosolható. A probléma nem csupán a szoftverrel kapcsolatos lehet, lehet külső tényező is. Pl. kapcsolódhat a szoftverfejlesztő cég belső szervezeti problémáihoz (pl. az embert ide-oda ráncigálják projektek között). A napi stand-up-ok alapján felfedhetők a résztvevők motivációs problémái is. (Ennek megoldása nem a stand-up-ok feladata.)

Iteratív fejlesztés

Az iteratív fejlesztés célja, hogy tanuljunk belőle, miközben csináljuk. Az iterációk után az ügyfélnek tartott demók, a demók utáni csapatmegbeszélések (retrospectives) mind azt a célt szolgálják, hogy a szoftverfejlesztésben résztvevők kinyilváníthassák véleményüket, felfedjék a (lehetséges) problémákat. Ezen problémák felismerése, a rájuk történő ellenlépések kidolgozása annak a folyamatnak a részei, amelyben a projekt – mint egy komplex rendszer – megtanulja önmagát kezelni.

Inkrementális fejlesztés

Az inkrementális fejlesztés célja, hogy az egyre növekvő rendszert szándékosan kitegyük a valós környezeti hatásoknak. A valós környezet (felhasználók, üzleti környezet, hardver, infrastruktúra) egy olyan tényleges visszajelzést juttat a projektbe, amely a tanulást és az adaptációt ténylegesen kikényszeríti. Ha rövidebbre vesszük a release-ciklusokat, az inkrementális fejlesztésből adódó visszajelzésekre még időben tudunk reagálni. (Nem 1 év múlva derül ki, hogy alapjaiban rossz a rendszer.) Az agilis módszertanok sürgetik a release-eket.

Share
This entry was posted in Módszertan and tagged , , , , , , , , , , , , . Bookmark the permalink. Follow any comments here with the RSS feed for this post. Post a comment or leave a trackback: Trackback URL.

Comments

  • [...] és hogy hogyan reagáljunk rájuk. A fejlesztési folyamat több pontján is alkalmazzunk hatékony visszacsatolási pontokat, amik lehetővé teszik, hogy a hibákat minél hamarabb észrevegyük, reagálhassunk rájuk, és [...]

Leave a Comment