Paindlik arendusmetoodika (inglise keelest - Agile tarkvaraarendus)- manifest, mis määratleb mõtteviisi ja sisaldab põhiväärtusi ja põhimõtteid, millel põhinevad mitmed lähenemisviisid (inglise keelest raamistikud). raamistik- raamistik, struktuur) tarkvaraarendusele (kuigi viimasel ajal on olnud tendents ja katsed rakendada paindlikku arendusmetoodikat ka muudes tegevusvaldkondades, mitte ainult infotehnoloogias), eeldades interaktiivset arendust, perioodilist (dünaamilist) nõuete pakkumist (uuendamist). Tellijalt ja nende elluviimine läbi iseorganiseeruvate töörühmade, mis on moodustatud erineva profiiliga ekspertidest (arendajad, testijad, juurutajad jne). See Agile'i kui "paindliku arendusmetoodika" tõlge ei ole täiesti õige, sest ... Tavaliselt ei nimetata Agile’i 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 paindlikul arendusmetoodikal, näiteks: Scrum, Extreme programming, FDD, DSDM jne.
Definitsioon BPM CBoK vaatepunktist [inglise keelest. - Äriprotsesside juhtimise ühise teadmistekogu juhend]. Agiilne- Üks iteratiivseid ja samm-sammult tarkvaraarenduse metoodikaid, erinevalt traditsioonilisest lineaarsest “juga” metoodikast. Agiilne arendusmetoodika määratleb disaini-, arendus- ja testimismeetodite süsteemi kogu tarkvara elutsükli jooksul. Agiilsed arendusmeetodid (näiteks SCRUM) põhinevad kiirel reageerimisel muutustele, kasutades adaptiivset planeerimist, nõuete ühist väljatöötamist, iseorganiseeruvate funktsionaalsete arendusmeeskondade tõhustamist ja samm-sammult tarkvaraarendust, millel on selge ajaraam. Seda lähenemist kasutatakse paljudes kaasaegsetes kommertstarkvara arendusprojektides.
Paindliku arendusmetoodika aluseks on liberaalne demokraatlik lähenemine meeskondade juhtimisele ja töökorraldusele, mille liikmed on keskendunud konkreetse tarkvara arendamisele.
Tänu sellele, et paindlikku metoodikat kasutav tarkvaraarendus määratleb 2-3 nädala pikkused lühikesed tsüklid (iteratsioonid), on riskid minimeeritud, kuna Iga iteratsiooni lõpus nõustub Klient tulemustega ja väljastab uued või korrigeerivad nõuded, s.t. kontrollib arengut ja saab seda kohe mõjutada. Iga iteratsioon sisaldab planeerimise, nõuete analüüsi, disaini, arenduse, testimise ja dokumenteerimise etappe. Tavaliselt ei piisa täisväärtusliku tarkvaratoote väljaandmiseks ühest iteratsioonist, kuid iga arendusetapi lõpus peaks ilmuma "käegakatsutav" toode või funktsionaalsus, mida saab vaadata, testida ja võtta täiendavaid või parandusmeetmeid. . Tehtud töö põhjal teeb meeskond peale iga etappi tulemused kokku ja kogub kokku uued nõuded, millest lähtuvalt teeb muudatusi tarkvara arendusplaanis.
Agile’i üks põhiidee on näost näkku suhtlemine meeskonnas ja kliendiga, mis võimaldab teha kiireid otsuseid ja minimeerida tarkvaraarenduse riske, mistõttu on meeskond paigutatud ühte kohta, geograafilisest punktist lähtudes. vaatest. Lisaks kuulub meeskonda kliendi esindaja (ingl tooteomanik - kliendi või kliendi enda volitatud esindaja, kes tutvustab tootele esitatavaid nõudeid; seda rolli täidab kliendi projektijuht või ärianalüütik).
Agile Manifesti ajalugu
Agile tarkvaraarenduse manifesti avaldas ja võttis 2001. aasta veebruaris (UTA, The Lodge at Snowbird) vastu ekspertide rühm. See manifest määratleb sellel põhinevate metoodikate jaoks 4 põhiväärtust ja 12 põhimõtet ning annab ka alternatiivse nägemuse tarkvaraarenduse käsitlusest erinevalt suurtest ja tuntud meetoditest ja metoodikatest, kuid ei ole metoodika omaette. Tavaliselt võrreldakse Agile’t eelkõige “kosemeetodiga”, sest Manifesti avaldamise ajal oli tarkvaraarenduse kavandamisel peamine “kose meetod”. 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. Juba manifesti avaldamine andis uue tõuke paindlike metoodikate väljatöötamisele, pani aluse, võiks öelda, et tarkvaraarenduse paindliku käsitluse loomise.
Agiilse tarkvaraarenduse manifest:
Agiilsete meetodite peamine mõõdik on tööprodukt. Otsese suhtluse eelistamisega vähendavad agiilsed meetodid kirjaliku dokumentatsiooni mahtu võrreldes teiste meetoditega.
See on viinud nende meetodite kui distsiplineerimatuse kriitikani.
Avastame pidevalt paremaid tarkvaraarenduse tehnikaid, tehes seda ise ja aidates seda teha ka teistel. Tänu tehtud tööle saime aru, et:
- Inimesed ja suhtlus on olulisemad kui protsessid ja tööriistad
- Töötav toode on olulisem kui põhjalik dokumentatsioon
- Lepingutingimustes kokkuleppimisest olulisem on koostöö kliendiga
- Valmisolek muutuda on olulisem kui esialgsest plaanist kinnipidamine
See tähendab, et eitamata selle tähtsust, mis on parempoolne, väärtustame 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:
- Meie kõrgeim prioriteet on klientide rahulolu väärtusliku tarkvara korrapärase ja varajase tarnimise kaudu.
- Nõuete muutumine on teretulnud, isegi hilises arengujärgus. Agiilsed protsessid võimaldavad kasutada muutusi, et pakkuda kliendile konkurentsieelist.
- Töötav toode tuleks välja anda nii sageli kui võimalik, vahemikus paarist nädalast paari kuuni.
- Arendajad ja ettevõtete esindajad peavad kogu projekti vältel iga päev koostööd tegema.
- Projekti kallal peaksid töötama motiveeritud spetsialistid. Töö tegemiseks looge tingimused, pakkuge tuge ja usaldage neid täielikult.
- Otsesuhtlus on kõige praktilisem ja tõhusam viis infovahetuseks nii meeskonna endaga kui ka meeskonna sees.
- Töötav toode on edusammude peamine näitaja.
- Investorid, arendajad ja kasutajad peaksid saama püsivat rütmi lõputult hoida. Agile aitab sellist säästva arengu protsessi paika panna.
- Pidev tähelepanu tehnilisele tipptasemele ja disaini kvaliteedile suurendab projekti paindlikkust.
- Lihtsus – tarbetu töö minimeerimise kunst – on hädavajalik.
- Parimad nõuded, arhitektuursed ja tehnilised lahendused tulevad iseorganiseeruvatelt meeskondadelt.
- Meeskond peab süstemaatiliselt analüüsima võimalikke viise efektiivsuse tõstmiseks ja kohandama vastavalt oma tööstiili.
Agile kriitika
Agile ei kirjelda hästi nõuete haldamise protsesse, võime öelda, et sellist mõistet lihtsalt ei eksisteeri, sest Agiilne arendusmetoodika ei eelda pikaajalist planeerimist (planeerimine toimub lühiajaliselt), selle tulemusena jääb tootearendusplaani ehk teisisõnu toote teekaardi koostamise samm vahele. Sest planeerimine on lühiajaline (arenduse järgmiseks iteratsiooniks) ning Klient võtab iga iteratsiooni lõpus toote vastu ja esitab uued nõuded, toode ise võib oma juurtes muutuda ning uued seatud nõuded on sageli vastuolus klientidele juba tarnitud toote struktuur ja arhitektuur. Üldiselt, kui Klient ei saa lõpuni aru, mida ta lõpuks näha tahab (lõpptoodet) ja arusaam tuleb arenduse käigus (see juhtub 90% juhtudest), muutub arendusprotsess formaliseeritud ja legaliseeritud bürokraatiaks. , st. toodet viimistletakse lõputult, kuni raha saab otsa või klient läheb teisele tootele üle. Ausalt öeldes tuleb märkida, et Klient teab, millesse ta läheb, ja otsustab ise, kas maksab tootearenduse eest või mitte, arendusmeeskond lihtsalt täidab kliendi nõuded. Tegelikkuses toob see aga töös kaasa kaose, tähtaegade ülejäämise ja kiirustamise, mis toob kaasa uued nõuded, mis muudavad toodet hullemaks. Pealegi langeb väljatöötatud toote kvaliteet, kuna Agile määratleb arenduskäsitluse, mis keskendub tulekahjude kiirele kustutamisele võimalikult lihtsal ja kiiremal viisil. Kood on kirjutatud toote arendamise platvormi nõudeid järgimata, ilmneb palju lahendusi ja defekte ning selline disain pole kuigi stabiilne ega ohutu ning klientide pahameel tarkvara sagedaste tõrgete pärast kasvab. Selle tulemusena kannab äri kahjumit ja planeerimise kvaliteet langeb.
Mõned eksperdid seostavad Agile'i pigem olemasoleva toote täiustamise kui uue väljatöötamisega. Paindliku arendusmetoodika pooldajaid ja ka vastaseid on palju. Viimane avaldas omal ajal isegi Anti Agile'i manifesti. Allpool tutvustame informatiivsel eesmärgil kahe populaarseima manifesti sisu, mis on vastuolus peamise Agile manifestiga:
Anti-Agile manifest (tuleb märkida, et see anti-agile manifest ei ole tegelikult vastuolus Agile'i endaga, vaid pigem ühe raamistikuga, mis põhineb Agile'i põhimõtetel - Scrum, kuna manifest kasutab selle konkreetse raamistiku termineid):
Oleme käinud läbi paljude konsultantide ja veetnud lugematuid tunde agaratel koosolekutel ja koosolekutel. Selle kogemuse põhjal saime aru, et Agile on lihtsalt huulekõne, sest:
- eeposed on lihtsalt projektid
- kasutajate lood on lihtsad kasutusjuhtumeid
- sprindid on lihtsalt töö
- püstijalad on lihtsalt koosolekud
- iteratsioonid on vaid versioonid
- mahajäämused on vaid ülesannete nimekiri
- meeskonna kiirus (kiirus) on vaid tulemused
- ja need ülesanded on reaalsed, lihtsalt ülesanded
Ehkki vasakpoolsed terminid peaksid olema uuenduslikud ja mängu muutvad, on need parempoolsete terminite ebamäärased mõisted.
Agiilsete arendusmetoodikate tüübid
Agile Manifestis määratletud väärtuste ja põhimõtete alusel moodustati järgmised paindlikud arendusmetoodikad:
- Agiilne modelleerimine (AM)- see lähenemine määratleb põhimõtteliselt modelleerimise protseduurid (sh mudeli koodiga kontrollimine) ja dokumentatsiooni tarkvaraarenduse raames. Diagrammide kujundamise ja koostamise protseduure UML-is kirjeldatakse vähemal määral. Samuti ei mõjuta see arenduse, testimise, projektijuhtimise, juurutamise ja hoolduse valdkondi.
- Agile Unified Process (AUP)- RUP (IBM Rational Unified Process) metoodika ühtne versioon, mille koostas Scott Ambler. AUP määratleb mudeli ärirakendustes tarkvara loomiseks.
- Agiilne andmemeetod (ADM)- iteratiivsete agiilsete tarkvaraarendustehnikate kogum, mis rõhutab nõuete ja lahenduste väljatöötamist läbi erinevate funktsionaalsete meeskondade koostöö.
- Dynamic Systems Development Method (DSDM)- iteratiivne ja inkrementaalne lähenemine, mis põhineb kiire rakenduste arendamise (RAD) kontseptsioonil, mis keskendub lõppkasutaja maksimaalsele kaasamisele tarkvaratoote arendamisse.
- Essential Unified Process (EssUP)- Ivar Jacobsoni välja töötatud lähenemine sisaldab iteratiivse tarkvaraarenduse meetodeid, rõhuasetusega tootearhitektuuril ja väljakujunenud 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.
- Ekstreemne programmeerimine (XP)- ekstreemprogrammeerimise mõte on kasutada tarkvaraarenduse vallas olemasolevaid parimaid praktikaid, tõstes need uuele (äärmuslikule) tasemele. Näiteks erinevalt tavapärasest praktikast, kui üks programmeerija kontrollib järjestikku oma kolleegi kirjutatud koodi, siis ekstreemse programmeerimise puhul toimub see kontroll paralleelselt, mis suurendab toote vabastamise kiirust, aga ka riske.
- Funktsioonipõhine arendus (FDD)- Selle lähenemisviisi peamine piirang on "iga funktsioon tuleks rakendada mitte rohkem kui kahe nädala jooksul". Need. Kui saate ühe funktsiooni välja töötada, siis on see 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 suunast, 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-i baasil. Selle meetodi raames määratletakse arenduse elutsükkel (käivitamise faas, selgitamise faas, arenduse ja kliendile üleandmise faas). Tänu kindlale etapiviisile ja kontrollpunktidele suureneb projekti edenemise kontrolli ja monitooringu efektiivsus ning selle tulemusena projekti õigeaegne otsustamine.
- lahja tarkvaraarendus- see lähenemine põhineb tootmisettevõtte säästliku juhtimise kontseptsioonil (lean tootmine, säästlik tootmine).
- Scrum- üks levinumaid lähenemisi paindlikule tarkvaraarendusele, see määratleb reeglid arendusprotsessi juhtimiseks, kasutades olemasolevaid arenduspraktikaid. Rõhk on Kliendi kaasamisel protsessi (võimalus muuta või täpsustada iga etapi järel loodavale tootele esitatavaid nõudeid), mis võimaldab kõrvalekaldeid õigeaegselt tuvastada ja vajalikke muudatusi teha.
Agiilne metoodika on tänapäeval kõigi huulil olev termin, kuid mis on selle taga? Kas see on projektijuhtimise imerohi või asendab see aegunud meetodeid? Kas see on rakendatav mujal kui IT-l? Vastused nendele küsimustele on selles artiklis.
Mis on Agile
Agiilne(inglise keeles: “agile, quick-witted”) - filosoofia, tarkvaraarenduse paindlike lähenemisviiside kogum, mida hakati kasutama projektijuhtimiseks. Agiilne lähenemine eeldab, et toode sünnib iteratsioonide tulemusena, klient arendab nõudeid järk-järgult ning muudatused nõuetes on teretulnud ka arenduse hilises staadiumis. Kliendinõuete täitmise tagavad erinevate valdkondade spetsialistidest koosnevad töörühmad. Agile'i peamised ideed ja põhimõtted on kirjas Agile'i manifestis.
“Agiilne” on üldpõhimõtete kogum, mis on ühised paljudele uutele arendus- ja projektijuhtimismeetoditele, nagu SCRUM, äärmuslik programmeerimine, Kanban ja mitmed teised, vastandina traditsioonilisele bürokraatlikule ja sageli tänapäeva nõuetele mittevastavale lähenemisele. . Kuid lisaks sellele on see ka turundustermin, katusbränd, agiilsete metoodikate edendamise sünergia jaoks.
Tahan rõhutada, et Agile ei ole metoodika, vaid üldpõhimõtted. Vaatamata sellele, et manifestis on kirjas, et Agile on tarkvaraarenduse metoodika, saab paindlikke meetodeid rakendada laiemale ülesannete ringile ning selle põhimõtteid kasutatakse kõikjal, kus on suur ebakindlus lõpptulemuse osas, on arenduse ajastus ja maksumus kriitilise tähtsusega.
Agiilseid meetodeid peetakse tõhusaks väikeste rühmade (kes teevad homogeenset loometööd) töö korraldamisel.
Laadige alla ja kasutage:
11. Parimad nõuded, arhitektuursed ja tehnilised lahendused tulevad iseorganiseeruvatelt meeskondadelt. Nii arvavad manifesti autorid ja allakirjutanud, seetõttu on kõigi paindlike meetodite raames nõuete ja lahenduste väljatöötamine delegeeritud meeskonna tasandile. Tõhusa iseorganiseerumise saavutamine võimaldab ühishuvi ja eesmärkides kokkuleppe olemasolu ning sünergiat nende eesmärkide koos saavutamisel.
12. Analüüs ja kohanemine muutuvate tingimustega, pidev töö efektiivsuse tõstmise võimaluste otsimine. See on sama paindlikkus, mis on kirjas lähenemise nimetuses ja mille poole kõik arendajad peaksid püüdlema Agile metoodika kontseptsiooni raames.
Agiilne SCRUM
SCRUM (loe kui "scrum") on ragbi termin, mida kasutatakse praegu saadaoleva kõige struktureerituima agiilse arendusmetoodika nimetamiseks. Spordis on see meeskondlik ja kõrge intensiivsusega tegevus tulemuse saavutamiseks – palli vastuvõtmine järgnevaks rünnakuks, mis kestab lühikest aega. Selles mängufaasis kasutatakse oma kõrge haigestumuse tõttu meeskonna parimaid ja kõige ettevalmistatumaid mängijaid ning kui selliseid mängijaid mingil põhjusel (näiteks eemaldamise või vigastuse tõttu) ei jätku, on scrum. ei teostata.
Venemaal levib metoodika üha laiemalt. Scrum põhineb nn sprintidel – jäigalt fikseeritud ja lühiajalistel tööde iteratsioonidel, mille käigus on vaja välja töötada ja pakkuda lõppkasutajale töötav toode, millel on võrreldes eelmise sprindiga uued võimalused. Sprindi kestus on rangelt fikseeritud ja määrab arendusprotsessi paindlikkuse ja prognoositavuse, mida lühem on sprint, seda suurem on paindlikkus ja prognoositavus, kuid suureneb iga iteratsiooni suhteline maksumus ning aeg, mis kulub planeerimisele ja koosolekute pidamisele; suureneb ka klient ja meeskonna sees.
Selle paindliku metoodika väga oluline element on toote mahajäämus - toote lõppversiooni tehniliste ja ärinõuete loend, mis on struktureeritud tähtsuse astme järgi, millest võetakse ülesandeid iga järgneva sprindi jaoks projekt viiakse ellu ja täpsustatakse parameetrid.
Järgmiseks sprindiks arendatava toote uus funktsionaalsus määratakse kindlaks planeerimisetapis, misjärel luuakse Sprint Backlog, mis kogu selle kestuse jooksul ei muutu.
Metoodika näeb ette ka rollide struktuuri projektis:
- Scrum-master – vahendaja kliendi ja meeskonna vahel;
- Tooteomanik – Kliendi esindaja, kelle ülesanneteks on Toote mahajäämuse moodustamine ja prioritiseerimine ning sprintide vahetulemuste aktsepteerimine;
- Meeskond on projektimeeskond, milles ei ole eraldi rolle, see on ristfunktsionaalsete motiveeritud professionaalide iseorganiseeruv süsteem.
Miks on rahastajatel Agile'i vaja?
Agilw projektijuhtimise metoodika peamised eelised rahastajate jaoks:
- võimalus säästa raha projekti dokumentatsiooni pikaajalisel väljatöötamisel;
- kõrge kontroll eelarve üle (
Kaasaegses juhtimises käsitletakse “paindlikku” juhtimismudelit kolmes erinevas kontekstis, mis (igaüks omal moel) määratlevad, mis on Agile.
Kolm köidet Agile'i tähendusest
Esimeses, kitsamas tähenduses hakati seda terminit tarkvaraarenduse valdkonnas kasutama 2000. aastate alguses, kui Ameerika Utah' osariigis, mägikuurordis kogunesid tööstuse eksperdid, et arutada meetodeid ja tavasid tarkvaratoodete loomiseks, olid lõpptarbija nõutud. Selle kohtumise tulemuseks oli 12 põhimõttega tarkvaratoodete arendamise Agiilne manifest, mis puudutas eelkõige autorite kitsast tegevusvaldkonda, kuid võiks potentsiaalselt laieneda ka mõnele teisele äriprojektile.
Mõiste teises, laiemas tähenduses rakendatakse agiilseid põhimõtteid peaaegu iga ettevõtte juhtimisel ja neid kasutatakse komponentidena näiteks “lean startupi” (Lean Startup) kontseptsioonis. Agiilse mudeli all mõistetakse selles mõttes paindlikku projektide arendamise metoodikat, mis järgib iseloomulikku skeemi mitmes etapis.
- Projekti kallal töötamine toimub iteratsioonidena - lühikeste tsüklitena (sprint). (Tarkvara arenduse puhul on nende tsüklite kestus 1 nädal kuni 1 kuu).
- Iga tsükli lõpus lastakse välja toode, mida saab juba äritegevuses kasutada. Tarkvara puhul võib selliseks tooteks olla rakendus või ainult osa sellest, kuid ka “toores” tarkvara saab ja peaks proovima tegevuses.
- Toodet testivad klient või kasutajad, kes annavad arendajatele pidevat tagasisidet. Kliendile orienteeritud lähenemist rakendatakse kogu projekti vältel (kõik iteratsioonid).
- Kõik kommentaarid lisatakse redaktsiooni kiiresti ja muudatused, mis võimaldavad meil toote arengut koheselt parandada, on teretulnud, kuna see võimaldab meil vältida globaalsete süsteemivigade kuhjumist.
Kolmandas, veelgi laiemas tähenduses, on Agile osa Toyota tehastes kasutatavast juhtimismudelist ja on nüüd peaaegu iga eduka tootmise juhtimise üks põhikomponente. Agile'i põhialused on selles kontekstis sarnased tehnoloogia mõistmise põhialustega muudes kontekstides.
Kiiret tagasisidet Toyota tehaste lõpliku tootmisformaadi seadistamisel andsid kõik töötajad, kellest võis saada konveieri peatamise algataja ja tootmistsükli peenhäälestuse seadistuste autor. Tootmismastaabis võib agiilne ümberkujundamine hõlmata tootmistegevuse kui terviku ümbertöötlemist, kui toode muutub klientide hetkevajadustele reageerimise tulemuseks. Seega, kui tehas tootis plastmassist kraanikausid ja kliendi tagasiside näitab ämbrite vajadust, siis kiire kohanemine koos nüansside (käepideme kuju, suurus, värvus) paralleelse reguleerimisega on täpselt Agile juhtimisstiilis (kui järgitakse muid põhimõtteid). ).
Agiilse juhtimise põhimõtted
Agiilset projektijuhtimist kui äriprotsesside juhtimismudelit kasutavad tuhanded meeskonnad üle maailma ning selle lähenemisviisi järgmised eripärad on kõikjal olemas:
- Tarbija ja tema kaasatuse määr tulemuse loomisesse on toote kohandamisel kriitilise tähtsusega.
- Otsuse tegemiseks peavad meeskonnad olema väga tõhusad ja ühtsed.
- Protsessi aluseks saab samm-sammult ja tsükliline töö. Projekt on jagatud väikesteks osadeks, mis valmivad teatud kuupäevaks enne projekti kui terviku valmimist.
- Tulemuslikkuse hindamise fookuses on vaheprojekti olekute sagedased esitlused.
- Oma töös tugineb meeskond Pareto seadusele, mille kohaselt 20% pingutustest annab 80% efektiivsusest, mis võimaldab mitte viia iga üksikut tsüklit täiuslikkuseni enne tulemuse tarbijale esitamist. Toode paraneb loomulikult iga uue iteratsiooniga.
- Eeldatakse, et üks etapp tuleb läbida, enne kui järgmisse liigutakse.
“Paindlik” lähenemine on saanud aluseks mitmetele üksteisest erinevale, kuid Agile’i ideid sisaldavatele metoodilistele praktikatele: Scrum, Kanban, Lean, Crystal jne. Näiteks Scrumi metoodikat käsitletakse peaaegu alati koos Agile'iga kui ühtse tarkvaraarenduse projektijuhtimissüsteemiga.
Scrumi meetod näitab, kuidas "agiilset lähenemist" saab konkreetsetes operatsioonides praktikas rakendada. Näiteks projektinõuetega töötamist rakendatakse nelja "artefakti" abil:
- Toote mahajäämus hõlmab nõuete loendi loomist, mis luuakse ühe malli (kasutaja lugu) abil ja sorteeritakse prioriteedi järgi. Kui nõudeid pole, projekt lõpeb.
- Sprindi mahajäämus on lähima sprindi (etapi) nõuded, mis on jagatud ülesanneteks ilma võimaluseta sprindi käigus uusi nõudeid lisada. Järgmise etapi kohustused, mille võtab Agile juhtimistüübiga meeskond, on kirjutatud tahvlile (nn Kanban).
- Sprint Goal – sprindi üldeesmärk – juhend alternatiivsete otsuste tegemiseks.
- Sprint Burndown Chart - "põlemisdiagramm". See näitab, kui kaugele on meeskond etapi jooksul arenenud.
Agile projektijuhtimise formaat ei sobi kõigile ja mitte alati. Valitsusstruktuurid, mille tegevus põhineb muutumatul seadusandlusel ning on oma eesmärkidelt ja elluviimiselt konservatiivsed, sellist optimeerimist ei vaja.
Tüüpilised vead Agile'i rakendamisel ja lähenemisviisi puudused
Sama tegur, mida mõnel juhul peetakse lähenemisviisi tugevuseks, võib mõnel juhul põhjustada probleeme. Seega muutub "paindlikkus" sageli fookuse hägustumise põhjuseks. Metoodilise baasi puudumisel kaob juhised ja esmane asendamine sekundaarsega. Selliste "moonutuste" vältimiseks kasutavad nad valmis metoodikat või oma arendusi, mis reguleerivad projekti elluviimise ajal rangemalt toimingute sisu ja järjekorda. Kuid sel juhul on Agile-halduses võimalikud vead.
Levinud juurutamisvead on järgmised.
Vaatamata kõigile paindliku lähenemise rakendamise raskustele, on see uue kliendile orienteeritud toote kiirel loomisel üldiselt tõhusam kui traditsiooniline "aeglane" tootmine. Kui traditsiooniline tootmine on takerdunud bürokraatlikesse viivitustesse, siis Agile lähenemine tagab loomuliku liikumise kohe pärast projekti käivitamist.
Agile on paindlik lähenemine arendusele, mis hõlmab erinevaid metoodikaid (Scrum, Kanban, XP, Lean jt). Paljud inimesed teavad sellest. Kuid on kümneid pisiasju ja igasuguseid huvitavaid asju, mis ei jää pinnale.
Oleme koostanud artiklite sarja nii algajatele, kes on veel paindlike metoodikatega kursis, kui ka neile, kes on nendega pikka aega sõbrad. Räägime Agile'i ja Scrumi põhikontseptsioonidest (lühidalt) ja ootamatutest rakendustest igapäevaelus. Tänane artikkel on nagu sissejuhatav loeng: sellest, mis on Agile ja millega see kaasneb.
Projektide suur pauk
Kui tõmmata paralleel Universumi sünniga - määrame selle rolli Agile'ile -, siis Suurest Paugust saab probleem number üks, mis on ajanud närvivapustuseni üle saja projektijuhi - tootenõuete muutumine. Just see on ka hädaldamise ja ahastavate hüüde "Milleks mulle seda karistust vaja on" põhjus? ja hõrenevad juuksed.
Tavaliselt töötavad protsessid kaskaadmudeli (või kosemudeli) raames – kõik toimub etappide kaupa ja järjestikku. Lihtsamalt öeldes: "Ma näen eesmärki - ma lähen eesmärgi poole." Ja kui ühel hetkel muutuvad nõuded tootele, lõppeesmärk, tuleb vahel uuesti teha. Niipea, kui täiuslikult lihvitud plaan reaalsusega kokku põrkub, variseb see kohe tolmuks. Kuid selle asemel, et nii plaan kui ka selle lähenemine prügikasti visata, teesklevad juhid, et plaan töötab, ja palkavad isegi spetsialiste seda tegema. Põhimõtteliselt maksavad nad inimestele selle eest, et nad neile valetaksid.
Scrumi looja Jeff Sutherlandi sõnul meenutab see 1980. aastate lõpu NLKP Keskkomitee poliitbüroo käitumist, kes väidetavalt uskus Nõukogude Liidu lagunemise eelõhtul saadud teateid.
Agiilsed meetodid on nende paindlikkuse tõttu loodud selle vastu võitlemiseks. Võime öelda, et Agile on mitme lähenemisviisi segu, mille eesmärk on minimeerida kõikvõimalikke riske, kasutades mitmeid põhimõtteid. Need samad põhimõtted ja 4 peamist ideed on koondatud 2001. aasta Agile Manifesti.
Agiilne manifest
Kui lihtsustada keelt, et "kristalliseerida" kaalutlused, mis juhivad kõiki agiilselt töötavaid, saame midagi sellist:
- Kõige tähtsamad on inimesed, mitte asjad
- Dokumentatsioon (mida keegi veel ei loe) ei tohiks kellegi tööd segada
- Lepingu uuesti lugemise asemel tehke koostööd
- Ela, hinga, muutu – nii kiiresti kui võimalik
Kuidas protsessid toimivad
Vaatame, kuidas saate Agile'i järgi töötada. Võtame näiteks Scrumi – täna on see kõige populaarsem paindlik metoodika. Scrumi autor Jeff Sutherland leiutas selle tehnika klassikalise projektijuhtimise puuduste ületamiseks.
1. Valige toote omanik- see on inimene, kes näeb, millise eesmärgi poole sa lähed ja mida lõpuks saada tahad.
2. Otsustage meeskonna üle- 3 kuni 10 inimest, kellel on oskused, mis võimaldavad teil saavutada tulemusi (st töötav toode).
3. Valige Scrum Master- see inimene jälgib projekti kulgu ja aitab meeskonnal raskustega toime tulla.
4. Looge toodete mahajäämus- koguge ühte kohta (soovitavalt Agile'i tahvlile) kõik tootele esitatavad nõuded ja seadke prioriteediks. Tooteomanik peab kõik soovid läbi mõtlema ja kokku koguma. Seejärel peab meeskond hindama mahajäämust, et näha, kas see kõik saab tehtud ja kui kaua see aega võtab.
Selline näeb välja agiilne tahvel Yandexis - .
5. Planeerige oma sprintid- ajaperioodid (nädal või kaks), mille jooksul meeskond täidab teatud ülesandeid. Sprindid on regulaarsed: näiteks 15 korda kahe nädala jooksul kuni valmistoote saamiseni.
6. Pidage igapäevaseid koosolekuid 15 minutit (ja mitte minutitki rohkem)- päevakorras on kolm küsimust, millele kõik lühidalt vastavad: mida ma eile tegin, mida täna teen ja millised takistused ei lase mul "kõrgusi võtta".
7. Tehke arvustusi- sprindi lõpus räägib meeskond, millega nad hakkama said, ja demonstreerib toote töötavaid osi. Ülevaatustel võivad osaleda kõik: tooteomanik, põhiklient või isegi potentsiaalsed kliendid.
8. Tehke tagasivaade- pärast iga sprinti arutab Agile meeskond probleeme ja otsib lahendusi. Peaks olema muudatuste plaan, mille meeskond kohe ellu viib – järgmisel sprindil.
Lisateavet Scrumi rakendamise ja meeskonna tõhususe suurendamise kohta leiate sellest artiklist.
Scrum on midagi enamat kui meeskonnatöö meetod. Scrum kiirendab kõigi inimlike ettevõtmiste tempot. Olenemata projektist või probleemist saab Scrumit kasutada mis tahes ettevõtmises, et tõsta tootlikkust ja saavutada paremaid tulemusi.
Agile tunneb nägemise järgi
Agiilsed meetodid on hõlpsasti tuvastatavad põhiomaduste, näiteks "signaalilippide" järgi.
- Riskide minimeerimine on iga agiilse lähenemise peamine eesmärk.
- Iteratiivne arendus – lühikeste tsüklitena töötamine.
- Inimesed ja suhtlemine on kõige tähtsamad.
Kui vaadata Agile’i mõlemalt poolt jõge – nii kliendilt kui meeskonnalt –, on see lähenemine mõttekas kõigile.
- Kliendil on vaja õigeaegselt kätte saada vähemalt minimaalselt funktsionaalne toode (pole vahet, kas räägime tarkvarast või muudest protsessidest ja nähtustest), muutma tingimusi, ilma, et tal sõõrikuauk taskusse jääks - see on juba riskikindlustuse küsimus.
- Meeskonnale tuleb kasuks suhtlemine kliendi ja kolleegidega (et ilma selleta: "Sa said minust valesti aru - tee kõik kiiresti uuesti. Ja jah, seda on eile vaja!"), protsesside läbipaistvus, mis vähendab ootamatuste tõenäosust, ja kiire lahendus probleemidest. Noh, paljud saavad aru, kuhu aeg läheb ja kus töö takerdub. See on väike asi (mitte tegelikult), kuid see on tore.
Lisaks paraneb meeskonnasisene suhtlus kvalitatiivselt. Kõik keskenduvad ühisele ideele, üksteise ees pole saladusi, kõik annavad lubaduse (sotsiaalsed kohustused - kus ilma). Kirsiks tordil on oskus töötada mugavas tempos, kuigi kiiresti (vähemalt kiiremini kui tavaliselt).
Agiilne toob korra kaosest. Tehti uuringud: selgus, et projektid, kus töötati paindliku lähenemise raames, olid 3 korda edukamad kui need, kus protsessid olid üles ehitatud standardparadigmas. Ja see tundub üsna loogiline: klient saab, mida ta tahab, ja minimaalse aja- ja ressursikuluga.
Kellele see ei meeldiks?
Alates selle loomisest on Scrumi kontseptsioon moodustanud aluse tehnoloogiatööstusele mõeldud uute tarkvaratoodete kujundamisel. Olles aga Silicon Valleys tarkvara ja uue riistvara loomise projektijuhtide seas tunnustust ja edu saavutanud, jääb Scrum üldises äripraktikas vähetuntud metoodikaks.
See on tänaseks kõik. Järgmisel korral räägime Scrum of Scrumsist ja sellest, kuidas paindlikud metoodikad Venemaa reaalsuses töötavad. Ära vaheta.
P.S.Kas soovite saada igal nädalal kasulikke näpunäiteid kõige huvitavamatest äri- ja turundusteemalistest raamatutest, õppida tundma uusi tooteid ja saada allahindlusi? Liituge meie uudiskirjaga. Esimene kiri sisaldab kingitust.
- Tõlge
"Iga äri võtab alati oodatust kauem aega, isegi kui võtame arvesse Hofstadteri seadust."
- Hofstadteri seadus
YouTube'i vaadatuim video agiilsuse teemal. 744 625 vaatamist selle artikli avaldamise ajal. Lihtne esitlusstiil, pildid ja ainult 15 minutit – parim, mida olen näinud. TED teeb pausi.
Rollid
See on Pat toote omanik. Ta ei tea tehnilisi üksikasju, kuid tal on nägemus suurest pildist, ta teab Milleks me valmistame toodet, milliseid probleeme see lahendab ja kelle jaoks.
See huvitatud inimesed. Nad kasutavad toodet, toetavad seda või osalevad muul viisil arendustegevuses.
See kasutajate lood. Nad väljendavad huvitatud isikute soove. Näiteks "lennufirma broneerimissüsteemis peaks kasutajal olema võimalik otsida lennu järgi."
Sidusrühmadel on palju ideid ja Pat aitab muuta ideed kasutajalugudeks.
See arendusmeeskond. Need, kes tahavad ehitada töötav süsteem.
Ribalaius
Kuna käsk kasutab paindlik arendusmetoodika, nad ei kogu neid lugusid enne suurt väljalaskmist, vastupidi, avaldavad need kohe ja nii tihti kui võimalik. Tavaliselt avaldavad nad nädalas 4–6 kasutajalugu. See on nende oma läbilaskevõime. Seda on väga lihtne mõõta – kasutajalugude arv 7 päeva jooksul.
Et seda rütmi säilitada ja mitte takerduda käsitsi regressioonitestidesse, teeb meeskond kõvasti tööd automaatne testimine ja pidev integratsioon. Seetõttu peate iga funktsiooni jaoks kirjutama automaattestid ja enamikul koodist on sisseehitatud automaattestid.
Probleem on selles, et huvilisi on palju ja nende soove ei saa rahuldada 4-6 looga nädalas.
Iga kord, kui me kasutajalugu rakendame, tulevad nad välja veel mõne ideega, mis toob kaasa veelgi rohkemate taotluste arvu.
Mis juhtub, kui teeme kõike, mida nad meilt paluvad? Oleme ülekoormatud.
Oletame, et meeskond kohustub sel nädalal tegema 10 uut lugu Kui sisend on 10 ja väljund on 4-6, siis on meeskond ülekoormatud. Ta tormab, lülitub tööülesannete vahel, kaotab motivatsiooni ning selle tulemusena väheneb tootlikkus ja kvaliteet. See on ilmselgelt kaotaja strateegia.
Scrum ja XP kasutavad sel juhul "eilse ilma" meetodit. Meeskond ütleb: "Viimasel ajal oleme teinud 4-6 funktsiooni nädalas, milliseid 4-6 funktsiooni me järgmisel nädalal teeme?"
Tooteomaniku ülesanne on targalt valida, millised kasutajalood sel nädalal kasutusele võetakse.
Kanban soovitab piirduda mõne ülesandega – WIP limiit. Oletame, et meeskond otsustab, et 5 on vastuvõetav arv kasutajalugusid, millega nad saavad üheaegselt töötada ilma ülekoormuseta, ilma ühelt teisele hüppamata.
Mõlemad lähenemisviisid töötavad hästi ja mõlemad loovad ülesannete järjekorra, mida Scrumis nimetatakse backlogiks või prioriteetsete ülesannete loendiks.
Seda järjekorda tuleb ka hallata, kui huvirühmad soovivad 10 lugu nädalas ja meeskond rakendab 4-6 lugu, siis see järjekord muutub järjest suuremaks. Ja peagi planeeritakse teie mahajäämus kuus kuud ette. See tähendab, et üks lugu ootab ilmumist 6 kuud.
Ülesandenimekirja kontrolli all hoidmiseks on ainult üks viis – sõna "ei"
See on tooteomaniku jaoks kõige olulisem sõna. Ta peab seda iga päev peegli ees harjutama.
"Jah" ütlemine on lihtne. Kuid olulisem ülesanne on otsustada, mida mitte teha ja selle eest vastutama. Tooteomanik määrab ka järjestuse, mida me praegu teeme ja mida hiljem. See on keeruline töö ja seda tuleks teha koos arendusmeeskonna ja vähemalt ühe sidusrühmaga.
Õigesti prioritiseerimiseks peab tooteomanik mõistma iga loo väärtust ja selle ulatust.
Otsuste tegemine
Mõned lood on tingimata vajalikud ja mõned on lihtsalt lisafunktsioonid. Mõne loo arendamiseks kulub paar tundi, teistel aga kuud.Milline on seos loo suuruse ja väärtuse vahel? Pole võimalik. Rohkem ei tähenda paremat. Ülesande väärtus ja keerukus on see, mis aitab Patil prioriteete seada.
Kuidas määrab tooteomanik loo väärtuse ja ulatuse? Pole võimalik. See on äraarvamismäng. Ja parem on kõigil selles osaleda. Pat suhtleb pidevalt huvirühmadega, et teada saada iga loo väärtust, suhtleb arendusmeeskonnaga, et teada saada töö ulatust, kuid need on kõik umbkaudsed oletused, täpseid numbreid pole. Alguses tuleb alati vigu ja see on normaalne. Suhtlemine on palju väärtuslikum kui ülitäpsed numbrid.
Iga kord, kui arendajad annavad välja midagi uut, saame rohkem teavet ja saame paremini navigeerida.
Ainuüksi prioriteetide seadmisest ei piisa. Lugude kiireks ja sagedaseks avaldamiseks tuleb need jagada tükkideks, mida saab teha paari päevaga. Tahame väikseid ja selgeid lugusid lehtri alguses ning suuri ja ebamääraseid lugusid lõppu. Kui teeme selle jaotuse õigeaegselt, saame ära kasutada oma viimaseid avastusi toote ja kasutajate vajaduste kohta. Seda kõike nimetatakse mahajäämuse puhastamiseks.
Pat korraldab igal kolmapäeval kell 11.00–12.00 Backlogi puhastuskoosolekut. Tavaliselt toob see kokku kogu meeskonna ja mõnikord ka mitu sidusrühma. Koosolekute sisu on erinev. Keskenduge hindamisele, lugude jaotusele, aktsepteerimiskriteeriumidele.
IT-toote omanik peab pidevalt kõigiga suhtlema
Kogenud tooteomanikud tuvastavad kaks edu komponenti: kirg töö vastu ja suhtlemine. Milliseid probleeme tooteomanik koos meeskonnaga lahendab?Arenduste keerukuse ja kasutaja loo väärtuse tasakaalustamine
Varasel etapil ähvardab bilanssi ebakindlus ja mitu riski korraga.
Riskid
Äririsk: "Kas me teeme õigesti?"Sotsiaalne risk: "Kas me saame teha seda, mida peame tegema?"
Tehniline risk: "Kas projekt töötab sellel platvormil?"
Riskid kulude ja rakendusajaga: "Kas jõuame õigeks ajaks ja kas raha on piisavalt?"
Teadmisi võib pidada riski vastandiks. Kui ebakindlus on suur, keskendume teadmiste omandamisele – liidese prototüübid, tehnilised katsed,
Kompromiss teadmiste väärtuste ja kliendi väärtuste vahel
Kliendi vaatenurgast näeb kõver välja järgmine:
Kliendi väärtuse vaatenurgast näeb kõver välja selline. Kuna ebakindlus väheneb, saame keskenduda kliendi väärtusele. Me teame, mida ja kuidas teha. Jääb üle vaid teha. Pärast põhilugude juurutamist loome lisafunktsioone või käivitame uue projekti.
Kompromiss lühi- ja pikaajalise mõtlemise vahel
Mida kõigepealt rakendada? Parandage kiiresti vead või alustage uimastava funktsiooni väljatöötamist, mis hämmastab kasutajaid. Või tehke keeruline platvormi uuendamine, mis kiirendab tööd tulevikus. Pidevalt on vaja leida tasakaal reaktiivse ja proaktiivse töö vahel.
Kas teha õigeid asju, teha asju õigesti või teha asju kiiresti?
Ideaalis kõik kolm korraga, aga tegelikult tuleb valida.
Oletame, et oleme kohal. Püüame täiusliku arhitektuuri abil luua täiuslikku toodet. Kui kulutame palju aega, võime turundusaknast ilma jääda ja lõppeda rahaprobleemidega.
Valmistame tootest kiire prototüübi. Lühiajaliselt pole see halb. Pikas perspektiivis saame tehnilise riski. Ja arenduskiirus langeb nulli.
Oleme siin ja loome rekordajaga kauni templi. Kuid kasutajal polnud vaja templit, vaid matkaautot.
Scrumi rollide vahel valitseb eluterve pinge
Tooteomanik keskendub õigete asjade loomisele. Meeskond keskendub asjade õigele ehitamisele. Scrum Master või Agile Coach keskendub tagasisideahela lühendamisele.
Rõhutada tasub ka kiiruse tähtsust, kuna lühike tagasisideahel kiirendab õppimist. See võimaldab meil kiiresti teada saada, millised asjad on õiged ja kuidas neid õigesti ehitada.
Kompromiss uue toote väljatöötamise ja vana täiustamise vahel
Toodet ei saa kunagi täielikult valmis saada, sest see vajab pidevalt muudatusi. Kui meeskond hakkab töötama uue tootega, mis juhtub vanaga? Toote üleviimine ühelt meeskonnalt teisele on väga kulukas ja riskantne. Tavaliselt hooldab meeskond vana toodet, töötades samal ajal uut. Seetõttu viitab "tagasilogi" mõiste pigem mitte tootele, vaid meeskonnale. Mahajääk on nimekiri asjadest, mida tooteomanik meeskonnalt soovib. Ja lugude komplekt erinevate toodete kohta. Tooteomanik peab juurutamiseks pidevalt asjakohaseid valima.
Loo hävitamise ajakava
Aeg-ajalt küsivad sidusrühmad Patilt: "Millal mu funktsioon avaldatakse?" või "Kui palju funktsioone jõuludeks välja antakse?" Tooteomanik peab suutma hallata kasutaja ootusi. Ja juhtige ootusi realistlikult.
Kaks suundumust – optimistlik ja pessimistlik (neid on silmaga näha). Trendide vaheline kaugus näitab, kui ebastabiilne on meeskonna kiirus. Aja jooksul need suundumused stabiliseeruvad ja ebakindluse koonus väheneb.
Oletame, et huviline küsib, millal see funktsioon tehakse?
See on fikseeritud sisu ja tähtajatu küsimus. Pat kasutab vastamiseks kahte trendijoont. Vastus on aprillis või mais.
Huviline küsib Patilt: "Kui palju jõuludeks tehtud saab?" See on fikseeritud tähtaja ja ebamäärase sisuga küsimus. Trendijooned lõikavad vertikaalsel skaalal ära tõenäolise segmendi sellest, mida neil on aega rakendada.
Huviline küsib: "Kas meil on aega need funktsioonid jõuludeks valmis saada?" See on kindla ajaraamiga ja kindla sisuga küsimus. Trendidele keskendudes vastab Pat: "Ei." Lisades: "Jõuludeks on meil aega nii palju ära teha, kuid nii kaua kulub meil kogu selle töö täielikuks lõpuleviimiseks."
Tavaliselt on parem projekti sisu vähendada kui aega pikendada. Kui sisu vähendame, on meil võimalus tähtaega edasi lükata. Võib-olla vabastame mõned siin ja ülejäänud hiljem.
Tooteomanik teeb arvutusi iganädalaselt ja kasutab soovmõtlemise asemel ainult empiirilisi andmeid. Ta räägib ausalt ebakindlusest. Meeskond hoiab töötempot ja Pat ei survesta neid kiirendama.
Laadimine...
