Miért nem a “waterfall model”

Krisztián Augusztini
Junior Product Manager at Onbox
2019. július 21.
Megosztás

A vízesés modell többszintes elképzelése a következőkből áll: rendszerkövetelmények majd szoftverkövetelmények tisztázása, ami után következik az elemzés majd a programtervezés és csak azután a kódolás. Ezt követi egy tesztelési fázis, mielőtt piacra bocsátanák a rendszert.

waterfall modell

"A fázisok eredménye tulajdonképpen egy dokumentum. A modell fontos szabálya, hogy a következő fázis addig nem indulhat el, amíg az előző fázis be nem fejeződött. A gyakorlatban persze ezek a szakaszok kissé átfedhetik egymást. Maga a szoftverfolyamat nem egyszerű lineáris modell, hanem a fejlesztési tevékenységek iterációjának sorozata. Ez a vízesésmodellnél a visszacsatolásokban jelenik meg.” - írja dr. Mileff Péter a Szoftverfejlesztés című tankönyvében. Az idézetben említett dokumentum tulajdonképpen egy részletes specifikáció. Ez az elejétől meghatározza a végterméket és a fejlesztést, ami mentén haladni kell a projekt folyamán.

A vízesés modell hátrányai

A vízesés modellnek vannak azonban problémái, annak ellenére, hogy sok cégnél bevált az előző 40 évben. Ám az elméletet Winston W. Royce űrhajó-projektben eltöltött 9 évéből alakította ki. Tehát viszonylag nagy szoftverfejlesztésről beszélünk, ahol a pontos előre tervezés elengedhetetlen.
De nem minden szoftverfejlesztés ilyen mértékű és nem minden vállalat környezete ilyen stabil.

Egy űrhajó építésénél a követelmények évek kutatásai alapján alakulnak ki, és várható az egy-két év múlva fennálló állapot is, így könnyebb tartani a tervet.

A mai világban viszont a változás a mindennapok része. Ezekhez a folyamatosan változó felhasználói igényekhez a vállalatoknak és a szoftverfejlesztésnek is igazodniuk kell. A változó igényeket és ennek kiszolgálását célzó törekvéseket mi sem érzékelteti jobban, mint a Skyscanner 2018 áprilisában tartott előadásán elhangzó kijelentés, miszerint naponta tízezer deploy-t / release-t szeretnének a weboldalukra.
Egy vállalat versenyképességének fenntartásához a meglévő igényeket kell kiegészíteni, az igazi versenyelőnyt viszont az okozza, ha a vállalat a célközönségének rejtett igényeire is rátapint. Emiatt a folyamatos innováció elengedhetetlen a szoftverfejlesztésben.

cost of change

De nézzük csak meg a vízesés modelljét! Mire eljut a kódolásig, a folyamat már túl van jó esetben egy prototípus elkészítésén és két felhasználói igényfelmérésen. Tekintsünk el most attól a ténytől, hogy a felhasználó rejtett igényekkel rendelkezhet, és nem biztos, hogy tudja, mit akar. A projekt a harmadánál jár, és még nem történt kód írás, de a specifikáció már nagyon kidolgozott, és részletes.
Látjuk tehát, hogy már az elején eldől, mivel fog hosszabb távon foglalkozni a csapat, és ebben egy új igénynek nincsen helye. Tudásom szerint egyelőre nincs olyan folyamatmodell, amely a váratlan problémákat elkerülné, ezért a váratlan problémák rugalmas és olcsó kezelésében rejlik a megoldás.

A vízesés modell nem eredményes, ha a követelmények nem jól definiáltak, vagy nem értelmezhetőek egyértelműen.
Az elemzést megelőző igényfelmérési időszakon és a végén az elemzésben megfogalmazott dokumentáción múlik minden. Ha a követelmény félreérthető és ha az igényt rosszul fogalmazzák meg, minden olyan döntés, ami ezeken alapszik valószínűleg a projektet rossz irányba viszi, így minden kód ami azokból a döntésekből indult ki, megkérdőjelezhető. Ráadásul a tesztelés hiába eredményes, és mutatja a termék rendeltetésszerű működését, hogyha a rossz feltételeknek megfelelően van elkészítve.
Azt is tudjuk, hogy hibák mindig jönnek elő. A vízesés modellben a hibák a szoftverfejlesztési életciklusban nagyon későn jelennek meg, mivel a tesztelők nincsenek bevonva a kezdetektől, hanem csak a tesztelési fázisnál.
Az SDLC (Softwer decelo) minél későbbi szakaszában jön elő egy hiba, a javítása annál nagyobb költséget jelent S. Ambler eltelt idő - hiba javításának költsége mátrixa alapján.

Tehát a folyamatos felülvizsgálás és a változásokhoz való igazodás nagyon fontos az IT iparban, ami nem erőssége ennek a modellnek.

Megosztás

Krisztián Augusztini
Junior Product Manager at Onbox
2019. július 21.

Apró szokások

Pár saját gondolatot szeretnék kiemelni tömören, hogy mi milyen szokásokat vezettünk be saját magunknak. Egyáltalán, miért kellenek szokások a szervezeten belülre?

Krisztián Augusztini
Junior Product Manager at Onbox
2019. július 21.

Hogyan jelezzük a haladást az egész csapat számára?

Az előző cikkemben a quick winek, vagyis gyors győzelmek jelentőségét fejtettem ki.

Krisztián Augusztini
Junior Product Manager at Onbox
2019. július 16.

Miért éri meg a ,,quick winek” mentén haladni?

Észrevettük az Onbox 2017 októberi indulása után, hogy a specifikációinkban sok volt az alaptalan funkció, amikről igazából nem is tudtuk, hogy a felhasználó mit gondol, mennyire van rá szüksége. Ezért kezdtünk el Sprintekben gondolkodni. A Sprinteket User Story-k építik fel. Ezek olyan részfejlesztések, amelyek határideje napokban mérhető. Ezek teszik ki az 1-2 hetes Sprinteket. Tehát egy fejlesztési ciklus elején tudjuk, hogy mit szeretnénk elérni, mi a célunk.

Krisztián Augusztini
Junior Product Manager at Onbox
2019. július 8.

Próbálja ki most

Az Onbox hatékonyabbá tette a Mi munkákat,
és az Ön csapatáét is azzá teszi

Próbálja ki kártyaadatok nélkül