Mis on Agile puhul nii tore? Algus paindliku metoodika kohta
Agiilne Määratlege kui vilgas haldussüsteem, mis on juba mõnda aega olemas olnud, kuid viimasel ajal raha omandanud. Tegelikult on Agile Management igal aastal peaaegu iga IT-projektihalduse ajaveebi peamistes projektijuhtimise trendides.
Agile rakendused IT-põhistes projektides on vaieldamatud, kuna see leiab kasutamist mitte ainult IT-tarkvara projektides, vaid ka tootearenduses ja innovatsioonis.
Mis on Agile nii tore? Küsige töötajatelt, kes on liikunud üle traditsioonilisest süsteemist Agile'i, ja nad võiksid pahandada pidevate koosolekute ja koosolekute teemaliste koosolekute üle.
Selgub, et Agile jaoks on palju muud kui lihtsalt kohtumised ja tagasiside. See keskendub meeskondade võimestamisele ja järjestikuste projekti arendamise viiside eemaldamisele, nii et oleks rohkem paindlikkust ja innovatsiooni. Kuigi see tähendab kohtumisi ja edastusi sagedamini kui traditsiooniliste süsteemide puhul, tähendab see ka seda, et hiljem on väiksem korduste ja muudatuste võimalus projektitsüklis edasi.
Seda peetakse ravimiks kõikidele probleemidele, mis vaevavad IT-ga seotud projekte. Mis see täpselt on ja kuidas see on parem kui traditsioonilised süsteemid?
Vajadus paindliku metoodika järele - juhtimispraktikad
Kõigil, kes on tarkvaraarendusprojektides töötanud paindliku metoodika kallal, on mõni idee projekti käigus esile kerkivatest tavapärastest probleemidest: ulatuse muutus, tähtajad, mida on võimatu täita, ja ressursside ületöötlus.
Projektijuhtimise traditsioonilistel paindlikel metoodikatel oli palju puudusi, mille tõttu nad ei suutnud pidevalt muutuvas ärikeskkonnas hakkama saada, eriti tarkvaraarenduses, ning ülaltoodud olukorrad olid kahjuks liiga tavalised. See ei tähenda, et traditsioonilised meetodid pole kuskil kohaldatavad . Need on endiselt parim panus projektidele, mille idee on algusest peale täielikult välja kujunenud.
Agiilsed juhtimispraktikad said tunnivajaduseks, kuna need rahuldasid dünaamilises keskkonnas turule viidud toote järgmised vajadused:
- Toote turule jõudmiseks on vaja kiirust
- Vajadus paindlikkuse järele, et kohandada tehniliste kirjelduste mitmeid muudatusi
- Tööjaotuse stsenaariumi puudused
- Kliendi dilemma
- Kulude vähendamise vajadus
Toote turule jõudmiseks on vaja kiirust:
Me elame kiire tempoga keskkonnas, kus paindlikkus ja kiirus on edu võti.
Tehnoloogia on üks kiiremini muutuvaid sektoreid tööstuses. Iga minutiga on mõni uuem idee, toode või uuendus. Selles kontekstis ei suuda traditsiooniline projektijuhtimise lähenemisviis tulemusi anda. Järjestikune projekt sõltub tingimata sellest, kuidas paindlikud metoodika sammud on järjekorras rahuldavalt täidetud. Traditsiooniliselt juhitud projektide ajakavad on alati vaidluse all.
Organisatsioonid ja meeskonnad, kes pole dünaamilised, kaotavad võistluse nende vastu, kes muutuvad muutuvas keskkonnas sobivaks.
Vajadus paindlikkuse järele, et kohandada tehniliste kirjelduste mitut muudatust:
Klientide ootused ja nõuded muutuvad tootearenduse käigus sageli. Enne Agile Management Systems'i peavoolu olid IT-projektid sageli ebaõnnestunud, kuna traditsiooniline projektijuhtimissüsteem ehitati üles. Muutuste korral tundsid kliendid sageli oma rahakotti või ajajooni. Muudest tööstusharudest kohandatud traditsiooniline projektijuhtimismudel lihtsalt ei töötanud sellise dünaamilise tööstuse jaoks nagu IT.
Tööjaotus:
Traditsioonilises mudelis on erinevad etapid, alustades süsteeminõuete analüüsist ja lõpetades toote vabastamise ja hooldusega. Selle tulemuseks on tööjaotus ja liikmete märgistamine “disaineriteks”, “programmeerijateks” või “testijateks”. Kuid tegelikkuses on tänapäeva ressursid äärmiselt funktsionaalsed ja rollide selline selge eristamine pole enamiku projektide puhul teostatav.
Kliendi dilemma:
Lenduvates projektides pole kliendid sageli täiesti kindlad, milline peab olema nende lõpptoode koos kõigi spetsifikatsioonidega. Funktsioonid ja nõuded muutuvad sageli just siis, kui tööd on tehtud. Traditsioonilised mudelid, näiteks jugamudel, rõhutavad selgust lõpptoote suhtes ja plaanide kõrvalekalded seavad süsteemi tohutu rõhu. See viib meid viimase tegurini, mis viis Agile süsteemide arendamiseni.
Kulude vähendamise vajadus:
Tavapäraselt ei suudetud nõude muutmist teha pärast projekti algust. Pigem olid mis tahes lisakomponendi kulud suured, mõnikord liiga suured. Seetõttu oli hädavajalik kaasata planeerimisetappi kõik võimalikud stsenaariumid. See tähendas, et kaaluti kõiki stsenaariume ja pakuti välja lahendus. Kuid kuna on peaaegu võimatu kindlalt teada saada, millist toote osa kasutaja eelistab, arendasid meeskonnad sageli toote “ülespuhutud versioone”. See sisaldas kõiki võimalikke stsenaariume, millest tavakasutaja kasutaks kuni 20%. Selle tulemuseks olid tarbetud kulud ja areng.
Ütlematagi selge, et see tähendas, et kõik projektid olid oma planeerimisel globaalsed.
Ja kui tekkis täiesti uus planeerimata stsenaarium, olid lisatasud ikkagi vaatamata kogu planeerimisele.
Rühm inimesi kohtus 2001. aasta veebruaris, et arutada täpselt seda: vajadus paindliku ja paindliku tarkvaraarenduse mudeli järele, mis aitaks välja töötada tooteid, mis tegelikult töötasid kliendi ja arendaja jaoks. Selle tulemuseks oli “Agile manifest”, mis oli agiilsest metoodikatarkvara arendamise eelistest, st neljast põhimõttest koosnev, nii lihtne kui kirjeldav. Samuti töötati välja kaksteist “Agiilset põhimõtet”, mis selgitavad, kuidas agiilsed süsteemid projektikeskkonnas tegelikult töötaksid.
Selle töö kaudu oleme väärtustanud:
- Üksikisikud ja protsesside ning tööriistade vastastikune mõju
- Töötav tarkvara üle põhjaliku dokumentatsiooni
- Klientide koostöö lepinguläbirääkimistel
- Kava järgimise muutusele reageerimine
See tähendab, et kuigi paremal olevatel üksustel on väärtus, hindame vasakpoolset üksust rohkem.
12 agiilset põhimõtet
12 Agiilset põhimõtet on Agile Manifesti aluseks olevad juhtmõisted, mis toetavad projektimeeskondi Agile Projektide rakendamisel. Nemad on:
- Meie peamine prioriteet on kliendi rahuldamine väärtusliku tarkvara varajase ja pideva tarnimisega.
- Muutuvate nõuete rahuldamine, isegi hilises arenguetapis. Agiilsed metoodikaprotsessid muudavad rakmete muutmise kliendi konkurentsieeliseks.
- Edastage töötavat tarkvara sageli, paarist nädalast paari kuuni, eelistades lühemat ajakava.
- Ärimehed ja arendajad peavad kogu projekti vältel tegema iga päev koostööd.
- Ehitage projekte motiveeritud inimeste ümber. Andke neile keskkond ja tugi, mida nad vajavad, ja usaldage neid töö tegemiseks.
- Kõige tõhusam ja tõhusam viis arendusmeeskonnas ja selle sees teabe edastamiseks on näost näkku vestlus.
- Töötav tarkvara on edusammude peamine mõõt.
- Agiilsed metoodikaprotsessid edendavad säästvat arengut. Sponsorid, arendajad ja kasutajad peaksid suutma püsimatut tempot hoida.
- Pidev tähelepanu tehnilisele tipptasemele ja heale disainile suurendab paindlikkust.
- Äärmiselt oluline on lihtsus - tehmata tööde maksimeerimise kunst.
- Parimad arhitektuurid, nõuded ja kujundused tulenevad iseorganiseeruvatest meeskondadest.
- Regulaarsete ajavahemike järel mõtiskleb meeskond, kuidas efektiivsemaks muutuda, seejärel häälestab ja kohandab vastavalt oma käitumist.
Näide agiilset juhtimist vajavast projektist
Kujutage ette idufirmat, mis arendab kliendi jaoks mobiilirakendust. Terve rakenduse kujunduse külmutamine enne arendamise algust võib olla katastroofiline. Samuti on piiratud aeg turu-uuringu läbiviimiseks, detailplaneeringu kriimustamiseks, valikute otsustamiseks, mida nad soovivad pakkuda, ja seejärel toote väljatöötamine. Lisaks selle lähenemisviisiga kaasnevatele suurtele kuludele on neil oht, et mõni teine ettevõte võib rakenduse välja töötada enne, kui nad seda teevad.
Projektijuhtimise vilgas metoodika aitab neist probleemidest üle saada. Selle süsteemi kohaselt arendatakse rakendus järk-järgult, klientidega suhtlemisel iga päev ja näiteks iga nädala jaoks kindlaks määratud väljundid või projekti verstapostid.
Sama rakendusega võivad töötada ka mitu meeskonda, nii et arendusaeg väheneb drastiliselt.
Funktsionaalsusi täpsustatakse iga kohtumisega ja lõpptoode peegeldab lõppvajadust. Nad õpivad samm-sammult, mis töötab kliendi jaoks, ja improviseerivad pakkumisi, kuni nad saavad soovitud toote.
Projektijuhtimise traditsioonilises lähenemisviisis võiks enne toote vabastamist mõelda kõigile muudatustele. See tooks kaasa tähtaegade vahelejäämise, suurenenud töökoormuse ja kulude inflatsiooni. Pealegi võis toode vabastamise ajaks oma tähtsuse täielikult kaotada.
Kuidas Agile Management täpselt töötab?
Ehkki Agile Managementi nimetatakse enamasti IT-kontseptsiooniks, ei piirdu selle kasutusvõimalused ainult IT-tööstusega. Näiteks keti rõivaste jaemüüja Zara kasutas ettevõtte ümberkorraldamiseks Agile Management põhimõtteid.
Kasutades Agile põhimõtteid, valmistas Zara tooteid uue hooaja eel suurtele toodetele keskendumise asemel väikeste partiidena. Selle meetodi abil vältis ettevõte suure varude ja ettearvamatute allahindluste pakkumisega seotud kulusid.
Mõned Agiilse projektijuhtimise võtmeaspektid on:
- Agiilne projektijuhtimine järgib paindlikku lähenemist.
Agile Management tervitab täiendusi ja muudatusi kogu tootearenduse vältel, selle asemel et viia see algsesse spetsifikatsiooni.
- Agiilsed projektid jagunevad tavaliselt eraldi tööosadeks, kusjuures meeskonnad tegelevad ühe või mitme sellise töö osaga.
Nii on võimalik, et näiteks neli meeskonda töötab üheaegselt projekti eri osades, nii et projekti tähtajad lühenevad. Meeskonnad koordineerivad iga päev üksteisega ja kliendiga tulemusi.
- Projekti edenemise või takistuste teemal toimuvad igapäevased kohtumised pideva tagasiside abil.
Pärast klientide tagasiside saamist inkorporeeritakse muudatused ja meeskonnad liiguvad järgmisse tükki. See protsess jätkab dünaamilisema ja kliendi vajadustele paremini vastavat toodet.
- Tiimiliikmed on rohkem kaasatud, mitte ülalt-alla lähenemine.
Tarkvaraarenduse elutsükli jooksul on meeskonnaliikmed kaasatud kõigisse etappidesse: nõuete väljatöötamine, väljatöötamine ja paindlik metoodika testimine. Kuna ülesannete efektiivsuse kohta antakse regulaarset ülevaadet, kohandavad meeskonna liikmed vastavalt käitumist ja protseduure.
- Agiilses projektis projektijuhi profiil muutub tavapärasest rollist suuremaks.
Ta ei kuluta enam palju aega ressursside kavandamisele ega jälgimisele, vaid veedab nüüd rohkem aega meeskondadega koostööd tehes ja jälgides, et üldpilt oleks alati silma peal. See ei ole lihtne üleminek ja Agile süsteemidele üle liikuvad juhid peavad projekti õnnestumiseks kiiresti kohanema.
Paar sõna Scrumi kohta:
Scrum on Agile metoodika rakendamise üks populaarsemaid raamistikke. Mis on Agile metoodika? See eelneb Agile-le ja seda pakuti esmakordselt välja 1986. aastal ning rakendati auto- ja trükitööstuses.
Agile metoodika koos saastumisega ei ole sünonüümid; on ka teisi raamistikke, mida saab kasutada Agile rakendamiseks, kuid Scrum on üks tõhusamaid ja tõenäoliselt kõige populaarsemaid. Mis on saast? Tavaliselt on Scrumil ainult kolm rolli: toote omanik, meeskond ja Scrumi kapten. Scrumi metoodikameister ei ole projektijuht. Traditsioonilise projektijuhi rolli kohustused jagunevad kolme Scrumi projektijuhtimise rolli vahel. Projekt on sisseehitatud kindla pikkusega iteratsioonide seeriaks, mida nimetatakse sprintideks. Iga vilgas metoodika sprindi edu toob kaasa käegakatsutavate edusammude ja pideva inspiratsiooni. Iga iteratsiooni eesmärk on saada toimiv toode, mida saab sidusrühmadele näidata. Agiilne metoodikakraapimismeister teeb tooteomaniku ja meeskonnaga koostööd eesmärgi hõlbustamiseks teetõkete eemaldamise abil. Agile metoodika arendusmeeskond on ristfunktsionaalne ja hõlmab lisaks arendajatele ka testijaid, disainereid ja opside insenere.
Traditsiooniline projektijuhtimine: juga
Üks silmapaistvamaid traditsioonilisi projektijuhtimissüsteeme on juga. Seda kasutati sageli alates 1970. aastatest. IT-projektides on mitmeid tuntud ja laialdaselt rakendatud jugametoodikaid. Nende hulgas on PRINCE2, mille lõi Ühendkuningriigi valitsus oma avalikule sektorile.
Nagu nimigi ütleb, on see järjestikune töövoog. Lõpptoode fikseeritakse projekti alguses. Seejärel viiakse järjest läbi töövoo erinevad etapid (kontseptsiooni algatamine, analüüs, kavandamine, ehitamine, testimine, juurutamine ja hooldus). Kui eelmine samm on lõpule viidud, siirduvad arendajad järgmisse sammu. Projekti plaan peaks olema lollikindel; Kui järjendi etapp on lõpule viidud, ei saa arendajad seda uuesti läbi vaadata, alustamata uuesti otsast. See on staatiline lähenemisviis projektijuhtimise paindlikule metoodikale. Muutmistes ega vigades ei ole ruumi ja paindlikku metoodika projektiplaani tuleb hoolikalt järgida.
Analüüsi saab tõmmata jugajuhtimise ja meistriteose maalimise vahel. Lõpliku meistriteose pilt on kunstnikul juba meeles ja ta töötab selle nimel järjekindlalt. Kui lõpptoode erineb mingil põhjusel sellest, mida ta nägi, ei saa ta seda hõlpsalt muuta.
Agile või juga?
- Mis on Agile? Agile sobib rohkem väikestele meeskondadele, kes tegelevad järkjärguliste ja arenevate projektidega, samas kui Waterfall sobib suurteks kavadeks või arendusprojektideks. Jugajuhtimine võiks paremini sobida sellistele tööstusharudele nagu ehitustööstus. Agiilset kasutatakse dünaamilisemates projektides, näiteks IT-valdkonnas.
- Agiilsed süsteemid nõuavad kõrge kvalifikatsiooniga meeskonnaliikmeid, kes saavad hakkama projekti kõigi etappidega. See nõuab projektijuhi rolli dramaatilist muutust. Jugaprotsess on üles ehitatud traditsioonilisemal viisil, see on lineaarne ja seda on ehk lihtsam mõista mittearendajatele ja neile, kes on tarkvaraarenduses uued.
- Paljud organisatsioonid leiavad, et jugametoodika on lohutav, kuna see on paremini dokumenteeritud. Agile on tuntud selle poolest, et ei rõhuta ulatuslikku dokumentatsiooni. See on rohkem inimestest sõltuv, mis võib tekitada ebameeldivusi organisatsioonides, kus kurnatuse määr on kõrge.
- Väiksemad otsekohesed projektid ei pruugi vajada Agiilset metoodikaraamistikku ja sama hästi võib töötada ka järjestikune jugamudel.
Kuhu see kõik läheb?
Agiilsed arendusmetoodikad moodustavad enam kui kaks kolmandikku kõigist USA IT-projektidest, selgub HP 2015. aasta mais tehtud uuringust.
Kuid Agile ei ole alati 'täiuslik' lahendus. See ei ole kõigile sobiv lahendus ja selle tulemusel on paljud organisatsioonid (HP uuringu kohaselt 24%) nüüd kasutusele võtnud hübriidse lähenemise.
Agile ja Waterfall meetodite hübriid võib kasutada mõlema eeliseid. See hübriidne lähenemisviis võiks töötada keerukate projektide korral koos välisklientide ja suurte meeskondadega. Seda lähenemist on kirjeldanud Erick Bergmann ja Andy Hamilton. See on kompromiss kahe meetodi vahel, võimaldades tarkvara meeskondadel töötada "paindlikult", samal ajal kui riistvara arendusmeeskonnad ja tootejuhid kasutavad traditsioonilist meetodit.
Digitaalkonsultant Mark Fromson juhib tähelepanu veel ühele hübriidi töötamise võimalusele:
Projekti jaotamine jugataolisteks etappideks, et võimaldada fikseeritud pakkumisega lepingute sõlmimist ja kindlaksmääratud ulatust väiksema etapi jooksul, kuid kogu projekti sujuvus.
Sõltumata sellest, millist vormi tulevased meeskonnad võtavad, on selge, et Agile metoodika arendamine on siin selleks, et jääda. See on võimaldanud paindlikkust, ajalisi ja kulueeliseid koos kõige olulisema teguriga: nende projektide kallal töötavatele inimestele rahulolutunde ja motiveeriva õhkkonna loomine.
Allikas:
Agiilse manifesti ja 12 agiilse põhimõtte jaoks - www.agilemanifesto.org
Seotud kursused: -
Agiilne projektijuhtimine - õppige tundlikku metoodikat