Szoftverfejlesztési módszertanok

Sok interjún valószínűleg megkérdezik a módszertanokról. Nem ez a legfontosabb vagy legnehezebb kérdés, de jó lenne egy csalólap. Ebben a cikkben megpróbáljuk átadni, mi is az a fejlesztési módszertan, és összehasonlítani azokat. A szoftverfejlesztési módszertan egy adott termék fejlesztésére használt folyamat, azaz egy fejlesztői csapat általi fejlesztés megszervezésének egyik módja. Számos különböző fejlesztési modell létezik, amelyek mindegyike meghatározza a saját megközelítését. Nem mondható el, hogy bármelyik projekthez felhasználható lenne. A helyes megközelítés teljes mértékben a helyzettől függ. Ezek közül hármat kívánok részletesebben megvizsgálni.

Vízesés

A vízesés módszertana az egyik legrégebbi, és szigorúan szekvenciális megvalósítást foglal magában: minden szakaszt be kell fejezni a következő megkezdése előtt. Más szavakkal, a következő szakaszba való áttérés azt jelenti, hogy az előző szakasz munkája 100%-ban befejeződött. A képen látható, hogyan működik: először elemezzük a problémát (feladatok dokumentálása, kihívások megbeszélése), majd tervezünk (ebben a szakaszban formálódik a projekt szerkezete), majd kódoljuk és teszteljük. A korábbi szakaszokhoz való visszatérés nem megengedett. Ez a megközelítés olyan kis projekteknél javasolt, ahol a követelmények előre ismertek, és nem valószínű, hogy változni fognak. Előnyök:

• Teljes és következetes dokumentáció minden szakaszban
• Egyszerű használat
• Stabil követelmények
• A költségvetések és a határidők előre meghatározottak

Hátrányok:

• Nagy mennyiségű dokumentáció
• Nem túl rugalmas
• Az ügyfél nem láthatja a termék demóverzióját
• Nincs lehetőség hátralépni

Dulakodás

A Scrum egy szoftverfejlesztési módszertan, amely a teljes folyamatot iterációkra osztja. Minden interakció végén a csapat készen áll a termék demóverziójának bemutatására. A képen látható, hogy a csapat párhuzamosan halad végig a fejlesztés minden szakaszán, ami lehetővé teszi, hogy minden iteráció végén elkészüljön a projekt egy része. Megpróbálom röviden elmagyarázni a módszertan lényegét egyszerű szavakkal, de sok a terminológia. Szerintem a legfontosabb, hogy megértsük a lényeget. Tapasztalattal fog emlékezni a terminológiára. Minden fejlesztés sprintekre oszlik (gyakran 2-3 hét). Lemaradás van(feladatlista) a teljes fejlesztési időszakra és minden egyes sprintre. Minden feladatnak megvan a maga történetpontja (nehézségi fok). A folyamatban minden résztvevőnek szerepe van:

• A scrum csapat a projekten dolgozó szakemberekből (fejlesztők, tesztelők, tervezők) áll.
• A scrum mester az a személy, aki gondoskodik a scrum elveinek tiszteletben tartásáról.
• A termék tulajdonosa a vásárló.

Ez a módszertan a kommunikáción alapul, ezért nagyszámú megbeszélésről van szó:

• Stand-up – Ez egy minden nap megtartott rövid találkozó, amelyen minden csapattag részt vesz. Minden résztvevő 3 kérdésre válaszol: Mit csináltam? Mit fogok csinálni? És milyen blokkolási problémák vannak?
• Tervezési értekezlet – Ezt a találkozót a sprint elején tartják. Ezen a megbeszélésen azonosítják azokat a feladatokat, amelyeket a következő sprintben el kell végezni.
• Retrospektív – Ez a találkozó a sprint végén kerül megrendezésre, és célja annak meghatározása, hogy mi sikerült jól, és min lehetne javítani.

Előnyök:

• Az ügyfél a fejlesztési folyamat során láthatja az eredményeket
• A fejlesztési folyamat napi nyomon követése
• Kiigazítási képesség fejlesztés közben
• Kiépült a kommunikáció a csapat minden tagjával
• Kis mennyiségű dokumentáció

Hátrányok:

• Nehéz felmérni a fejlesztéshez szükséges munkaerő- és egyéb költségeket
• A fejlesztés megkezdése előtt nehéz azonosítani a szűk keresztmetszeteket
• Mindenkit be kell vonni a többi csapattag munkájába.

Kanban

A Kanban egy olyan módszer, amely a csapat feladatainak végrehajtásában elért előrehaladás vizualizálásán alapul. A fő ötlet a jelenleg végrehajtott feladatok számának csökkentése (a "Folyamatban" oszlopban). A scrumban a csapat a sprintek sikeres teljesítésére összpontosít. A Kanbanban a feladat foglalja el a kiemelkedő helyet. Ez jó a karbantartási szakaszban lévő projekteknél, ahol az alapvető funkciókat már megvalósították, és minimális fejlesztések és hibajavítások maradtak. A Kanbanban a feladatok egyenként vannak kiosztva. Egy feladat a többi feladattól függetlenül végigmegy a táblán az összes szakaszon, és miután elkészült, meg lehet mutatni az ügyfélnek. A Kanban tábla oszlopokból áll, amelyek mindegyike külön fejlesztési folyamatot jelent. Egyes oszlopok (például "Folyamatban" ) korlátozza a betölthető feladatok számát. Ez segít gyorsan és egyszerűen megtalálni a problémás területeket a feladatok elosztásában. A képen egy példa látható egy ilyen táblára. Az oszlopok száma és elnevezésük változhat. Bemutatom a leggyakoribbakat:

• To Do – Az elvégzendő feladatok listája
• Folyamatban – Jelenleg folyamatban lévő feladatok
• Kód felülvizsgálata – Elvégzett és felülvizsgálatra benyújtott feladatok
• Tesztelés alatt – Tesztelésre kész feladatok
• Kész – Elkészült feladatok

Előnyök:

• Egyszerű használat
• Láthatóság (segíti a szűk keresztmetszetek megtalálását, egyszerűsíti a megértést)
• Magas szintű csapat részvétel a folyamatban
• Rendkívül rugalmas fejlesztés

Hátrányok:

• Instabil feladatlista
• Hosszú távú projektekre nehéz alkalmazni
• Kemény határidők hiánya

Egy utolsó szó a szoftverfejlesztési módszerekről

Azoknak, akik vezetői pozíciót töltenek be vagy arra vágynak, alaposan ismerniük kell a szoftverfejlesztési módszereket, de mindenkinek meg kell értenie legalább az alapokat. A módszertanok a fejlesztési folyamat szerves részét képezik, és nem csak az IT-szférában alkalmazzák. Köszönöm, hogy időt szánt cikkem elolvasására. Remélem hasznos volt számodra. Igyekeztem csak a legfontosabb pontokat a lehető legközérthetőbben és tömörebben leírni. Ennek eredményeként ez a cikk nem teljes körű. Örülnék, ha meghallgatnám a véleményét ezzel kapcsolatban, és válaszolnék kérdéseire. Minden jót!