055.1 Lecke 1

Egy projekt irányítása rendkívül összetett feladat. Egyes helyzetek elsőre könnyűnek tűnnek, de a helyes megoldásukhoz gondosságra és tapasztalatra van szükség. Az ezt végző személy a projektmenedzser (project manager).

A projektmenedzser felelősségi körébe tartozik annak biztosítása, hogy a projektet időben, a költségvetésen belül és elfogadható minőségben fejezzék be. Még ha nem is írnak egyetlen sor kódot sem, a projektmenedzserek azok, akik felelősek és elszámoltathatók a csapat eredményeiért. A határidőkkel kapcsolatban egyeztetniük kell az ügyfelekkel. Emellett beszélnek a más szerepkörökben dolgozókkal is, hogy megbizonyosodjanak arról, hogy minden rendben van.

Nincs helye a mikromenedzsmentnek — legalábbis egy egészséges munkahelyen nincs. A business analyst-ok (üzleti elemző — BA) és requirement engineer-ek (követelménymérnök — RE), a projektcsapat belső vagy külső munkatársai, a projektmenedzserek jobb kezei. Ők felelősek a követelményekről szóló gazdag és egyértelmű dokumentáció létrehozásáért. Ők képezik a hidat az ügyfelek és a fejlesztők között. Az ügyfelek közérthető nyelven kommunikálnak, amelyet a BA/RE világos és egyértelmű dokumentációvá alakít, ezzel biztosítva, hogy a fejlesztők hatékonyan végezhessék munkájukat.

Képzeljük el, hogy megkérnek, hogy vigyünk egy “nagy tortát” egy partira. Mit jelent az, hogy “nagy”? Tíz szelet vagy húsz? Talán egy nagy esküvő tortájáról van szó, és száz szeletesnek kellene lennie. A BA/RE-nek pontosan meg kell határoznia az olyan követelményeket, mint például a mennyiségek, hogy a fejlesztők tudják, hogy egy alkalmazást egy bizonyos számú felhasználóra terveztek.

Még csak a követelmények meghatározásának elején járunk, de már most láthatjuk, milyen fontos a világos kommunikáció. Minden közös munkához elengedhetetlen, de egy nyílt forráskódú projekt esetében talán még fontosabb, mivel a projekt egyes részein nagyon eltérő háttérrel rendelkező emberek dolgozhatnak. Lehet, hogy valaki diákként, valaki más szülőként, nyugdíjasként vagy két munkahely között lévő személyként stb. dolgozik. Még így is zökkenőmentesnek kell lennie a haladásnak ebben a környezetben — tehát a kommunikáció nem hátráltathatja a haladást.

A követelmények megvalósításához egy szoftverprojektnek fejlesztőkre (developer) van szüksége, akik a dokumentáció és a tervezési döntések alapján hozzák létre a terméket. Munkájukat az architect bírálja el, aki általában a projektben részt vevők közül a legszélesebb körű technikai és szakterületi ismeretekkel rendelkezik. Minden fejlesztő, különösen a vezető fejlesztők, felelősek a saját kódjukért, de a nagy döntéseket az architekt hozza meg vagy hagyja jóvá.

Néha az embereket kifejezetten tesztelőknek nevezik ki, akik felelősek mindenféle tesztelésért, az eredmények dokumentálásáért és hibajegyek létrehozásáért.

Ebben a kezdeti fázisban összegyűjtik és dokumentálják a projekt összes követelményét. Ez a munka kiterjedt megbeszéléseket foglal magában a projektmenedzser és az érdekelt felek között, hogy megértsék igényeiket és elvárásaikat. Az eredmény egy átfogó követelményspecifikációs dokumentum, amely felvázolja, hogy a rendszernek mit kell tennie.

Az üzleti elemzők üzleti szempontból vizsgálják meg a követelményeket, hogy azok összhangban legyenek a szervezeti célokkal. A BA-k megvalósíthatósági tanulmányokat, kockázatértékeléseket és költség-haszon elemzéseket végeznek annak megállapítására, hogy a projekt életképes-e és érdemes-e megvalósítani. Az így nyert ismereteket a projekt hatókörének és célkitűzéseinek finomítására használják fel.

A szoftvertervezés az a lépés, amikor az architect részletes tervezési specifikációt készít, amelyet a fejlesztők követhetnek. E specifikáció birtokában a csapat elkezdheti a követelmények megvalósítását — más szóval a fejlesztési fázis megkezdését, amely ezután következik.

A fejlesztési fázis az, ahol a varázslat történik — ahol a kódot írják. A dokumentációt és a tervezési döntéseket szorgalmasan követve a fejlesztők megírják a részüket. Miután a fejlesztők a többi fejlesztővel vagy az architecttel átnézik és ellenőrzik a kódot, ez a fázis befejezettnek tekinthető.

A fejlesztést egy tesztelési szakasz követi, amelyet a tesztelők irányítanak. A tesztelésnek különböző típusai vannak, amelyeket egy másik leckében ismertetünk, mint például az egységtesztelés (unit testing), az integrációs tesztelés (integration testing), a rendszertesztelés (system testing) és az átvételi tesztelés (acceptance testing).

Ezeknek a teszteknek az a célja, hogy még a kiadás előtt felszínre hozzák a problémákat, és lehetővé tegyék a fejlesztők számára, hogy időben kijavítsák azokat — nem pedig azután, hogy a projektet már telepítették és publikálták, és a felhasználókat a hibák irritálják és frusztrálják.

A tesztek lebonyolítása és a hibák kijavítása után a projekt kiadható –- azaz üzembe helyezhető az éles környezetben. Ez a fázis tartalmazhat telepítést, konfigurálást és néha még a felhasználói oktatást is. Miután a projekt használatra kész, karbantartási fázisban van, ahol a csapat kezelheti a felhasználók problémáit, és szükség esetén frissítéseket is biztosíthat.

Mit vettünk észre, miközben erről a modellről olvastunk? Hatékonynak találjuk? Hiányzik valami? Lássuk az előnyöket és hátrányokat!

A vízesésmodell előnyei:

A vízesésmodell hátrányai:

A Scrum az egyik legnépszerűbb keretrendszer — talán a legnépszerűbb — az agilis szoftverfejlesztésen belül. A Scrum a következő építőelemekre épül:

De ki a scrum master és a product owner? Mi az a product backlog és a sprint? Merüljünk el a szerepekben és folyamatokban!

A Kanban egy másik népszerű agilis keretrendszer, amely a munka vizualizálására, a munkafolyamatok irányítására és a folyamatok javítására helyezi a hangsúlyt. Az egyik nagy különbség a Scrum és a Kanban között az, hogy a Kanban nem igényel fix hosszúságú iterációkat, így rugalmasabbá teszi a folyamatos szállítást, és képes egyensúlyt teremteni a különböző munkaprioritások között.

A következő alfejezetekben megvizsgáljuk, hogy mire van szüksége a csapatoknak egy Kanban projekt megvalósításához.

Bár a DevOps erősen ajánlott a modern szoftverprojektek számos típusa esetén, az előnyöket és hátrányokat figyelembe kell venni.

A DevOps modell előnyei:

A DevOps modell hátrányai: