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.
![Szoftverfejlesztési módszerek - 2]()
Előnyök:
![Szoftverfejlesztési módszerek - 3]()
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:
![Szoftverfejlesztési módszerek - 4]()
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
- 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ó.
- 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.
- 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ó
- 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
- 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
- Instabil feladatlista
- Hosszú távú projektekre nehéz alkalmazni
- Kemény határidők hiánya
GO TO FULL VERSION