Fejlesztési módszerek

Elvileg lehetséges különösebb módszertan nélkül is fejleszteni, viszont a tapasztalat azt mutatja, hogy egy adott módszer következetes alkalmazása hatékonyabb annál, mintha nem használnánk semmit. Sokféle fejlesztési modell létezik. Vannak általános modellek, és cég specifikus modellek is. Ezekből kettőt mutatok be, melyek filozófiájukban is jelentősen eltérnek.

Vízesés modell

Ez a modell egy régi modell, amit tipikusan nagy projektek esetén alkalmaznak. Az átfutási ideje éves nagyságrendben mérhető, és a szoftver újabb verziója a végén lesz kész. 5 fő fázist különböztetünk meg:

  • követelmények meghatározása,
  • rendszer- és szoftvertervezés,
  • implementáció és egységteszt,
  • integráció és rendszerteszt,
  • működtetés és karbantartás.

Ezek a fázisok alapvetően egymás után, valamelyest átlapolva követik egymást. Konkrét esetekben meghatározzák, hogy melyik dátumig melyik fázisnak milyen elkészültségi szinten kell lennie. Pl. lehet, hogy a rendszer- és szoftvertervezés fázis elkezdődhet akkor, ha a követelmények meghatározása elért egy bizonyos arányt, de az implementáció és egységteszt csak akkor kezdődhet, ha a követelmények meghatározása már 100%-os. Ha függőlegesen ábrázoljuk az elkészültséget, felül van a 0, alul a 100%, a fenti 5 fázist egymás mellé helyezzük, és az idő függvényében animáljuk, akkor az eredmény kb. úgy nézne ki, hogy először a legbaloldalibb kezdene lefelé haladni, utána a második bizonyos fáziskéséssel stb., és az egész egy vízesésre hasonlít.

Agilis fejlesztés

A vízesés modellnek - kétség kívüli előnyei ellenére - van egy óriási hátránya: a megrendelő túl későn lát belőle valamit. Egy-két év túl hosszú idő az informatikában, ennyi idő alatt sok minden történik, sok minden elavul, és ha mondjuk 200 fejlesztő 2 évnyi munkája után derül ki, hogy a megrendelő valójában nem is ezt akarta, akkor az óriási veszteség. Ezekre a problémákra jelentek meg az agilis fejlesztési módszerek, mindenekelőtt a Scrum, melyben (ideális esetben) a megrendelő is be van vonva a folyamatba, folyamatosan látja a fejlődést, a szoftver nagyon sok kicsi, használható iterációban épül fel. A fejlesztés a következőképpen történik:

  • A scrum csapat pár fős, és egy scrum master vezeti.
  • A módszer legfontosabb fogalma a sprint: ez az az időtartam, ami alatt elkészül a következő demózható változat. A spring hossza változó, tipikusan 2-4 hét.
  • A sprint tervezéssel kezdődik: ennek során meghatározzák a következő pár hétben megvalósítandó feladatokat. Ennek egy része az ún. esztimációs póker: minden feladatra, miután valaki ismertette, megpróbálják megbecsülni az összetettségét, mégpedig úgy, hogy minden csapattag titokban választ egy Fibonacci számot, és egyszerre felmutatják. A végén konszenzusra kell jutni.
  • Ideális esetben a becslés és a tervezés időben elkülönül. Ha a tervezés során becsül a csapat, akkor az azzal a veszéllyel jár, hogy ha már egyébként is túl van tervezve a sprint, akkor nyomás van a csapaton, hogy a ténylegesnél kisebb értékeket mondjanak. Ha elkülönül akkor ez a veszély nem fenyeget, ugyanis akkor még nincs kőbe vésve, hogy melyik sprintbe lesz betervezve.
  • A fejlesztés során napi megbeszélést tartanak a résztvevők (ha fizikailag együtt ülnek, akkor általában állva, emiatt hívják ezt daily standup meeting-nek), melyben mindenki elmondja, hogy mit csinált a legutóbbi megbeszélés óta, van-e valami, ami akadályozza, és mit tervez a következő napra. Ezeknek a megbeszélésnek a hossza kb. negyed óra.
  • A feladatok alapvetően a csapathoz vannak rendelve, és (ideális esetben) a csapattagok helyettesíteni tudják egymást. (A valóságban persze mindenkinek kialakul egy területe, és általában nem kérdés, hogy ki fog elvégezni egy adott feladatot, de addig mindenképpen eljutnak a csapattagok, hogy legalább nagy vonalakban értsék egymás feladatait.)
  • Ideális esetben a sprint tartalma nem változik, és a közben felmerülő feladatok az ún. backlog-ba kerülnek. Ez képezi a következő sprintek bemenetét. (A valóságban ezt nem lehet teljesen következetesen végigvinni, mert vannak tényleg halaszthatatlan feladatok, emiatt érdemes némi puffert hagyni a tervezésnél a nem várt feladatokra.)
  • A sprint review-val végződik: amikor átnézik, hogy mit hogyan teljesítettek. Ideális esetben lehet demózni az eredményt, és ugyancsak ideális esetben ezen a demón a megrendelő is részt vesz. Ez mindenkinek jó, mert a vevő látja a fejlődést, és azonnali visszajelzést tud adni, ami nyilván hasznos a csapatnak is. Ezzel a módszerrel elkerülhető az, hogy hónapok, évek elteltével derüljön ki, hogy nem azt kapja a vevő, amit várt.
  • A sprint a retrospective-vel zárul, melynek során a csapat visszatekint az elmúlt sprintre, mindenki elmondja, hogy mi volt benne a jó és hol lehetne még javítani, majd a javítandó pontokról szavaznak, és a legtöbb szavazatot kapott problémákhoz akciótervet készítenek.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License