1. Ajalugu
Agiilne mudel arendati välja 1990. aastate lõpus, kuid ametlikult määratleti see 2001. aastal Agiilse tarkvaraarenduse manifestiga, mille koostasid 17 tarkvaraarenduse eksperti, sealhulgas Kent Beck ja Jeff Sutherland. Manifesti eesmärk oli tutvustada paindlikku, iteratiivset arendusprotsessi, mis keskendub koostööle, töötavale tarkvarale ja kiirele reageerimisele muutuvatele nõudmistele.
Agiilne mudel (Agile model) on tarkvaraarenduse lähenemisviis, mis rõhutab paindlikkust, koostööd ja kiiret reageerimist muutuvatele nõudmistele.
Agiilne arendus keskendub lühikeste iteratsioonide ehk sprindidega töötamisele, pidevale tagasisidele ja toote järkjärgulisele täiustamisele. Agiilne lähenemine on tänapäeval üks populaarsemaid tarkvaraarenduse meetodeid, kuid sellel on oma ajalugu, millele on andnud aluse mitmed eelnevad meetodid ja teooriad.
2. Etapid ja tegevused
- Nõudmiste kogumine (Requirements Gathering) – Kogutakse ja analüüsitakse kasutaja või kliendi nõudmisi. Loetakse toote backlog, kuhu pannakse kõik arendatavad funktsioonid ja ülesanded.
- Planeerimine (Planning) – Määratakse järgmise sprindi ülesanded ja prioriteedid. Koostatakse plaan, kuidas jagada ülesanded meeskonnaliikmete vahel ja mida järgmiseks saavutada.
- Arendus (Development) – Arendajad töötavad valitud ülesannete kallal, luues töötava tarkvara. Iga iteratsiooni lõpus on loodud toimiv ja testitav tooteosa.
- Testimine (Testing) – Iga sprindi lõpus testitakse loodud tarkvara, et tagada selle töökindlus. Kasutatakse erinevaid testimise tasandeid, sealhulgas üksuste testimist ja süsteemitestimist.
- Ülevaatus ja tagasiside (Review and Feedback) – Esitletakse tarkvara klientidele ja kogutakse tagasisidet. Tagasiside abil korrigeeritakse toote suunda ja plaanitakse järgmised sammud.
- Retrospektiiv (Retrospective) – Meeskond analüüsib, mis töötas hästi ja mis vajab parendamist. Pärast igat sprindi arutatakse, kuidas protsessi tõhustada ja järgmistes iteratsioonides paremini töötada.
3. Skeem
4. Plussid
- Minimeerige riske paindliku muudatussüsteemiga
- Projekti esinejate, korraldajate ja tellijate kõrge kaasatus
- Lühikesed ja arusaadavad iteratsioonid – arendustsüklid kestavad 2 nädalast 2 kuuni, mille järel saab klient toote tööversiooni
- Meetodi populaarsus ärijuhtimistarkvara arendajate seas
- Esirinnas on töötav toode kui peamine edusammunäitaja – seda võib pidada nii plussiks kui miinuseks, sest sel juhul esitatakse projektimeeskonnale kõrged nõuded eneseorganiseerumisele
5. Miinused
- Julgustage pidevat projekti muutmist: tootearenduse paindlikkus võib viia selleni, et see ei jõua kunagi lõpliku versioonini
- Kõrgendatud nõuded meeskonna kvalifikatsioonile ja kogemustele: lisaks otsesele toote loomisele peab meeskond analüüsima võimalikke võimalusi enda töö efektiivsuse tõstmiseks, pidevalt vahetama projekti kohta infot,
olema motiveeritud ja iseorganiseerunud.
- Meeskond ei saa mehaaniliselt rakendada “agiilse” arenduse mehaanikat, vaja on aktsepteerida süsteemi põhiprintsiipe
- Lõpliku töömahu arvutamise keerukus: lõpptoote muudatuste ja täiustuste stimuleerimine toob kaasa projekti maksumuse ujuva väärtuse. Seetõttu ei sobi Agile projektijuhtimiseks ehituses, kus kõikidele töödele tehakse
selge hinnang.
- Nõrk tähelepanu dokumentidele. Nõuete ja konfliktiolukordade korral ei ole esinejal lihtsalt oma kaitseks argumente.
Полученные результаты
