Mjete të shkathëta. Cila është qasja Agile dhe pse i nevojitet biznesit? Metodologjitë e shkathëta kundrejt menaxhimit tradicional të projekteve

Për fillim. Scrum dhe Agile - cili është ndryshimi? Me pak fjalë, Agile është një filozofi, një familje e qasjeve fleksibël për zhvillimin e softuerit. Scrum është një qasje e tillë. Ai ka një vëlla - Kanban. Kjo është gjithashtu një qasje e përdorur në Agile.

Elena Truskova thotë:

Këtë javë përfundova një trajnim dy-ditor Agile/Scrum (shqiptohet “agile” dhe “scrum”). Sipas metodologjive të zhvillimit të shkathët softwareËshtë shkruar shumë letërsi abstruse dhe jo aq abstruse, kam lexuar shumë. Por vetëm pas dy ditësh zhytjeje në temë, më në fund mblodha një kuptim bazë të temës nga e cila po shkruaj këtë shënim.

Agile dhe Scrum ndihmojnë në organizimin e procesit të punës ekipore në mënyrë të tillë që të lëshojë një produkt që është interesant për përdoruesit rregullisht dhe shpesh.

Në disa banka, rruga e një ideje për përdoruesit falë shkathtësisë u shkurtua nga dy vjet në gjashtë muaj në kompani të tjera, cikli gjashtëmujor i zhvillimit u ngjesh në tre. Në kohët tona të trazuara kjo është e vërtetë. avantazh konkurrues, veçanërisht për lojtarët e vegjël.

Parimet e Scrum mund të zbatohen për absolutisht çdo gjë: për shembull, për të punuar në një produkt krijues. Kjo, natyrisht, nuk është "i shkathët kanonik"; Damë apo shkoj?

Disa gjëra nga Agile dhe Scrum madje mund të merren në punë individuale. Siguroni publikimin e rregullt të postimeve, matni ngarkesën e interpretuesit, vlerësoni detyrat e ardhshme në terma kohorë dhe mos harroni të analizoni cilësinë e punës së bërë - shikoni, gjithçka tashmë është menduar për ne. E vetmja gjë që mbetet është ta zbatojmë atë.

I shkathët

(eng.agile - "i shkathët, i shkathët, mendjemprehtë")

Koncepti i fleksibilitetit:

Zëvendësoni llojin e aktivitetit tuaj me fjalën "zhvillim" - dhe këto parime do të bëhen të afërta dhe të kuptueshme.

"Një produkt i punës është treguesi kryesor i progresit", "thjeshtësia si arti i minimizimit punë shtesë" dhe "njerëzit dhe ndërveprimet janë më të rëndësishme se proceset dhe mjetet" - a nuk duket e arsyeshme?

Scrum

(Scrum anglez - nxitim në luftën për topin në regbi)

Vlen të kujtohet këtu se ky është këndvështrimi im personal dhe subjektiv për Scrum. Këtu unë reflektoj mbi zbatueshmërinë e elementeve Scrum si në projekte kreative, larg IT-së, dhe në punë individuale(le të themi mbi një blog). Për ta bërë këtë, do t'ju duhet të hiqni shumë detaje të sakta; Mundohem ta mbaj tekstin të thjeshtë dhe të mos e teproj me terminologjinë e lexuesit.

Fortësia e Scrum qëndron në strukturë. Ekziston një grup i caktuar qasjesh që funksionojnë më mirë së bashku sesa veçmas. Shpresoj se askush nuk do t'ju ndalojë të nxirrni diçka dhe ta përdorni atë.

Në mënyrë tipike, Scrum ndodh aty ku ka një produkt të caktuar që ka vlerë për përdoruesit dhe klientët, dhe ne duhet të kuptojmë sa më shpejt që të jetë e mundur në rrugën drejt qëllimit nëse po vrapojmë tani në drejtimin e duhur - apo nëse duhet të korrigjojmë kursi. Formati Scrum ju lejon të lëshoni versionin tjetër më shpesh, të merrni rregullisht komente dhe të përsosni shpejt produktin, si dhe të përmirësoni procesin e punës.

Nëse punoni në një ekip, Scrum i udhëzon të gjithë në proces që të përpiqen për këmbyeshmëri, aftësinë për të "marrë" një detyrë të varur nëse një fqinj është i sëmurë, ndarjen e aftësive dhe përgjegjësinë kolektive për produktin. Ka pak individualizëm në Scrum. Vendimet merren kolektivisht (sipas parimeve strikte askush nuk mund të bëjë presion dhe t'i detyrojë ata të zgjedhin një zgjidhje tjetër nëse ekipi është i sigurt se ata kanë zgjedhur atë të duhurin).

Të kesh këtë lloj besimi te Scrum nuk është e frikshme, pasi çdo marshim i detyruar zgjat saktësisht një sprint (një periudhë e qartë kohore, zakonisht nga një deri në katër javë). Pasi mbaron sprinti, vjen momenti i analizës: si ia dolëm? Çfarë mund të bëni edhe më mirë herën tjetër?

Prandaj, edhe nëse të gjithë vrapuam me besim në drejtimin e gabuar, do të kemi mundësinë në fund të sprintit ta korrigjojmë dhe të rregullojmë atë që po na dërgon në drejtimin e gabuar. Një ekip Scrum është vetë-organizues dhe vetë-rregullues.

Ekipi në Scrum

Madhësia standarde e një ekipi Scrum është 7 plus ose minus 2 persona. Kjo është, nga pesë në nëntë. Ndodh shkallëzimi i Scrum: ju mund të ndërtoni një sistem të punës për një detyrë gjigante nga 25 ekipe. Por njësia bazë e Scrum është ekipi.

Çdo ekip ka:

• pjesëmarrësit (në rastin e IT - zhvilluesit, cilët janë këta shtatë persona - vendosni vetë)
• pronari i produktit (pronari i produktit). Roli i tij: të kuptojë tregun dhe përdoruesin, të formulojë detyra në gjuhën e biznesit dhe të përdoruesve, të ketë parasysh vetëdijen për drejtimin në të cilin duhet të zhvillohet vlera dhe përfitimi, të shpikë dhe të zgjedhë detyrat për zhvillimin e produktit. Diçka si një menaxher produkti (jo një ekip).
• Scrum master (scrum master, scrum ungjilltar). Roli i tij: monitoron procesin, vëzhgon jetën e brendshme të ekipit, motivon njerëzit, heq pengesat. Diçka si trajner.
  Rreth ekipit ka përdorues dhe palë të interesuara (klientë). Pronari i produktit shkon tek këta njerëz për këshilla.

Pajisja Sprint

Puna Scrum përbëhet nga sprinte. Të gjitha sprintet janë të strukturuara njësoj. Supozohet se me çdo sprint të mëpasshëm ekipi bëhet gjithnjë e më bashkëpunues dhe efektiv. Në Scrum, ju mësoni nga gabimet tuaja, por shpejt - çdo sprint analizoni se çfarë saktësisht keni bërë dhe si dëshironi ta rregulloni atë.

Pronari i produktit ka një listë me ide biznesi për t'i bërë përdoruesit të lumtur. Quhet një grumbullim i produktit, një listë e ideve të produktit. Ai rendit idetë sipas rëndësisë dhe rëndësisë.

Çdo sprint ka një sprint të prapambetur - një listë të renditur idesh që ekipi vendosi të bëjë në sprintin tjetër. Thelbi i Scrum është se vetë ekipi vlerëson kompleksitetin e secilës detyrë dhe vendos se cilat detyra do të përfshihen në sprintin e ardhshëm.

Një detyrë në një sprint ka një peshë të njohur për ekipin (dihet sa kohë do të marrë), i caktohet një interpretues dhe është e kuptueshme dhe e rëndësishme. Nëse nuk e dini se sa kohë do të marrë një detyrë, duhet ta ndani në pjesë më të vogla.

Një ekip gjithmonë planifikon keq në fillim të jetës së tij. Ky është realitet objektiv. Por ajo mban statistika të asaj që arrin të arrijë gjatë sprintit dhe planifikon gjithnjë e më saktë me kalimin e kohës. Ajo ndihmohet nga takimi përfundimtar i sprintit - një retrospektivë. Aty mund të diskutoni pikat e dobëta të sprintit në dalje dhe të gjeni mënyra për t'i bërë gjërat ndryshe.

Zakonisht një sprint i përshtatet 5 ideve plus ose minus 2. Nëse idetë janë shumë të mëdha, ekipi i ndan ato në mënyrë që në çdo sprint të mund të shfaqet diçka e vogël.

Në Scrum, idetë quhen histori të përdoruesve (histori për përdoruesit) dhe formulohen si më poshtë: "Si (roli?) Unë dua (çfarë?) në mënyrë që (pse?)." Kështu, ekipi sheh jo vetëm funksionalitetin, por edhe kuptimin e krijimit të tij, dhe për një rol specifik: përdorues, klient, blerës.

Rezultati i një sprinti është gjithmonë diçka për të treguar për të. Ekipi tregon punën e tyre në demo në fund të sprintit.

Sipas mendimit tim, procesi Scrum është i ngjashëm me punën në një blog ekipor. Një proces i tillë do të ndihmonte në ruajtjen e rregullsisë, të bashkonte ekspertizën e autorëve dhe të mos mblidhte aq shumë sa të mos kesh kohë për ta bërë.

Struktura e sprintit

Sprinti fillon me planifikimin: ekipi ulet dhe diskuton: ne do ta marrim këtë ide, ne nuk do ta marrim atë. Në IT, ky proces mund të zvarritet për disa orë, sepse diskutimi shkon deri në detaje. Në rastin e punës me një blog, kjo mund të kthehet në një diskutim temash dhe planesh për artikuj, të cilët më pas duhet të uleni dhe të shkruani - duke kuptuar se çfarë po shkruajmë, kur dhe pse.

Çdo ditë ka një takim stand-up për 15 minuta. Është e rëndësishme ta bëni atë në këmbë: nëse dikush fillon të bisedojë, pjesa tjetër do të zhvendoset në mënyrë elokuente nga këmba në këmbë dhe do të gërvisht veshët. Ju mund të përdorni një objekt në mënyrë që vetëm një pjesëmarrës të flasë në të njëjtën kohë dhe ta kaloni atë në një rreth.

Secili pjesëmarrës stand-up i përgjigjet tre pyetjeve:

• cfare bera dje
• cfare do bej sot
• çfarë po më ngadalëson

Të gjitha bisedat e detajuara që lindin gjatë procesit shkojnë përtej stand-up-it. Stand-up është një pikë në të cilën ju mund të kapni probleme ose të zbuloni se për ndonjë arsye kolegu im dhe unë po bëjmë të njëjtën gjë në të njëjtën kohë, që do të thotë se njëri prej nesh mund të bëjë diçka tjetër.

Në përgjithësi, Scrum Master duhet të jetë përgjegjës për ruajtjen e të gjitha këtyre rregullave të qarta të sjelljes. Këta janë zakonisht ideologë të teknologjisë, të cilët besojnë në të dhe janë të gatshëm të ndërtojnë një proces për efikasitetin maksimal të kohës së kaluar së bashku. Pa një Scrum Master, proceset do të degjenerojnë në minimumin e mundshëm, sepse personi është dembel dhe ekonomik.

Në fund të sprintit ka një demonstrim (demonstrim) që tregon atë që kemi arritur të krijojmë gjatë sprintit, një rishikim sprint (rishikim i sprintit) me një rishikim të sasisë së mbetur të produktit dhe biseda rreth asaj që po bëjmë, si dhe një retrospektivë. (retro ) - çfarë nuk kemi bërë në mënyrën më të mirë gjatë sprintit dhe duam të përmirësojmë më tej - rreth SI e bëjmë atë.

"Nëse do të kisha tetë orë për të prerë një pemë, do të shpenzoja gjashtë orë duke mprehur sëpatën." (i atribuohet druvarit dhe Presidentit Abraham Lincoln)

A keni punuar ndonjëherë në projekte ose të paktën keni marrë pjesë në projekte? Nëse po, ndoshta e keni vënë re se puna e një ekipi mund të jetë mjaft e vështirë. Dhe edhe nëse vërtetohet, ekziston rreziku që të gjitha përpjekjet të jenë të kota, sepse kërkesat për rezultatin e dëshiruar shpesh ndryshojnë.

Megjithatë, ju mund të thjeshtoni ndjeshëm punën në një projekt dhe të mësoni se si ta menaxhoni atë, duke rritur kështu efikasitetin e ekipit, duke përdorur një sistem fleksibël të menaxhimit të projektit të quajtur Agile ("Agile" ose "Agile"). Në përgjithësi, ne tashmë folëm shkurtimisht për të në mësimin tonë (të katërt), por tani do të flasim për këtë temë në më shumë detaje.

Metoda e shkathët: Përkufizimi dhe historia e shkurtër

Pavarësisht se sa e pazakontë mund të tingëllojë, zhvillimi serioz i softuerit dhe menaxhimi i projektit filloi tashmë në vitet '70 të shekullit të kaluar. Ishte në vitin 1970 që shkencëtari amerikan i kompjuterave Winston Royce përpiloi një dokument të quajtur "Menaxhimi i zhvillimit të të mëdhave. sistemet softuerike" Në të, ai kritikoi zhvillimin sekuencial, duke theksuar se zhvillimi i softuerit nuk duhet të jetë si puna në një linjë montimi (siç bëhet, për shembull, në prodhimin e automobilave), ku pjesë të reja shtohen në faza të njëpasnjëshme.

Në vend që të priste që çdo fazë (fazë) të përfundonte një nga një, Royce propozoi një qasje fazore. Thelbi i tij është që fillimisht të mblidhen të gjitha kërkesat e nevojshme për projektin, pas së cilës përfundon e gjithë arkitektura, krijohet dizajni, shkruhet kodi, etj.

Bazuar në këtë, në vitet '90 ishte e mundur të krijohej një grup metodash fleksibël të zhvillimit të softuerit që mund të zëvendësonin metodat komplekse dhe që kërkonin kohë. Ndodhi kështu:

• Në vitin 1991, u prezantua metoda e zhvillimit të shpejtë të aplikacionit RAD.
• Në 1994, u shfaq një metodë zhvillimi sistemet dinamike DSDM
• Në 1995, u shfaq platforma (korniza) Scrum për zhvillim fleksibël.
• Në 1996, u shfaq metodologjia e zhvillimit të shkathët Crystal Clear, si dhe programimi XP Extreme
• Në 1997, u shfaq metodologjia përsëritëse e zhvillimit të softuerit FDD

Së bashku, këto metoda janë bashkuar nën emrin e përgjithshëm të metodave fleksibël të zhvillimit të softuerit.

Katër vjet më vonë, në 2001, shtatëmbëdhjetë zhvillues softuerësh u mblodhën në vendpushimin Snowbird në Utah (SHBA). Si rezultat i diskutimit të metodave të zhvillimit, u botua "Manifesti mbi zhvillimin e softuerit të shkathët" (i përkthyer nga anglishtja, koncepti "agile" do të thotë "i shkathët", "i shkathët" ose "i shpejtë", por në shumicën e rasteve përkthehet pikërisht si “fleksibël”) . Ai vendosi ritmin për të gjithë punën e mëtejshme në krijimin e softuerit.

Manifesti i shkathët

Manifesti, i krijuar nga programuesit, përfshin 4 ide themelore dhe 12 parime menaxhim efektiv projektet. Çdo sistem i menaxhimit të projektit të bazuar në Agile (për sistemet do të flasim më vonë) bazohet pikërisht në këto ide dhe parime, megjithëse i përdor ato në variacione të ndryshme.

1. Njerëzit dhe ndërveprimet e tyre janë më të rëndësishme se proceset dhe mjetet
2. Softueri i punës është më i rëndësishëm se dokumentacioni
3. Klientët dhe bashkëpunimi me ta janë më të rëndësishëm se një kontratë dhe negocimi i kushteve
4. Gatishmëria për të bërë ndryshime është më e rëndësishme se plani origjinal

Parimet e shkathët:

1. Kënaqni klientët duke ofruar softuer në fillim dhe në mënyrë të vazhdueshme (klientët janë të kënaqur kur softueri i punës mbërrin rregullisht dhe në intervale të rregullta)
2. Ndryshoni kërkesat për produktin përfundimtar gjatë ciklit të tij të zhvillimit
3. Jepni softuerin e punës sa më shpesh të jetë e mundur (një herë në javë, çdo dy javë, një muaj, etj.)
4. Mbështetni bashkëpunimin midis zhvilluesve dhe klientëve gjatë gjithë ciklit të zhvillimit
5. Mbështetni dhe motivoni të gjithë të përfshirë në projekt (nëse, ajo i përballon detyrat e saj shumë më mirë sesa një ekip, anëtarët e të cilit janë të pakënaqur me kushtet e punës)
6. Siguroni ndërveprim të drejtpërdrejtë midis zhvilluesve (mundësia e kontaktit të drejtpërdrejtë kontribuon në komunikim më të suksesshëm)
7. Matni progresin vetëm përmes softuerit të punës (klientët duhet të marrin vetëm softuer funksional dhe funksional)
8. Mbani një ritëm të vazhdueshëm të punës (ekipi duhet të zhvillojë një shpejtësi optimale dhe të qëndrueshme të punës)
9. Kushtojini vëmendje dizajnit dhe detajeve teknike (në sajë të aftësive efektive dhe dizajnit të mirë, ekipi i projektit është në gjendje të përmirësojë vazhdimisht produktin dhe të punojë për ta përmirësuar atë)
10. Përpiquni ta bëni rrjedhën e punës sa më të thjeshtë të jetë e mundur, dhe softuerin të thjeshtë dhe të kuptueshëm
11. Lejo anëtarët e ekipit (nëse zhvilluesit mund të marrin vendimet e tyre, të organizohen dhe të komunikojnë me anëtarët e tjerë të ekipit, duke shkëmbyer ide me ta, gjasat për të krijuar një produkt cilësor rriten ndjeshëm)
12. Përshtatuni vazhdimisht me një mjedis në ndryshim (për shkak të kësaj produkti i përfunduar do të jetë më konkurrues)

Ndërsa mësoni Agile, përveç përmbledhjes së ideve dhe rregullave, sigurohuni që të shikoni këtë video të shkurtër ku specialisti i menaxhimit të projektit, konsulenti dhe trajneri i biznesit Alexey Tachenkov flet për bazat e sistemit.

Për të vënë në praktikë idetë dhe parimet e mësipërme, duhet t'u përmbaheni disa rregullave. Vetëm atëherë menaxhimi i projektit Agile mund të jetë efektiv.

Pikat kryesore në përdorimin e Agile

Metodologjia e shkathët bazohet kryesisht në kontrollin vizual. Më shpesh, pjesëmarrësit e projektit përdorin karta të veçanta me ngjyra kur punojnë për të arritur rezultate. Një ngjyrë sinjalizon përfundimin e planifikimit për disa elementë të produktit përfundimtar, një tjetër tregon përfundimin e zhvillimit të tij, një e tretë tregon gatishmërinë, etj. Inspektimi vizual lejon ekipin të ketë një pasqyrë të qartë të gjendjes aktuale të procesit dhe siguron që të gjithë anëtarët e ekipit të kenë të njëjtin vizion për projektin.

Anëtarët e ekipit dhe klienti punojnë së bashku dhe krah për krah në shumicën e rasteve. Falë kësaj, shumë procese pune që lidhen me informimin e pjesëmarrësve të projektit janë përshpejtuar ndjeshëm. Përveç kësaj, puna së bashku ndihmon në krijimin e një atmosfere të shëndetshme për të frytshme dhe bashkëpunim efektiv dhe arritjen e rezultateve sa më shpejt të jetë e mundur.

Kur menaxheri i projektit, ekipi dhe klienti punojnë së bashku, nuk ekziston rreziku i keqkuptimit të qëllimeve dhe humbjes së informacionit. Të gjitha proceset e punës bëhen sa më transparente, që do të thotë se çdo problem që lind mund të zgjidhet pothuajse menjëherë dhe të gjenden opsionet më të mira për zgjidhjen e tyre.

Vëmendje e veçantë duhet t'i kushtohet menaxherit të projektit. Ai nuk mund të quhet person që jep udhëzime majtas e djathtas. Menaxheri këtu vepron më shumë si një lider që përcakton drejtimin dhe përcakton rregullat e bashkëpunimit dhe punës. Me fjalë të tjera, menaxhimi i shkathët është i adaptueshëm.

Edhe një pikë e rëndësishme Metodologjia e shkathët është ndarja e të gjithë fushës së projektit në disa më të vogla komponentët. Kjo qasje thjeshton shumë procesin e zhvillimit dhe grupe të veçanta të ekipit mund të fokusohen secili në detyrën e tyre specifike.

Duke punuar në një cikël, pjesëmarrësit e projektit zotërojnë aftësi të reja dhe fitojnë njohuri të reja, si dhe analizojnë gabimet e bëra në proces. E gjithë kjo zvogëlon mundësinë për të bërë gabime të ngjashme në të ardhmen (në ciklet e mëvonshme dhe projekte të tjera) pothuajse në zero.

Dhe së fundi, elementi i fundit domethënës i qasjes janë sprintet dhe takimet e përditshme. Sprintet janë periudha kohore të kufizuara nga afate specifike gjatë të cilave një ekip arrin të kryejë detyra të caktuara. Është falë sprinteve që skuadra mund të shohë rezultatet e veprimeve të tyre.

Nëse e ndajmë të gjithë kohën e caktuar për projektin në disa sprinte, do të marrim një numër specifik të tyre; le të jenë 15 prej tyre. Çdo sprint zgjat, për shembull, dy javë. Pikërisht gjatë këtyre dy javëve (koha e caktuar për sprint) pjesëmarrësit takohen çdo ditë për të diskutuar mbi procesin dhe përparimin.

Takimet ditore nuk duhet të kalojnë 15 minuta. Ato janë të organizuara në mënyrë që secili anëtar i ekipit t'i japë vetes përgjigjen e tre pyetjeve:

• Çfarë bëra dje?
• Çfarë do të bëj sot?
• Çfarë më pengon të punoj?

Përgjigja e këtyre pyetjeve ju lejon të mbani kontrollin e procesit, të kuptoni se në cilën fazë ndodhet secili anëtar i ekipit dhe të eliminoni problemet e mundshme në rrugën drejt qëllimit. Për ta përmbledhur, zbatimi i metodologjisë Agile është i mundur nëse plotësohen disa kushte:

1. Rëndësia e projektit është shprehur qartë
2. Klienti merr pjesë aktive në procesin e zbatimit
3. Shtrirja e përgjithshme e punës kryhet hap pas hapi
4. Ju duhet të përqendroheni në një rezultat specifik
5. Numri i një grupi pune: nga 7 në 9 persona

Aktualisht, menaxhimi i projektit me mbështetjen e Agile është më së shumti i zakonshëm në sektorin e IT-së, megjithatë sferën e biznesit fillon ta zotërojë atë. Ky sistem përdoret në trajnime, marketing dhe biznes. Menaxhimi i shkathët i projektit po miratohet nga shumë kompani dhe agjenci qeveritare.

Shembuj: qeveria e Zelandës së Re, qeveria nigeriane, fondi norvegjez i pensioneve, kompania e rrugës së kthimit (softuer), kompania Oreo (prodhimi i biskotave), kompania Aviasales (motori më i madh i kërkimit të biletave të linjës ajrore), kompania Hewlett-Packard (kompania më e madhe amerikane e IT), Sberbank " (ju ndoshta e dini se çfarë është kjo J).

Këto dhe shumë organizata të tjera përdorin një sërë metodash të menaxhimit të projektit të bazuara në Agile. Dhe të flasësh për këto metoda nuk është më pak e rëndësishme sesa të flasësh për vetë metodologjinë.

Metodat popullore të menaxhimit të projektit

Ka shumë metoda të menaxhimit të projektit që përdoren nga të ndryshme kompani moderne. Por Scrum dhe Kanban konsiderohen me të drejtë më të famshmit dhe më të kërkuarit mes tyre.

Metoda Scrum

Ndër të gjitha metodat e sistemit Agile, Scrum dallon në atë që vë theksin kryesor në kontrollin e cilësisë së procesit të punës. Specialistët japonezë që e përshkruan të parët menaxhimit strategjik Hirotaka Takuechi dhe profesori i shkencës dhe teknologjisë Ikujiro Nonaka e quajnë metodën "qasja e rugbit", ku Scrum "lufton për topin".

Metoda është që zhvillimi i projektit ndahet në sprinte, në fund të të cilave klienti merr softuer të përmirësuar. Sprintet janë në kohë strikte dhe mund të zgjasin nga 2 deri në 4 javë. Rrjedha e punës në një sprint përfshin disa faza:

• Përcaktohet fusha e punës
• Takimet 15-minutëshe mbahen çdo ditë në mënyrë që anëtarët e ekipit të mund të rregullojnë punën e tyre dhe të përmbledhin rezultatet e ndërmjetme
• Rezultatet e marra janë demonstruar
• Diskutohen sprintet për të gjetur të suksesshme dhe vendime të këqija dhe veprimet

Në shumicën e rasteve, Scrum përdoret për të punuar me softuer kompleks dhe për zhvillimin e produktit duke përdorur metoda shtesë dhe përsëritëse. Falë tij, produktiviteti i ekipit rritet ndjeshëm dhe koha e shpenzuar në punë zvogëlohet.

Scrum përmirëson rezultatet, ndihmon projektin të përshtatet me ndryshimet, ofron vlerësime më të sakta me më pak përpjekje analize dhe ju lejon të kontrolloni në mënyrë më efektive fazat e punës dhe skenarin e projektit. E gjithë kjo përputhet në mënyrë të përkryer me qëllimet e biznesit.

Metoda Kanban

Kanban është një metodë tjetër që bën punë ekipore më efikase dhe produktive. Kuptimi i tij zbret në dhënien e procesit të zhvillimit transparencë maksimale dhe shpërndarje uniforme ngarkesa e punës midis pjesëmarrësve të projektit. Një tipar tjetër i rëndësishëm i Kanban është se ai i motivon njerëzit të bashkëpunojnë vazhdimisht, të përmirësohen dhe të mësojnë.

Puna duke përdorur metodën Kanban bazohet në disa parime. Së pari, të gjitha informacionet në lidhje me projektin duhet të vizualizohen, gjë që ju lejon të shihni mbivendosjet, gabimet dhe mangësitë dhe t'i eliminoni ato në mënyrë aktive. Së dyti, puna në një detyrë duhet të kryhet njëkohësisht nga i gjithë ekipi - kjo ndihmon në balancimin e përpjekjeve dhe rezultateve të marra dhe eliminon shpërndarjen e pabarabartë të ngarkesës. Dhe së treti, koha e nevojshme për të përfunduar të gjitha detyrat kontrollohet rreptësisht, duke optimizuar procesin dhe duke kursyer kohë.

Ndryshe nga Scrum, Kanban fitoi popullaritet shumë më vonë, por kjo në asnjë mënyrë nuk i zvogëlon meritat e tij ose e bën atë më pak efektiv. Metoda është e dobishme si në fushën e IT ashtu edhe në fushën e biznesit.

Këto janë vetëm shembuj të praktikave bazë të menaxhimit të projektit Agile. Por nuk duhet të neglizhoni metodat e tjera, si PRINCE2, Lean, Six Sigma, XP, CCPM, ECM, Waterfall dhe të tjera. Përveç kësaj, Agile, së bashku me avantazhet e tij, ka edhe disa disavantazhe.

Të mirat dhe të këqijat e Agile

Kur mësoni Agile, është e rëndësishme të njihni si anët pozitive ashtu edhe ato negative të kësaj metodologjie. Le të fillojmë me pozitivet.

Para së gjithash, vlen të theksohet se menaxhimi Agile është shumë fleksibël. Nëse, për shembull, metodologjia tradicionale tregon faza specifike të punës, atëherë Agile përshtatet lehtësisht me përdoruesit e produktit përfundimtar dhe kërkesat e klientit.

Në fakt, numri i defekteve në produktin përfundimtar është minimizuar, sepse është rezultat i një kontrolli të plotë të cilësisë, i cili kryhet në fund të çdo etape sprint.

Përveç kësaj, Agile është i shpejtë në fillim, i lehtë për t'iu përgjigjur ndryshimeve dhe lejon ekipin e zhvillimit dhe klientët të mbajnë komunikim të vazhdueshëm në kohë reale. Përparësitë janë të dukshme, por le të flasim për disavantazhet.

Disavantazhet e metodologjisë janë se, së pari, reagimet e vazhdueshme mund të çojnë në shtyrjen e afatit të projektit gjatë gjithë kohës, duke krijuar kështu kërcënimin e vazhdimit të pafund të punës. Nëse klienti sheh vetëm rezultate, për shembull, por nuk ka idenë e përpjekjes së kërkuar për t'i arritur ato, ai vazhdimisht do të kërkojë përmirësime.

Disavantazhi i dytë është nevoja për të përshtatur dokumentacionin e projektimit me ndryshimin e kushteve të projektit. Nëse ekipi nuk është i informuar siç duhet për ndryshimet ose veçoritë shtesë, kërkesat funksionale ose dokumentet e arkitekturës mund të mos jenë të rëndësishme për ekipin. momenti aktual koha.

Disavantazhi i tretë i rëndësishëm i Agile është nevoja për takime të shpeshta. Ato, natyrisht, ndihmojnë në përmirësimin e efikasitetit të punës, por megjithatë, shpërqendrimi i vazhdueshëm i anëtarëve të ekipit mund të ketë një ndikim negativ në proces, sepse vëmendja e njerëzve në mënyrë sistematike largohet nga detyrat në fjalë.

Këtu përfshihen edhe gjëra të tilla si nevoja për praninë e vazhdueshme të klientit, pamundësia për të bërë plane afatgjata dhe nevoja për specialistë të motivuar dhe shumë të kualifikuar. Nga rruga, kjo e fundit ka të bëjë shumë me zbatimin e menaxhimit të shkathët në aktivitetet e organizatës. Dhe, ndërsa kuptoni Agile, duhet të njiheni edhe me temën e zbatimit të tij.

Zbatimi i Agile

Ka mjaft shembuj të futjes së Agile në punën e kompanive. Dhe pothuajse të gjithë thonë se kjo kërkon një sërë masash të rëndësishme.

Për të filluar, zgjidhet një metodë specifike, e cila varet nga kushtet e projektit. Pastaj përcaktohen detyrat dhe qëllimet, afatet kryesore dhe datat e sprintit, madhësia e ekipit dhe komponentët e tjerë të projektit. Është e rëndësishme të zgjidhni një metodë që plotëson numrin maksimal të kërkesave.

Siç thamë, zbatimi i Agile kërkon një ekip profesionistësh. Të gjithë anëtarët e saj duhet të njohin idetë dhe parimet bazë të metodologjisë dhe të jenë në gjendje t'i zbatojnë ato. Nëse kompania nuk ka njerëz të tillë, punonjësit duhet të trajnohen. Menaxhmenti i një kompanie që ka vendosur të kalojë në përdorimin e Agile duhet gjithashtu të kuptojë qartë nëse organizata është e gatshme për ndryshime, nëse sistemi mund të aplikohet në projektet e saj, etj. Më shpesh, për t'iu përgjigjur këtyre pyetjeve, duhet t'i drejtoheni specialistëve të Agile.

Aktiv fazën tjetër Ftohet një person me përvojë pune me sistemin. Ai e demonstron atë, shpjegon thelbin e sprinteve dhe veprimeve, funksionet e anëtarëve të ekipit të ardhshëm, veçoritë e ndërveprimit midis tyre dhe çështje të tjera. Dhe vetëm pas kësaj formohet ekip i ri, shpërndahen rolet, detyrat dhe përgjegjësitë, zgjidhen mjetet për analitikë, raportim etj.

Faza e fundit do të jetë përvoja e parë me Agile, d.m.th. projekti i parë duke e përdorur atë. Duhet të kuptoni se gabimet, mangësitë, mospërputhjet dhe vonesat janë të pashmangshme. Do t'ju duhet të hiqni dorë nga disa mjete dhe t'i zëvendësoni me të tjera, dhe ndoshta të ndryshoni rolet midis njerëzve në ekip. Përvoja e parë është një proces përshtatjeje, dhe përshtatja është e dyanshme: kompania mësohet me metodologjinë dhe metodologjia përshtatet me kompaninë.

konkluzioni

Për ta përmbledhur këtë rishikim, le të kujtojmë se teoria dhe praktika janë dy gjëra të ndryshme. Metodat dhe teknologjitë e reja dhe zbatimi i tyre janë një lloj sfide për ekipin, dhe si të arrihet efikasitet më të madh- është gjithmonë një çështje individuale. Agile nuk është një ilaç ose një garanci suksesi, por ju lejon të vendosni rrugën e duhur dhe të gjeni udhëzime gjatë rrugës.

Për të zbatuar ndonjë projekt, patjetër do të duhet të ndryshoni diçka, të kërkoni zgjidhje të reja, . Vetëm duke iu përshtatur kushteve të punës që ndryshojnë vazhdimisht dhe kërkesave të klientëve mund të gjejmë mënyrat e duhura për të vepruar. Dhe metodologjia fleksibël e menaxhimit të projektit Agile mund të bëhet një asistent besnik në këtë çështje.

• Përkthimi

"Çdo biznes kërkon gjithmonë më shumë se sa pritej, madje duke marrë parasysh ligjin e Hofstadter."
- Ligji i Hofstadter-it

Videoja më e shikuar në YouTube me temën e shkathtësisë. 744,625 shikime në kohën e publikimit të këtij artikulli. Stili i thjeshtë i prezantimit, fotografi dhe vetëm 15 minuta - më i miri që kam parë. TED po bën një pushim.

Rolet

Ky është Pat pronari i produktit. Ajo nuk i di detajet teknike, por ajo ka një vizion të pamjes së madhe, ajo e di Për çfarë ne po bëjmë një produkt, çfarë problemesh do të zgjidhë dhe për kë.

Kjo palët e interesuara. Ata do ta përdorin produktin, do ta mbështesin atë ose do të përfshihen ndryshe në zhvillim.

Kjo historitë e përdoruesve. Ata shprehin dëshirat e palëve të interesuara. Për shembull, "në një sistem rezervimi të linjës ajrore, përdoruesi duhet të jetë në gjendje të kërkojë me fluturim."

Palët e interesuara kanë shumë ide dhe Pat ndihmon në shndërrimin e ideve në histori përdoruesish.

Kjo ekipi i zhvillimit. Ata që do ndërtoj sistemi i punës.

Gjerësia e brezit

Meqenëse komanda përdor metodologji zhvillimi fleksibël, nuk i grumbullojnë të gjitha këto histori deri në daljen e madhe, përkundrazi i nxjerrin menjëherë dhe sa më shpesh. Ata zakonisht lëshojnë 4-6 histori përdoruesish në javë. Është e tyre xhiros . Është shumë e thjeshtë për t'u matur - numri i tregimeve të përdoruesve në 7 ditë.

Për të ruajtur këtë ritëm dhe për të mos u zhytur në testimin manual të regresionit, ekipi po punon shumë në testim automatik dhe integrim të vazhdueshëm. Prandaj, duhet të shkruani autoteste për çdo veçori, dhe shumica e kodit ka autoteste të integruara.

Problemi është se ka shumë të interesuar dhe kërkesat e tyre nuk mund të plotësohen me 4-6 histori në javë.

Sa herë që ne implementojmë një histori përdoruesi, ata vijnë me disa ide të tjera, të cilat çojnë në edhe më shumë kërkesa.

Çfarë ndodh nëse bëjmë gjithçka që ata na kërkojnë të bëjmë? Do të jemi të mbingarkuar.

Le të themi se ekipi merr përsipër të bëjë 10 histori të reja këtë javë nëse hyrja është 10 dhe dalja është 4-6, atëherë skuadra do të mbingarkohet. Ai do të nxitojë, do të kalojë mes detyrave, do të humbasë motivimin dhe si rezultat do të ulet produktiviteti dhe cilësia. Kjo është padyshim një strategji humbëse.

Scrum dhe XP në këtë rast përdorin metodën "moti i djeshëm". Ekipi thotë: "Kohët e fundit ne kemi bërë 4-6 funksione në javë, cilat 4-6 funksione do të bëjmë javën e ardhshme?"

Detyra e pronarit të produktit është të zgjedhë me mençuri se cilat histori përdoruesish do të zbatohen këtë javë.

Kanban rekomandon të kufizoni veten në disa detyra - limiti WIP. Le të themi se ekipi vendos që 5 është një numër i pranueshëm i tregimeve të përdoruesve, mbi të cilat ata mund të punojnë njëkohësisht pa mbingarkesë, pa u hedhur nga njëra në tjetrën.

Të dyja këto qasje funksionojnë mirë dhe të dyja krijojnë një radhë detyrash, e cila në Scrum quhet Backlog, ose një listë detyrash me prioritet.

Kjo radhë duhet gjithashtu të menaxhohet nëse palët e interesuara kërkojnë 10 histori në javë dhe ekipi dorëzon 4-6 histori, atëherë kjo radhë do të bëhet gjithnjë e më e madhe. Dhe së shpejti Regjistrimi juaj i prapambetur do të planifikohet për gjashtë muaj përpara. Kjo do të thotë, një histori do të presë 6 muaj për publikim.

Ekziston vetëm një mënyrë për të mbajtur nën kontroll listën tuaj të detyrave - fjala "jo"

Kjo është fjala më e rëndësishme për një pronar produkti. Ai duhet ta praktikojë çdo ditë para pasqyrës.

Të thuash “po” është e lehtë. Por detyra më e rëndësishme është vendosni se çfarë të mos bëni dhe mban përgjegjësi për të. Pronari i produktit përcakton gjithashtu sekuencën e asaj që bëjmë tani dhe çfarë më vonë. Kjo është punë komplekse dhe duhet bërë së bashku me ekipin e zhvillimit dhe të paktën një palë të interesuar.

Në mënyrë që të caktojë prioritetet e duhura, pronari i produktit duhet të kuptojë vlerën e çdo historie dhe shtrirjen e saj.

Marrja e Vendimeve

Disa histori janë absolutisht të nevojshme, dhe disa janë vetëm veçori bonus. Disa histori do të duhen disa orë për t'u zhvilluar, të tjera muaj për t'u zhvilluar.

Cila është marrëdhënia midis madhësisë dhe vlerës së tregimit? Në asnjë mënyrë. Më shumë nuk do të thotë më mirë. Vlera dhe kompleksiteti i një detyre është ajo që e ndihmon Patin të japë përparësi.

Si e përcakton një pronar produkti vlerën dhe shtrirjen e një historie? Në asnjë mënyrë.Është një lojë me hamendje. Dhe është më mirë që të gjithë të marrin pjesë në të. Pat komunikon vazhdimisht me palët e interesuara për të ditur vlerën e çdo historie, komunikon me ekipin e zhvillimit për të ditur qëllimin e punës, por këto janë të gjitha supozime të përafërta, pa shifra të sakta. Do të ketë gjithmonë gabime në fillim dhe kjo është normale. Komunikimi është shumë më i vlefshëm se numrat ultra të saktë.

Sa herë që zhvilluesit lëshojnë diçka të re, ne mësojmë më shumë informacion dhe mund të navigojmë më mirë.

Nuk mjafton vetëm përcaktimi i prioriteteve. Për të publikuar histori shpejt dhe shpesh, ju duhet t'i ndani ato në copa që mund të bëhen brenda disa ditësh. Ne duam histori të vogla dhe të qarta në fillim të hinkës dhe të mëdha dhe të paqarta në fund. Duke bërë këtë ndarje në kohë, ne mund të përfitojmë nga zbulimet tona më të fundit në lidhje me produktin dhe nevojat e përdoruesve. E gjithë kjo quhet pastrimi i prapambetjeve.

Pat organizon një takim pastrimi të prapambetur çdo të mërkurë nga ora 11:00 deri në orën 12:00. Ai zakonisht mbledh së bashku të gjithë ekipin dhe ndonjëherë disa palë të interesuara. Përmbajtja e takimeve ndryshon. Përqendrohuni në vlerësimin, në ndarjen e historisë, në kriteret e pranimit.

Pronari i një produkti IT duhet të komunikojë vazhdimisht me të gjithë

Pronarët me përvojë të produkteve identifikojnë dy komponentë të suksesit: pasionin për punën dhe komunikimin. Çfarë problemesh zgjidh pronari i produktit së bashku me ekipin?

Balancimi i kompleksitetit të zhvillimit dhe vlerës së historisë së përdoruesit

Në një fazë të hershme, bilanci kërcënohet nga pasiguria dhe disa rreziqe njëherësh.

Rreziqet

Rreziku i biznesit: "A po bëjmë gjënë e duhur?"

Rreziku social: "A mund të bëjmë atë që duhet të bëjmë?"

Rreziku teknik: "A do të funksionojë projekti në këtë platformë?"

Rreziqet me koston dhe kohën e zbatimit: "A do t'ia dalim me kohë dhe a do të ketë para të mjaftueshme?"

Njohuria mund të konsiderohet si e kundërta e rrezikut. Kur pasiguria është e lartë, ne fokusohemi në marrjen e njohurive - prototipet e ndërfaqes, eksperimentet teknike,

Shkëmbimi midis vlerave të njohurive dhe vlerave të klientit

Nga këndvështrimi i klientit, kurba duket si kjo:

Nga perspektiva e vlerës së klientit, kurba duket si kjo. Ndërsa pasiguritë zvogëlohen, ne mund të fokusohemi në vlerën e klientit. Ne e dimë se çfarë dhe si të bëjmë. Gjithçka që mbetet është ta bëjmë atë. Pasi të kemi zbatuar historitë kryesore, ne do të krijojmë veçori bonus ose do të nisim një projekt të ri.

Kompensimi midis të menduarit afatshkurtër dhe afatgjatë

Çfarë të zbatoni së pari? Rregulloni urgjentisht gabimet ose filloni të zhvilloni një veçori mahnitëse që do të mahnisë përdoruesit. Ose bëni një përmirësim kompleks të platformës që do të përshpejtojë punën në të ardhmen. Ekziston një nevojë e vazhdueshme për të vendosur një ekuilibër midis punës reaktive dhe proaktive.

Bëni gjërat e duhura, bëni gjërat në mënyrën e duhur, apo bëni gjërat shpejt?

Idealisht, të treja në të njëjtën kohë, por në realitet ju duhet të zgjidhni.

Le të themi se jemi këtu. Ne po përpiqemi të krijojmë produktin perfekt me ndihmën e arkitekturës së përsosur. Nëse shpenzojmë shumë kohë, mund të humbasim dritaren e marketingut dhe të përfundojmë me probleme parash.

Ne bëjmë një prototip të shpejtë të produktit. Kjo nuk është e keqe për një afat të shkurtër. Në terma afatgjatë, ne kemi rrezik teknik. Dhe shpejtësia e zhvillimit do të bjerë në zero.

Ne jemi këtu, duke krijuar një tempull të bukur në kohë rekord. Por përdoruesi nuk kishte nevojë për një tempull, ai kishte nevojë për një autobus.

Ekziston një tension i shëndetshëm midis roleve në Scrum

Pronari i produktit fokusohet në ndërtimin e gjërave të duhura. Ekipi fokusohet në ndërtimin e gjërave siç duhet. Scrum Master ose Agile Coach fokusohet në shkurtimin e ciklit reagimet.

Vlen gjithashtu të theksohet rëndësia e shpejtësisë, pasi një cikli i shkurtër reagimi përshpejton të mësuarit. Kjo na lejon të mësojmë shpejt se cilat gjëra janë të sakta dhe si t'i ndërtojmë ato në mënyrë korrekte.

Tregti ndërmjet zhvillimit të një produkti të ri dhe përmirësimit të një produkti të vjetër

Një produkt nuk mund të përfundojë kurrë plotësisht, sepse vazhdimisht ka nevojë për ndryshime. Kur një ekip fillon të punojë për një produkt të ri, çfarë ndodh me atë të vjetër? Transferimi i një produkti nga një ekip në tjetrin është shumë i kushtueshëm dhe i rrezikshëm. Në mënyrë tipike, ekipi ruan një produkt të vjetër ndërsa zhvillon një të ri. Prandaj, përkundrazi, koncepti i "Backlog" nuk i referohet produktit, por ekipit. Një listë e mbetur është një listë e gjërave që pronari i produktit dëshiron nga ekipi. Dhe një grup historish për produkte të ndryshme. Pronari i produktit duhet të zgjedhë vazhdimisht ato përkatëse për zbatim.

Orari i shkatërrimit të historisë

Herë pas here, palët e interesuara do ta pyesin Patin: "Kur do të publikohet funksioni im?" ose "Sa veçori do të publikohen deri në Krishtlindje?" Pronari i produktit duhet të jetë në gjendje të menaxhojë pritjet e përdoruesve. Dhe menaxhoni pritshmëritë në mënyrë realiste.

Dy tendenca - optimiste dhe pesimiste (mund t'i shihni me sy). Distanca midis tendencave tregon se sa e paqëndrueshme është shpejtësia e ekipit. Me kalimin e kohës, këto tendenca do të stabilizohen dhe koni i pasigurisë do të ulet.

Supozoni se një palë e interesuar pyet se kur do të bëhet kjo veçori?

Kjo është një pyetje me një përmbajtje të caktuar dhe një periudhë të pacaktuar. Pat përdor dy linja prirje për t'u përgjigjur. Përgjigja është në prill ose maj.

Një palë e interesuar pyet Patin: "Sa do të bëhet deri në Krishtlindje?" Kjo është një pyetje me afat të caktuar dhe përmbajtje të pacaktuar. Linjat e trendit ndërpresin në një shkallë vertikale segmentin e mundshëm të asaj që ata do të kenë kohë për të zbatuar.

Një palë e interesuar pyet: "A do të kemi kohë t'i realizojmë këto veçori deri në Krishtlindje?" Kjo është një pyetje me një afat kohor të caktuar dhe një përmbajtje fikse. Duke u fokusuar në tendencat, Pat përgjigjet, "Jo". Duke shtuar: "Do të kemi kohë për të bërë kaq shumë deri në Krishtlindje, por kjo është sa kohë do të na duhet për të përfunduar plotësisht gjithë këtë punë."

Zakonisht është më mirë të zvogëlohet përmbajtja e një projekti sesa të rritet koha. Nëse zvogëlojmë përmbajtjen, do të kemi mundësi të shtyjmë afatin. Mund t'i lëshojmë disa këtu dhe të tjerat më vonë.

Pronari i produktit bën llogaritjet në baza javore dhe përdor vetëm të dhëna empirike në vend të mendimeve të dëshiruara. Ai flet sinqerisht për pasigurinë. Ekipi ruan ritmin e punës dhe Pat nuk i bën presion që të shpejtojnë.

Ne ju tregojmë se cila është metodologjia themelore, zbulojmë konceptet bazë, shpjegojmë se si është strukturuar një ekip i shkathët dhe si vlerësohet efektiviteti i tij.

Agile është një familje e tërë e metodologjive fleksibël të menaxhimit të projektit. Është interesante që vetë koncepti i menaxhimit këtu rezulton të jetë jo plotësisht i saktë. Do të ishte më e saktë të përdorni formulën "Agile është një mënyrë e ndërveprimit ekipor që ju lejon të krijoni së bashku produkte." Megjithatë, ne jemi shumë të mësuar me fuqinë e lidhjeve vertikale, hierarkike, kështu që edhe këtu përdorimi i fjalës "menaxhim" është bërë i qëndrueshëm.

Pyetje të papërshtatshme

• Si të siguroheni që një vonesë në punën e një departamenti të mos ndalojë pjesën tjetër?
• Si të sigurohemi që zhvillimi i një plani projekti të mos marrë deri në 30% të kohës së të gjithë zbatimit të tij?
• Në fund të fundit, si mund të sigurohemi që këto plane të ndiqen?

Menaxherët e nivele të ndryshme, nga menaxherët e nivelit të ulët te drejtorët e korporatave dhe zyrtarët e qeverisë, kanë luftuar me këtë për dekada. Por për sa kohë që e vetmja mënyrë e njohur e krijimit pak a shumë të kontrolluar të produkteve dhe zhvillimit të projekteve mbeti hap pas hapi, njëra pas tjetrës, asgjë nuk mund të bëhej me këto sfida.

Për të kaluar në një nivel të ri cilësor puna e projektit, kërkohej një ndryshim themelor i paradigmës.

Doli se thjesht nuk kishte nevojë të kërkonte përgjigje për shumicën e këtyre pyetjeve të dhimbshme. Ato duhet të hiqen dhe konceptet që i kanë lindur, nëse është e mundur, të shfuqizohen. Pra, në vend të zhvillimit të ujëvarave hap pas hapi, u ngritën metodologji fleksibël.

Bëje menjëherë!

Masa kryesore e efektivitetit e adoptuar në metodologjinë e shkathët është produkti. Ndërsa të tjerët janë vetëm duke përgatitur dokumentacionin, ekipet e shkathët përpiqen të paraqesin një prototip pune. Kjo është si formula e famshme motivuese "të bësh është më mirë se sa e përsosur". Zbatoni funksionin e parë dhe filloni ta testoni, krijoni një tjetër, dhe kështu me radhë pa pushim - ky është rregulli kryesor.

Faza e zhvillimit në Agile, kjo gjë "kohë pas kohe", quhet përsëritje. Përsëritjet kanë të njëjtën kohëzgjatje gjatë gjithë projektit dhe mesatarisht dy javë. Brenda një përsëritjeje të vetme, kryhet një detyrë specifike, vetia kryesore e së cilës është se zgjidhja e saj duhet të përditësojë produktin në version i ri ose rrisin efektivitetin e tij. Mbi këtë bazë zgjidhen detyra të tilla.

Si siguron fleksibilitet një qasje përsëritëse? Falë faktit që procese të veçanta mund të ecin paralelisht dhe të pavarur nga njëri-tjetri. Po, duhet të pranojmë se kjo mund të rrisë kohën përfundimtare të zhvillimit nga një ide në një produkt plotësisht të përfunduar. Por fakti është se një produkt funksional, funksional që tashmë është i aftë të takojë konkurrentët dhe përdoruesit e këndshëm është krijuar në Agile shumë më herët dhe natyra ciklike e përmirësimeve na lejon të arrijmë zhvillimin shumë më të mirë të funksioneve dhe aftësive të tilla që do të nuk janë arritur asnjëherë gjatë punës së planifikuar.

Organizimi horizontal

Një ekip i shkathët është ndërtuar mbi parimet e vetëorganizimit dhe barazisë relative të të gjithë pjesëmarrësve. Edhe personi që shumë e imagjinojnë si kreun e projektit, pronarin e produktit, në fakt është vetëm një personifikimi i kërkesave për produktin. Ai luan rolin e bartësit të njohurive për atë që pritet të jetë rezultati përfundimtar, por nuk është aspak një menaxher në kuptimin standard. Meqenëse zakoni i hierarkisë është i vështirë për t'u çrrënjosur, në shumë ekipe pronari i produktit, për fat të keq, duhet të marrë përsipër funksione mbikëqyrëse. Por ideali i zhvillimit të shkathët është përgjegjësi kolektive anëtarët e ekipit përballë njëri-tjetrit.

Parimet për formimin e ekipeve të shkathët ndryshojnë në varësi të projektit specifik. Për shembull, në shërbimin muzikor Spotify ato janë ndërtuar si kjo:

Një vlerë tjetër e rëndësishme e ekipeve të shkathët është shkëmbimi i njohurive. Një anëtar i ekipit nuk duhet të kufizohet në fushën e tij të ngushtë, por duhet të përpiqet për ndërdisiplinaritet. Kjo nuk do të thotë që një programues duhet të jetë gjithashtu një shitës, dhe një dizajner duhet të jetë një tregtar.

Por kanë njohuritë bazë në lidhje me specializimet përkatëse në zhvillimin e shkathët është e nevojshme.

Fillimisht, supozohej se kjo thjesht do të rriste efikasitetin e punës dhe nivelin e mirëkuptimit të ndërsjellë në ekip, por sot, me zhvillimin e neuroshkencës, është bërë e qartë se kjo qasje siguron gjithashtu mbajtjen e trurit në gjendje të mirë dhe krijimi dinamik i lidhjeve të reja nervore. Ky ndër-pjalmim i njohurive në Agile quhet një formë t-je. Ilustrimi i mëposhtëm do të shpjegojë pse kjo është kaq më mirë se çdo fjalë.

Si të zbatohet Agile?

Kalimi nga zhvillimi i ujëvarave, ende i zakonshëm në shumë organizata, në metodat e shkathëta të punës në projekte mund të jetë mjaft i dhimbshëm.

Së pari, ju duhet të hiqni hierarkinë dhe në të njëjtën kohë të siguroheni që të gjithë pjesëmarrësit në procese të mund të ndajnë në mënyrë të barabartë përgjegjësinë për rezultatin.

Së dyti, Kalimi në zhvillimin përsëritës do t'ju detyrojë të përqendroheni në sigurimin që çdo fazë të jetë e garantuar për të sjellë diçka të re në produkt. Kjo nuk është e lehtë, inercia e zhvillimit të planifikuar do t'ju ndjekë për muajt e parë.

Sistemi operativ i fabrikës Toyota është bërë tashmë një model klasik dhe i suksesshëm menaxhimi. Secili punonjës i ndërmarrjes kishte mundësinë të ndalonte transportuesin në çdo kohë për të eliminuar një defekt, mosfunksionim ose për të bërë të tijën propozim racionalizimi. Filozofia Agile bazohet në këtë qasje. Fillimisht, metodologjia Agile rreth 10-15 vjet më parë ishte një metodë e zhvillimit të softuerit në ekipe të vogla. Për momentin, metodologjia Agile është një kulturë e re për menaxhimin e ndërmarrjeve të mëdha. Sot, çdo menaxher progresiv e di se çfarë është Agile.

Produktet dhe shërbimet krijohen, si rregull, sipas një skeme të vetme klasike. Kjo vlen veçanërisht për industrinë e IT. Kjo skemë quhet ujëvarë ose metodologji përsëritëse e zhvillimit, dhe në anglisht– zhvillimi i ujëvarës (“ujëvara”). Për çfarë arsye skema e ka këtë emër? Puna është se nëse tashmë keni miratuar një plan për një produkt softuer, nuk mund ta pezulloni ose të bëni rregullime përpara zbatimit. Ekziston një parim krejtësisht i ndryshëm Metodologjia e shkathët. Ujëvara është një koncept që nuk vlen për të. Kjo është një qasje cilësore e re për krijimin e produkteve. Baza e metodologjisë është një ide e thjeshtë - secili pjesëmarrës ka mundësinë të bëjë propozime të dobishme për optimizimin e procesit, ndalimin e transportuesit në mënyrë që të rimendojë detyrat dhe kauzën e përbashkët.

Metodologjia e shkathët ka një kornizë me një sërë karakteristikash. Midis tyre:

• Përgjigje e shpejtë ndaj ndryshimeve.
• Organizatë e pavarur procesi i prodhimit.
• Parashikueshmëria.
• Disponueshmëria e reagimeve të vazhdueshme dhe të vazhdueshme.
• Kufizimi i rrezikut.

Në shumë ndërmarrje të zhvillimit të produkteve, specialistët që zgjidhin probleme të rëndësishme për prodhimin shpërndahen nëpër departamente të ndryshme, shpesh në konflikt me njëri-tjetrin. Kjo është veçanërisht e vërtetë për punonjësit e departamentit të operacioneve, zhvilluesit dhe testuesit. Nëse produktet nuk mund të shiten siç duhet dhe nuk mund të krijohen të ardhura prej tyre, palët në konflikt fajësojnë njëra-tjetrën. Në të njëjtën kohë, të gjithë janë zakonisht fajtorë në situata të tilla.

Metodologjia e shkathët është një qasje që përfshin praninë e secilit që zhvillohet produkt software. Në të njëjtën kohë, çdo specialist bën punën e tij. Metodologjia e shkathët bën të mundur të shihet se të gjithë pjesëmarrësit në proces janë të bashkuar nga një qëllim - krijimi i produkteve me cilësi të lartë për klientët e tyre.

Kur aplikohet metodologjia Agile, e gjithë kultura e biznesit të kompanisë ndryshon. Programet MBA përmbajnë një kurs të plotë mbi strukturën organizative të një ndërmarrje, gjatë studimit të të cilit mund të hasni termin "ekuilibër", kur në kompanitë fillestare dhe bizneset fillestare të gjithë punonjësit dhe pjesëmarrësit zgjidhin problemet e zakonshme. Praktika tregon se në ndërmarrje të tilla ekipet janë më të bashkuara dhe punojnë me efikasitet dhe efektivitet të lartë. Kur bëhet fjalë për sjelljen e ideve të reja në treg dhe rritjen e efikasitetit, metodologjia Agile është mjeti optimal.

Sigurisht, disa kompani nuk kanë nevojë për metodologjinë Agile. Ne po flasim, për shembull, për departamentet qeveritare, pasi baza e aktiviteteve të tyre janë normat legjislative. Ndërveprimi me shtetin është i pamundur nëse rregullat e lojës ndryshojnë rregullisht.

Kjo do të thotë, infrastruktura organizative mund të paraqitet në dy versione, rrënjësisht të ndryshme nga njëra-tjetra. E para është një kompani e rreptë burokratike që respekton një sërë formalitetesh. Ky opsion ka të drejtë të ekzistojë dhe funksionon shkëlqyeshëm në kushte të caktuara. Lloji i dytë janë startup-et në fazat e hershme që bashkojnë njerëz me të njëjtin këndvështrim dhe një qëllim të përbashkët, të cilët krijojnë diçka thelbësisht të re. Metodologjia e shkathët është sigurisht më afër ekipit emocional që punon për të prodhuar një produkt cilësor. Nëse shfaqen probleme në çdo fazë, të gjithë specialistët e ndërmarrjes ose pjesëmarrësit në startup i zgjidhin ato brenda kornizës së metodologjisë Agile.

Parimet themelore të metodologjisë Agile

Ekziston një manifest i shkathët, i cili flet për parimet themelore të metodologjisë:

1. Gjëja më e rëndësishme është të dorëzoni një produkt të vlefshëm rregullisht dhe paraprakisht, duke kënaqur kështu nevojat e klientit. Në përputhje me këtë parim të metodologjisë Agile, krijuesit e produkteve janë të detyruar jo vetëm të zbatojnë kërkesat e përshkruara në dokumentet e projektimit, por edhe t'i bëjnë të ditur konsumatorit sa më shpejt që të jetë e mundur se çfarë lloj produkti do të jetë, me çfarë tipare dhe karakteristikash. Nëse produkti nuk e kënaq klientin, është urgjentisht e nevojshme korrigjimi i tij duke marrë parasysh komentet. Meqenëse kur futni një produkt të ri në mjedisin e tregut, ekziston një rrezik i madh për të bërë gabime, është logjike të përdoret kërkesat teknike për të krijuar një produkt minimal të zbatueshëm (MVP), detyra kryesore e të cilit është të kontrollojë se sa cilësitë kryesore janë të kërkuara nga blerësit dhe të vlerësojë nivelin e kërkesës.
2. Kërkesat mund të ndryshohen dhe kjo do të perceptohet pozitivisht nëse flasim për rritjen e cilësive konkurruese të produktit. Zakonisht ato ndryshohen në fund të fazës përfundimtare të zhvillimit. Ky parim i metodologjisë Agile është shumë i rëndësishëm sot, sepse produktet e fushave të teknologjisë së lartë në sa më shpejt të jetë e mundur vjetërohet dhe ia lë vendin një të reje. Ju mund të formuloni një sërë kërkesash për një produkt tashmë në fund të krijimit të tij. Kjo zakonisht shkaktohet nga ndryshimet në treg ose konkurrentët. Le të theksojmë se zbatimi i këtij parimi është i pamundur nëse po flasim për një model të menaxhimit të kaskadës, ose nëse është real, por do t'i kushtojë sponsorit një shumë të rregullt. Por sa më shumë teknologji të bashkohen, aq më e rëndësishme do të bëhet përgatitja e versionit të ardhshëm të produktit për të qëndruar përpara konkurrentëve.
3. Ekipi dhe klienti duhet të ndërveprojnë vazhdimisht në të gjitha fazat e krijimit të produktit. Ky rregullështë afërsisht e njëjta natyrë me dëshirat e klientit. Kjo është gjëja më e rëndësishme. Nëse nuk ka ndërveprim të vazhdueshëm, është e vështirë të arrini qëllimet tuaja.
4. Metodologjia Agile thotë se projektet duhet të zbatohen ekskluzivisht nga profesionistë të motivuar. Kujdesuni të krijoni kushtet e duhura dhe besoni specialistëve. Në këtë rast, probabiliteti i zbatimit me cilësi të lartë të projektit është shumë i lartë. Shkenca moderne sugjeron se puna intelektuale është e vështirë të stimulohet me stimuj financiarë. Prandaj, duhet të bashkëpunoni vetëm me ata specialistë për të cilët motivimi kryesor është vetë projekti. Gjithçka që u nevojitet është të jenë në gjendje të punojnë në kushte të pranueshme dhe të fitojnë besimin e klientit.
5. Mënyra më e mirë komunikimet - kontakt personal. Është e dëshirueshme që të gjithë personat e përfshirë në projekt të vendosen në një territor të përbashkët. Le të jetë një ndërtesë. Në mënyrë ideale, vetë klienti duhet të jetë atje.
6. Projekti përparon nëse produkti funksionon. Klienti është i interesuar mallra të gatshme me karakteristika të caktuara. Një fazë tjetër e përfunduar me sukses e procesit nuk do të thotë asgjë për të. Klienti duhet të shohë që produkti po zhvillohet, dhe më e rëndësishmja, ai funksionon dhe plotëson kërkesat e deklaruara. Nëse forma dhe përmbajtja e tij janë afër modelit të dëshiruar, kjo do të thotë se zhvilluesit po veprojnë në mënyrë efektive.
7. Sponsorët, klientët dhe zhvilluesit duhet të shqetësohen për sigurimin e një ritmi konstant të aktivitetit. Nëse të gjithë pjesëmarrësit në proces veprojnë me një ritëm të qëndrueshëm, ata pushojnë së shqetësuari për mundësinë e një emergjence ose afatesh të humbura.
8. Vëmendje duhet t'i kushtohet gjithashtu përsosmërisë teknike dhe cilësisë së projektimit. Metodologjia e shkathët thotë se zhvillimi i projektit duhet të jetë fleksibël, pa kompromentuar cilësinë e produktit ose thjeshtuar karakteristikat e tij. Vini re se kjo shpesh përdoret për të përshpejtuar procesin e krijimit të një projekti dhe për ta optimizuar atë.
9. Mos harroni parimin e thjeshtësisë. Duke e përdorur atë, ju ulni në minimum gjasat për të kryer veprime të panevojshme. Çështja nuk është të thjeshtojmë karakteristikat e produktit, por të heqim qafe operacionet e panevojshme dhe të mos përfshijmë në dizajn diçka të panevojshme për përdorimin e synuar.
10. Ekipet vetë-organizuese gjenerojnë gjithmonë idetë më të mira plane arkitektonike, teknike e të tjera. Autorët e Manifestit të Agile janë të sigurt për këtë. Prandaj, të gjithë anëtarët e ekipit duhet të zhvillojnë kërkesat dhe të marrin vendime së bashku. Nëse anëtarët e ekipit kanë interesa të përbashkëta dhe qëllime të përbashkëta, vetëorganizimi bëhet më efektiv.
11. Kushtet e jashtme po ndryshojnë vazhdimisht. Në këtë drejtim, duhet analizuar dhe përshtatur vazhdimisht situatës, si dhe të kërkohen metoda për të përmirësuar efikasitetin operacional. Metodologjia e shkathët është e fokusuar veçanërisht në fleksibilitetin e zhvilluesve. Kjo është ajo për të cilën duhet të përpiqeni.

Mendimi i ekspertit

Perspektivat për metodologjinë e shkathët në Rusi

Andrey Kocheshkov,

Analisti kryesor i Shtëpisë Botuese OJSC Prosveshcheniye

Metodologjia e shkathët ka një sërë përparësish, kryesore prej të cilave është fleksibiliteti dhe aftësia për t'u përshtatur, përshtatur me çdo situatë dhe procesi organizativ. Metodologjia e shkathët është alternativa më e mirë për projektet, fundi i të cilave është "i hapur". Ky mund të jetë krijimi i një loje kompjuterike, sistemi operativ ose shërbimi në internet. Megjithatë, fleksibiliteti përfundimisht mund të çojë në humbje të fokusit dhe ulje të parashikueshmërisë.

Është jashtëzakonisht e rëndësishme të dallohen gabimet kur përdoret një qasje e shkathët nga mangësitë e metodologjisë Agile. Do të duhet pak kohë para se të realizohen përfitimet e metodologjisë. Është e nevojshme të përshtatet qasja me situatën aktuale në një biznes të caktuar dhe gjatë kësaj periudhe është e mundur që të bëhen shumë gabime. Por fakti mbetet: Metodologjia e shkathët po bëhet një nga paradigmat më të njohura si në Rusi ashtu edhe në mbarë botën.

Metodologji fleksibël: Agile, Lean, Scrum dhe të tjera

Manifesti i shkathët përcakton parime specifike. Bazuar në to, u formua një metodologji fleksibël zhvillimi e quajtur Agile.

• Modelimi i shkathët (AM). Këtu zbatohen procedurat e modelimit (përfshirë verifikimin me kodin e modelit) dhe dokumentacionin gjatë krijimit të softuerit. Më pak vëmendje i kushtohet procedurave për hartimin dhe ndërtimin e diagrameve në UML. Nuk përmenden fusha të tilla si zhvillimi, testimi, menaxhimi i projektit, vendosja dhe mirëmbajtja.
• Procesi i Unifikuar i Agile (AUP) është një version i unifikuar i metodologjisë RUP (IBM Rational Unified Process) i krijuar nga Scott Ambler. AUP përcakton një model të zhvillimit të softuerit për aplikacionet e biznesit.
• Agile Data Method (ADM) është një metodologji përsëritëse për zhvillimin e softuerit të shkathët në një kompleks që thekson zhvillimin e zgjidhjeve dhe kërkesave. Ekipe të ndryshme ndërfunksionale bashkëpunojnë me njëri-tjetrin.
• Metoda Dinamike e Zhvillimit të Sistemeve (DSDM) është një metodë në rritje dhe përsëritëse e bazuar në Zhvillimin e Shpejtë të Aplikimit (RAD). Theksi vihet në maksimizimin e përfshirjes së konsumatorit fundor në krijimin e produkteve.
• Procesi i Unifikuar Thelbësor (EssUP). Autori i qasjes është Ivar Jacobson. Qasja është e pajisur me metoda të krijimit të softuerit përsëritës. Theksi është në arkitekturën e produktit dhe praktikat e ekipit të huazuara nga RUP, CMMI dhe Agile Development. Thelbi i idesë është të përdoren vetëm ato metoda dhe teknika që përdoren në një rast të veçantë. Është zgjedhja e tyre ajo që është baza për përcaktimin e procesit të synuar. Kjo qasje ndryshon nga RUP me metoda dhe praktika të ndërlidhura. Ekziston gjithashtu fleksibilitet dhe aftësia për të izoluar elementët e nevojshëm nga gjithçka që është në dispozicion.
• Programim ekstrem (XP), ose programim ekstrem. Thelbi i metodës është përdorimi i teknikave më të mira tashmë të disponueshme në fushën e krijimit të softuerit dhe përmirësimi i tyre. Kjo qasje dhe praktika e zakonshme ndryshojnë nga njëra-tjetra, veçanërisht në atë që në rastin e fundit programuesi kryen një kontroll të vazhdueshëm të kodit të shkruar nga kolegu i tij. Programimi ekstrem përfshin testimin paralel, i cili kontribuon në lëshimin më të shpejtë të produktit, por në të njëjtën kohë rrit rreziqet.
• Zhvillimi i Drejtuar nga Veçoritë (FDD). Në kuadrin e përdorimit të metodës, ekziston një ndalim kryesor, domethënë që zbatimi i secilit funksion duhet të kryhet brenda dy javësh dhe jo më shumë. Në mënyrë ideale, zhvillimi i tij bëhet me një lëvizje. Nëse kjo nuk është e mundur, funksioni ndahet në disa dhe zbatohet pa probleme.
• Marrja e Realit (GR) - kur përdorin metodën, ata nuk përdorin procedurat e specifikimeve funksionale të përdorura për aplikacionet në internet. Zhvillimi fillon me ana e kundërt, domethënë, së pari ata mendojnë për dizajnin dhe ndërfaqen, dhe më pas për përmbajtjen funksionale.
• OpenUP (OUP) - zhvillimi i qasjes bazohet në RUP. Metoda përcakton një metodë përsëritëse-rritëse të krijimit të softuerit. Në kuadër të qasjes thuhet për cikli jetësor zhvillim (fazat e nisjes, përsosjes, zhvillimit dhe transferimit te klienti). Metoda zbatohet në disa faza, duke kontrolluar disa pika kontrolli, gjë që ndihmon në rritjen e efikasitetit të kontrollit dhe monitorimit të zbatimit të projektit. Të gjitha vendimet në lidhje me projektin merren në kohë.
• Zhvillimi i dobët i softuerit. Baza e qasjes është koncepti i menaxhimit të dobët të një kompanie prodhuese (prodhimi i dobët, prodhimi i dobët).
• Scrum është një nga metodat më të njohura për zhvillimin e softuerit të shkathët dhe përcakton rregullat për menaxhimin e procesit të prodhimit duke përdorur metoda të njohura. Në këtë rast, theksi vihet në përfshirjen e klientit në zhvillim (kur të përfundojë faza tjetër, është e mundur të ndryshohen ose sqarohen kërkesat për produktin që krijohet). Kjo ju lejon të identifikoni mangësitë dhe të rregulloni produktin.

Metodologjia Agile Scrum është një nga teknologjitë më të njohura

Pothuajse metodologjia më e zakonshme Agile është Scrum. Emri vjen nga regbi. Aktualisht, ky është emri i metodologjisë më të strukturuar fleksibël të zhvillimit, Agile. "Scrum" në fushën sportive është një veprim intensiv ekipor që synon arritjen e qëllimit - marrjen e topit për sulmin pasues të armikut.

Periudha Scrum është e shkurtër. Në këtë fazë të ragbit marrin pjesë sportistët më të mirë me përgatitje të shkëlqyer, pasi është mjaft traumatike. Nëse nuk ka lojtarë të stërvitur dhe të fortë, Scrum thjesht nuk kryhet. Metodologjia Scrum po bëhet gjithnjë e më e përhapur në Rusi. Le ta shohim më në detaje.

Baza e Scrum është sprinti. Ky është emri për veprimet fikse afatshkurtra për të krijuar dhe siguruar konsumatorin me një produkt funksional me karakteristika të reja. Aftësitë e tij në të njëjtën kohë tejkalojnë ato që ishin më parë. Periudha e sprintit është fikse, dhe nga ajo varet parashikueshmëria dhe fleksibiliteti i procesit të krijimit. Nëse afati kohor është i shkurtër, indikacionet për fleksibilitet dhe parashikueshmëri bëhen më të larta, por kostoja relative e çdo përsëritjeje, si dhe koha e shpenzuar për organizimin dhe takimin me klientin dhe anëtarët e ekipit, rriten gjithashtu.

Një element i rëndësishëm i metodologjisë është grumbullimi i produkteve. Kjo është një listë e kërkesave për rezultati përfundimtar. Kërkesat këtu janë të strukturuara qartë sipas nivelit të rëndësisë. Është nga lista që merren detyrat për sprintet e mëvonshme. Ju mund të bëni rregullime dhe shtesa në listë pasi karakteristikat janë sqaruar dhe produktet shiten.

Ekziston një fazë planifikimi në të cilën përcaktohen cilësitë e reja funksionale të produktit të krijuar për sprintin e ardhshëm. Pas zgjidhjes së problemit, krijohet një Sprint Backlog. Ai mbetet i pandryshuar gjatë gjithë kohëzgjatjes së tij.

Metodologjia përcakton gjithashtu rolet e strukturuara në projekt:

• Scrum Master është ndërmjetësi midis ekipit dhe klientit.
• Pronari i produktit përfaqëson klientin, formon, i jep prioritet Regjistrimit të Produkteve dhe pranon rezultatet e përkohshme të punës.
• Ekipi - një ekip projekti ku nuk ka role të veçanta. Është një sistem vetë-organizues që përfshin profesionistë ndërfunksionalë dhe të motivuar.

Metodologjia ofron një sërë avantazhesh për financuesit, përkatësisht:

• ofron një mundësi për të kursyer para duke mos punuar në dokumentet e projektit për një kohë të gjatë;
• ju lejon të kontrolloni plotësisht buxhetin e projektit;
• bën të mundur kryerjen e rregullimeve pa humbje të konsiderueshme financiare për ndërmarrjen;
• ju lejon të lansoni produktet herët dhe të merrni të ardhurat e para prej tij.

Problemi kryesor në këtë rast është pyetja regjistrimi ligjor ky lloj aktiviteti dhe ndërveprimi me ekipin e jashtëm të zhvillimit.

Pse keni nevojë për metodologjinë e menaxhimit të shkathët?

• Sistemi ju lejon të ndiheni mirë gjatë një krize dhe në situata të pasigurta, të fitoni të ardhura, të mbroni biznesin tuaj dhe të përdorni me kompetencë burimet dhe mundësitë në dispozicion.
• Metodologjitë e shkathëta preferohen nga të dyja ndërmarrjet e mëdha të përfshira në zbatimin e metodave fleksibël të menaxhimit, dhe kompanitë e vogla. Për metodologjinë më të fundit Agile - opsioni më i mirë. Këtu po flasim për objektet hotelierike. klinikat dentare dhe zyra, sallone makinash; Për më tepër, metodologjia Agile ju lejon të "akordoni" proceset e biznesit në fusha të tilla si organizimi aktivitetit të jashtëm ekonomik, ndërtimin e sistemeve të shitjeve dhe menaxhimin e krizave.
• Metodologjia e shkathët përdoret në menaxhim, marketing, industri financiare dhe menaxhimin e personelit. Falë tij, ju mund të arrini zbatimin ultra të shpejtë të projektit dhe rezultate të shkëlqyera.
• Metodologjia e shkathët ka të bëjë para së gjithash me të menduarit fleksibël dhe vetëm më pas me mjetet. Për ta përdorur me sukses, duhet të futni ndryshime të caktuara në mentalitetin dhe kulturën e punës me projekte në ndërmarrje.
• Ka shumë metoda në Agile. Më të njohurat sot janë Scrum dhe Kanban.
• Metodologjia e shkathët ndihmon për ta çuar biznesin tuaj në një nivel tjetër, duke marrë parasysh aftësitë ekzistuese, burimet dhe aftësitë praktike të punonjësve.
• Metodologjia e shkathët është e përshtatshme për çdo ndërmarrje të fokusuar në gjenerimin e më shumë të ardhurave dhe rritjen e ndikimit në mjedisin e tregut.
• Metodologjia e shkathët siguron kërkimin dhe futjen e teknologjive të reja që lidhen me përparimet, zhvillimin e brendshëm aktiviteti sipërmarrës, kreativiteti i qasjes dhe të menduarit në organizata të mëdha.

E gjithë sa më sipër është vetëm fillimi. Shumë ekspertë dhe drejtues të biznesit ndërmarrjet e mëdha Ne kemi besim: Metodologjia e shkathët është e ardhmja e industrisë moderne ekonomike.

Mendimi i ekspertit

Zbatimi i metodologjisë Agile për të përmirësuar efikasitetin e stafit

Maria Onuchina,

Drejtor i Departamentit të Menaxhimit të Aseteve në Becar Asset Management Group, Moskë

Ne kemi modifikuar hapësirën tonë të zyrës për të kaluar në menaxhimin Agile:

Faza 1.Organizimi i vendeve të punës.

Gjatë një muaji, ne studiuam vendet e punës së stafit, identifikuam departamente ku kërkohet heshtje e plotë për të kryer punë efektive (kjo është, për shembull, kontabiliteti) dhe i kushtuam vëmendje departamenteve që punësojnë specialistë që janë vazhdimisht larg dhe nuk shpenzojnë më. se 3 dite ne zyre. Ne morëm një orar që tregon numrin e punonjësve dhe specifikat e përgjegjësive të tyre të punës. Duke marrë parasysh informacionin e marrë, filluam të rikonstruktojmë zyrën.

Për punonjësit, aktivitetet e të cilëve kërkojnë prani të vazhdueshme në punë, janë pajisur vendet e përhershme. Personelit të lëvizshëm iu dha hapësirë ​​e përkohshme në zonën e hapur. Mund të vini atje, të zini vendin tuaj të preferuar dhe të ndizni akses në distancë. Gjithashtu i kushtuam vëmendje zonave informale: dhomave për relaksim, negociatash dhe një kafene pune.

Ne u përpoqëm të organizojmë hapësirën në zyrë në mënyrë që punonjësit të kenë mundësinë të ndryshojnë vendndodhjen në çdo kohë:

• nëse është e nevojshme, jini vetëm;
• bashkohuni në mini-grupe;
• të mbajë një takim ndërmjet departamenteve në çdo përbërje.

Numri i zonave të tilla brenda projektit është ndikuar nga pjesa e biznesit të cilit i përket procesi.

Faza 2.Përshtatja e punëtorëve.

Më pas, ne u siguruam specialistëve ndihmë në përshtatje. Shumë njerëz kanë frikë nga ndryshimet që nënkupton metodologjia Agile, edhe nëse ato janë për mirë. Me kalimin e disa javëve, u bë e qartë se punonjësve u pëlqente gjithçka dhe u larguan nga zyrat e tyre. Në këtë fazë, ia vlen t'i bëni stafit të kuptojë se nëse nuk ka ndryshime në proceset e biznesit, ndërmarrja rrezikon të largohet nga hapësira e tregut.

Faza 3.Prezantimi i zgjidhjeve të pazakonta.

Prezantuam një sërë veçorish: organizuam një kinema në zonën e përbashkët, ku shfaqen prezantime gjatë punës, dhe filma në mbrëmje, si dhe një mur me foton e një peme, ku janë shkruar vlerat e kompanisë.

Zyra e re është e pazakontë, por e rehatshme. E pajisëm me mobilje me shumë nivele: karrige bar, karrige fasule, divane prej lëkure dhe pëlhure, tavolina xhami. Menaxhimi i shkathët karakterizohet nga detaje të tilla si:

• zgjidhje moderne inxhinierike;
• infrastruktura e TI-së;
• mobilje të rehatshme;
• sipërfaqet për regjistrimin e ideve gjatë negociatave etj.

Puna e projektimit dhe rinovimit zgjati dy muaj. Gjatë kësaj periudhe, specialistët e kompanisë performuan përgjegjësitë e punës në territorin e zyrës së vjetër. Kostoja e rinovimit ishte afërsisht e njëjtë me koston e një rinovimi tipik. Çmimi u ndikua vetëm nga mobiljet dhe teknologjia më e fundit.

Rezultati. Qëndrimi disa mujor në zyrën e përmirësuar tregoi se puna është bërë ekip dhe komunikimi ndërmjet specialistëve nga departamente të ndryshme është përmirësuar. Arriti të kursente në qira. Mesatarisht, ka 12-40 m2 për person në zyrën e një organizate të madhe. Më parë kishim 10 m2 dhe kjo shifër u zvogëlua në 6 m2 duke shpërndarë efektivisht vendet e punës. Periudha e shlyerjes për projektin ishte 1.5 vjet.

Ne kemi pajisur të gjitha dhomat e takimeve me Wi-Fi dhe thirrje konferencash. Kjo eliminoi nevojën për të marrë me qira salla konferencash për të mbajtur takime të jashtme. Kushtet e rehatshme tërheqin punonjësit, kështu që ata kalojnë më shumë kohë në punë dhe kryejnë detyrat e tyre në mënyrë më efikase.

Çfarë problemesh mund të lindin kur përdoret metodologjia Agile?

Problemi 1.Duke u mësuar me rolin.

Specialistët në ekipi i projektit Në fillim, me pak ngurrim, kalojnë në kryerjen e punëve të pazakonta për ta, madje duke kuptuar se kështu do të jetë më mirë. Për shembull, analistët shpesh nuk e pëlqejnë testimin e një sistemi, megjithëse kush, nëse jo ata, di gjithçka për veçoritë e funksionimit të tij? Këto lloj problemesh janë të lehta për t'u dalluar në një ekip dhe zakonisht nuk janë të vështira për t'u zgjidhur.

Problemi 2.Zakoni i dokumentimit.

Së pari, zhvilluesit presin kërkesat nga klienti - dokumentacioni i projektit që shpjegon të gjitha çështjet. Kjo metodë e transmetimit të informacionit nuk është më efektive, dhe për këtë arsye zhvilluesit mësohen më mirë të komunikojnë drejtpërdrejt me klientin. Me kalimin e kohës, pas komunikimit me klientin, do të bëhet më e lehtë për zhvilluesit të gërmojnë në ndërlikimet e biznesit dhe të zgjidhin çështje të dukshme. Edhe nëse bëjnë një gabim, klienti do ta vërejë shpejt atë në fund të përsëritjes dhe defekti mund të korrigjohet me kohë.

Problemi 3.Skuadra e re.

Menaxheri i projektit rrezikon të hasë vështirësi në punën me një ekip të ri. Pjesëmarrësit ende nuk mund të komunikojnë siç duhet me njëri-tjetrin, nuk ka asnjë kontakt mes tyre, kanë siklet të kërkojnë ndihmë dhe kanë frikë të kritikojnë dikë për një vendim të gabuar. Përgjegjësia bie mbi menaxherin e projektit. Ai është i detyruar të ndihmojë anëtarët e ekipit të krijojnë marrëdhënie joformale, prania e të cilave nënkuptohet nga metodologjia Agile. Mund të jetë e dobishme të organizoni një udhëtim të përbashkët në një restorant, një ngjarje të ndërtimit të ekipit ose një garë sportive.

Problemi 4.Problemet e komunikimit.

Detyra e menaxherit të projektit është faza fillestare– mbajtjen e takimeve me anëtarët e ekipit për të arritur aktivitete produktive dhe efikase.

Problemi 5.Presioni i afatit.

Shpesh, klientët ushtrojnë presion mbi zhvilluesit dhe i nxitojnë ata. Klientët duan të marrin produktin e dëshiruar në afat minimal. Ekipi duhet të zbatojë me saktësi kërkesat pa sakrifikuar cilësinë. Përndryshe, në afat të gjatë, shpejtësia e krijimit do të ulet, pasi kostoja e ndryshimeve do të rritet për shkak të cilësisë së dobët. Për më tepër, cilësia e pamjaftueshme ka një ndikim negativ në motivimin e zhvilluesve. Menaxheri i projektit duhet t'i kujtojë rregullisht ekipit të projektit që të ruajë cilësinë e lartë.

Problemi 6.Kreativiteti.

Detyrat e projektit mund të jenë interesante dhe jo aq interesante. Zhvilluesve shpesh u pëlqen të marrin vendime që dëmtojnë projektin, por janë teknikisht interesante. Këtu ia vlen të kujtoni parimet e KISS (mbajeni të thjeshtë, budallaqe) dhe YAGNI (nuk do t'ju duhet). Le të jetë karakteristika kryesore e zgjidhjeve të projektimit thjeshtësia. Nuk duhet të bëni asgjë që nuk është veçanërisht e nevojshme për momentin.

Çfarë duhet të bëni për të ndihmuar ekipin tuaj të marrë vendime të thjeshta? Ndonjëherë është e dobishme të lejohen specialistët të bëjnë një gabim një herë, në mënyrë që ata të mund ta analizojnë me kujdes atë dhe t'i lënë zhvilluesit të kuptojnë se çfarë duhet dhe nuk duhet bërë. Pothuajse çdo projekt në një mënyrë ose në një tjetër plotësohet nga detyra kërkimore (teknologji të reja dhe fusha inxhinierike të njohurive). Këtu duhet të provoni dhe eksperimentoni.

Problemi 7.Vlerësimi i kohës.

Kur përcaktojnë kohën për të zgjidhur një problem, specialistët marrin parasysh vetëm shkrimin e kodit. Në të njëjtën kohë, detyra gjithashtu përfshin, së paku, krijimin e një dizajni dhe testimi. Që në fillim të projektit, zhvilluesit mendojnë se do ta përfundojnë projektin më herët se sa është e mundur. Në fund të procesit, ekspertët vërejnë gabime dhe nxjerrin përfundime për të ardhmen. Koha kalon, dhe ekipi mëson të vlerësojë saktë situatën. Në mënyrë tipike, pas 3-4 përsëritjesh, niveli i saktësisë dhe produktivitetit përmirësohet.

Problemi 8.Problem me menaxhimin.

Menaxhmenti pret që një funksion i caktuar do të jetë i disponueshëm në kohën e caktuar. Por metodologjia Agile nuk garanton zbatimin 100% të planeve. Është logjike të pritet që detyrat prioritare të zgjidhen. Është e dobishme të pajtoheni me menaxhmentin për planet në nivelin e lëshimit. Niveli i lartë i planit të lëshimit i lejon menaxherit të ndryshojë fushëveprimin e zhvillimit edhe të karakteristikave individuale të sistemit brenda një harku kohor mjaft të madh. Për shembull, detyra e krijimit të një nënsistem kërkimi mund të përfshijë marrjen parasysh të morfologjisë. Kursimet janë gjithashtu të mundshme në këtë fazë.

Problemi 9.Problemet e sjelljes së pakoordinuar.

Në procesin e zbatimit të metodologjisë Agile nuk mund të përjashtohet situata e mëposhtme. Po zhvillohet një mbledhje dhe papritmas një nga pjesëmarrësit ngrihet dhe fillon të flasë për idetë e tij. Ai nuk pranon kundërshtime dhe pas disa kohësh flet për vendimin e marrë, duke propozuar që të fillojë shqyrtimi i çështjes së dytë. Sigurisht, skuadra nuk e mori vendimin. Në fakt ai e bëri atë këtë pjesëmarrës, duke ia hequr këtë të drejtë.

Këtu ka disa opsione. Është e mundur që personi ishte thjesht në një gjendje tepër entuziaste, e cila së shpejti duhet të kalojë. Por shpesh ka nga ata që thjesht nuk mund të jenë pjesë e ekipit për shkak të karakterit të tyre.

Metodologji e shkathët pa gabime

Gabim 1.Menaxherët e lartë nuk e kuptojnë se çfarë është metodologjia Agile dhe për çfarë qëllimi duhet të zbatohet.

Ne kemi nevojë për një kuptim të saktë se çfarë rezultati na intereson, çfarë afatesh dhe buxheti kemi. Qëllimet e paqarta dhe formulimet e bukura, për shembull, "Bëhuni numër një në fushën tuaj" ose "Filloni të punoni në mënyrë më efikase" nuk janë të përshtatshme. Lërini detyrat të shprehen me numra. Për shembull: “Arritni një qarkullim prej 3 miliardë dollarësh në 2018”, “Ulni kohën për të krijuar një produkt në 3 muaj”, etj.

Gabim 2.Diagnoza e gabuar.

Shpesh, kur prezanton metodologjinë Agile, një kompani dëshiron të zgjidhë një sërë problemesh specifike, siç janë kostot e fryra ose cilësia e dobët e mallrave. Por ju duhet të kuptoni në detaje se ku janë boshllëqet. Përndryshe, menaxheri do të presë që metodologjia Agile të ndryshojë gjithçka. Megjithatë, këtu ai rrezikon vetëm të përkeqësojë situatën.

Gabim 3.Futja e Agile vetëm në një zonë të veçantë të proceseve të biznesit.

Ky është një vazhdim logjik i gabimit të dytë të përshkruar më sipër. Arsyeja e supozimit të saj është e njëjtë: mungesa e të kuptuarit të problemit dhe ku fshihet. Të gjithë sektorët e ndërmarrjes duhet të ndryshojnë: prodhimi dhe marketingu, kontabiliteti dhe shitja. Përndryshe, asgjë nuk do të funksionojë. Nëse ndryshimet futen vetëm në marketing dhe nuk arrihet efekti i dëshiruar, do të keni një mendim të fortë se metodologjia Agile është joefektive.

Gabim 4.Duke kuptuar rëndësinë e përfshirjes së të gjithë punonjësve të kompanisë.

Ju duhet të jeni aleatë me kolegët tuaj. Nëse kjo nuk ndodh, është më mirë të kurseni burime, kohë dhe të mos filloni asgjë. Metodologjia e shkathët presupozon iniciativën, mobilizimin dhe përgjegjësinë e të gjithëve që marrin pjesë në proces, të paktën menaxherëve të ndërmarrjeve. Nëse këta njerëz janë udhëheqës të fortë dhe autoritativë që janë në gjendje të arrijnë disiplinë të mirë kur zgjidhin problemet dhe futin rregulla të reja në punë, atëherë gjithçka do të funksionojë. Sipas statistikave, 85% e ndërmarrjeve nuk kanë menaxherë të fortë me përgatitje të mjaftueshme profesionale.

Gabim 5.Iluzioni se gjithçka është e mundur vetëm përmes përpjekjeve njerëzore.

Sigurisht, kompetencat, motivimi dhe niveli profesional i personelit janë të rëndësishme në arritjen e qëllimeve. Por vëmendje duhet t'i kushtohet edhe pajisjes së duhur teknike të kompanisë, softuerit me ndihmën e të cilit menaxhimi dhe planifikimi i aktiviteteve bëhet më efikas. Në këtë drejtim, ju pëlqen apo jo, do t'ju duhet të investoni në blerjen e makinerive, pajisjeve dhe programeve kompjuterike.

Gabim 6.Ngurrimi për të ndryshuar personelin.

Pothuajse 90% e suksesit varet nga ekipi i ndërmarrjes. Vëmendje e vazhdueshme duhet t'i kushtohet zhvillimit, trajnimit dhe motivimit të duhur të punonjësve. Shumë specialistë nuk janë të gatshëm të kryejnë aktivitete duke përdorur metodologjinë Agile, ata nuk janë të interesuar për njohuri dhe mundësi të reja, ose për të zotëruar proceset e biznesit. Rreth 25-30% e personelit të ndërmarrjes nuk duan të japin më të mirën e tyre dhe të përpiqen për të fitime të larta. Është më mirë t'u thuash "lamtumirë" punonjësve të tillë. Lidhjet e dobëta mund të jenë mjaft të vështira për t'u identifikuar, dhe për këtë arsye menaxherët e burimeve njerëzore shpesh nuk merren me këtë.

Gabim 7.Humbja e interesit dhe pjesëmarrja e menaxherëve të lartë.

Në mënyrë tipike duhen 8-16 muaj për të zbatuar një projekt. Në 70% të situatave, pas tre muajsh interesi i pjesëmarrësve ulet. Si rezultat, anëtarët e ekipit thjesht nuk duan të jenë pjesë e projektit. Nëse është kështu, sigurisht që nuk do të jeni në gjendje ta zgjidhni problemin.

Metodologjia e shkathët: shembuj të aplikimit të pasuksesshëm

Metodologjia Agile tërheq shumë profesionistë dhe deri më sot, një sërë kompanish me famë botërore janë përpjekur ta zbatojnë atë. Por pothuajse askush nuk arriti të arrijë rezultatin e dëshiruar.

Shembull: në vitin 2015, tregtimi u mbajt në bursën e Nju Jorkut, i cili duhej të ndalohej deri në 4 orë. Në fillim u shpjegua si një sulm kibernetik. Por, siç doli më vonë, problemi ishte një gabim gjatë përditësimit të radhës. Sigurisht, 4 orë pushim në qendrën tregtare botërore sollën miliarda humbje.

Dhe ky shembull nuk është i vetmi. Është më e lehtë për ndërmjetësit: ata humbën dhe më pas fituan dy herë më shumë. Gjërat janë më të komplikuara për linjat ajrore. Përafërsisht e njëjta situatë ndodhi me transportuesin ajror Delta pas një përditësimi të thjeshtë të softuerit. Sistemi i dispeçimit ndaloi marrjen e të dhënave, gjë që çoi në anulimin e detyruar të fluturimeve. Kompania jo vetëm që pësoi humbje, por humbi edhe reputacionin e saj.

Dështimi më famëkeq i përdorimit të metodologjisë Agile lidhet me fillimin e sistemit të sigurimit shëndetësor Obama Care në Shtetet e Bashkuara. Kuptimi i programit ishte si vijon: kategori të caktuara të qytetarëve amerikanë pajiseshin me polica sigurimi falas. Për të marrë një të drejtë të tillë, një person duhej të plotësonte një formular në faqen e internetit dhe të priste një vendim nga shërbime të caktuara. Sigurisht, miliona njerëz nxituan të plotësonin formularët. Por problemi ishte se ata ishin në gjendje të plotësonin formularin, por jo ta dërgonin, kishte një lloj dështimi të serverit. Obama Care përfundoi rreth 6 muaj pasi filloi. Për të përmirësuar punën, të interesuarit sollën një specialist të jashtëm, i cili vlerësoi situatën. Konsulenti ka bërë një rrugë të gjatë, duke filluar nga fundi - "prodhimi", bashkoi pjesët dhe arriti të arrijë funksionimin e duhur të sistemit.

Mendimi i ekspertit

Shembull i zbatimit të suksesshëm Amenaxhimi i gille

Sergej Buchik,

menaxher i përgjithshëm Grupi NPM, Novosibirsk

Kompania, duke përfshirë të gjitha divizionet, kaloi në punë sipas metodologjisë Agile për 1.5 vjet. Më parë, departamenti i burimeve njerëzore përbëhej nga: një specialist i burimeve njerëzore, një menaxher trajnimi dhe një rekrutues. Menaxhimi i departamentit, duke zgjedhur staf i ri ose gjatë kryerjes së trajnimit, plotësuan aplikimet në një numër i madh. Tani çdo departament i ndërmarrjes ka HR-në e vet. Në ekipet e zhvillimit që punojnë sipas metodologjisë Scrum, ky vend i caktohet Scrum Master. Produktet këtu janë një shërbim personeli dhe anëtarët e ekipit janë konsumatorë të brendshëm.

Stili i ri i menaxhimit i bazuar në metodologjinë Agile ka zënë rrënjë mirë në fushën e përzgjedhjes së punonjësve. Klienti mund të planifikojë aktivitetet e tij, duke marrë parasysh daljen e kandidatit në kohën e saktë të caktuar. Gjatë 9 sprinteve që zgjasin 2 javë, ne arritëm të reduktojmë numrin e vendeve të lira të prapambetura me 2 herë. Një vend i lirë pune i thjeshtë (për shembull, një punëtor shkritore) tani plotësohet në 20 ditë, një vend vakant mesatar (për një inxhinier shërbimi) - në 32 ditë dhe një specialist i rrallë (një inxhinier i procesit të formimit me injeksion plastik) - në 51 ditë. Pasi përfundoi sprintin e parë, u bë e qartë për rekrutuesit: për menaxhimin e departamentit, gjëja kryesore nuk është shpejtësia e kërkimit, por afatet transparente për plotësimin e vendeve të lira dhe periudha kohore që ata mund të shpenzojnë për zgjedhjen e një punonjësi me trajnime të mëvonshme. . Për momentin, menaxheri po i tregon klientit për kohën dhe fazën e kërkimit për një aplikant. Përgjegjësitë e rekrutuesve përfshijnë gjithashtu zhvillimin e kompetencave teknike të nevojshme për të plotësuar në mënyrë efektive punët e prodhimit, të tilla si të mësuarit për të lexuar projekte.

Le të japim një shembull: menaxhmenti i departamentit nuk e kupton se çfarë punonjësi i nevojitet, ose kjo çështje po zgjidhet nga specialistë të disa departamenteve menjëherë. Le të themi se një kompanie ka nevojë për një magazinier që do të punojë në një depo mjetesh. Në këtë rast, vendi vakant rezervohet nga departamenti i prodhimit dhe shërbimi i logjistikës. Përgjegjësitë e rekrutuesit përfshijnë marrjen parasysh të kërkesave të këtyre departamenteve për aplikantin. Prodhuesit kanë nevojë specialist teknik, kush e njeh modernen mjet për prerjen e metaleve. Logjisistët duan të shohin çdo profesionist me përvojë dhe që e di në mënyrë të përsosur se çfarë është logjistika e magazinës. Klientët nuk kanë vendosur ende dhe nuk kanë dalë me një emërues të përbashkët, por rekrutuesi tashmë po kërkon një kandidat, duke marrë parasysh aplikantët. Pas përzgjedhjes së kandidatit më të mirë, sipas tij, ai zhvillon një dialog me të gjithë klientët. Nëse nuk është e mundur të arrihet një marrëveshje pas intervistës, rekrutuesi bën ndryshime në tekstin e konkursit.

Për momentin, departamentet po arrijnë në përfundimin se grupi i synuar duhet të përfshijë ekspertë teknikë që kanë njohuri të shkëlqyera të mjetit. Rekrutuesi përsëri kryen kërkimin, zgjedh aplikantët e përshtatshëm dhe takohet me ta. Kjo vazhdon deri në plotësimin e vendit të lirë.

Metodologjia e menaxhimit të projektit të shkathët: 6 rregulla të efikasitetit

Rregulli 1. Punoni në planin e projektit dhe përgjigjuni pyetjeve të mëposhtme: cilat detyra janë më të rëndësishmet për të përfunduar, cilat burime kërkohen për këtë, çfarë afati kohor është caktuar për të arritur rezultatin?

Planet afatgjata kanë saktësi të ulët, ndaj bëni një plan në tre dimensione:

• një plan afatgjatë që tregon të gjitha detyrat që kërkohen për t'u përfunduar dhe planifikim në shkallë të gjerë të afateve për zbatimin e pikave kryesore;
• planet mujore të synimeve, bazuar në planin e përgjithshëm (zbatimi i tyre nuk duhet të jetë më i ulët se 90%);
• Përcaktoni qëllimet më të detajuara brenda muajit, duke përshkruar qartë rezultatet e arritjes së tyre.

Rregulli 2. Përfshini ekipin në zbatimin e projektit, informoni punonjësit për këtë. Të gjithë specialistët duhet të kuptojnë dhe të ndajnë qëllimet e organizatës, të dinë se çfarë duhet bërë për të zgjidhur detyrat e caktuara, edhe nëse këta punonjës nuk i kryejnë ato brenda kornizës së projektit.

Rregulli 3. Takohuni herë pas here me ekipin e zbatimit. Frekuenca e takimeve është 1-2 herë në muaj. Kjo kërkohet për të përcaktuar zgjidhjet e detyrave dhe problemeve, rregullimin në kohë të planit nëse lindin vështirësi me zbatimin. Në të njëjtën kohë, rregulloni të mprehtë situatat e konfliktit nuk duhet të bëhet gjatë takimit, i cili është planifikuar të zhvillohet brenda një jave. Autorizimi duhet të jetë i qartë dhe i shpejtë.

Rregulli 4. Nuk duhet të ndaloni një projekt nëse shihni se nuk ka një efekt pozitiv. Problemet, si rregull, lindin për shkak të pakënaqësisë së ekipit, anëtarët e të cilit duhet të largohen nga zona e tyre e rehatisë dhe të bëhen krijues. Mos harroni se rezultatet e para zakonisht maten pas përfundimit të 80% të të gjithë rrugës.

Rregulli 5. Thuajuni "Mirupafshim" punonjësve me performancë të dobët nëse shihni se metodologjia Agile nuk është afër tyre.

Rregulli 6. Mos prisni t'i zgjidhni problemet në mënyrë perfekte herën e parë. Rreth 95% mjete efektive dhe idetë u arritën pas shumë përsëritjeve dhe rregullimeve në disa përsëritje.

1. Andrew Stellman, Jennifer Greene "Të kuptuarit e shkathët".

Libri flet për katër opsionet kryesore në të cilat paraqitet metodologjia Agile. Përshkrimi i tyre është mjaft interesant dhe i detajuar. Falë manualit, zotërimi i artit të aplikimit të teknikave bëhet i lehtë dhe argëtues.

Libri zbulon thelbin e metodologjive më të njohura Agile: Scrum, XP (programim ekstrem), Lean (programim i dobët) dhe Kanban; ju tregon se si t'i përdorni ato për të krijuar programe cilësore dhe për të arritur qëllimet tuaja. Manuali përshkruan se si metodologjia Agile ndihmon në ndryshimin e të menduarit të pjesëmarrësve të projektit, bashkimin e tyre dhe përpjekjet për përmirësime së bashku. Qëllimi i botimit është të flasim për metodat, vlerat dhe parimet Agile, falë të cilave ekipet mund të ndryshojnë plotësisht strategjinë e punës në projekte dhe t'i qasen ndryshe. Manuali do të jetë me interes për menaxherët e projektit, drejtuesit dhe thjesht ata që janë të interesuar në metodologjinë e zhvillimit fleksibël Agile.

2. Boris Volfson "Projekti i shkathët dhe menaxhimi i produktit".

Libri ndërthur teorinë dhe praktikën. Ai përshkruan aspekte të ndryshme të konceptit të metodologjisë Agile, zhvillimit të produktit, menaxhimit dhe analitikës. Pjesa teorike mbi menaxhimin e projektit dhe produktit përmban informacion në lidhje me gjendjen aktuale të Scrum dhe Kanban. Ai praktik flet për menaxhimin e kërkesave, ekipet, rreziqet, modelimin e biznesit, analitikën e kërkesave, vlerësimin e kohës, praktikat inxhinierike për zhvillimin e produktit (kryesisht për programimin ekstrem), kontrollin dhe sigurimin e cilësisë, zbatimin dhe shkallëzimin e Scrum.

3. Jeff Sutherland Scrum. Një metodë revolucionare e menaxhimit të projektit."

Jeff Sutherland ka metodologjinë e tij, të cilën e zhvilloi në përpjekje për të kapërcyer mangësitë e menaxhimit klasik të projektit. Specialistët në kompani të ndryshme Shpesh është e vështirë të arrihet një punë efikase, e shpejtë dhe e koordinuar. Ata nuk arrijnë të përmbushin shumicën e planeve të tyre për shkak të mungesës së kohës dhe burimeve, dhe departamentet dhe ekipet shpesh zgjidhin detyra që janë të kundërta për nga rëndësia ose i përsërisin ato.

Scrum ka ekzistuar për 20 vjet, dhe gjatë kësaj kohe metodologjia është përdorur me sukses jo vetëm nga zhvilluesit e softuerit, por edhe nga prodhuesit e makinave, farmacistët, FBI dhe njerëzit e zakonshëm duke planifikuar kohën dhe mundësitë e tyre.

Falë leximit të librit, ju do ta shikoni menaxhimin e projektit ndryshe dhe do të kuptoni se si të zgjidhni problemet që më parë dukeshin të paarritshme. Nuk ka rëndësi se cilat janë planet tuaja: hapja e një startup-i, ndryshimi sistemi arsimor, futja e teknologjive të reja ose menaxhimi më efektiv i ekipit. Falë Scrum, ju do të rrisni produktivitetin tuaj në mënyrë eksponenciale. Manuali është i përsosur për menaxherët e projektit, drejtuesit dhe specialistët e IT-së.

4. Roman Pichler "Menaxhimi i produktit në Scrum".

Manuali do të jetë me interes për të gjithë ata që studiojnë metodologjinë Agile, veçanërisht ata që zotërojnë teknologjinë. Libri shpjegon se çfarë roli luan pronari i produktit, si ta menaxhoni atë më mirë dhe cilat metoda themelore ekzistojnë për këtë. Ne po flasim për vizualizimin e produktit, krijimin dhe përmirësimin e një numri të prapambetur, planifikimin dhe gjurmimin e lëshimeve dhe përdorimin efektiv të Scrum.

5. Kenneth S. Rubin "Scrum Fundamentals".

Nga libri do të mësoni gjithçka për Scrum, kushtet e kësaj metodologjie dhe do të kuptoni se si të përfitoni nga aplikimi i saj. Nëse jeni të interesuar për metodologjinë Agile, udhëzuesi do t'ju tregojë se çfarë duhet për të arritur rezultate të shkëlqyera. Libri është shkruar nga një ekspert kryesor i trajnimit Scrum. Autori flet në detaje për parimet, vlerat dhe standardet kryesore të praktikës, duke prekur qasje fleksibël, efektiviteti i të cilave është vërtetuar me kalimin e kohës.

Informacion në lidhje me ekspertët

Andrey Kocheshkov, Analisti kryesor i Shtëpisë Botuese OJSC Prosveshcheniye. "Prosveshchenie" është një shtëpi botuese e specializuar sovjetike dhe më vonë ruse e letërsisë arsimore dhe pedagogjike.

Maria Onuchina, Drejtor i Departamentit të Menaxhimit të Aseteve në Becar Asset Management Group, Moskë. Becar-Exploitation LLC (Becar Asset Management Group). Fusha e veprimtarisë: zgjidhje sistematike e problemeve të menaxhimit të pronës, menaxhimit të projekteve dhe investimeve (ndërmjetësim, vlerësim). Numri i personelit: 5000. Territori: zyrat e përparme - në Moskë dhe Shën Petersburg; tre zyra përfaqësuese dhe 55 ndarje të veçanta- në qytete të ndryshme të Rusisë.

Sergej Buchik, Drejtori i Përgjithshëm i NPM Group, Novosibirsk. NPM LLC (NPM Group). Fusha e veprimtarisë: prodhimi i pajisjeve për industrinë e pijeve; zhvillimi i zgjidhjeve të TI-së për integrim me pajisje, aplikacionet celulare. Numri i punonjësve: më shumë se 300. Pjesa e tregut: 95% e pajisjeve për mbushjen e birrës dhe pijeve të gazuara në Rusi. Numri i patentave për prodhimet e veta: mbi 80.