Agiilsete tarkvaraarenduse metoodikate võrdlus (0)

Agiilsete tarkvaraarenduse metoodikate võrdlus Esimest korda kuulsime Agile arendusest (või terminist Agile) 2001. aastal, kui arendajate 
kogukond, kes oli väsinud rasketeks peetud arendusmeetodite kasutamisest - nimelt juga 
mudel(waterfall) - otsustas koostada manifesti: Agile manifest. Sellel väga olulisel 
dokumendil oli nii suur mõju, et see on olnud Agile arengu piibliks ka tänaseni, pannes paika
kõik põhimõtted ja head tavad. Vastavalt Agile manifestile ja mõnele selle 12 põhimõttest: ● Klientide rahulolu on prioriteet, mida demonstreerivad pidevad tarned ja  lisandväärtus. ● Klient ja arendusmeeskond peaksid igapäevaselt koostööd tegema.
● Arendusmeeskondadele on vaja pakkuda head keskkonda ja head tuge. Ainult nii on  võimalik neid motiveerida. ● Agiilsed protsessid soodustavad säästvat arengut nende pideva rütmi ja tehnilise  tipptaseme tõttu, mis parandab tootlikkust. ● Retrospektiivsed hetked meeskonnas on hädavajalikud, võimaldades tal teha  vajalikke kohandusi ja edendada tõhusust. Scrum
Scrum on kergekaaluline agiilne projektijuhtimise raamistik, mida saab kasutada igat liiki 
iteratiivsete ja inkrementaalsete projektide haldamiseks. Scrumis töötav toote omanik on tihedas 
koostöös oma meeskonnaga, et tuvastada ja seada prioriteedid süsteemi funktsionaalsusele, 
luues toote backlog'i. Toote backlog koosneb sellest, mida tuleb teha, et edukalt toimivat 
tarkvarasüsteemi realiseerida. Kogu arendustegevus on jaotatud sprint'ideks, mille kestus võib 
olla sõltuvalt 1–2 nädalat. HALB: ● Projekti segmenteerimine ja arenduse väleduse otsimine võivad mõnikord viia  meeskonna projekti kui terviku jälgimisele, keskendudes ainult ühele osale; ● Iga arendaja roll ei pruugi olla täpselt määratletud, mistõttu meeskonnaliikmed võivad  segadust tekitada. Lean & Kanban Kanban on visuaalne töövoo juhtimise meetod, mis on Lean meeskondade hulgas populaarne. 
Tegelikult 83% Leani kasutavatest meeskondadest kasutab Kanbani, et visualiseerida ja 
aktiivselt hallata toodete loomist rõhuasetusega pidevale tarnimisele. Nagu Scrum, on ka Kanban
protsess, mille eesmärk on aidata meeskondadel tõhusamalt koos töötada.


HALB: ● Meeskonna liikmetel on võimalik Kanbani juhatuses olevat infosaadet valesti tõlgendada, eriti kui see ilmneb vananenuna; ● Kuna Kanbanis pole ajakavasid, võite iga etapiga seista silmitsi ajaga seotud  probleemidega, näiteks viivitustega. Lean arendus kõrvaldab raiskamine (inglise keeles Waste), paludes kasutajatel valida süsteemi 
jaoks tõeliselt väärtuslikud funktsioonid, seada need funktsioonid esikohale ja seejärel töötada 
väikeste osade kaupa nende edastamiseks. See metoodika tugineb kiirele ja usaldusväärsele 
tagasisidele programmeerijate ja klientide vahel, rõhutades arendustöövoogude kiirust ja 
tõhusust. Lean seitse peamist printsiibi, mis tuleks selle kasutamisel rakendada: 1. Eemalda  rämps (Eliminate Waste) a. ebavajalik kood ja funktsionaalsus;
b. alustades rohkemaga, millega saaks hakkama, lisab ebavajalikku keerulisust  süsteemile; c. arenduse venimine;
d. hägused ja pidevalt muutuses olevad nõuded;
e. bürokraatia;
f. aeglane ja mitte tõhus suhtlus meeskonna vahel;
g. osaliselt tehtud töö;
h. ülesannete vahetamine töötajate vahel. 2. Kvaliteedile keskendumine a. kahele arendajale sama ülesande andmine, et nad saaksid teineteist abistada ja toodet muuta kvaliteetsemaks; b. pidev töövoog ja tagasiside;
c. ooteaegade minimaliseerimine;
d. automatiseerimine.


3. Teadlikuse suurendamine a. koos programmeerimine;
b. koodi ülevaatamine;
c. dokumentatsioon;
d. wiki;
e. põhjalikult kommenteeritud kood
f. harjutamine;
g. töövahendite kasutamine, et hoida silma peal vajaminevate ülesannete ellu  viimisel. 4. Liigse pühendumise vähendamine; a. asju ei tohiks planeerida mitmeid kuid detailselt ette ja tuleks hoida pigem  pead avatuna ideedele ja tagasisidele. 5. Kiire arendus;
6. Inimeste austamine;
7. Optimeerimine. HALB: ● See sõltub väga palju arendusmeeskonna võimekusest ja Lean'i põhimõtete  järgimisest, mis tähendab, et vaja on äärmiselt pühendunud ja andekaid arendajaid; ● Fookuse kaotamine on lihtsam, kuna erinevad ülesanded on jagatud mitmeks  elemendiks; ● See nõuab mõningaid dokumente, eriti töö objektiks oleva ettevõtte omaduste kohta.  Vastasel juhul on oht, et arendus võidakse teha valesti ja see võib sisaldada vigu. Extreme Programming
Extreme Programming (XP), mida algselt kirjeldas Kent Beck, on kujunenud üheks kõige 
populaarsemaks agiilseks metoodikaks. XP on distsiplineeritud lähenemine kvaliteetse tarkvara 
kiirele ja pidevale tarnimisele. Selle eesmärk on parandada tarkvara kvaliteeti ja 
reageerimisvõimet klientide muutuvatele vajadustele. See soodustab klientide suurt kaasamist, 
kiiret tagasisidet, pidevat testimist, pidevat planeerimist ja tihedat meeskonnatööd. HALB: ● Äärmine keskendumine koodile võib põhjustada disaini vähem tähtsust, mistõttu on vaja  sellele küsimusele erilist tähelepanu pöörata; ● See raamistik ei pruugi töötada parimal võimalikul viisil, kui kõik meeskonnaliikmed ei  tööta samas geograafilises piirkonnas; ● XP projektides ei peeta võimalike vigade registrit alati ja seire puudumine võib tulevikus  põhjustada sarnaseid vigu. Crystal
Crystali metoodika on üks kõige kergekaalulisemaid, kohandatavamaid lähenemisviise tarkvara 
arendamisele. Crystal koosneb tegelikult agiilsete meetodite perekonnast, sealhulgas Crystal 
Clear, Crystal Yellow, Crystal Orange ja teised. Iga üks omab unikaalseid tunnusjooni, mida 


juhivad mitmed tegurid nagu meeskonna suurus, süsteemi kriitilisus ja projekti prioriteedid. 
Crystali perekond annab mõista, et iga projekti puhul võib vaja minna veidi kohandatud 
poliitikate, tavade ja protsesside kogumit, et vastata toote ainulaadsetele omadustele. HALB: ● Asjaolu, et metoodikaperekonnas on teisendeid, tähendab, et põhimõtted võivad  varieeruda sõltuvalt meeskonna suurusest ja projekti suurusest, mille tulemuseks on 
projektid, mis ei pruugi olla nii otsesed; ● See ei pruugi töötada erinevates piirkondades hajutatud meeskondades, kuna pidev  vajadus suhelda ja reflekteerida; ● Planeerimine ja arendamine ei sõltu nõuetest. DSDM
DSDM põhineb kaheksal põhiprintsiibil, mis juhivad meeskonda ja loovad mõtteviisi, mis 
võimaldaksid ette nähtud aja ja eelarvega tarnida. Need põhimõtted keerlevad peamiselt 
ettevõtte vajaduste ja väärtuste, aktiivse kasutajate kaasamise, sagedase tarnimise, integreeritud
testimise ja sidusrühmade koostöö ümber. FDD
Feature Driven Development on mudelitel põhinev lühiajaline iteratsiooniprotsess, mis oli üles 
ehitatud tarkvaratehnika parimate tavade, nagu domeeni objektide modelleerimine, funktsioonide
arendamine ja koodide omandiline kuuluvus järgi.