AGILE on paindlik projektijuhtimissüsteem. Agiilne. Kuidas ja millal seda meetodit rakendada Mis on agiilne lähenemine

Agiilse arendusmetoodika (inglise keelest - Agile software development)- manifest, mis määratleb mõtteviisi ja sisaldab põhiväärtusi ja põhimõtteid, millel on mitu lähenemisviisi (raamistikud, inglise keelest. raamistik- raam, struktuur) tarkvaraarendusse (kuigi viimasel ajal on olnud trend ja katsed rakendada agiilset arendusmetoodikat ka muudes tegevusvaldkondades, mitte ainult osaliselt infotehnoloogiad), mis eeldab interaktiivset arendust, perioodilist (dünaamilist) nõuete pakkumist (uuendamist) Kliendilt ja nende elluviimist läbi iseorganiseeruvate töörühmade, mis on moodustatud erineva profiiliga ekspertidest (arendajad, testijad, juurutajad jne). Selline Agile'i tõlge kui "agiilne arendusmetoodika" ei ole täiesti õige. tavaliselt Agile’i ei nimetata metoodikaks, vaid sellel manifestil põhinevad lähenemised on metoodikad, kuid Agile’i seisukohalt nimetatakse neid raamistikeks. Hetkel on palju raamistikke (metoodikaid), mille lähenemised põhinevad agiilsel arendusmetoodikal, näiteks Scrum, Extreme programming, FDD, DSDM jne.

Määratlus BPM CBoK mõistes [inglise keelest. - Äriprotsesside juhtimise ühise teadmistekogu juhend]. Agiilne- Üks iteratiivseid ja järkjärgulisi tarkvaraarenduse metoodikaid, erinevalt traditsioonilisest lineaarse juga metoodikast. Agiilne arendusmetoodika määratleb disaini-, arendus- ja testimistavade süsteemi kogu tarkvara elutsükli jooksul. Agiilsed arendusmeetodid (nagu SCRUM) põhinevad kiirel reageerimisel muutustele, kasutades adaptiivset planeerimist, koostööl põhinevat nõuete genereerimist, iseorganiseeruvate ristfunktsionaalsete arendusmeeskondade tõhustamist ja selgete ajaraamidega järkjärgulist tarkvaraarendust. Seda lähenemisviisi kasutatakse paljudes kaasaegsed projektid kaubandusliku tarkvara arendamine.

Agiilne arendusmetoodika põhineb liberaaldemokraatlikul lähenemisel meeskondade töö juhtimisel ja korraldamisel, mille liikmed on keskendunud konkreetse tarkvara arendamisele.

Tänu sellele, et agiilset metoodikat kasutav tarkvaraarendus määratleb rea lühikesi tsükleid (iteratsioone), mille kestus on 2-3 nädalat, saavutatakse riskide minimeerimine. iga iteratsiooni lõpus nõustub Klient tulemustega ja väljastab uued või korrigeerivad nõuded, s.o. kontrollib arengut ja saab seda kohe mõjutada. Iga iteratsioon hõlmab planeerimist, nõuete analüüsi, disaini, arendust, testimist ja dokumenteerimist. Tavaliselt ei piisa täisväärtusliku tarkvaratoote väljaandmiseks ühest iteratsioonist, vaid iga arendusetapi lõpus peaks olema "käegakatsutav" toode või funktsionaalsus, mida saab vaadata, testida ja väljastada lisa- või parandusmeetmeid. Tehtud töö põhjal teeb meeskond peale iga etappi kokkuvõtteid ja kogub kokku uued nõuded, mille alusel teeb muudatused tarkvara arendusplaanis.

Agile’i üks põhiidee on meeskonnasisene ja kliendiga näost näkku suhtlemine, mis võimaldab kiiresti otsuseid langetada ja tarkvaraarenduse riske minimeerida, nii et meeskond on paigutatud ühte kohta, geograafilisest punktist lähtudes. vaade. Veelgi enam, meeskonda kuulub kliendi esindaja (ingliskeelne tooteomanik – kliendi või kliendi enda volitatud esindaja, kes esindab tootele esitatavaid nõudeid; seda rolli täidab kliendist projektijuht või ärianalüütik).

Avalda Agile Manifesti ajalugu

"Agile Software Development Manifesto" avaldati ja võeti 2001. aasta veebruaris vastu (UTA USA, The Lodge at Snowbird suusakuurort) ekspertide rühma poolt. See manifest määratleb sellel põhinevate metoodikate jaoks 4 põhiväärtust ja 12 põhimõtet ning pakub ka alternatiivse nägemuse tarkvaraarenduse käsitlusest erinevalt suurtest ja tuntud meetoditest ja metoodikatest, kuid ei ole metoodika omaette. Tavaliselt võrreldakse Agile'i peamiselt "juga" meetodiga, kuna. manifesti avaldamise ajal oli just "kose meetod" tarkvaraarenduse planeerimisel peamine. Agile Manifesti väljatöötamisel ja avaldamisel osalesid järgmiste metoodikate esindajad:

• Adaptiivne tarkvaraarendus (ASD)
• Kristallselge
• Dynamic Systems Development Method (DSDM)
• Extreme Programming (XP)
• Funktsioonipõhine arendus (FDD)
• Pragmaatiline programmeerimine
• Scrum

Tegelikult olid need väledad arendusmetoodikad olemas juba enne manifesti avaldamist. Manifesti ilmumine ise andis uue tõuke agiilsete metoodikate arendamisele, pani aluse, võiks öelda, et konstitutsiooni agiilsele lähenemisele tarkvaraarenduses.

Agiilse tarkvaraarenduse manifest:

Agiilsete meetodite peamine mõõdik on tööprodukt. Eelistades näost näkku suhtlemist, vähendavad agiilsed meetodid kirjaliku dokumentatsiooni mahtu võrreldes teiste meetoditega.
See on viinud nende meetodite kui distsiplineerimatuse kriitikani.

Avastame pidevalt paremaid viise tarkvara arendamiseks, arendades otse ja aidates teisi. Tänu tehtud tööle saime aru, et:

• Inimesed ja suhtlus protsessidest olulisem ja tööriistad
• Töötav toode on olulisem kui põhjalik dokumentatsioon
• Koostöö kliendiga on olulisem kui lepingutingimuste läbirääkimine
• Valmisolek muutusteks on olulisem kui algse plaani järgimine

See tähendab, et eitamata selle tähtsust, mis on parempoolne, hindame siiski rohkem seda, mis on vasakul.

Manifesti autorid:

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland Dave Thomas

Agile Manifesti aluspõhimõtted:

Järgime neid põhimõtteid:

1. Meie kõrgeim prioriteet on klientide rahulolu väärtusliku tarkvara korrapärase ja varajase tarnimise kaudu.
2. Nõuete muutumine on teretulnud, isegi hilises arengujärgus. Agiilsed protsessid võimaldavad kasutada muutusi, et pakkuda kliendile konkurentsieelist.
3. Töötav toode tuleks välja anda nii sageli kui võimalik, sagedusega paar nädalat kuni paar kuud.
4. Kogu projekti vältel peavad arendajad ja ettevõtete esindajad igapäevaselt koostööd tegema.
5. Projekti kallal peaksid töötama motiveeritud spetsialistid. Töö tegemiseks looge tingimused, pakkuge tuge ja usaldage neid täielikult.
6. Otsesuhtlus on kõige praktilisem ja tõhus viis infovahetus nii meeskonna endaga kui ka meeskonna sees.
7. Töötav toode on edusammude peamine näitaja.
8. Investorid, arendajad ja kasutajad peaksid saama püsivat rütmi lõputult hoida. Agile aitab sellist säästva arengu protsessi paika panna.
9. Pidev keskendumine inseneri tipptasemele ja disaini kvaliteedile suurendab projekti paindlikkust.
10. Lihtsus – tarbetu töö minimeerimise kunst – on hädavajalik.
11. Parimad nõuded, arhitektuursed ja tehnilised lahendused tulevad iseorganiseeruvatelt meeskondadelt.
12. Meeskond peaks süstemaatiliselt üle vaatama võimalikud viisid parandada tõhusust ja kohandada oma tööstiili vastavalt.

Agile'i kriitika

Agile ei kirjelda hästi nõuete haldusprotsesse, võib öelda, et sellist kontseptsiooni lihtsalt ei eksisteeri. agiilne arendusmetoodika ei tähenda pikaajaline planeerimine(planeerimine toimub lühiajaliselt), jäeti seetõttu tootearendusplaani ehk teisisõnu toote teekaardi koostamise samm vahele. Sest lühiajaline planeerimine (järgmise arenduse iteratsiooni jaoks) ja iga iteratsiooni lõpus nõustub Klient tootega ja esitab uued nõuded, toode ise võib radikaalselt muutuda ning uued seatud nõuded on sageli vastuolus toote struktuuri ja arhitektuuriga. toode on juba klientidele tarnitud. Üldiselt, kui Klient ei saa täielikult aru, mida ta tulemusena näha tahab (lõpptoode) ja arusaam tuleb arenduse käigus (see juhtub 90% juhtudest), muutub arendusprotsess formaliseeritud ja legaliseeritud bürokraatiaks, st . toodet täiustatakse lõputult, kuni raha saab otsa või klient läheb teisele tootele üle. Ausalt öeldes tuleb märkida, et Klient teab, mida teeb ja otsustab, kas maksab tootearenduse eest või mitte, suures plaanis täidab arendusmeeskond lihtsalt kliendi nõudmisi. Tegelikkuses toob see aga töös kaasa kaose, tähtaegadest möödalastud ja kiirustades töid, mis toob kaasa uued nõuded, mis muudavad toodet hullemaks. Pealegi langeb väljatöötatud toote kvaliteet, kuna Agile määratleb lähenemise arendusele, mille puhul tulekahjud tuleb kustutada kiiresti, kõige lihtsamalt ja kõige rohkem kiire tee. Kood on kirjutatud toote arendamise aluseks oleva platvormi nõudeid järgimata, ilmneb palju lahendusi ja defekte ning selline disain pole kuigi stabiilne ega ohutu, klientide pahameel sagedaste tarkvaratõrgete pärast kasvab. Väljapääsu juures olev äri saab kahjumit, planeerimise kvaliteet langeb.

Mõned Agile'i eksperdid seostavad pigem juba valmistoote täiustamise kui uue väljatöötamisega. Agiilsel arendusmetoodikal on palju pooldajaid, nagu ka vastastel. Viimane avaldas omal ajal isegi Anti Agile Manifesti. Lisaks esitame informatiivsel eesmärgil kahe populaarseima manifesti sisu, mis on vastuolus peamise Agile manifestiga:

Anti-Agile manifest (tuleb märkida, et see anti-agile manifest pole tegelikult vastuolus mitte Agile'i endaga, vaid pigem ühe raamistikuga, mis põhineb Agile'i põhimõtetel - Scrum, kuna manifestis kasutatakse selle raamistiku termineid):

Meie kaudu on olnud palju konsultante ning veetnud lugematu arv tunde agaratel koosolekutel ja koosolekutel. Selle kogemuse põhjal saime aru, et Agile on lihtsalt ajupesu, sest:

• eeposed on lihtsalt projektid
• kasutajalood (kasutajalood) – see on lihtne kasutusjuhtumeid
• sprindid on lihtsalt töö
• stand ups (stand-up) on lihtsalt koosolekud
• iteratsioonid on vaid versioonid
• mahajäämused on vaid ülesannete nimekiri
• meeskonna kiirus (kiirus) on vaid tulemused
• ja need ülesanded (ülesanded) on reaalsed, lihtsalt ülesanded

Seega, kui vasakpoolseid termineid tehakse ettepanek pidada uuenduslikeks, muutes arengukäsitlust, on need parempoolsete terminite ebamäärased mõisted.

Agiilsete arendusmetoodikate sordid

Agile Manifestis määratletud väärtuste ja põhimõtete alusel on välja töötatud järgmised agiilse arendusmetoodikad:

• Agiilne modelleerimine (AM)- see lähenemine määrab põhimõtteliselt modelleerimise (sh mudeli koodiga kontrollimise) ja dokumenteerimise protseduurid tarkvaraarenduse raames. Vähemal määral kirjeldatakse UML-is diagrammide kujundamise ja koostamise protseduure. Samuti ei mõjuta see arenduse, testimise, projektijuhtimise, juurutamise ja hoolduse valdkondi.
• Agile Unified Process (AUP)- RUP metoodika (IBM Rational Unified Process) ühtne versioon, mille koostas Scott Ambler. AUP määratleb mudeli tarkvara loomiseks ärirakendustes.
• Agiilne andmemeetod (ADM)- iteratiivsete agiilsete tarkvaraarenduse metoodikate kogum, mis rõhutab nõuete ja lahenduste kujundamist läbi erinevate funktsionaalsete meeskondade koostöö.
• Dynamic Systems Development Method (DSDM)- iteratiivne ja inkrementaalne lähenemine, mis põhineb rakenduste kiire arendamise kontseptsioonil - Rapid Application Development (RAD), mis keskendub lõppkasutaja maksimaalsele kaasamisele tarkvaratoote arendamisse.
• Essential Unified Process (EssUP)- Ivar Jacobsoni (Ivar Jacobson) välja töötatud lähenemisviis sisaldab iteratiivse tarkvaraarenduse meetodeid, rõhuasetusega tootearhitektuuril ja meeskonnapraktikatel (sisuliselt laenatud RUP-ilt, CMMI-lt ja Agile Developmentilt). Idee seisneb selles, et kasutate ainult neid tavasid ja meetodeid, mis on konkreetses olukorras rakendatavad. Valitud meetodite ja praktikate põhjal määratakse sihtprotsess. Erinevalt RUP-ist, kus kõik praktikad ja meetodid on omavahel seotud, on sel juhul paindlikkus ja võimalus isoleerida täpselt vajalikud elemendid (meetodid ja praktikad) kogu olemasolevast mahust.
• Äärmuslik programmeerimine (XP)- äärmusliku programmeerimise idee on kasutada olemasolevat parimad tavad tarkvaraarenduse vallas nende tõstmine uuele (äärmuslikule) tasemele. Näiteks erinevalt tavapärasest praktikast, kui üks programmeerija kontrollib järjestikku oma kolleegi jaoks kirjutatud koodi, siis ekstreemse programmeerimise puhul toimub see kontroll paralleelselt, mis suurendab toote vabastamise kiirust, aga ka riske.
• Funktsioonipõhine arendus (FDD)- peamine piirang, mis selle lähenemisviisi raames kehtestatakse, on "iga funktsioon tuleb rakendada mitte rohkem kui kahe nädala jooksul". Need. kui on realistlik töötada välja funktsioon ühe istungiga, siis see on hea, vastasel juhul tuleks see funktsioon jagada mitmeks ja rakendada järk-järgult.
• Realiseerimine (GR)- selle lähenemisviisi raames on veebirakenduste jaoks kasutatavad funktsionaalsete spetsifikatsioonide protseduurid välistatud. Arendus algab vastupidisest, algul töötatakse välja liides ja disain ning seejärel funktsionaalsus ise.
• OpenUP (OUP)- see lähenemine määratleb tarkvaraarenduse iteratiiv-inkrementaalse meetodi. Välja töötatud RUP baasil. Osana seda meetodit määratletud eluring arendus (käivitamise faas, täpsustamise faas, arendusfaas ja kliendile üleandmine). Tänu teatud etapiviisidele ja verstapostidele suureneb projekti edenemise kontrolli ja monitooringu efektiivsus, mille tulemuseks on projekti õigeaegne otsustamine.
• lahja tarkvaraarendus- see lähenemine põhineb säästliku juhtimise kontseptsioonil tootmistehas(lean tootmine, lahja tootmine).
• Scrum- üks levinumaid lähenemisi agiilsele tarkvaraarendusele, määratleb arendusprotsessi juhtimise reeglid, kasutades olemasolevaid arenduspraktikaid. Rõhk on Kliendi kaasamisel protsessi (võimalus muuta või täpsustada iga etapi järel loodud tootele esitatavaid nõudeid), mis võimaldab kõrvalekaldeid õigeaegselt tuvastada ja vajalikke muudatusi teha.

Agiilsed projektijuhtimise meetodid (Agile) on muutumas üheks populaarseimaks juhtimisvahendiks nii strateegiliselt kui ka taktikaliselt. Selles märkuses püüame välja mõelda, kui palju on vajalik Agiilne projektijuhtimine Teie ettevõtte juhtimises, olles läbi mõelnud mitmeid küsimusi, mille vastused võimaldavad juhil teha otsuse: kas Agile metoodikat tasub rakendada ettevõttes. tema ettevõtte äriprotsesse või mitte, ja kui selline vajadus on olemas, siis milliseid konkreetseid ülesandeid see võimaldab teie ettevõttes lahendada.

Paindlikud juhtimismeetodid Agiilsed on ennekõike lähenemised, mis võimaldavad väga kiiresti lahendusi leida, pilootprojekte käivitada ja vajadusel ka skaleerida.

Agiilne on projektijuhtimise seisukohalt teie ettevõtte jaoks vajalik, kui:

• teie toode, teenus või tooteesitlus vajab pidevat kohandamist.
• kui teil on vaja turundust kohandada vastavalt turu nõuetele.
• kui olete huvitatud uuendustest, et suurendada kasumit ja vähendada kulusid.

Ja piltlikult öeldes: sul on alati vaja Agile’i metoodikat, kui töötad kiiresti muutuval turul tingimustes pidev muutumine või ebakindlust nii strateegia kui praktika seisukohast.

Agiilne metoodika(agiilne metoodika) võimaldab moodustada uut tüüpi juhtimise ja juhtimise agiilseid meeskondi, tagades samal ajal protsessi läbipaistvuse ja efektiivsuse, toote otsustamise, arendamise, kohandamise ja skaleerimise kiiruse ning reageerimisvõime ebakindlusele, muutustele ja kriisidele.

Agiilne metoodika, mis see on?

Kas võib öelda, et agiilne on kriisijuhtimise ja muudatuste juhtimise tööriist? Kindlasti jah!

Agiilne metoodika on tööriist konkreetsete praktiliste probleemide lahendamiseks kriisijuhtimises ja muudatuste juhtimises.

Kuidas Agile'i õigesti rakendada?

Üsna levinud viga on soov rakendada Agile’i, kasutades ära suuna populaarsust ja teiste ettevõtete positiivset kogemust, kuid nii hoolimatult tegutsedes on oht suur:

Agiilne organisatsioon nõuab muutust mõtlemises, töökäsitluses ja suhtlemispõhimõtetes nii meeskonnas kui ka juhtimises, kas oled selleks valmis? Aga teie töötajad? Pange tähele, et see on väga oluline probleem, millest paljud tavaliselt tähelepanuta jäävad:

Agiilne metoodika see ei ole toode karbis, see on lahendus, mille rakendamine eeldab oskust õppida uusi asju, kohaneda oma ülesannetega ja alles seejärel skaleerida.

Seetõttu soovitan alati läbi viia, läbi viia mitmeid äriülesandeid agiilse juurutamise küsimustes ja alles siis kaaluda metoodikate juurutamise võimalust. paindlik juhtimine nende ettevõtetele. Lahendusena võin soovitada läbida minu praktiline kursus:

Agiilsed meetodid võib teie ettevõtte hävitada ja see sõltub teie ettevõttest, teie äriprotsessidest, mitte teist või teie töötajatest.

Millal mitte rakendada Agile

On lihtne reegel:

Agiilne metoodika saab kasutada ainult siis, kui olete nõus vigade eest maksma.

Agiilne metoodika ei anna mitte ainult tulemust:

Agiilne, paindliku arenduse mõttes, võimaldab üles ehitada protsessi läbi tulemuste saavutamise tagasisidet, palju võimalusi tagasiside saamiseks, kuid tagasiside ei ole ainult emotsioonid ja küsimustikud, see on ka raha: kasum ja kahjum, pidage seda meeles.

Kui soovite kaaluda agiilse projektijuhtimise juurutamist, siis on teie ettevõte valmis integreerima agiilseid projektijuhtimise meetodeid teie äriprotsessidesse:

• isiklik ja grupi juhendamine.
• teie kolleegid jagavad agiilse meeskonna väärtusi
• oled otsustanud rakendada Agile’i organisatsioonis kõigis vajalikes äriprotsessides ning oled teadlik Agile’i rakendamise riskidest projektijuhtimises.

Ja kordan veel kord: Agiilne metoodika see on mõtlemine, mitte ainult tööriistad.

Ja mõtlemine tähendab iseenesest: suhtumist tulemusesse ja kommunikatsiooni ning korralikult üles ehitatud tagasisidet, mis on väga oluline, kui plaanite kasutada paindlikke projektijuhtimise meetodeid.

Agiilne metoodika töötab suurepäraselt ebakindluse ja prognoositavate tulemuste tingimustes, valmisoleku tingimustes suurteks kuludeks. kõrgeim eesmärk; kui teil on äriprotsessid üles ehitatud, siis mõelge, milliseid eesmärke te püüdlete Agile projektijuhtimise rakendamisega saavutada ja kas see on seda "mängu-tööd" väärt.

Algoritm Agile juurutamiseks ettevõttes

Vaatame indikatiivset algoritmi Agile metoodika juurutamiseks ettevõtte praegustes äriprotsessides, keskendudes Agile’ile projektijuhtimises:

• Alustades eesmärkidest: Milliseid eesmärke püüate saavutada, rakendades agiilseid juhtimismeetodeid? Ja kuidas need eesmärgid Agile organisatsioonile vastavad.
• Kirjeldame Sinu ettevõtte või osakonna probleeme, mille oled Agile pilootprojekti elluviimiseks valinud, vajadusel kirjeldame, millisest stiilist oma töös kinni pead, kuidas arvamusi vahetad ja tulemuste saavutamist jälgid.

Muidugi soovitab ennast järgmine samm, klassikaline “kuidas teha”, kuid siin ei tasu kiirustada, sest kust sa tead, kuidas seda teha? - Agiilne metoodika ehitab ümber mõtlemise ning Agile’i rakendamisel projektijuhtimises on vaja luua efektiivne suhtluskeskkond dialoogi loomiseks Agile meeskonna liikmete vahel.

Agiilse meeskonna loomine ettevõttes

Agile meeskonna moodustamine võib olla üsna kiire, võib kuluda mitu päeva, kuid kui kaua võtab aega meeskonnaliikmete “lihvimine”?

Loomulikult eristatakse meeskonna loomise seisukohalt etappe: moodustamine, konfliktid, reeglite ja normide väljatöötamine ning selle tulemusena saame: teatud tööstiili, kuid Agiilses meeskonnas toimub kõik veidi teisiti. :

• Agiilsed meeskonnaliikmed ja juhid peavad kinni Agile Manifestist ning on keskendunud tõhusa töö loomisele ja eesmärkide saavutamisele kiirete muutuste keskkonnas.
• nad ei loo mugavustsooni, ei loo utoopiat, nad ise otsivad muutusi, uusi suundumusi, analüüsivad nende kasutamise võimalust ettevõtte eesmärkide elluviimisel.

Agiilne metoodika on:

Agiilne metoodika ei ole projektijuhtimine, Agile on agiilne juhtimismeetod, mis võib olla projektijuhtimise tööriist või olla teie organisatsioonis täiesti sõltumatu. Loomulikult on Agiilsete meeskondade efektiivsuse huvides suur viga koolitada töötajaid klassikalise meeskonna loomise ja juhtimise alal, sundides neid seeläbi vanaviisi mõtlema!

Paindlikud agiilsed juhtimismeetodid see on üleskutse tegutseda, leida midagi uut, saavutada seatud eesmärke, osata kasutada välis- ja sisekeskkond vajalike eesmärkide saavutamiseks ja konkreetsete probleemide lahendamiseks, mis mõjutavad kasumit ja konkurentsivõimet ettevõtluses.

Daamid ja härrad! Agiilne metoodika on ettevõtte juhtimisel hädavajalik, kuid eeldab paindlikku lähenemist elluviimisele ja uutele ideedele, samas kui vanade meetodite kasutamine viib tulemusteni, mis ei võimalda saavutada uusi eesmärke ega tõsta ettevõtte konkurentsivõimet. Seetõttu olge Agile konsultantide valikul väga ettevaatlik, hinnake nende kohanemisvõimet nõuetele vastavaks. kaasaegne turg, teie küsimused on teretulnud, kirjutage kommentaaridesse. Aitäh!

Kõik teavad näidet klassikalistes juhtimisõpikutes sisalduvast tehaseseadmest, kus igal töötajal oli õigus konveier seisata, et viga kõrvaldada või teha ratsionaliseerimisettepanek. Just see lähenemine oli agiilse filosoofia aluseks.

Agile, mis ilmus tarkvaraarenduse meetodina väikestes meeskondades 10-15 aastat tagasi, on nüüd saamas suurettevõtete juhtimise uueks kultuuriks. Tänu German Grefi hiljutisele kõnele on mõiste Agile kaasatud kõigi kaasaegsete Venemaa juhtide leksikoni.

Mis on Agile ja miks nimetatakse seda meetodit peaaegu ainsaks õigeks?

Toodete ja teenuste loomisel on klassikaline lähenemine, mis on omane eelkõige IT-tööstusele. Sellist lähenemist nimetatakse koseks või iteratiivseks arendusmetoodikaks. AT Ingliskeelne terminoloogia seda lähenemist nimetatakse kose arendamiseks (inglise keelest - kosk). Miks nimetatakse seda koseks? Sest sellise arendusskeemi puhul, kui oled tarkvaratooteplaani kinnitanud, ei saa te seda plaani enne selle loomist peatada ega muuta.

Agiilne on uuenduslik lähenemine uue toote või teenuse loomise ümbermõtestamiseks. See põhineb väga lihtne idee: iga protsessis osaleja, iga selle "konveierikoostu" töötaja peaks olema kaasatud oma ülesannete ja ühise eesmärgi ümbermõtestamise protsessi. Igaüks saab konveieri peatada ja teha oma ratsionaalseid ettepanekuid.

Enamikus organisatsioonides asuvad tarkvaratoodete loomisel projekti teatud etappide eest vastutavad inimesed erinevates, sageli vastuolulistes osakondades. Pole saladus, et operatiivtöötajad, testijad ja arendajad on tavaliselt omavahel konfliktis. Ja kui toode ei tööta ega too ettevõttele kasumit, siis püüavad kõik teist süüdistada. Kuigi tegelikult on sellistel juhtudel reeglina kõik süüdi.

Agiilne meetod hõlmab kõigi osalejate kaasamist tarkvara tootearendusprotsessi, jättes osalejatele tuttavad kompetentsid. Selline lähenemine teeb selgeks, et nad kõik töötavad sama lõppeesmärgi nimel – kvaliteetse toote oma klientidele.

Seega on toimunud muutus ettevõtte enda ärikultuuris. MBA programmide osana on terve kursus, mis käsitleb organisatsiooniline struktuur ettevõtted. Selles on tasakaalu mõiste, kui kõik teevad kõike idufirmade ja idufirmade sees, mistõttu sünnibki seal sageli sõbralik meeskond, kes turul tõhusalt tegutseb. Ja tõhususe ja uute ideede turule toomise seisukohalt on see ideaalne organisatsiooniline struktuur.

Muidugi on organisatsioone, kes Agile’i üldse ei vaja. Näiteks valitsusasutused. Nende tegevus põhineb seadusandlusel. Me ei saa riigiga suhelda, kui mängureeglid muutuvad iga päev.

Seega on meil organisatsiooni infrastruktuuri kaks radikaalset vastandit. Ühelt poolt on kõige rangem bürokraatlik formaliseeritud organisatsioon, mida teatud juhtudel kasutatakse ja mis teatud olukordades hästi toimib. Ja selle täielik diametraalne vastand on noored idufirmad, mõttekaaslaste meeskonnad, kes loovad tõesti midagi uut, ja Agile on palju lähemal emotsionaalse meeskonna seisundile, mis töötab lõppeesmärgi, toimiva kvaliteetse (tarkvara) nimel. toode. Ja seetõttu on igal etapil tekkivad probleemid kõigi inimeste probleemid ja sellesse protsessi on kaasatud kõik, kes suudavad neid lahendada.

Suure klassikalise ettevõtte (Enterprise) üleminek Agile'ile

See on äärmiselt oluline küsimus ja see on väga huvitav. Kogu maailm räägib sellest, German Gref ütles sama. Ta ütles: "Poisid, me oleme pank, meie konkurendid ei ole pangad, meie konkurendid on noored ettevõtted, kes toovad digitaalset ühiskonda."

Arenenud äri põhineb kolmel sambal: kogemused ja teadmised valdkonnas (milles ettevõte tegutseb), toodete ja teenuste arendamine Agile metoodika abil ning mis kõige tähtsam – uuenduslik kultuur.

Juhtivad IT-ettevõtted, olles hõlpsasti kopeerinud pangatooteid ja -teenuseid, hakkavad neid täiendama (või ümber kujundama) tasemele, milleni pank neid viia ei suuda, kuna traditsiooniline finantseerimisasutus ei ole piisavalt arenenud innovatsioonikultuuri.

Väga lihtne näide onnid. Need on ettevõtted, kes loovad teenuse sõna otseses mõttes ühe sõrmenipsuga. Täna ilmus ettevõte, väljastas laenu uskumatult kõrge intressiga - homme on selle kasumlikkus mitu korda suurem kui pangal. Sellised organisatsioonid saavad oma teenuseid ja tooteid koheselt uuesti üles ehitada, kiiresti siseneda uutele turgudele, tõrjudes välja klassikalised pangad.

Sarnased asjad ei juhtu mitte ainult panganduses, vaid kõigis tööstusharudes ja ärivaldkondades. Mobiilioperaatorid hakkavad tegelema maksesüsteemidega. Uber on muutnud oma lähenemist reisijatevedu paari aastaga üle maailma ja Airbnb tegi sama reisiäri hotellisegmendiga.

Paindlik planeerimine

Kose arendusega tuleb planeerida aasta ette. Aga kui midagi muutub - näiteks on vaja rohkem servereid või muid komponente, siis on selline stsenaarium projekti peatamisel võimalik - lõppude lõpuks on vaja läbi viia uus hange, osta uus infrastruktuur jne.

See tähendab, et Agile ei muutu pelgalt uue tarkvara loomise metoodikaks, vaid paindliku planeerimise süsteemiks kogu ettevõtte arendamiseks. Ehitada tuleks selline infrastruktuur, mis vastab paindlikult ka klientide soovidele ja nõudmistele, mis tarkvaratoote arendamise ja selle toimimise käigus muutuvad (see, muide, eeldab totaalset üleminekut pilvetehnoloogiatele).

Agiilne planeerimine nõuab iga äriprotsessi mõistmist ja analüüsi. Ja see juba on järgmine etapp ettevõtte arendamine – selle digitaliseerimine.

Lugege materjali

Agiilse arendusmetoodika(eng. Agiilne tarkvaraarendus, agiilsed meetodid) – tarkvaraarenduse lähenemisviiside sari, mis keskenduvad kasutamiseleinteraktiivne arendus , nõuete dünaamiline kujundamine ja nende elluviimise tagamine iseorganiseeruvate töörühmade pideva suhtluse tulemusena mis koosneb erineva profiiliga spetsialistidest. Agiilsete arendusmetoodikate klassiga on seotud mitu tehnikat, eriti äärmuslik programmeerimine, DSDM, Scrum, FDD.

Enamiku agiilsete metoodikate eesmärk on vähendada riski arengut vähendadeslühikeste tsüklite seeriale, mida nimetatakse iteratsioonideks mis kestavad tavaliselt kaks kuni kolm nädalat. Iga iteratsioon ise näeb välja nagu miniatuurne tarkvaraprojekt ja sisaldab kõiki ülesandeid, mis on vajalikud funktsionaalsuse minikasvu saavutamiseks: planeerimine, nõuete analüüs, disain, programmeerimine, testimine ja dokumenteerimine. Kuigi ühest iteratsioonist toote uue versiooni väljalaskmiseks üldiselt ei piisa, eeldatakse, et agiilne tarkvaraprojekt on iga iteratsiooni lõpus avaldamiseks valmis. Iga iteratsiooni lõpus hindab meeskond arendusprioriteedid ümber.

Agiilsed meetodid

Agiilsed meetodid on sellised paindlikud metoodikad nagu Lean Development (“Lean tarkvaraarendus”), Scrum jne. Need töötati välja juba 2000ndate alguses alternatiivina ebaefektiivsetele traditsioonilistele IT-meetoditele.

Peaaegu kõik agiilsed meeskonnad on koondunud ühte kontorisse (bullpen). Büroosse kuulub toote omanik – klient, kes määrab tootele esitatavad nõuded. Klient võib olla ärianalüütik, projektijuht või klient. Lisaks võivad kontorisse kuuluda liideste kujundajad, testijad, tehnilised kirjutajad. See on Agiilsed meetodid keskendunud eelkõige vahetule suhtlusele.

Agiilsete meetodite peamine mõõdik on tööprodukt.Eelistades näost näkku suhtlemist, vähendavad agiilsed meetodid kirjaliku dokumentatsiooni mahtu võrreldes teiste meetoditega.

Peamised ideed:

— inimesed ja suhtlemineprotsessidest ja tööriistadest olulisem;

— töötav toodeolulisem kui terviklik dokumentatsioon;

— koostöö kliendigaolulisem kui lepingutingimustes kokkuleppimine;

— valmisolek muutudatähtsam kui algse plaani järgimine.

Agiilsuse põhimõtted:

1. Kliendi rahulolu väärtusliku tarkvara varajase ja katkematu tarne tõttu;

2. tervitada muudatusi nõuetes ka arenduse lõpus (see võib tõsta saadava toote konkurentsivõimet);

3. töötava tarkvara sage tarnimine (iga kuu või nädala tagant või isegi sagedamini);

4. tihe, igapäevane suhtlus tellija ja arendajate vahel kogu projekti vältel;

5. projekti viivad ellu motiveeritud isikud, kellele on tagatud vajalikud töötingimused, tugi ja usaldus;

7.töötarkvara on parim edusammude mõõt;

8.sponsorid, arendajad ja kasutajad peavad suutma lõputult ühtlast tempot hoida;

9. Pidev tähelepanu tehnilise tipptaseme ja kasutajasõbraliku disaini parandamisele;

10. lihtsus – kunst mitte teha mittevajalikku tööd;

11.parim tehnilised nõuded, disain ja arhitektuur saadakse iseorganiseerunud meeskonnalt;

12.Pidev kohanemine muutuvate oludega.

Agile'i peamised eelised:

• Veebitoodete kvaliteet

Kliendi kaasamine iga iteratsiooni protsessi võimaldab protsessi kohandada, mis parandab alati kvaliteeti.

• Kõrge arengukiirus

Kordamine ei kesta kauem kui 3 nädalat, selle perioodi lõpuks on alati tulemus.

• Riski minimeerimine

Suur projekt võimaldab kliendil tasuda mitme iteratsiooni eest ning töö käigus aru saada, et ta saab õigeaegselt ja taskukohase hinnaga täpselt selle, mida soovib. Kose mudelid (kasutades spetsifikatsioone ja lähteülesandeid) selliseid võimalusi ei paku.

Kliendil on alati võimalus jälgida arenduse kulgu, kohandada projekti funktsionaalsust, testida või käivitada ning igal ajal isegi peatada.