Agiilsed juhtimismeetodid. Agiilne. Kuidas ja millal seda meetodit kasutada. Agiilsed metoodikad versus traditsiooniline projektijuhtimine

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 projektiarenduse metoodikat, mis järgib iseloomulikku skeemi mitmes etapis.

1. Töö projektiga toimub iteratsioonidena - lühikeste tsüklitena (sprint). (Tarkvara arenduse puhul on nende tsüklite kestus 1 nädal kuni 1 kuu).
2. Iga tsükli lõpus lastakse välja toode, mida saab juba ettevõtluses kasutada. Tarkvara puhul võib selliseks tooteks olla rakendus või ainult osa sellest, kuid ka “toores” tarkvara saab ja peaks proovima tegevuses.
3. Toodet testivad klient või kasutajad, kes annavad arendajatele pidevat tagasisidet. Kliendikeskset lähenemist rakendatakse kogu projekti vältel (kõik iteratsioonid).
4. 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 tehases toodetakse 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 kõikjal on olemas järgmine: eristavad tunnused see lähenemine:

1. Tarbija ja tema kaasatuse määr tulemuse loomisesse on toote kohandamisel kriitilise tähtsusega.
2. Otsuse tegemiseks peavad meeskonnad olema väga tõhusad ja ühtsed.
3. 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.
4. Tulemuslikkuse hindamise fookuses on projekti vaheseisundite sagedased esitlused.
5. 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.
6. 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 genereerimist, mis luuakse ühe malli (kasutaja lugu) järgi 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 arvestatakse tugev külg teistel juhtudel võib see probleeme tekitada. 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.

Kas olete kunagi projektide kallal töötanud või vähemalt projektitöös osalenud? Kui jah, siis olete ilmselt märganud, et meeskonna tööle panemine võib olla üsna keeruline. Ja isegi kui see on kindlaks tehtud, on oht, et kõik jõupingutused on asjatud, sest soovitud tulemuse nõuded muutuvad sageli.

Siiski saate projektiga töötamist oluliselt lihtsustada ja õppida seda juhtima, suurendades seeläbi meeskonna efektiivsust, kasutades paindlikku projektijuhtimissüsteemi nimega Agile ("Agile" või "Agile"). Üldiselt rääkisime sellest juba põgusalt oma (neljas õppetükis), kuid nüüd räägime sellest teemast üksikasjalikumalt.

Agiilne meetod: määratlus ja lühiajalugu

Ükskõik kui ebaharilikult see ka ei kõlaks, algas tõsine tarkvaraarendus ja projektijuhtimine juba eelmise sajandi 70ndatel. 1970. aastal koostas Ameerika arvutiteadlane Winston Royce dokumendi "Suurte tarkvarasüsteemide arendamise juhtimine". Selles kritiseeris ta järjestikust arendust, viidates sellele, et tarkvaraarendus ei tohiks olla nagu töötamine koosteliinil (nagu seda tehakse näiteks autotootmises), kus järjestikuste etappide kaupa lisatakse uusi osi.

Selle asemel, et oodata iga etapi (faasi) ükshaaval läbimist, soovitas Royce kasutada faasilist lähenemist. Selle olemus seisneb selles, et algselt kogutakse kokku kõik projekti jaoks vajalikud nõuded, misjärel valmib kogu arhitektuur, luuakse disain, kirjutatakse kood jne.

Sellest lähtuvalt õnnestus 90ndatel luua paindlike tarkvaraarendusmeetodite komplekt, mis võiks asendada keerukaid ja aeganõudvaid meetodeid. See juhtus nii:

• 1991. aastal võeti kasutusele RAD-i kiirrakenduste arendamise meetod.
• 1994. aastal ilmus arendusmeetod dünaamilised süsteemid DSDM
• 1995. aastal ilmus paindliku arenduse jaoks mõeldud Scrumi platvorm (raamistik).
• 1996. aastal ilmus agiilne arendusmetoodika Crystal Clear, samuti XP Extreme Programming
• 1997. aastal ilmus iteratiivne tarkvaraarenduse metoodika FDD

Üheskoos on need meetodid ühendatud paindlike tarkvaraarendusmeetodite üldnimetuse alla.

Neli aastat hiljem, 2001. aastal, kogunes seitseteist tarkvaraarendajat Snowbirdi kuurorti Utahis (USA). Arendusmeetodite arutelu tulemusena ilmus “Agiilse tarkvaraarenduse manifest” (inglise keelest tõlgituna tähendab mõiste “giilne” “agiilne”, “agiilne” või “kiire”, kuid enamasti tõlgitakse kui "paindlik"). Ta määras kogu edasise tarkvara loomise töö tempo.

Agiilne manifest

Programmeerijate loodud manifest sisaldab 4 põhiideed ja 12 tõhusa projektijuhtimise põhimõtet. Kõik Agile-põhised projektijuhtimissüsteemid (süsteemidest räägime hiljem) põhinevad just neil ideedel ja põhimõtetel, kuigi kasutab neid erinevates variatsioonides.

1. Inimesed ja nende suhtlus on olulisemad kui protsessid ja tööriistad
2. Töötav tarkvara on olulisem kui dokumentatsioon
3. Kliendid ja koostöö nendega on olulisemad kui leping ja tingimuste läbirääkimised
4. Valmisolek muutusteks on olulisem kui algne plaan

Agiilsuse põhimõtted:

1. Rahuldage kliente, tarnides tarkvara varakult ja järjepidevalt (kliendid on rahul, kui töötav tarkvara saabub korrapäraste ajavahemike järel)
2. Muutke lõpptootele esitatavaid nõudeid kogu selle arendustsükli jooksul
3. Tarnige töötavat tarkvara nii sageli kui võimalik (kord nädalas, iga kahe nädala tagant, kuus jne)
4. Toetage arendajate ja klientide vahelist koostööd kogu arendustsükli jooksul
5. Toetada ja motiveerida kõiki projektis osalejaid (kui ta tuleb oma ülesannetega palju paremini toime kui meeskond, kelle liikmed pole töötingimustega rahul)
6. Pakkuge arendajate vahel otsest suhtlust (otsekontakti võimalus aitab kaasa edukamale suhtlusele)
7. Mõõtke edusamme ainult töötava tarkvara kaudu (kliendid peaksid saama ainult funktsionaalset ja töötavat tarkvara)
8. Säilitada pidev töötempo (meeskond peab arendama optimaalset ja säilitatavat töökiirust)
9. Pöörake tähelepanu disainile ja tehnilistele detailidele (tänu tõhusatele oskustele ja heale disainile on projektimeeskonnal võimalik toodet pidevalt täiustada ja selle täiustamise nimel tööd teha)
10. Proovige muuta töövoog võimalikult lihtsaks ning tarkvara lihtsaks ja arusaadavaks
11. Võimaldab meeskonnaliikmeid (kui arendajad saavad ise otsuseid teha, end organiseerida ja teiste meeskonnaliikmetega suhelda, nendega mõtteid vahetades, suureneb kvaliteetse toote loomise tõenäosus oluliselt)
12. Pidevalt kohaneda muutuva keskkonnaga (tänu sellele on valmistoode konkurentsivõimelisem)

Agile’i õppides vaata lisaks ideede ja reeglite ülevaatele kindlasti ka seda lühikest videot, kus projektijuhtimise spetsialist, konsultant ja äritreener Aleksei Tatšenkov räägib süsteemi põhitõdedest.

Ülaltoodud ideede ja põhimõtete tegelikuks rakendamiseks peate järgima mitmeid reegleid. Ainult sel juhul saab agiilne projektijuhtimine olla tõhus.

Põhipunktid Agile'i kasutamisel

Agiilne metoodika põhineb eelkõige visuaalsel juhtimisel. Kõige sagedamini kasutavad projektis osalejad tulemuste saavutamiseks töötades spetsiaalseid värvilisi kaarte. Üks värv annab märku mõne lõpptoote elemendi planeerimise lõpetamisest, teine ​​selle väljatöötamise lõpetamisest, kolmas valmisolekust jne. Visuaalne kontroll võimaldab meeskonnal omada selget pilti protsessi hetkeseisust ja tagab, et kõigil meeskonnaliikmetel on projektist sama nägemus.

Meeskonnaliikmed ja klient töötavad enamasti koos ja kõrvuti. Tänu sellele kiirenevad oluliselt paljud tööprotsessid, mis on seotud projektis osalejate teavitamisega. Lisaks aitab koos töötamine luua tervisliku õhkkonna viljakaks ja tulemuslikuks koostööks ning kiireks tulemuste saavutamiseks.

Kui projektijuht, meeskond ja klient teevad koostööd, ei teki ohtu eesmärkidest arusaamatuks ja info kadumiseks. Kõik tööprotsessid muutuvad võimalikult läbipaistvaks, mis tähendab, et kõik tekkivad probleemid on peaaegu hetkega lahendatavad ning nende lahendamiseks leitakse parimad võimalused.

Erilist tähelepanu tuleks pöörata projektijuhile. Teda ei saa nimetada inimeseks, kes annab juhiseid vasakule ja paremale. Juht käitub siin pigem juhina, kes määrab suuna ning määrab koostöö ja töö reeglid. Teisisõnu, agiilne juhtimine on kohandatav.

Teine oluline punkt Agile metoodikas on kogu projekti ulatuse jagamine mitmeks väiksemaks komponendiks. Selline lähenemine lihtsustab oluliselt arendusprotsessi ja meeskonna eraldi rühmad saavad igaüks keskenduda oma konkreetsele ülesandele.

Ühe tsükliga töötades omandavad projektis osalejad uusi oskusi ja omandavad uusi teadmisi ning analüüsivad ka selle käigus tehtud vigu. Kõik see vähendab tulevikus sarnaste vigade tegemise tõenäosust (järgmistes tsüklites ja muudes projektides) peaaegu nullini.

Ja lõpuks, lähenemisviisi viimane oluline element on sprindid ja igapäevased kohtumised. Sprintid on kindlate tähtaegadega piiratud ajaperioodid, mille jooksul meeskond suudab teatud ülesandeid täita. Tänu sprindidele näeb meeskond oma tegevuse tulemusi.

Kui jagame kogu projektile eraldatud aja mitmeks sprindiks, saame neist kindla arvu; olgu neid 15 Iga sprint kestab näiteks kaks nädalat. Just nende kahe nädala jooksul (sprintiks määratud aeg) kohtuvad osalejad iga päev, et protsessi ja edusamme arutada.

Igapäevased koosolekud ei tohiks ületada 15 minutit. Need on korraldatud nii, et iga meeskonnaliige annab ise vastuse kolmele küsimusele:

• Mida ma eile tegin?
• Mida ma täna teen?
• Mis takistab mind töötamast?

Nendele küsimustele vastamine võimaldab teil hoida protsessi kontrolli all, mõista, millises etapis iga meeskonnaliige on, ja kõrvaldada võimalikud probleemid teel eesmärgi poole. Kokkuvõtteks võib öelda, et Agile metoodika rakendamine on võimalik, kui on täidetud mitu tingimust:

1. Projekti tähtsus on selgelt välja toodud
2. Klient osaleb aktiivselt teostusprotsessis
3. Tööde kogumaht viiakse läbi samm-sammult
4. Peaksite keskenduma konkreetsele tulemusele
5. Ühe töörühma arv: 7-9 inimest

Praegu on Agile toega projektijuhtimine valdavalt levinud IT-sfääris, kuid ka ärisfäär hakkab seda omaks võtma. Seda süsteemi kasutatakse koolituses, turunduses ja äritegevuses. Agiilset projektijuhtimist võtavad kasutusele paljud ettevõtted ja riigiasutused.

Näited: Uus-Meremaa valitsus, Nigeeria valitsus, Norra pensionifond, ettevõte Return Path (tarkvara), ettevõte Oreo (küpsiste tootmine), Aviasales (suurim lennupiletite otsingumootor), Hewlett-Packardi ettevõte (suurim Ameerika IT-ettevõte), Sberbank " (Te ilmselt teate, mis see on J).

Need ja paljud teised organisatsioonid kasutavad erinevaid projektijuhtimise meetodeid, mis põhinevad Agile'il. Ja nendest meetoditest rääkimine pole vähem oluline kui metoodikast endast.

Populaarsed projektijuhtimismeetodid

Erinevates kaasaegsetes ettevõtetes on kasutusel palju projektijuhtimise meetodeid. Kuid Scrum ja Kanban peetakse õigustatult nende seas kõige kuulsamateks ja nõutuimateks.

Scrum meetod

Kõigi Agile süsteemi meetodite seas erineb Scrum selle poolest, et see paneb põhirõhu tööprotsessi kvaliteedikontrollile. Jaapani strateegilise juhtimise spetsialistid Hirotaka Takuechi ning teaduse ja tehnoloogia professor Ikujiro Nonaka, kes seda esimest korda kirjeldasid, nimetavad seda meetodit "ragbi lähenemiseks", kus Scrum "võitleb palli eest".

Meetod seisneb selles, et projektiarendus jagatakse sprintideks, mille lõpus saab klient täiustatud tarkvara. Sprindid on rangelt ajastatud ja võivad kesta 2 kuni 4 nädalat. Ühe sprindi töövoog koosneb mitmest etapist:

• Töö maht määratakse
• Iga päev toimuvad 15-minutilised koosolekud, et meeskonnaliikmed saaksid oma tööd kohandada ja vahetulemusi kokku võtta
• Saadud tulemusi demonstreeritakse
• Sprintide üle arutatakse heade ja halbade otsuste ja tegude leidmiseks

Enamasti kasutatakse Scrumit keeruka tarkvaraga töötamiseks ning tootearenduseks, kasutades inkrementaalseid ja iteratiivseid meetodeid. Tänu sellele tõuseb oluliselt meeskonna tööviljakus ja väheneb tööle kulutatud aeg.

Scrum parandab tulemusi, aitab projektil kohaneda muutustega, annab väiksema analüüsikuluga täpsemaid hinnanguid ning võimaldab tõhusamalt kontrollida tööetappe ja projekti stsenaariumi. Kõik see vastab suurepäraselt ärieesmärkidele.

Kanbani meetod

Kanban on veel üks meetod, mis muudab meeskonnatöö tõhusamaks ja produktiivsemaks. Selle tähendus taandub arendusprotsessi maksimaalse läbipaistvuse andmisele ja koormuse ühtlasele jaotusele projektis osalejate vahel. Kanbani oluline omadus on ka see, et see motiveerib inimesi pidevalt koostööd tegema, täiustama ja õppima.

Kanbani meetodil töötamine on üles ehitatud mitmele põhimõttele. Esiteks tuleb kogu projekti kohta käiv info visualiseerida, mis võimaldab näha kattumisi, vigu ja puudusi ning neid aktiivselt kõrvaldada. Teiseks peaks ühe ülesande kallal töötama kogu meeskond üheaegselt - see aitab tasakaalustada jõupingutusi ja saavutatud tulemusi ning välistab koormuse ebaühtlase jaotumise. Ja kolmandaks, kõigi ülesannete täitmiseks kuluv aeg on rangelt kontrollitud, optimeerides seeläbi protsessi ja säästes aega.

Erinevalt Scrumist saavutas Kanban populaarsuse palju hiljem, kuid see ei vähenda kuidagi selle eeliseid ega muuda seda vähem tõhusaks. Meetod on kasulik nii IT-valdkonnas kui ka ärivaldkonnas.

Need on vaid näited põhilistest Agile projektijuhtimise tavadest. Kuid te ei tohiks tähelepanuta jätta ka muid meetodeid, nagu PRINCE2, Lean, Six Sigma, XP, CCPM, ECM, Waterfall ja teised. Lisaks on Agile'il koos oma eelistega ka mõned puudused.

Agile plussid ja miinused

Agile õppimisel on oluline teada nii positiivset kui negatiivset negatiivsed aspektid seda metoodikat. Alustame positiivsetest.

Esiteks väärib märkimist, et agiilne juhtimine on väga paindlik. Kui näiteks traditsiooniline metoodika näitab konkreetseid tööetappe, siis Agile kohandub kergesti lõpptoote kasutaja ja kliendi nõudmistega.

Tegelikult on lõpptoote defektide arv minimaalne, sest see on iga sprindietapi lõpus läbiviidava põhjaliku kvaliteedikontrolli tulemus.

Lisaks on Agile kiire käivitatav, lihtne muutustele reageerida ning võimaldab arendusmeeskonnal ja klientidel hoida pidevat suhtlust reaalajas. Eelised on ilmsed, kuid räägime puudustest.

Metoodika miinusteks on see, et esiteks võib pidev tagasiside kaasa tuua projekti tähtaega kogu aeg edasi lükkuda, tekitades sellega lõputu töö jätkumise ohu. Kui klient näeb näiteks ainult tulemusi, kuid tal pole õrna aimugi nende saavutamiseks vajalikest jõupingutustest, nõuab ta pidevalt parandusi.

Teiseks puuduseks on vajadus kohandada projekteerimisdokumentatsiooni muutuvate projektitingimustega. Ilma meeskonnaga muudatuste või lisafunktsioonide kohta nõuetekohase teabevahetuseta ei pruugi funktsionaalsed nõuded või arhitektuuridokumendid praegu olla aktuaalsed.

Agile'i kolmas oluline puudus on vajadus sagedaste kohtumiste järele. Need aitavad loomulikult parandada töö efektiivsust, kuid siiski võib meeskonnaliikmete pidev hajameelsus protsessile negatiivselt mõjuda, sest inimeste tähelepanu hajub süstemaatiliselt käsilolevatelt ülesannetelt.

Siia alla kuuluvad ka sellised asjad nagu vajadus kliendi pideva kohaloleku järele, suutmatus teha pikaajalisi plaane ning vajadus motiveeritud ja kõrge kvalifikatsiooniga spetsialistide järele. Viimane puudutab muide suuresti Agiilse juhtimise rakendamist organisatsiooni tegevustes. Ja Agile'ist aru saades peate tutvuma ka selle rakendamise teemaga.

Agile'i juurutamine

Näiteid Agile’i sissetoomisest ettevõtete töösse on päris palju. Ja peaaegu kõik ütlevad, et see nõuab tervet rida olulisi meetmeid.

Alustuseks valitakse konkreetne meetod, mis sõltub projekti tingimustest. Seejärel määratakse ülesanded ja eesmärgid, peamine tähtaeg ja sprindikuupäevad, meeskonna suurus ja muud projekti komponendid. Oluline on valida meetod, mis vastab maksimaalsele hulgale nõuetele.

Nagu ütlesime, nõuab Agile'i juurutamine professionaalide meeskonda. Kõik selle liikmed peavad teadma metoodika põhiideid ja põhimõtteid ning oskama neid rakendada. Kui ettevõttes selliseid inimesi pole, tuleb töötajaid koolitada. Agile’i kasutamisele üle minna otsustanud ettevõtte juhtkond peab samuti selgelt aru saama, kas organisatsioon on muutusteks valmis, kas süsteemi saab rakendada oma projektides jne. Kõige sagedamini tuleb nendele küsimustele vastamiseks pöörduda Agile spetsialistide poole.

Järgmises etapis kutsutakse inimene, kellel on süsteemiga töötamise kogemus. Ta demonstreerib seda, selgitab sprindide ja aktsioonide olemust, tulevase meeskonna liikmete funktsioone, nendevahelise suhtluse tunnuseid ja muid probleeme. Ja alles pärast seda moodustatakse uus meeskond, jaotatakse rollid, ülesanded ja vastutus, valitakse tööriistad analüüsiks, aruandluseks jne.

Viimaseks etapiks on esimene kogemus Agile’iga, st. esimene projekt seda kasutades. Peate mõistma, et vead, puudused, ebakõlad ja viivitused on vältimatud. Peate mõnest tööriistast loobuma ja need teistega asendama ning võib-olla meeskonnas inimeste vahel rolle vahetama. Esimene kogemus on kohanemisprotsess ja kohanemine on kahesuunaline: ettevõte harjub metoodikaga ja metoodika kohandub ettevõttega.

Järeldus

Selle ülevaate kokkuvõtteks tuletagem meelde, et teooria ja praktika on kaks erinevat asja. Uued meetodid ja tehnoloogiad ning nende rakendamine on meeskonna jaoks ainulaadne väljakutse ning see, kuidas saavutada suurem efektiivsus, on alati individuaalne küsimus. Agiilsus ei ole imerohi ega edu tagatis, kuid võimaldab teil määrata õige kursi ja leida sellel teel juhiseid.

Iga projekti elluviimiseks peate kindlasti midagi muutma, otsima uusi lahendusi, . Ainult pidevalt muutuvate töötingimuste ja klientide nõudmistega kohanedes saame leida õiged tegutsemisviisid. Ja paindlik projektijuhtimise metoodika Agile võib saada selles küsimuses ustavaks abiliseks.

Agile levib Venemaal: sellest räägitakse tehastes, pankades, kindlustus- ja raamatupidamisfirmades. Kui plaanite ka Agile'i, siis on aeg teemast aru saada.

Mis on Agile

Agiilne on mõtteviis, millel on oma väärtussüsteem. See sarnaneb filosoofia, religiooni või kultuuriga – sama hoiakute kogum, millesse inimene usub ja mis tema käitumist mõjutavad. Näiteks nagu budism ja veganlus:

Budistid usuvad, et valgustumist on võimalik saavutada. Nad mediteerivad, püüavad olla mõõdukad ega kahjusta teisi.

Veganid hindavad iga elusolendi elu. Nad ei kasuta midagi loomset ja on loomade peal katsetamise vastu.

Agileistid usuvad, et töötavaid tooteid toodavad isemotiveeritud professionaalide meeskonnad. See kõlab utoopiana, kuigi Agile’i leiutasid programmeerijad.

Kuidas Agile tekkis?

Varem valmistati tooteid täielikult korraga. Selleks järgisime ahelat: idee → tehnilised andmed → disain → programmeerimine → testimine → väljalase. Kui katsetamise etapis ilmus uus idee, pidin seda ignoreerima või eelmised sammud uuesti tegema. See oli ebaefektiivne – tooted osutusid kehvemaks, kui oleks võinud, või ületasid tähtajad ja eelarved.

Progressiivsed arendajad hakkasid proovima uusi lähenemisviise. Nii tekkisid Scrum, Kanban ja tosin muud meetodit. Meeskonnad said oma töö käigus tooteid testida ja muuta – sel põhjusel nimetati selliseid lähenemisviise paindlikuks. Katsed osutusid edukaks: kliente ei petnud oma ootused ning arendajad pidasid kinni tähtaegadest ja eelarvetest.

Töötavate toodete valemi leidmiseks 17 praktikut 2001.a kaasaegsed lähenemised kogunesid Snowbirdi mägikülla. Nad arutasid oma juhtimismeetodeid ja tõdesid: kõigil on erinevad lähenemised, kuid ideed on samad. Need ideed moodustasid Agile’i aluse, lisati Agile Manifesti ja mida täiendati Agile’i põhimõtetega.

Mis on agiilse filosoofia olemus?

Nii väledat manifesti kui ka väledaid põhimõtteid kirjeldatakse üldiselt, mistõttu on neid raske mõista. Otsustage ise: "inimesed ja suhtlus on olulisemad kui protsessid ja tööriistad" või "pidev tähelepanu tehnilisele tipptasemele ja disaini kvaliteedile suurendab projekti paindlikkust."

Selguse huvides võrdleme, kuidas erinevad meeskondade koosseis, tööprotsess ja tulemus agiilse mõtteviisiga ja ilma. Oletame, et kaks pagariäri soovivad hakata tootma uusi küpsetisi:

Agile on sõltumatute professionaalide meeskond

Ka tööprotsess on väga erinev. Range funktsioonide jaotus traditsioonilises pagariäris ja agiilse meeskonna ühised katsetused:

Traditsiooniline pagariäri Pagariäri omanik ütleb, et neil on uusi küpsetisi vaja ja enam ei sega. Kokk määrab, milliseid kooke pagariäri tootma hakkab, tehnoloog töötab välja retseptid. Mõnikord katsetavad kokk ja tehnoloog retseptidega, kuid tootmiskondiitreid ei kaasata. Igaüks on hõivatud oma tööga.

Agile pagariäri Pagariäri omanik selgitab, miks uusi kooke vaja on ja mis kuluga tulus on. Müüjad täpsustavad, milliseid küpsetisi kliendid ootavad. Ostjad pakuvad tooteid, mis on hetkel soodsate hindadega. Protsess on üles ehitatud eksperimenteerimisele. Meeskond mõtleb välja retsepti, küpsetab proovipartii ja saab tagasisidet.

Agile on töö klientidega ja valmisolek esialgset plaani muuta

Ka tulemus on erinev. Mõne jaoks ettearvamatu ja teistele garanteeritud hea:

Agile on töötavate toodete väljaandmine, mis kõigile meeldivad

Agile Manifesti ja väledate põhimõtete ideed aitasid pagariäril hakata tootma uusi küpsetisi. Kuid ideoloogia äärmused on kahjulikud – on vale arvata, et Agile eitab regulatsioone ja planeerimist. Kõik see on olemas, kuid see mängib väiksemat rolli kui inimestevaheline elav suhtlus ja paindlikkus töös.

Mida Agile annab?

Agiilne muudab mõtteviisi, mistõttu töötajad korraldavad tööd ettevõttes uutmoodi. Ilmub vabadus ettevõtte formaalsustest, soov erialaselt areneda, meeskonnatunne ja mugav töökoormus.

Vabadus ülemustest ja paberimajandusest. Spetsialistid pühendavad rohkem aega huvitavatele ülesannetele ja vähem aega ametlike aruannete koostamisele.

Tavaliste töötajate maatriksist lahtiühendamine. Nad lakkavad olemast süsteemi hammasrattad ega oota elama asumiseks enam tööpäeva lõppu. Vastupidi, töötajad tunnetavad, et ettevõte vajab neid ja mõtlevad professionaalsele arengule.

Rohkem suhtlemist. Meeskonna sees moodustuvad tõelised meeskonnad, kus üks on kõigi ja kõik on ühe eest. Kõik jagavad oma probleeme ja tulevad ühise edu nimel õigel ajal appi.

Mugav töörütm. Agiilne keelab kiirustavad tööd ja soodustab mugavat rütmi, mis muudab uute väljakutsetega toimetuleku lihtsamaks. Tänu sellele saavad meeskonnad töötada lõputult.

Mis on Scrum ja Kanban sellega pistmist?

Saime teada, et Agile on filosoofia, millel on oma väärtussüsteem. Need kõlavad ahvatlevalt, kuid neid on tööl raske kasutada. Mitte iga meeskond ei saa homme ilma ülemusteta töötada. Mitte iga klient ei nõustu arendajate kontorisse sõitma või mitu korda päevas helistama. Ja pole selge, kust agiilset alustada.

Agile’i filosoofia praktikas rakendamiseks kasutatakse Scrum, Kanban ja teisi juhtimismeetodeid. Need on reeglid, mis selgitavad, kuidas Agile vaimus tööd korraldada. Nemad on erineval määral spetsiifilisus. Näiteks Kanbanil on kuus üldreeglit, samas kui Scrum kirjeldab rolle, sündmusi ja artefakte. Neid saab laiendada ja kohandada, peamine on järgida Agile'i väärtusi.

Võid olla agar ilma reegliteta. Nii töötavad peaaegu kõik idufirmad ja mõned ettevõtete divisjonid. Kui teid on ainult kaks, ei järgi te tõenäoliselt reegleid ega jagate funktsioone üksteise vahel rangelt. Pigem rehitsete pidevalt sissetulevate ülesannete hunnikut läbi. Igaüks võtab töö, mis talle kõige rohkem meeldib, teeb selle ära ja vaatab oma sõbrale tagasi. Vajadusel pakub või võtab abi vastu.

Saate reegleid kasutada ilma Agileta. Nii eksib enamik agiilseks saada üritavaid Venemaa ettevõtteid. Nad panevad kleepuvate märkmetega tahvleid üles, kuid tegelikult ei muuda need midagi. See on rohkem nagu cargo-kultus.

Tarkvaraarendus on töö, mis nõuab õigete otsuste õigeaegset langetamist. Tehnoloogiajuhid, arhitektid, meeskonnajuhid ja arendajad ise teevad regulaarselt valikuid teatud tööriistade, platvormide ja raamistike kasuks.

Kuid kõik tehtud otsused tuleb kuidagi "sünkroonida". Üks Hacker Newsi elanikest märkis, et pidi jälgima, kuidas ühes suures ettevõttes lubati viiesajal arendajal meeskonnast “eraldatult” iseseisvalt mingeid otsuseid teha. Tema sõnul oli tegemist kaosega. Ja kuigi meeskond hakkas kiiremini tööle, ei läinud see kuhugi, sest hiljem tekkisid probleemid tarkvara toe etapis.

Selliste olukordade vältimiseks kasutatakse agiilsete arendusprotsesside perekonda. Nende rakendamine võimaldab ettevõtte juhtkonnal tõsta töötajate huvi ja motivatsiooni, samuti kiirendada toote tarnimist kliendini. Viimasel ajal on see teema muutunud üha populaarsemaks, kuna mõned Agile metoodikad on peatükkide kaupa avalikkuse tähelepanu pööratud suurimad korporatsioonid.

Seetõttu otsustasime alustada postituste sarja "agiilsete" metoodikate kohta, et heita uus pilk nende funktsioonidele, võrrelda võimalusi ja aidata teie ettevõttel protsesse optimeerida. Täna räägime Scrumist, Kanbanist ja Extreme Programmingust.

Scrum

Scrum on agiilne tarkvaraarenduse raamistik, mida peetakse "vaike" metoodikaks. Paljude jaoks on see Agile'i sünonüüm. VersionOne’i 2016. aasta statistika kohaselt kasutab Scrum 58% agiilsetest ettevõtetest. Lisaks toetavad seda paljud SaaS-i platvormid. Näiteks ServiceNow lahendus, mille osaks on Agile Development Tool.

Scrum on kogu oma eksisteerimise jooksul saavutanud tohutu populaarsuse ja seda kasutavad arendusmeeskonnad isegi suurtes ettevõtetes. Selle aja jooksul tuvastas kogukond aga ka teatud puudusi.

Näiteks märgivad nad nende hulgas liigset keskendumist punktide kogumisele. Planeerimisel valib meeskond eelmise etapi kiiruse põhjal välja lood, mille suudab sprindi lõpuks läbida. Nende prillide peamine eesmärk on muuta planeerimine usaldusväärsemaks ja pakkuda selget perspektiivi.

Siin on aga probleem: kuna arendajate tööd hinnatakse punktidega, siis püütakse neid rohkem teenida ja oma tegevusi vastavalt optimeerida. Mis ei paranda koodibaasi, ei muuda seda lihtsamaks.

Teine probleem on pikad kohtumised. Lisaks toimuvad koosolekud sünkroonselt kõigi arendusosalistega, mis muutub kaugtöötavatele spetsialistidele probleemiks. Inimesed peavad oma ajakavasse mahutama tundidepikkused koosolekud, et vahetada teavet, mida saaks muul viisil edastada.

Mis puutub lugudesse, mis sprindi ajal ei muutu, siis see toob kaasa ka suuremahulisi probleeme. Programmeerijatel puudub võimalus uute funktsioonide avastamisel tööd ümber jagada. Scrum ei luba laeva sõitmise ajal ümber ehitada, seega pead muudatuste tegemiseks ootama seansi lõpuni.

Ekstreemne programmeerimine

Scrumi eripära on see, et see raamistik pöörab arenduspraktikatele vähe tähelepanu. Seetõttu kombineerivad mõned agiilsed ettevõtted (umbes 10%) seda Extreme Programmingiga (XP).

Ekstreemprogrammeerimine pälvis tähelepanu 90ndate lõpus. Kontseptsioon sai alguse Smalltalki kogukonnast ning selle autoriteks peetakse arendajaid Kent Becki ja Ward Cunninghami, kes soovisid luua inimestele mõeldud tarkvaraarenduses uusi praktikaid.

Esimene projekt, mis loodi Extreme Programming metoodikat kasutades, oli Chrysler Comprehensive Compensation (C3) maksete kontrollisüsteem üheksakümnendate keskel. Mõiste "äärmuslik programmeerimine" ilmus 1997. aastal.

Kontseptsioon põhineb kaheteistkümnel tehnikal:

Kanban

Scrum on jätkuvalt tõhus metoodika, mis on populaarne. Eriti koos ekstreemse programmeerimisega. Kokku ulatub nende kasutusmäär Agile tiimide seas 68%-ni.

Kuid täna kaaluvad paljud meeskonnad muid võimalusi ja pööravad tähelepanu muudele metoodikatele. Üks neist oli Kanban. ConvertKiti tehnoloogiadirektor Grant Ammons ütleb, et ettevõtted võtavad esmalt kasutusele Scrumi, mis õpetab neile tarkvara arendamiseks vajalikke distsipliine, ning seejärel otsivad mugavamat alternatiivi ja pöörduvad Kanbani poole.

Kanban on arenduse haldamise tehnika, mille puhul arendusprotsessi vaadeldakse kui funktsioonipäringute kogumit, mis tarnib täiustatud tarkvara.

Kanban sai alguse Toyota just-in-time tootmissüsteemi osana, seega välistab metoodika tarbetu ülesannete kuhjumise. Näiteks kui testijad testivad nädala jooksul viit funktsiooni ning arendajad ja analüütikud rakendavad kümmet, siis on "konveieri kogu läbilaskevõime" piiratud viie funktsiooniga. See on vajalik selleks, et kvaliteedikontrolli meeskond ei saaks tööd kuhjata, vastasel juhul võivad nad hakata nurki lõikama ja kogemata turule lasta ebakvaliteetse toote.

Sel juhul on võimalik ka ressursse ümber jagada: kui programmeerijad ja analüütikud on oma kvoodi täitnud, saavad nad aidata testimisel ja automatiseeritud testide kirjutamisel. Tulevikus võimaldab see suurendada konveieri läbilaskevõimet.

Ja Kanban tuvastab sellised kitsaskohad kergesti. Lihtsaimas teostuses on see suur vooderdatud veergudega tahvel, kuhu asetatakse kleebiskaardid. Tulbad tähistavad arendusprotsessi etappe ja kleebised tööülesandeid. Iga veeru ülaosas olevad numbrid näitavad, mitu kaarti on lubatud sellesse "koguda".

Kuid nagu HN-i kogukonnas märgiti, on sellel lähenemisviisil ka teatud puudused. Scrumis mõjutavad lühikesed sprindid arendajate motivatsiooni positiivselt. Programmeerijad teavad, et töö tootega lõpeb, kui kogu 30 päeva nõuete loend on täidetud. Kanbani puhul on tegemist pideva ja lõputu ülesannete vooga. Siiski on väljapääs - nädala (või kahe) lühike arutelu ülesannete loendite üle.

Samuti ei sobi kanban oma spetsiifilisuse tõttu hästi pikaajaliseks planeerimiseks ning on ebamugav suurtele arendusmeeskondadele (üle viie inimese).

Lõpetuseks märgime, et agiilsete metoodikate kasutamine seab tõsiseid nõudmisi meeskonnaliikmete kogemustele ja nende võimele üksteisega tõhusalt suhelda. Pealegi on igal enam-vähem levinud metoodikal oma tugevad ja nõrgad küljed ning rakendusvaldkonnad. Sel põhjusel ilmuvad uued raamistikud ja "vanu" täiustatakse.

"Kõikidest väljakutsetest, millega NASA silmitsi seisis inimese Kuule saatmisel, oli juhtimine võib-olla kõige keerulisem."

— Roger Launis, NASA ajaloolane

Ajaloo jooksul on inimkond kogunud muljetavaldava nimekirja edukalt ellu viidud keerukatest projektidest. Alates Giza püramiidide ehitamisest kuni inimese Kuule saatmiseni nõudsid kõige julgemad inimlikud ettevõtmised tuhandete inimeste koordineeritud tööd. Ja see eeldab keerukat projektijuhtimissüsteemi.

Ja kuigi vaid vähesed meist seisavad silmitsi sellise ulatusega ülesannetega, puutub enamik selle ajaveebi lugejaid projektijuhtimisega ühel või teisel viisil kokku. PMI hinnangul on 2020. aastaks olemas – ja paljud teised spetsialistid peavad sageli juhtima miniprojekte, vähemalt isiklikul tasandil.

Lihtsamalt öeldes on projektijuhtimine kõige selle haldamine ja korraldamine, mida on eesmärgi saavutamiseks vaja – õigeaegselt ja loomulikult eelarve piires. Olgu selleks uue tarkvara arendamine, turunduskampaania läbiviimine või inimeste Marsile maandumine – projektijuhtimine võimaldab teil edu saavutada.

Kõik projektid on erinevad. Pole olemas täiuslikku projektijuhtimissüsteemi, mis sobiks igat tüüpi projekti jaoks. Samuti puudub süsteem, mis sobiks igale juhile ja oleks mugav kõigile meeskonnaliikmetele. Projektijuhtimise ajal on aga loodud palju tõhusaid lähenemisviise, meetodeid ja standardeid, mida saab omaks võtta. Täna räägime neist kõige populaarsematest.

Väljatöötatud lähenemisviisid on üksteisest väga erinevad. Need erinevad kasutusvaldkondade, detailide, iseseisvuse ja vormistamise poolest. Pealkirjas nimetasime neid mugavuse huvides "meetoditeks", kuid tegelikult esitatakse artiklis projektijuhtimises kasutatavad standardid, kontseptsioonid, meetodid ja raamistikud. Selle artikli eesmärk on anda kõige laiem ülevaade olemasolevatest projektijuhtimise lähenemisviisidest.

Selles artiklis vaatleme:

• Klassikaline projektijuhtimine
• Agiilne
• Scrum
• Lahja
• Kanban
• KuusSigma
• PRINTS2

Ja enne kui kaalute spetsiifilisi meetodeid, vastame ilmselgele küsimusele - "Miks meil üldse projektijuhtimissüsteeme ja -meetodeid vaja on?"– vaatame muidugi lühidalt projektijuhtimise ajalugu ja defineerime projektijuhtimise põhimõisteid.

Miks "projektijuhtimine"?

Neil Armstrongi ja Buzz Aldrini nimed jäävad igaveseks ajalukku inimkonna ühe suurima saavutuse – inimese Kuule maandumise – sümbolina. Selle sündmuse peamised panustajad olid aga 400 000 NASA töötajat ning 20 000 ettevõtet ja ülikooli, kes Apollo missioonil koos töötasid.

1961. aastal seadis John Kennedy ülesandeks maandada inimene Maa satelliidile ja ta tagasi saata – hoolimata sellest, et NASA saatis toona mehe kosmosesse vaid 15 minutiks. Selline ambitsioonikas eesmärk nõudis uskumatult palju ressursse, koostööd, innovatsiooni ja planeerimist.

NASA raamatu Managing the Moon Program kohaselt ei olnud peamine probleem " mida teha?" ja selles " kuidas nii lühikese ajaga nii palju ära teha? Johnsoni kosmosekeskuse insenerijuhi dr Max Fageti sõnul (Lyndon B. Johnsoni kosmosekeskus, JSC), siis polnud NASA-l aimugi, kuidas mahutada kõik vajalikud toimingud 10 aasta sisse. Seetõttu oli esimene samm "jagada projekt juhitavateks etappideks".

Seejärel oli oluline kiirendada iga üksikut etappi ja tagada, et igas etapis töötavad meeskonnad ja ettevõtted suhtleksid üksteisega tõhusalt ja annaksid tulemusi õigeaegselt. See ülesanne usaldati dr George E. Mullerile, kes juhtis Apollo projekti kõiki osasid alates Valgest Majast kuni väikseima osa tarnijani. Projekti juhtimise hõlbustamiseks otsustas ta jagada projekti 5 valdkonda: programmi juhtimine, süsteemitehnoloogia, testimine, töökindlus ja kvaliteet ning lennuoperatsioonid. Apollo programmi juhtimisskeem on näidatud joonisel Joonis 1.

Nagu Mueller ise märgib, see 5-astmeline süsteem, mida Dr. Muelleri initsiaalide järgi kutsuti "GEM-faasideks", loodi selleks, et "keskenduda toote testimisele ja testimiseks kavandamisele". Programmikontroll määras ära, mida tuleb teha, haldas eelarveid ja nõudeid ning haldas programmi elementide omavahelisi seoseid. Süsteemitehnika valdkond vastutas uute seadmete ja komponentide väljatöötamise eest, testimine vastutas selle eest, et need uued elemendid töötaksid, töökindlus ja kvaliteet kontrollisid väljatöötatud üksusi, et tagada vastavus nõuetele ja standarditele, ning lennuoperatsioonid vastutas nende sõlmede tagamise eest. töötab lennu ajal.

Paljud olid Mulleri pakutud meetodi suhtes alguses skeptilised, kuid lõpuks õnnestus tal veenda programmi liikmeid selle algoritmi järgimise vajaduses. See süsteem on näidanud oma tõhusust – projekt viidi edukalt lõpule ja võib isegi öelda, et võidukalt, enne määratud tähtaegu. See oli võimalik vaid suuremahulise projekti jagamisel juhitavateks korratavateks sammudeks, võimaldades paljudel üksikutel ettevõtetel ja spetsialistidel töötada samas rütmis. Nii tõestas projektijuhtimine kosmosevõistlusel oma tõhusust.

Projektijuhtimise lühiajalugu

Projektijuhtimist ei leiutanud NASA ega dr Mueller. Egiptuse püramiidid ja Hiina müür on eelajaloolise ajastu projektijuhtimise tooted. Kahjuks dokumentaalsed tõendid kuidas nende projektide elluviimine ja juhtimine toimus, pole säilinud ning praegune projektijuhtimine on lahutatud möödunud sajandite teadmistest.

Kõige ilmsem viis projekti elluviimiseks on jagada see etappideks või üksikuteks ülesanneteks. Nagu kulinaarne retsept – ostad koostisosad, segad õigesti, küpsetad ja serveerid. Lihtsaim projektijuhtimise tööriist on kontrollnimekiri tegevustest, mida tuleb eesmärgi saavutamiseks teha. Lihtne ja tõhus.

Kui aga olete kokk ja valmistate mitte ühte rooga, vaid mitut, näiteks salatit (mille valmistamine koosneb 3 etapist) ja magustoitu (mis tuleb ainult serveerida), siis on teil vaja tööriist, mis võimaldab teil jälgida iga üksuse jaoks kuluvat aega ja aega, millal need peaksid olema valmis. Ja siin tuleb appi üks esimesi kaasaegseid projektijuhtimise tööriistu: Gantti diagramm, mida esitletakse Joonis 2.

Leiutas iseseisvalt K O Korol Adamecki ja Henry L. Gantti roll 20. sajandi alguses näitab Gantti diagramm projekti ajakava, mis põhineb ülesannete lõpu- ja lõpetamiskuupäevadel. Sellesse sisestatakse ülesanded, nende kestused ja seosed ning seejärel arvutatakse kriitiline tee - pikim omavahel seotud ülesannete ahel, mis määrab projekti kestuse. Väga olulised on erinevate tööülesannete alguse ja lõpu suhted – sa ei saa ju oma külalistele suppi serveerida enne, kui oled selle keetnud?

Seega on tüüpiline projekt väga sarnane õhtusöögi valmistamise ja serveerimisega, ainult et sellel on palju rohkem ülesandeid, suhteid, tähtaegu ja ressursse. Kitsaste tähtaegadega projektide puhul aitab Gantti diagramm otsustada, millal on kõige parem teatud toiminguid alustada, et lühendada rakendamisaega. Tugevate ressursipiirangutega projektide puhul annab Gantti diagramm võimaluse koostada diagramm sündmustepõhise protsessiahela kujul ressursside planeerimiseks.

Erinevad projektid nõuavad erinevat kontrollitaset. Näiteks kui avaldate artiklite sarja aastal, siis pole ranged tähtajad nii olulised. Palju olulisem on arusaadav protsess, mille käigus on võimalik iga artiklit struktureerida, teha igast konspekt, saada tagasisidet, teha muudatusi, lõpetada artikkel, lugeda korrektuure ja avaldada. Aja ja ressursside haldamise asemel juhite protsessi.

Selliste projektide jaoks sobivad paremini Agile projektijuhtimise meetodid ja nendega seotud lähenemisviisid nagu Lean, Kanban jt. Samuti on olemas meetodid, mis võimaldavad hallata nii töövoogu, aega kui ka ressursse – 6 Sigma ja Scrum.

Populaarsed projektijuhtimissüsteemid

Läbi projektijuhtimise ajaloo on loodud palju erinevaid projektijuhtimise meetodeid, mis vastavad peaaegu igale vajadusele. Isegi kui te ei kavatse meest Kuule saata ja teil pole sama palju ressursse, leiate endale sobiva tööriista ikkagi. Peaasi on mõista, mis on teie projekti jaoks kõige olulisem - tähtajad, ressursid, protsessi järgimine või mitu tegurit korraga - ja seejärel valida selle näitaja saavutamisele keskendunud projektijuhtimise meetod.

Enne kui vaatame kõige populaarsemaid meetodeid, määratleme mõned võtmeterminid.

Projektijuhtimise põhitingimused

Agiilne: Paindlik iteratiivne-inkrementaalne lähenemine projekti- ja tootejuhtimisele, mis on keskendunud nõuete dünaamilisele kujundamisele ja nende rakendamise tagamisele pideva interaktsiooni tulemusena iseorganiseeruvates töörühmades, mis koosnevad erinevate valdkondade spetsialistidest. Agile ideedel põhinevaid meetodeid on palju, neist populaarseimad on Scrum ja Kanban.

Kriitiline tee: Tööde ja sündmuste pidev jada algusest kuni viimase sündmuseni, mille lõpuleviimiseks kulub kõige rohkem aega.

Protsesside sündmuste ahel (EPC diagramm): diagramm, mis näitab projektitööde elluviimise järjekorda, lähtudes ressursside olemasolust ja töökoormusest

Ajareserv: Aeg, mille jooksul töö algust saab edasi lükata, ilma et see mõjutaks projekti üldist kestust. Seega on kriitilisel teel töötamise ujuk null.

verstapost (kontrollpunkt,verstapost): Võtmesündmus, mis tähistab näiteks etapi lõppu. Gantti diagrammil on näidatud ülesanne, mille kestus on null.

Projektijuht (projektijuht,projektjuhtP.M. ): Projektijuhtimise (projekti planeerimise, elluviimise ja lõpetamise) eest vastutav projektimeeskonna juht.

Vahendid: Projekti elluviimiseks vajalikud elemendid. Ressursid hõlmavad aega, varustust, materjale, töötajaid jne.

Sprint (Sprint): Nädalast kuuni kestev iteratsioon (töötsükkel) Scrumis, mille käigus luuakse tootest või selle kliendile väärtuslikust elemendist töötav versioon.

"Klassikaline" või "traditsiooniline" projektijuhtimine: Kõige laialdasemalt kasutatav projektijuhtimise meetod, mis põhineb nn kose- ehk kaskaaditsüklil, kus ülesanne kantakse üle järjestikku läbi voolu meenutavate etappide.

Klassikaline projektijuhtimine

Kõige ilmsem viis oma projekti juhitavamaks muutmiseks on jagada selle täitmisprotsess järjestikusteks etappideks. Sellel lineaarsel struktuuril põhineb traditsiooniline projektijuhtimine. Selles mõttes meenutab see arvutimängu – eelmist lõpetamata ei saa järgmisele tasemele liikuda. Töövoo diagramm on näidatud joonisel Joonis 3.

Selline lähenemine on keskendunud projektidele, mille puhul on ülesannete järjestusele seatud ranged piirangud. Näiteks maja ehitamine - ilma vundamendita ei saa seinu ehitada.

Tavaliselt on klassikalises projektijuhtimises 5 etappi, kuid kui projekt seda nõuab, saab lisada ka täiendavaid etappe.

Traditsioonilise juhtimise 5 etappi:

1. etapp. Algatamine. Projektijuht ja meeskond määratlevad projekti nõuded. Selles etapis korraldatakse sageli koosolekuid ja ajurünnakuid, et teha kindlaks, milline peaks olema projekti toode.

Etapp 2. Planeerimine. Selles etapis otsustab meeskond, kuidas ta saavutab eelmises etapis seatud eesmärgi. Selles etapis täpsustab meeskond projekti eesmärke ja tulemusi ning selle nimel tehtava töö ulatust. Selle teabe põhjal koostab meeskond ajakava ja eelarve, hindab riske ja selgitab välja huvirühmad.

3. etapp. Areng. Seda etappi ei rakendata reeglina kõigi projektide puhul, see on osa planeerimisetapist. Tehnoloogiaprojektidele iseloomulikult tehakse arendusfaasis kindlaks tulevase projekti ja/või toote konfiguratsioon ning tehnilised vahendid selle saavutamiseks. Näiteks IT-projektides valitakse selles etapis programmeerimiskeel. ( Kodumaises praktikas seda faasi tavaliselt ei eristata ja terminit "arendus" ei kasutata - u. trans.)

4. etapp. Rakendamine ja testimine. Selles etapis toimub tegelik põhitöö projekti kallal - koodi kirjutamine, hoone püstitamine jms. Väljatöötatud plaane järgides hakatakse looma varem määratletud projekti sisu, mille juhtimine toimub valitud mõõdikute järgi. Selle etapi teises osas testitakse toodet, kontrollitakse selle vastavust Kliendi ja huviliste nõuetele. Testimisosa tuvastab ja parandab toote puudused.

5. etapp. Projekti seire ja lõpuleviimine. Olenevalt projektist võib see faas koosneda lihtsast projekti tulemuste edastamisest Kliendile või pikast suhtlemisprotsessist klientidega projekti täiustamiseks ja nende rahulolu suurendamiseks ning projekti tulemuste toetamiseks. Viimane kehtib klienditeeninduse ja tarkvara valdkonna projektide kohta.

Eelpool kirjeldatu on aluseks, millele on üles ehitatud erinevad projektijuhtimise meetodid. Erinevad projektid nõuavad erinevaid elluviimise etappe – mõned nõuavad kolme etappi, teised palju rohkem. Mõnikord kasutatakse nn iteratiivset juga, mille iga etapp on alamprojekt, mille käigus ülesandeid realiseeritakse fikseeritud iteratsioonidena. Kuid olemus jääb samaks - projekt on jagatud etappideks, mis viiakse läbi rangelt määratletud järjekorras.

Kuna klassikaline projektijuhtimine on rangelt seotud ülesannete täitmise ajaga, mis on tavaliselt planeerimisetapis ette määratud, sobivad kalendri- ja võrguplaneerimise tööriistad selle lähenemisviisi raames projektide elluviimiseks suurepäraselt. Levinuim ajastamise ja võrguplaneerimise tööriist on eelnevalt mainitud Gantti diagramm. Selle ehitamiseks on palju tööriistu - alates lihtsad tabelid nagu Excel ja Smartsheet professionaalsetele tarkvarapakettidele nagu Microsoft Project ja Primavera.

Klassikalise projektijuhtimise tugevused

Tänapäeval öeldakse sageli, et klassikaline kosekäsitlus on ajale jalgu jäänud, kuid see ei mõtle kaotamisele. Selle lähenemise suureks eeliseks on see, et see nõuab kliendilt ja ettevõtte juhtkonnalt juba projekti esimeses etapis kindlaks, mida nad soovivad saada. Varajane kaasamine toob projekti teatud stabiilsuse ja planeerimine võimaldab projekti elluviimist sujuvamaks muuta. Lisaks hõlmab see lähenemine jõudluse jälgimist ja testimist, mis on erineva suurusega reaalsete projektide jaoks hädavajalik.

Potentsiaalselt võimaldab klassikaline lähenemine vältida stressi, mis on tingitud vaba aja olemasolust igal etapil, mis on sisse ehitatud mis tahes tüsistuste ja riskide korral. Lisaks teab projektijuht korralikult teostatud planeerimisfaasi korral alati, millised ressursid tal on. Isegi kui see hinnang ei ole alati täpne.

Nõrgad küljed klassikaline projektijuhtimine

Klassikalise projektijuhtimise peamine nõrkus on sallimatus muutuste suhtes. Selliste süsteemide nagu Lean ja Kanban loomise poolest kuulsa Toyota juhtkonda kritiseeritakse sageli selle pärast, et nad rakendavad oma ettevõtte tarkvara arendamisel klassikalist lähenemist, ja just paindlikkuse puudumise pärast.

Klassikalise lähenemise alustalaks on praegu ehitus- ja inseneriprojektid, mille puhul projekti sisu jääb kogu projekti vältel praktiliselt muutumatuks. Kuid kui teie projektis ei piira ressursid ja aeg ning projekti sisu võib muutuda, peaksite võib-olla teiste projektijuhtimissüsteemidega lähemalt tutvuma.

Agiilne

Nagu varem mainitud, ei saa kõiki projekte struktureerida nii, et neid saaks ellu viia klassikalise projektikäsitluse abil. Naastes meie näite juurde kokaga: ühe roa valmistamine sobib suurepäraselt “kose” lähenemisega, kuid neljakäigulise õhtusöögi õigeaegne valmistamine ja serveerimine on peaaegu võimatu, kui pead iga kord ootama ühe roa valmimist, et hakata valmistama. teine.

Ja siin tuleb mängu Agile – paindlike iteratiivsete-inkrementaalsete meetodite perekond projekti- ja tootehalduseks. Selle lähenemisviisi kohaselt ei jagata projekti järjestikusteks faasideks, vaid väikesteks alamprojektideks, mis seejärel “kokku pannakse” valmistooteks. Tööskeem on näidatud joonisel Joonis 5.

Seega toimub initsiatiiv ja tippplaneerimine kogu projekti kohta ning järgnevad etapid: arendus, testimine ja muu viiakse läbi iga miniprojekti jaoks eraldi. See võimaldab nende miniprojektide tulemused, nn juurdekasvud, kiiremini üle kanda ning uut alamprojekti (iteratsiooni) alustades saab selles teha muudatusi ilma suurte kuludeta ja mõjuta ülejäänud projektile.

Hoolimata asjaolust, et Agile on suhteliselt hiljuti moodi tulnud, pole iteratiivse arenduse idee uus. (välimuse ajaloo kohtaAgile saab lugeda – umbes). Paindlike metoodikate perekond sai oma praeguse nime 2001. aastal Agile Manifesti avaldamisega, mis pani paika paindliku tarkvaraarenduse põhiväärtused ja põhimõtted, mis põhinevad meeskonnatööl ja kohanemisel, isegi "armastusel" muutuste vastu.

Agile ise ei ole projektijuhtimise meetod. See on pigem ideede ja põhimõtete kogum, kuidas projekte tuleks ellu viia. Nende põhimõtete ja parimate praktikate põhjal on välja töötatud individuaalsed paindlikud meetodid või, nagu neid mõnikord nimetatakse, raamistikud: Scrum, Kanban, Crystal ja paljud teised. Need meetodid võivad üksteisest üsna erinevad olla, kuid järgivad samu põhimõtteid.

TugevusedAgiilne

Agile’i kõige olulisem eelis on selle paindlikkus ja kohanemisvõime. See suudab kohaneda peaaegu kõigi organisatsiooni tingimuste ja protsessidega. See määrabki selle praeguse populaarsuse ja selle, kui palju süsteeme erinevate valdkondade jaoks on selle põhjal loodud.

Üks agiilsetest põhimõtetest on: "Muutustele reageerimine on olulisem kui plaani järgimine." See kiire ja suhteliselt valutu reageerimine muutustele on põhjus, miks paljud suured ettevõtted soovivad muuta oma protsesse paindlikumaks. Lisaks on Agile suurepärane avatud projektide jaoks, näiteks teenuse või ajaveebi käivitamiseks.

Agile’i valdkond on uute innovaatiliste toodete arendamine. Taoliste tootearendusprojektide puhul on ebakindlus suur ja info toote kohta selgub projekti edenedes. Sellistes tingimustes muutub “kose” projekti elluviimine võimatuks - planeerimiseks pole teavet.

Nõrgad küljedAgiilne

Erinevalt PRINCE2-st ja PMBOK-ist ei ole Agile metoodika ega standard. Agiilne on põhimõtete ja väärtuste kogum. Nõrkus on see, et iga meeskond peab iseseisvalt looma oma juhtimissüsteemi, juhindudes Agile põhimõtetest. See on keeruline ja pikk protsess, mis nõuab muudatusi kogu organisatsioonis, alates protseduuridest kuni põhiväärtusteni. See on okkaline tee ja mitte kõik organisatsioonid ei saa sellega hakkama.

See tee nõuab muutuste juhilt mitte ainult teadmisi ja visadust, vaid ka tõsiseid haldusressursse ja kulusid. Õnneks on olemas juba valmis praktikate komplektid, mis muudavad organisatsiooni agiilse ümberkujundamise lihtsamaks. Selliste komplektide hulka kuuluvad Scrumi raamistik, Kanban meetod ja paljud teised – Crystal, LeSS, SAFe, Nexus.

Scrum

1986. aastal loodud Agile'i raamistikku peetakse Agile'i perekonna kõige struktureeritumaks. 1986. aastal loodud see ühendab endas klassikalise protsessi elemendid ja ideed agiilsest lähenemisest projektijuhtimisele. Tulemuseks oli paindlikkuse ja struktuuri väga tasakaalustatud kombinatsioon.

Järgides Agile'i ettekirjutusi, jagab Scrum projekti osadeks, mida Klient saab kohe väärtuse saamiseks kasutada, mida nimetatakse toote mahajäämuseks. Ja hoolimata asjaolust, et "toote mahajäämus" on üsna õige tõlge ja seda kasutatakse erialases kirjanduses, kasutatakse vene praktikas kõige sagedamini lihtsalt "mahajäämust". Seejärel seab need osad prioriteediks Tooteomanik – Kliendi esindaja meeskonnas. Kõige olulisemad "tükid" valitakse esimesena sprindis täitmiseks - nii nimetatakse Scrumi iteratsioone, mis kestavad 2 kuni 4 nädalat. Sprindi lõpus esitatakse Kliendile toote töökasv – need väga olulised “tükid”, mida saab juba kasutada. Näiteks veebisait, millel on osa funktsioonidest või programm, mis juba töötab, kuigi osaliselt. Pärast seda alustab projektimeeskond järgmist Sprinti. Sprindi kestus on fikseeritud, kuid meeskond valib selle projekti alguses iseseisvalt, lähtudes projektist ja enda sooritusest.

Tagamaks projekti vastavust Tellija nõuetele, mis kipuvad ajas muutuma, hinnatakse enne iga Sprindi algust täitmata projekti sisu ümber ja tehakse selles muudatused. Selles protsessis osalevad kõik – projektimeeskond, Scrum Master (Scrum Master, projektimeeskonna juht) ja tooteomanik. Ja vastutus selle protsessi eest lasub kõigil.

Nagu juba mainitud, on Tooteomanik kliendi esindaja projektis või esindab kõiki tulevase projekti kliente, kui Klienti pole. Selleks peab ta põhjalikult tundma nende vajadusi ja mõtteviisi, samuti mõistma toodet ja selle valmistamise tehnoloogiat. Scrum Master on loodud selleks, et aidata projektis osalejatel paremini mõista ja aktsepteerida Scrumi praktika väärtusi, põhimõtteid ja norme. Ta on liider ja vahendaja välismaailma ja meeskonna vahel. Tema ülesanne on tagada, et keegi ei segaks meeskonna võimet iseseisvalt ja mugavalt määratud ülesannetega töötada. Meeskond vastutab selle eest, et sprindi lõpus oleksid kõik vajalikud ülesanded täidetud ja tarned tehtud.

Scrumi protsesside põhistruktuur koosneb 5 peamisest koosolekust: mahajäämuse joondamine, sprindi planeerimine, igapäevased püstijalanõupidamised, sprindi kokkuvõte ja sprindi tagasivaade.

Paljude jaoks võib Scrum tunduda raskesti rakendatav – uus protsess, uued rollid, palju delegeerimist ja täiesti uus organisatsiooniline struktuur. Kuid see on paindlik ja samal ajal struktureeritud lähenemine projekti elluviimisele, mis erinevalt ebamäärasest ja üldised põhimõtted Agiilsus ei lase tööl vales suunas liikuda.

TugevusedScrum

Scrum töötati välja projektide jaoks, mis nõuavad "kiiret võitu" kombineerituna muutuste sallivusega. Lisaks sobib see raamistik olukordadeks, kus kõigil meeskonnaliikmetel ei ole piisavalt kogemusi selles valdkonnas, kus projekti ellu viiakse – pidev meeskonnaliikmete omavaheline suhtlus võimaldab mõne töötaja kogemuste või kvalifikatsiooni puudumisel kasu saada infost ja abist. kolleegid.

Interneti-telekanal Netflix on suurepärane näide tulemuste kiirest edastamisest. Ressursi veebisaiti uuendatakse iga kahe nädala tagant tänu Scrumile, mis mitte ainult ei võimalda suurel kiirusel töötada, vaid kogub ka kasutajakogemust ja võimaldab tuvastada klientide jaoks kõige olulisemad asjad.

Iga iteratsiooni ajal lisavad ja testivad arendajad saidi uusi funktsioone ning eemaldavad need, mida kliendid ei kasutanud. Netflixi meeskonna sõnul on Scrumi peamine eelis see, et see võimaldab teil kiiresti ebaõnnestuda. Selle asemel, et suure väljaande ettevalmistamine võtta kaua aega ja suuri kulutusi, on Scrumi kahenädalased tarned väikesed. Neid on lihtne jälgida ja kui midagi läheb valesti, parandage need kiiresti.

Nõrgad küljedScrum

Scrum on projektimeeskonna suhtes väga nõudlik. See peaks olema väike (5-9 inimest) ja funktsionaalne – see tähendab, et meeskonnaliikmetel peaks olema rohkem kui üks projekti elluviimiseks vajalik kompetents. Näiteks peavad tarkvaraarendajal olema teadmised testimisest ja ärianalüütikast. Seda tehakse selleks, et osa meeskonnast ei jääks projekti erinevatel etappidel “jõude seisma” ning ka selleks, et töötajad saaksid üksteist aidata ja asendada.

Lisaks peavad meeskonnaliikmed olema “meeskonnamängijad”, võtma aktiivselt vastutust ja suutma end organiseerida. Nii küpse meeskonna leidmine on väga raske!

Scrum ei sobi kõikidele meeskondadele ja organisatsioonidele ka seetõttu, et pakutav protsess ei pruugi sobida konkreetse toote – näiteks tööstusmasina või hoone ehitamiseks – arendamiseks.

Lahja

Agile käsib meil jaotada töö väikesteks hallatavateks pakettideks, kuid see ei ütle meile, kuidas selle paketi arendamist juhtida. Scrum pakub meile oma protsesse ja protseduure. Lean omakorda lisab Agile'i põhimõtetele töövoo diagrammi, nii et iga iteratsioon viiakse lõpule sama kvaliteediga.

Leanis, nagu ka Scrumis, on töö jaotatud väikesteks tarnepakettideks, mida rakendatakse eraldi ja iseseisvalt. Kuid Leanis on iga tarnepaketi väljatöötamiseks töövoog, mille sammud on sarnased Project Apollo jaoks loodud sammudega. Nagu klassikalises projektijuhtimises, võivad need olla planeerimise, arendamise, tootmise, testimise ja tarnimise etapid – või mis tahes muud etapid, mis on vajalikud projektide kvaliteetseks elluviimiseks.

Lean faasid ja nende paindlikkus võimaldavad teil olla kindel, et projekti iga osa viiakse ellu vastavalt vajadusele. Leanil pole selgeid etappide piire, nagu Scrumil pole Sprindi piire. Lisaks võimaldab Lean erinevalt klassikalisest projektijuhtimisest erinevatel etappidel paralleelselt täita mitmeid ülesandeid, mis suurendab paindlikkust ja suurendab projekti teostamise kiirust.

Nagu Agile, on ka Lean pigem kontseptsioon, mõtteviis, mitte midagi kivisse raiutud. Lean-ideid kasutades saate iseseisvalt luua süsteemi, mis vastab teie projektijuhtimise nõuetele.

TugevusedLahja

Kui teile meeldivad Agile'i ideed, kuid projekt nõuab väga sujuvat kvaliteeti ja täpset teostust, pakub Lean nende nõuete täitmiseks tööriistakomplekti. Lean ühendab paindlikkuse ja struktuuri nagu Scrum, kuid veidi erineval viisil.

Nõrgad küljedLahja

Mitte iga projekti osa ei nõua võrdselt üksikasjalikku ja põhjalikku uurimist ja tähelepanu. Kuid Lean eeldab täpselt sellist lähenemist igale ülesandele ja etapile. See on Leani kasutamise peamine puudus suurte ja heterogeensete projektide puhul.

Samuti ei paku Lean erinevalt Scrumist selget töövoogu projekti “tükkide” rakendamiseks, mis aitab kaasa projekti ajakava pikendamisele. Seda probleemi saab lahendada tõhusa juhtimise ja selge suhtlusega – peamine, mida meeles pidada, on see.

Kanban

Lean näeb iseenesest veidi abstraktne välja, kuid koos Kanbaniga muutub seda palju lihtsamaks kasutada oma projektihaldussüsteemi loomiseks. Toyota inseneri Taiichi Ono 1953. aastal loodud Kanban on väga sarnane tööstusliku tootmise vooskeemiga. Selle protsessi sisendis siseneb metallitükk ja väljundis saadakse valmis detail. Ka Kanbanis liigub toote juurdekasv etapist etapisse ja lõpus on tarnimiseks valmis kaup.

Lisaks sai Kanbani looja inspiratsiooni supermarketitest, nimelt nende põhimõttest – “hoia riiulitel ainult seda, mida klient vajab”. Seetõttu võimaldab Kanban jätta ülesande ühte etappi lõpetamata, kui selle prioriteet on muutunud ja on muid kiireloomulisi ülesandeid. Redigeerimata artikkel ajaveebi jaoks, postitus ilma avaldamiskuupäevata või koodijupp funktsioonile, mis ei pruugi tootes sisalduda, on kõik Kanbani töö jaoks tavalised.

Kanban on palju vähem range kui Scrum - see ei piira sprindide aega, puuduvad rollid, välja arvatud toote omanik. Kanban võimaldab isegi meeskonnaliikmel hallata mitut ülesannet korraga, mida Scrum ei luba. Samuti ei ole projekti seisu puudutavad koosolekud kuidagi reguleeritud - saate seda teha teile sobival ajal või ei saa seda üldse teha.

Kanbaniga töötamiseks peate määratlema töövoo etapid. Kanbanis on need kujutatud veergudena ja ülesanded on kujutatud spetsiaalsete kaartidega. Kaart liigub etappide kaupa, nagu tehase osa, mis liigub masinalt masinale, ja igal etapil muutub valmimisaste kõrgemaks. Selle tulemusena saame tooteelemendi valmis kliendile tarnimiseks. Veergude ja kaartidega tahvel võib olla kas päris või elektrooniline – isegi siin ei sea Kanban kasutajatele mingeid piiranguid.

Teie enda Kanbani süsteem võib olla nii paindlik, kui soovite – Kanban on paljuski Agile'i idee visualiseerimine. Kuid Kanbanil on neli sammast, millel kogu süsteem toetub:

1. Kaardid: Iga ülesande jaoks luuakse individuaalne kaart, kuhu kantakse kogu ülesande kohta vajalik info. Seega on kogu vajalik info ülesande kohta alati käepärast.
2. Ülesannete arvu piirang etapis: Kaartide arv ühel etapil on rangelt reguleeritud. Tänu sellele saab kohe selgeks, kui toiminguvoos tekib "ummistus", mis kiiresti kõrvaldatakse.
3. Pidev vool: Mahajäänud ülesanded pannakse voogu prioriteetsuse järjekorras. Nii et töö ei peatu kunagi.
4. Pidev täiustamine (Kaizen)kaizen)): Pideva täiustamise kontseptsioon tekkis Jaapanis 20. sajandi lõpus. Selle olemus on tootmisprotsessi pidev analüüs ja tootlikkuse tõstmise võimaluste otsimine.

TugevusedKanban

Sarnaselt Scrumiga sobib Kanban hästi üsna ühtehoidvatele ja hea suhtlusega meeskondadele. Kuid erinevalt Scrumist pole Kanbanil rangeid tähtaegu, mis on hea motiveeritud ja kogenud meeskondadele.

Kui Kanban on õigesti seadistatud ja hallatud, võib sellest projektimeeskonnale palju kasu olla. Meeskonna töökoormuse täpne arvutamine, piirangute korrektne seadmine ja keskendumine pidevale täiustamisele – kõik see võimaldab Kanbanil tõsiselt ressursse kokku hoida ning tähtaegadest ja eelarvetest kinni pidada. Ja kõik see kombineerituna paindlikkusega.

Nõrgad küljedKanban

Tihti võib kuulda, et erinevalt Scrumist võimaldab Kanban töötada peaaegu iga meeskonnaga. Kuid see pole nii. Kanban sobib kõige paremini meeskondadele, mille liikmete oskused kattuvad omavahel. Nii saavad nad aidata üksteisel probleemide lahendamise raskustest üle saada. Ilma selleta pole Kanban nii tõhus kui võiks. Samuti, nagu juba mainitud, sobib Kanban paremini juhtudel, kui puuduvad ranged tähtajad. Kitsaste tähtaegade korral on parem klassikaline lähenemine või Scrum.

6 sigmat (kuus sigmat)

Motorola aitas koos Toyotaga kaasa ka globaalse projektijuhtimise arendamisele. Ettevõtte insener Bill Smith lõi 6 Sigma kontseptsiooni 1986. aastal. See on Leani struktureeritum versioon kui Kanban, mis lisab rohkem planeerimist ressursside säästmiseks, kvaliteedi parandamiseks ning defektide ja probleemide arvu vähendamiseks.

Projekti lõppeesmärk on klientide rahulolu toote kvaliteediga, mida on võimalik saavutada läbi pideva projekti kõigi aspektide täiustamise protsessi, mis põhineb indikaatorite põhjalikul analüüsil. 6 Sigma kontseptsioon pöörab erilist tähelepanu esilekerkivate probleemide kõrvaldamisele.

Selleks on välja pakutud 5-etapiline protsess, mida tuntakse DMEDI nime all:

• Definitsioon (Defineeri): Esimene etapp on väga sarnane teiste projektijuhtimissüsteemide varajaste etappidega. See määrab projekti sisu, kogub infot projekti eelduste kohta ja seab eesmärgid.
• Mõõtmine (Mõõtmine): 6 Sigma on keskendunud projekti kohta kvantitatiivsete andmete kogumisele ja analüüsimisele. Selles etapis määratakse kindlaks, millised näitajad määravad projekti edukuse ning milliseid andmeid on vaja koguda ja analüüsida.
• Uuring (Uurige): Uurimisetapis otsustab projektijuht, kuidas meeskond suudab saavutada oma eesmärgid ja täita kõik nõuded õigeaegselt ja eelarve piires. Selles etapis on väga oluline, et projektijuht mõtleks tekkivate probleemide lahendamisel raamidest välja.
• Areng (Arendage): Selles etapis viiakse ellu eelmistes etappides tehtud plaanid ja otsused. Oluline on mõista, et selles etapis on teil vaja üksikasjalikku plaani, mis kirjeldab kõiki teie eesmärkide saavutamiseks vajalikke tegevusi. Ka selles etapis mõõdetakse projekti edenemist.
• Kontroll (Kontroll): 6 Sigma metoodika võtmeetapp. Selle peamiseks ülesandeks on projekti elluviimise protsesside pikaajaline täiustamine. See etapp nõuab saadud õppetundide hoolikat dokumenteerimist, kogutud andmete analüüsi ja omandatud teadmiste rakendamist nii projektides kui kogu ettevõttes tervikuna.

6 Sigma on väga sarnane Kanbaniga, ainult ülesande rakendamise kindlaksmääratud etappidega - planeerimine, eesmärkide seadmine ja kvaliteedi testimine. Suure tõenäosusega tuleb 6 Sigmat kasutades oluliselt rohkem meeskonnakoosolekuid kui Kanbani kasutamisel, kuid projekti elluviimise protsess on struktureeritum ja meeskonnal on keerulisem eksida. Ja nagu Kanban, saab ka 6 Sigmat suhteliselt lihtsalt kohandada konkreetse ettevõtte või meeskonna vajadustega. Rangeks nõudeks on vaid projektinäitajate hoolikas mõõtmine ja kontroll teostamisetappides – ilma selleta pole projekti elluviimise protsesside pidev pikaajaline täiustamine võimatu.

6 Sigma tugevused

6 Sigma kontseptsioon annab selge raamistiku projekti rakendamiseks ja protsesside pidevaks täiustamiseks. Eesmärke määratledes, seejärel neid hoolikalt analüüsides ja üle vaadates saate kvantitatiivseid andmeid projekti paremaks mõistmiseks ja paremate otsuste tegemiseks. Kuigi andmete kogumine, analüüsimine ja õppetundide joonistamine võib võtta veidi aega, parandab ja optimeerib see projekti elluviimise protsesse ning säästab seeläbi ressursse tulevikus.

6 Sigma sobib keeruliste projektide jaoks, mis hõlmavad palju uusi ja keerulisi tegevusi. Selline lähenemine võimaldab ellu viia projekti elemente, õppida vigadest ja parandada kvaliteeti tulevikus.

6 Sigma nõrkused

6 Sigma probleem seisneb selles, et kuigi peamiseks deklareeritud eesmärgiks on kulude vähendamine ja efektiivsuse tõstmine, tuleb sageli esile klientide rahulolu. Arvestades mõningaid erinevusi eesmärkides projekti eri etappides, on meeskonnad sageli prioriteetide osas segaduses ja seda pole lihtne vältida.

Lisaks on 6 Sigma peamine juhtmotiiv: "Alati saab kõike teha veelgi paremini." See võib demotiveerida töötajaid, kes ei tunne oma tööga rahulolu. Lisaks, kui tegemist on ühekordse projektiga ja ettevõttel ei ole plaanis edaspidi sarnaseid projekte ellu viia, võivad kõik analüüsi- ja õppetundide kulud olla asjatud.

PRINTS2

NASA pole ainuke riiklik organisatsioon, mis aitas kaasa projektijuhtimise arendamisele. Briti valitsus on pikka aega hinnanud projektijuhtimise tõhusust ja 1989. aastal loodi Briti PRINCE2 metoodika. Nimi pärineb akronüümist " PR objektid IN C kontrollitud E keskkondade versioon 2 ”, mis tähendab „Projektid kontrollitud keskkonnas, versioon 2”. Erinevalt agiilsetest meetoditest ei kasuta PRINCE2 projekti iteratiivset lähenemist. Kui PRINCE2 võrrelda teiste toodetega, võib seda võrrelda klassikalise projektijuhtimise lähenemisviisi ja kvaliteedile keskendumise hübriidiga 6 Sigmast.

PRINCE2 metoodika, erinevalt näiteks PMBOK teadmistepagasist, ei sisalda:

• Projektijuhtimise eriaspektid, näiteks valdkonnapõhised;
• Konkreetsed projektijuhtimise tavad ja tööriistad, nagu Gantti diagramm, WBS jne.

PRINCE2 keskendub projekti juhtimisaspektidele, mis on väljendatud 7 põhimõttes, 7 protsessis ja 7 projekti teemas.

• 7 põhimõtet määratlevad projektijuhtimise üldreeglid vastavalt PRINCE2-le, määratlevad metoodika alused;
• 7 protsessid määratlevad sammud projektitsükli läbimiseks;
• 7 teemat – aspekte, mida projekti edu saavutamiseks jälgitakse.

Projekti alguses palub PRINCE2 meil määratleda projekti kolm peamist aspekti:

• Äriaspekt (kas see projekt toob kasu?)
• Tarbija aspekt (millist toodet on vaja, mida me teeme?)
• Ressursi aspekt (kas meil on eesmärgi saavutamiseks piisavalt?)

PRINCE2 projektimeeskonna struktuur on selgemalt määratletud kui enamikul projektijuhtimismeetoditel. Selle põhjuseks on asjaolu, et PRINCE2 on keskendunud suuremahulistele valitsusprojektidele ja suurtele organisatsioonidele.

PRINCE2 järgi on igal meeskonnaliikmel selge roll kõigis 7 protsessis:

• Projekti algus (Starting ülesa projekt): Selle protsessi käigus määratakse projektijuht ja määratakse kindlaks toote üldised jõudlusnõuded. Projektijuht, kelle põhirõhk on detailidele keskendunud, annab aru projekti juhtkomiteele, kes vastutab projekti üldise juhtimise eest. Juhtkomitee tagab projekti õigel teel püsimise ja vastutab lõppkokkuvõttes projekti õnnestumise eest.
• Projekti algataminea projekt): Selle protsessi käigus kirjutab projektijuht "Projekti algatamise dokumendi", mis sisaldab projekti etapiviisilist plaani. Etapid võivad kesta erinevalt, kuid nagu ka klassikaline lähenemine, järgivad nad rangelt üksteise järel.
• Projektijuhtimine (Directing a projekt): See protsess võimaldab juhtkomiteel võtta projekti edukuse eest üldise vastutuse, takerdumata projektijuhi pädevusse kuuluvatesse üksikasjadesse.
• Lavakontrollmolva a etapp): Projekti elluviimise käigus tehakse ka ideaaltingimustel teatud muudatusi. Stage Control protsess rakendab ühte PRINCE2 põhimõtetest – erandjuhtimise põhimõtet. Projektijuhi kohustus on jälgida elluviimise etapis kõrvalekaldeid projekti planeeritud parameetritest ajastuse, sisu, eelarve jms osas Kui need kõrvalekalded ületavad juhtkomitee poolt projektijuhile antud volitusi (. PRINCE2 terminoloogias - tolerantsid), on projektijuht kohustatud teavitama juhtkomiteed ja pakkuma välja võimalusi olukorrast väljumiseks.
• Toote loomise juhtimine (Haldamine Toode Kohaletoimetamine): Toote loomise haldusprotsess on projektijuhi ja meeskonnajuhi vaheline suhtlus ühe projektitoote loomiseks. Projektijuhi kohustuste hulka selles protsessis kuulub toote loomise volituste delegeerimine meeskonnajuhile ja loodud toote aktsepteerimine.
• Etapi piiride haldamine (juhting a etapp piiri): Selle protsessi käigus annab projektijuht juhtkomiteele kogu vajaliku teabe, et hinnata läbitud etapi tulemusi ja teha otsus järgmisse etappi liikumise kohta.
• Projekti lõpuleviimine (sulgeminea projekt): Üks erinevus PRINCE2 vahel on see, et projekti valmimise protsessi ei eraldata eraldi etapiks või faasiks, nagu klassikalises lähenemises, vaid see viiakse läbi toote loomise viimase etapi osana. Protsessi eesmärk on kinnitada, et projekti toode on vastu võetud või projekt ei saa enam midagi kasulikku pakkuda.

PRINCE2 saab kohandada igas suuruses ja mis tahes teemavaldkonna projektide jaoks. Metoodika pakub konkreetseid soovitusi projekti elutsükli, eeskuju ja kohustuslike dokumentide kogumi muutmiseks vastavalt projekti vajadustele.

PRINCE2 tugevused

• Kohanemisvõime organisatsiooni omadustega;
• Rollide ja vastutuse jaotuse selge kirjelduse olemasolu;
• Keskenduge projektitoodetele;
• Teatud juhtimistasandid;
• Keskenduge majanduslikule teostatavusele;
• Järjekord projektitöö;
• Rõhk kogemuste jäädvustamisel ja pideval täiustamisel.

PRINCE2 nõrkused

• Tööstustavade puudumine;
• Konkreetsete tööriistade puudumine projektis töötamiseks.

Parim projektijuhtimissüsteem... teile!

Projektijuhtimine on teadus, kuid see pole täppisteadus. Selles vallas pole vankumatuid aluseid ja universaalsed lahendused. Kui teil õnnestub leida oma projekti jaoks ideaalne meetod, pidage end väga õnnelikuks, sest enamik vähem õnnelikke juhte peavad oma projektijuhtimissüsteemide loomise ja seadistamise nimel pingutama. Need süsteemid võivad koosneda olemasolevate süsteemide elementidest või luua isegi täiesti nullist, nagu juhtus Apollo missiooniga. Peaasi, et kasutate midagi, mis annab teile vähemalt struktuuri ja võimaldab teil meeles pidada, mis on teie projekti jaoks oluline.

Kuidas saada rahvusvaheline Agile sertifikaat

Neile, kes soovivad saada süstemaatilist arusaama Agile'ist, mõista projektidele ja toodetele paindliku lähenemise eeliseid ja puudusi, leida Agile'i parimad rakendusvaldkonnad ja saada rahvusvaheline ICAgile Certified Professional sertifikaat - meie koolitus