Fazat e zhvillimit të shkathët. Çfarë është Agile? Në fillim, ekipi eksploron realitetin e zhvillimit të aplikacionit dhe shtrirjen. Puna e mëtejshme ndahet në tre cikle të ndërlidhura

Agile (“i shkathët”) është një fjalë që është dëgjuar nga çdo hekur kohët e fundit. Por çfarë është Agile dhe, më e rëndësishmja, pse nevojitet ky Agile?

Nëse është e hapur Fjalor, për shembull, Oxford, atëherë mund të lexoni të paktën dy përkufizime atje:

1. Në gjendje të lëvizë shpejt dhe lehtë.
2. Të aftë për të menduar dhe kuptuar shpejt.

Domethënë, për të qenë i shkathët, duhet të jeni në gjendje të lëvizni shpejt dhe lehtë dhe të mendoni shpejt. Duket se janë cilësi mjaft të dobishme, veçanërisht në biznes. Të mendosh shpejt dhe të reagosh shpejt është pikërisht ajo që urdhëroi mjeku për kohën tonë, përndryshe thjesht nuk do të mbijetosh: konkurrentët do t'ju gllabërojnë. Ka gjithnjë e më pak industri në botë ku këta konkurrentë nuk ekzistojnë. Për më tepër, shpejtësia e kopjimit e bën praktikisht të pamundur nxjerrjen e produktit në treg dhe pushimin mbi dafinat e tij. Pa aftësinë për t'u përshtatur shpejt me ndryshimin, që jep të ashtuquajturën "metodologjia e shkathët", është gjithnjë e më e vështirë të mbijetosh.

Jo rastësisht e marr shprehjen “Metodologji e shkathët” në thonjëza, sepse shpesh mund ta dëgjosh, por nuk është plotësisht e saktë. Nëse nuk hyni në detaje teknike, atëherë Agile nuk është një metodologji, por një emër kolektiv për metoda dhe qasje të ndryshme ndaj menaxhimit që:

1. Fokusoni ekipin në nevojat dhe qëllimet e klientëve.
2. Thjeshtimi i strukturës dhe proceseve organizative.
3. Ofrojnë punë në cikle të shkurtra.
4. Përdorni në mënyrë aktive reagimet.
5. Ka një rritje të kompetencave të punonjësve.
6. Ato bazohen në një qasje humaniste.
7. Ata nuk janë një gjendje përfundimtare, por më tepër një mënyrë e të menduarit dhe e jetesës.

Asgjë e mbinatyrshme, apo jo? Le të shkojmë pikë për pikë dhe të shohim pse sa më sipër është e rëndësishme për të qenë të shpejtë dhe të shkathët dhe si i arrin Agile këto qëllime.

Përqendrohuni në nevojat dhe qëllimet e klientëve

Mendoj se nuk ia vlen të shpjegohet pse biznesi më i suksesshëm është ai që plotëson nevojat e klientit të tij më mirë se konkurrentët. Është më interesante të kuptosh se cilat mjete në Agile ndihmojnë për ta arritur këtë.

Më e rëndësishmja, fokusi te klienti me qasjen Agile nuk shfaqet vetëm në kokën e pronarit të biznesit (ai tashmë ekziston atje), por tek të gjithë ata që po punojnë për krijimin e një produkti ose shërbimi. Secili pjesëmarrës në proces duhet të kuptojë se kush është klienti, çfarë dëshiron, çfarë problemesh zgjidhim me produktin tonë, çfarë do, çfarë ka frikë, etj. Një fokus i tillë global ju lejon të krijoni një renditje të përmasave zgjidhje më të mira. Unë kam hasur në mënyrë të përsëritur një situatë ku njerëzit që më parë ishin përgjegjës për një pjesë të vogël të punës, pasi kishin kuptuar qëllimet e klientit, filluan të japin ide të mrekullueshme dhe njerëzit që janë përgjegjës për zhvillimin e produktit morën shënime me habi. Ose - se si idetë e tilla mprehen në seancat e zhvillimit të produktit në grup njerez te ndryshëm dhe plotësojnë njëra-tjetrën, nga thjesht e mira në të shkëlqyera. Dhe, natyrisht, se si ato zbatohen më pas.

“Mjetet e punës” në këtë rast janë sesione (takime) të shkurtra, por intensive të të gjithë pjesëmarrësve në punë ose shumicës kyçe, ku gjenerohen dhe testohen ide të ndryshme. Të njëjtat takime shërbejnë për të niveluar mirëkuptimin dhe fokusin: të gjithë pjesëmarrësit në takimin dalës kuptojnë se çfarë po bëjnë, pse dhe pse është e rëndësishme për klientin. Dhe formati demokratik i seminarit, ndryshe nga prezantimet e mërzitshme, garanton përfshirje dhe motivim më të madh të të gjithë pjesëmarrësve.

Shembuj të mjeteve të tilla janë Lean Canvas, Impact Mapping, User Story Mapping dhe metoda të tjera Agile për përshkrimin e hipotezave dhe proceseve.

Një nga themelet e Agile është thjeshtësia ekstreme. Dhe struktura organizative e organizatës, dhe proceset me të cilat njerëzit punojnë, dhe rregullat duhet të jenë sa më të thjeshta të jetë e mundur. Kjo do t'i lejojë njerëzit të përqendrohen në punën e tyre, në vlerën që ata krijojnë dhe jo në pajtueshmërinë me rregulloret dhe rregullat. Shembuj të shkëlqyer të kësaj qasjeje mund të gjenden në shumë ekipe që punojnë në Scrum, mënyra më e popullarizuar e organizimit të rrjedhës së punës në Agile. Në fakt, të gjitha marrëveshjet dhe rregullat e një ekipi prej 10-11 personash, detyrat aktuale për disa javë, qëllimet, si dhe planet strategjike mund të përshtaten lehtësisht në 2-3 fletë letre A0. Në një fletë mund të ketë një të ashtuquajtur "mbrapa sprint", një listë e gjithçkaje që ekipi do të bëjë në përsëritjen tjetër. Nëse e varni një të tillë në dhomën ku punoni, mund t'i kurseni vetes mundimin për të kujtuar të gjitha këto. E njëjta gjë vlen edhe për proceset. Për shembull, në Scrum, vendi dhe koha e të gjitha takimeve janë të fiksuara në mënyrë rigoroze. Çdo pjesëmarrës e di me siguri që, për shembull, të hënën në orën 10-00 është planifikuar përsëritja tjetër, dhe të Premten në 17-30 - një takim për të përmirësuar procesin e punës.

Dhe sa më e madhe të jetë organizata, aq më i madh është përfitimi i një thjeshtësie të tillë, sepse kompleksiteti priret të rritet në mënyrë eksponenciale, dhe Agile është mënyrë e mirë mposht këtë kompleksitet, ose të paktën të përmbajë rritjen e tij.

Shembuj të thjeshtimit (dhe rrafshimit, por kjo është një temë për një diskutim tjetër) në Agile janë Scrum, Nexus, LeSS (Scrum në shkallë të gjerë, ose Scrum në një shkallë të gjerë), si dhe manifestimi i Agile.

Në botën e shkathët, nuk është zakon të mbyllesh në një punishte për tre vjet për të mprehur diçka interesante atje. Rreziku është shumë i madh, të shpenzosh një det forcë dhe kohë për diçka që nuk i nevojitet askujt ose është e vjetëruar.

Për të shmangur këtë, përdoret e ashtuquajtura qasje përsëritëse-rritëse, kur:

• puna kryhet në periudha të vogla fikse kohore, për shembull, në një, dy ose katër javë,
• dhe, më e rëndësishmja, në fund të çdo periudhe kohore, krijohet jo vetëm një lloj rezultati i ndërmjetëm, por, megjithëse i vogël, i cunguar, i pakët, por versioni i punës i produktit, e cila mund të filloni të përdorni.

Si shembulli më i thjeshtë i një modeli të tillë pune, mund të imagjinojmë standardin e programit "llogaritës" për të gjithë kompjuterët, i cili në fillim ju lejon të shtoni vetëm dy numra, pastaj shtojmë zbritjen, shumëzimin, pjesëtimin, numrat transcendental, funksionet trigonometrike dhe kështu me radhë, sipas frekuencës së përdorimit. Në fillim, funksionaliteti është i vogël, por tashmë mund të shohim se si duket kalkulatori, sa i përshtatshëm është për t'u përdorur dhe imagjinoni se si ta zhvillojmë më tej. Dhe, më e rëndësishmja, disa nga klientët (të themi, nxënësit e shkollës Shkolla fillore) tashmë mund të fillojë ta përdorë atë.

Një tjetër avantazh i kësaj qasjeje, përveç hyrjes së hershme në treg dhe ndryshimeve në fazat e hershme të punës, është aftësia për të matur progresin më saktë. Ne nuk bëmë vetëm "15% të punës", që është goxha abstrakte. Ne "bëmë 15% të funksionalitetit" që tashmë po funksionon.

Të gjitha qasjet e procesit në Agile kanë cikle të shkurtra, qofshin ato Scrum, Nexus, LeSS, SAFe të përmendura më parë ose, plus nevoja për të punuar me cikle të tilla përmendet në vetë manifestin Agile.

Përdorimi aktiv, sistematik i reagimeve

Kjo pikë, për mendimin tim, është më e rëndësishmja për çdo proces, pasi ju lejon të rregulloni punën tuaj me kalimin e kohës, bazuar në përvojën, duke hequr gabimet dhe humbjet nga procesi dhe produktin që krijohet dhe duke shtuar diçka të dobishme.

Në çdo fushë të veprimtarisë njerëzore që lidhet me krijimin e diçkaje të re, do të gjeni një të ngjashme punë përmes eksperimentit. Raketa, inxhinieria e avionëve, farmaceutika, fizika, mjekësia, ndërtimi, psikologjia, ekonomia - çdo fushë e veprimtarisë filloi me eksperimente dhe përpunim të menduar reagime prej tyre.

Agile ofron një përdorim sistematik të kësaj qasjeje kudo: në krijimin e një produkti (ne e lëshojmë atë në treg, ose ia tregojmë klientit, ose kryejmë teste dhe përdorim reagime për ta korrigjuar), në proceset e ndërtimit (në mënyrë periodike ne "ndalojmë" punën dhe analizoni vetë procesin, për ta përmirësuar atë, për të hequr qafe humbjet dhe problemet), madje edhe në ndërtimin e strukturës së organizatës dhe rregullimin e marrëdhënieve në ekipe.

Përsëri, shembujt janë kudo: takime retrospektive në Scrum, Kanban, Nexus dhe LeSS, ciklet I&A në SAFe, qasja Design Thinking për krijimin e produkteve, etj.

Pse të jepni më shumë autoritet kur mund të jepni një copë letre me udhëzime? Ka të paktën tre arsye për ta bërë këtë.

Së pari, njerëzit e angazhuar në punë mendore nuk u pëlqen të ndjehen si majmunë (mirë, ose robotë), dhe duke i hequr aftësinë për të marrë vendime nga një person, ne ia heqim punën mendore në vetvete. Dhe kjo është padyshim demotivuese.

Së dyti, duke dhënë më shumë autoritet, ne japim më shumë përgjegjësi dhe njerëzit detyrohen të mësojnë të marrin vendime vetë dhe, më e rëndësishmja, të mbajnë përgjegjësi për to. Është e gjatë, e vështirë, por ia vlen. Puna nuk do të ndalet nëse një ekip i vetëorganizuar ndeshet me një problem të panjohur, të panjohur më parë. Dhe kush do të argumentojë se në punë, të rriturit e pjekur dhe të përgjegjshëm janë më të dobishëm se fëmijët e mëdhenj që nuk janë në gjendje të mendojnë vetë?

Së treti, është ende e njëjta shpejtësi. Nëse një person mund të zgjidhë një problem vetë, në vend të tij, pa pyetur askënd, kjo zvogëlon kohën për të marrë vendime. Nuk ka më dërgim të pyetjes "lart" dhe pritje për një përgjigje nga menaxhmenti. Ky avantazh nuk është aq i dukshëm nëse keni 3 persona që punojnë, por nëse keni 30, ose 300, ose 3000 ... Në organizatat e mëdha të ndërtuara mbi vendimmarrje thjesht hierarkike, paraliza e vullnetit mund të jetë mjaft e zakonshme.

Mënyrat e njohura të ndërtimit të punës në Agile, veçanërisht ato të bazuara në kornizën Scrum, përfshijnë një sistem ekipesh të vetëorganizuara dhe inkurajojnë udhëheqjen në të gjitha nivelet.

Pse t'i trajtojmë njerëzit si qenie njerëzore? Domethënë ana morale e çështjes është e qartë, por çfarë përfitimi do t'i sjellë pronarit të ndërmarrjes?

Përgjigja është goxha e thjeshtë. Nëse krijimi i asaj që po shit nuk kërkon puna mendore, por vetëm veprime mekanike - nuk mund të shqetësoheni. Vetëm paguani sipas punës së bërë, dhe kaq. Por sapo truri i punëtorëve të hyjë në lojë, do të duhet të llogarisni me parimet e motivimit të punës mendore. Dhe ata thonë se mundësia e vetë-realizimit, përmirësimi i aftësive të tyre, sjellja e diçkaje të vlefshme në botë, pavarësia në vendime dhe një sërë faktorësh të tjerë janë të rëndësishme për njerëzit. Dhe një person i motivuar (të mos ngatërrohet me një person të stimuluar!) do të investojë më shumë në punë dhe rezultati do të jetë më i mirë dhe më i shpejtë. Dhe në përgjithësi, një atmosferë e këndshme në punë shton dëshirën për të ardhur dhe për të punuar atje - vështirë se dikush mund të debatojë me këtë.

Dhe, çfarë është mirë, nëse gërmoni në të njëjtin Scrum, rezulton se të gjithë faktorët kryesorë për motivimin e një punonjësi të punës mendore dhe / ose krijuese janë përfshirë tashmë në të. Në çdo përsëritje (“sprint”), ne vendosim një qëllim që duam të arrijmë; na jepet mundësia të vendosim se si ta arrijmë saktësisht qëllimin; në fund shikojmë se sa jemi bërë më të mirë (ose më keq) për të punuar se më parë; ne shohim njerëz që janë të interesuar për produktin dhe emocionet e tyre nga njohja e tij. Është veçanërisht mirë nëse këto emocione janë pozitive.

Përfundimi është: njerëz të lumtur funksionojnë më mirë dhe teknologjitë Agile ndihmojnë në krijimin e një procesi në të cilin njerëzit ndihen më të lumtur. Dhe pika e parë e manifestit ka të bëjë vetëm me këtë: njerëzit dhe mënyra se si ata komunikojnë janë më të rëndësishme se çdo gjë tjetër.

Agile nuk është një gjendje përfundimtare, por një mënyrë e të menduarit dhe e të jetuarit

Kjo pikë ka të bëjë me atë se si Agile në përgjithësi është rruga, jo qëllimi. Ju nuk mund të "zbatoni" Agile dhe të relaksoheni. Nëse zgjedh këtë rrugë, do të kesh gjithmonë diçka tjetër për të bërë më mirë, një sfidë tjetër për t'iu përgjigjur, një problem tjetër për të zgjidhur, një lartësi tjetër për të pushtuar... Kjo është lëvizja, pafundësisht, sepse nuk ka asnjë proces apo produkt ideal, zhvillimi dhe konkurrenca nuk ndalen kurrë, ashtu siç nuk ndalet kurrë lufta për mbijetesë në natyrë.

Dhe nëse gjithçka ishte e suksesshme: njerëzit në kompani i kuptojnë dhe ndajnë vlerat dhe parimet e Agile dhe punojnë sipas tyre, atëherë menaxhmenti nuk do të duhet të "zvarrit" ndonjë ndryshim ose të "shkelë" punonjësit në mënyrë që ata të fillojnë të bëjnë diçka. ndryshe. Ndërmarrja do të bëhet një organizëm i vetëm, menaxhimi i të cilit do të marrë më pak përpjekje dhe do të sjellë më shumë kënaqësi.
Dhe aty ku ka më shumë kënaqësi nga puna, dhe rezultati është më i lartë. Kjo vlen jo vetëm për specialistët, por edhe për menaxhimin, dhe në një masë edhe më të madhe.

Të gjithë ata që janë marrë ndonjëherë me menaxhimin e projektit e dinë se sa e vështirë është të organizosh një punë të mirëkoordinuar të një ekipi dhe përballë kërkesave vazhdimisht në ndryshim për rezultatin e një projekti, të gjitha përpjekjet e bëra mund të bëhen të kota. Metoda e shkathët e menaxhimit të projektit është ideale për të punuar me projekte të tilla.

Metoda e menaxhimit të projektit Agile është një seri fazash pune të përcaktuara nga afate të vështira - sprintet, duke i lejuar ekipit të vlerësojë vazhdimisht rezultatet e punës së bërë dhe të marrë reagime nga klienti dhe pjesëmarrësit e tjerë të projektit. Kjo qasje ju lejon të bëni ndryshime të menjëhershme në produkt kur vijnë kërkesat e reja.

Historia e Agile

Menaxhimi evolucionar i projektit dhe zhvillimi adaptiv software u shfaq në fillim të viteve 1970. Në vitin 1970, Dr. Winston Royce prezantoi një punim të titulluar "Menaxhimi i zhvillimit të sistemeve të mëdha softuerike" që ishte kritik për zhvillimin e njëpasnjëshëm. Ai argumentoi se softueri nuk duhet të zhvillohet si një makinë në një linjë montimi në të cilën secila pjesë shtohet në faza të njëpasnjëshme. Në këto faza të njëpasnjëshme, çdo fazë e projektit duhet të përfundojë përpara se të fillojë faza tjetër. Dr. Royce rekomandoi përdorimin e një qasjeje me faza, në të cilën zhvilluesit fillimisht mbledhin të gjitha kërkesat e projektit, dhe më pas plotësojnë të gjithë arkitekturën dhe dizajnin e tyre, pastaj shkruajnë të gjithë kodin, e kështu me radhë.

Në vitet 1990, një sërë metodash të shkathët të zhvillimit të softuerit u zhvilluan në përgjigje të metodave mbizotëruese të peshave të rënda. Këto përfshijnë: që nga viti 1991 - RAD (zhvillimi i shpejtë i aplikacioneve); që nga viti 1994 - Metoda Dinamike e Zhvillimit të Sistemeve (DSDM); që nga viti 1995 - Scrum; Që nga viti 1996, Crystal Clear and Extreme Programming (XP); Dhe që nga viti 1997 - Zhvillimi i drejtuar nga veçoritë (FDD). Edhe pse ato kanë origjinën përpara publikimit të Manifestit të Zhvillimit të Softuerit të shkathët, ato quhen kolektivisht si Zhvillimi i Softuerit të shkathët.

Në shkurt 2001, shtatëmbëdhjetë zhvillues softuerësh u takuan në Snowbird Resort në Utah për të diskutuar teknikat e lehta të zhvillimit. Së bashku ata botuan Manifestin e shkathët.

Manifesti i shkathët

Manifesti i shkathët përbëhet nga 4 ide thelbësore dhe 12 parime. Çdo metodologji Agile i zbaton këto ide në mënyra të ndryshme, por të gjitha ato mbështeten në to për të menaxhuar projektet në mënyrë sa më efikase.

4 Ide të shkathëta

1. Njerëzit dhe ndërveprimi janë më të rëndësishëm se proceset dhe mjetet.
2. Softueri i punës është më i rëndësishëm se dokumentacioni.
3. Bashkëpunimi me klientët është më i rëndësishëm sesa negociimi i kushteve të kontratës.
4. Gatishmëria për të bërë ndryshime në prioritet në vend që t'i përmbaheni planit origjinal.

12 parimet e Agile

1. Kënaqësia e klientit përmes ofrimit të hershëm dhe të vazhdueshëm të softuerit. Klientët janë më të lumtur kur marrin softuer që funksionon në intervale të rregullta.
2. Bëni ndryshime në kërkesat e produktit gjatë gjithë procesit të zhvillimit.
3. Dorëzimi i shpeshtë i softuerit të punës (çdo muaj, çdo dy javë, çdo javë, etj.).
4. Bashkëpunimi ndërmjet palëve të interesuara (klient dhe zhvillues) gjatë gjithë projektit.
5. Mbështetja, besimi dhe motivimi i personave të përfshirë. Ekipet e motivuara kanë më shumë gjasa të përmbushin punën e tyre puna më e mirë sesa punonjësit e pakënaqur me kushtet e punës.
6. Ndërveprimi ballë për ballë. Komunikimi është më i suksesshëm kur ekipet e zhvillimit janë në gjendje të komunikojnë drejtpërdrejt.
7. Softueri i punës është masa kryesore e progresit. Shpërndarja e softuerit funksional te klienti është faktori përfundimtar që mat progresin.
8. Ruajtja e një ritmi konstant të punës. Ekipet krijojnë një shkallë të përsëritshme dhe të qëndrueshme operimi në të cilën ata mund të ofrojnë softuer funksional.
9. Vëmendje ndaj detajeve teknike dhe dizajnit. Aftësitë e duhura dhe dizajn i mirë lejoni ekipin të ruajë vrullin, të përmirësojë vazhdimisht produktin dhe të punojë për ndryshimin.
10. Thjeshtësia.
11. Ekipet vetë-organizuese inkurajojnë arkitekturë, kërkesa dhe dizajne të shkëlqyera. Anëtarët e ekipit të kualifikuar dhe të motivuar, të cilët kanë autoritetin për të marrë vendime, komunikojnë rregullisht me anëtarët e tjerë të ekipit dhe shkëmbejnë ide që do të sigurojnë krijimin e një produkti cilësor.
12. Përshtatja e vazhdueshme ndaj kushteve në ndryshim, gjë që do të ndihmojë në bërjen e produktit më konkurrues në treg.

Baza e metodës Agile

Baza e metodës së shkathët të menaxhimit të projektit është një numër elementësh kyç:

1. Kontrolli vizual. Pjesëmarrësit e projektit përdorin karta me ngjyra dhe lloje të ndryshme gjatë punës në projekt, të cilat sinjalizojnë se cili element i produktit përfundimtar tashmë është zhvilluar, planifikuar, përfunduar, etj. Kështu, ekipi ka një paraqitje vizuale të gjendjes aktuale të punëve. Kontrolli vizual siguron të njëjtin vizion të projektit nga secili prej pjesëmarrësve.
2. Të gjithë pjesëmarrësit e projektit punojnë krah për krah, duke përfshirë klientin. Kjo qasje jo vetëm që shpejton shumë nga proceset që lidhen me informimin e anëtarëve të grupit të punës, por edhe krijon atmosferë të favorshme për bashkëpunim dhe punë efektive.
3. Menaxhimi i adaptueshëm. Menaxheri i projektit nuk është një person që jep udhëzime, por një drejtues që përcakton rregullat bazë të punës dhe bashkëpunimit.
4. Bashkëpunimi. Ekipi, menaxheri i projektit dhe klienti punojnë së bashku, gjë që eliminon mundësinë e humbjes së informacionit dhe keqkuptimit të qëllimeve. Gjithashtu, transparenca e të gjitha proceseve ju lejon të eliminoni menjëherë problemet e shfaqura dhe të gjeni zgjidhje dhe përmirësime të suksesshme.
5. Puna e bazuar në ndarjen e qëllimit të përgjithshëm të projektit në pjesët përbërëse të tij. Ky sistem i punës redukton ndjeshëm kompleksitetin e projektit dhe lejon që ekipet të fokusohen në secilën pjesë veç e veç.
6. Punoni me gabimet. Gjatë punës së një cikli, ekipi mëson aftësi të reja dhe analizon gabimet që kanë ndodhur, gjë që përjashton shfaqjen e tyre në ciklin tjetër.
7. Sprintet dhe takimet e përditshme. Sprintet - periudha kohore gjatë të cilave ekipet kryejnë një sërë detyrash - ju lejojnë të shihni qartë rezultatet e punës. Duke e ndarë kohën e punës në projekt në sprinte, marrim, për shembull, 10 sprinte, secila për dy javë. Dhe takimet ditore për jo më shumë se 15 minuta do të ndihmojnë secilin anëtar të ekipit t'i përgjigjet vetes tre pyetjeve: çfarë bëra dje, çfarë do të bëj sot, çfarë më pengon të bëj punë?

Kështu, hyrja metodë fleksibël Agile është e mundur në kushtet e mëposhtme:

• kuptimi i projektit tregohet qartë,
• klienti është i përfshirë në mënyrë aktive gjatë gjithë projektit,
• zbatimi i mundshëm hap pas hapi i qëllimit të përgjithshëm të projektit,
• rezultati i punës është më i rëndësishëm se dokumentacioni,
• grupi i punës nuk është më shumë se 7-9 persona.

Në ky moment Metodologjia e shkathët është e përhapur në fushën e TI-së dhe ka filluar të zotërojë fushën e biznesit, në veçanti marketingun, menaxhimin, trajnimin, etj. Metoda e shkathët e menaxhimit të projektit përdoret nga shumë kompani dhe agjenci qeveritare, për shembull, qeveritë e Norvegjisë dhe e Re Zelanda përdor Agile. Në Rusi, Sberbank po zotëron Agile për sektorin tregtar.

Sistemet e menaxhimit të projektit të bazuara në Agile

Ka shumë metoda të bazuara në idenë e Agile, më të njohurat prej tyre janë Scrum dhe Kanban.

SCRUM

Scrum është një metodologji e menaxhimit të projektit që fokusohet në kontrollin e cilësisë së procesit të punës. Hirotaka Takeuchi dhe Ikujiro Nonaka, të parët që përshkruan qasjen Scrum, e shpjeguan atë si "qasja e rugbit", në të cilën scrum po lufton për topin. Vetë metoda është një proces zhvillimi i ndarë në përsëritje të vogla - sprinte, në fund të të cilave përdoruesit marrin një version të përmirësuar të softuerit. Sprint është fiksuar në mënyrë të ngurtë në kohë, dhe kohëzgjatja e tij është nga 2 në 4 javë. Puna brenda një sprinti përbëhet nga disa faza:

1. Planifikimi i fushës së punës për një sprint.
2. Takime ditore për 15 minuta për të korrigjuar punën e ekipit dhe për të përmbledhur rezultatet e ndërmjetme.
3. Demonstrimi i rezultateve të punës.
4. Një retrospektivë sprint që shqyrton sukseset dhe dështimet e sprintit të fundit.

Scrum përdoret më së shpeshti për të menaxhuar softuerin kompleks dhe zhvillimin e produkteve duke përdorur metoda përsëritëse dhe rritëse.

Scrum rrit shumë produktivitetin dhe zvogëlon kohën në avantazh ndaj proceseve klasike "ujëvara". Proceset Scrum i lejojnë organizatat të përshtaten pa probleme me kërkesat që ndryshojnë me shpejtësi dhe të krijojnë një produkt që plotëson qëllimet në ndryshim të biznesit. Scrum ju lejon të:

• Përmirësimi i cilësisë së rezultateve;
• Më mirë të merresh me ndryshimin;
• Siguroni vlerësime më të sakta, duke shpenzuar më pak kohë për krijimin e tyre;
• Është më mirë të kontrolloni skenarin e projektit dhe fazat e punës.

Kanban

Kanban është një proces i krijuar për të ndihmuar ekipet të punojnë së bashku në mënyrë më efektive. Në japonisht, kanban do të thotë " billboard, tabela”, dhe vetë metoda është marrë dhe përshtatur nga sistemi i prodhimit Toyota. Thelbi i Kanban është të bëjë procesin e zhvillimit sa më transparent dhe të shpërndajë ngarkesën në mënyrë të barabartë midis anëtarëve të ekipit. Kanban promovon bashkëpunimin e vazhdueshëm dhe inkurajon mësimin dhe përmirësimin aktiv, të vazhdueshëm.

Kanban bazohet në tre parime:

1. Vizualizimi i detyrave: dukshmëria e të gjithë informacionit rreth projektit do të ndihmojë për të parë mangësitë, gabimet dhe mbivendosjet.
2. Kontrolli dhe kufizimi i WIP (puna në vazhdim): Kjo ndihmon për të balancuar qasjen e filetimit në mënyrë që ekipet të mos fillojnë dhe të bëjnë shumë punë menjëherë.
3. Kontrolloni kohën për të përfunduar detyrën dhe optimizoni punën për të kursyer kohë.

Avantazhet dhe disavantazhet e Agile

Çdo metodologji ka avantazhe dhe disavantazhe. Merrni parasysh të mirat dhe të këqijat e Agile.

Përparësitë

1. Më shumë fleksibilitet në krahasim me metodologjinë Waterfall.

Metodologjia tradicionale e ujëvarës dikton qartë fazat e punës. Me metodologjinë Agile, orari dhe kostoja janë përcaktuesit kryesorë, dhe kjo është një fushë që ndryshon për të përmbushur kërkesat e klientëve dhe konsumatorëve të produktit.

2. Më pak defekte në produktin përfundimtar.

Ky është rezultat i kontrolleve cilësore të kryera në çdo fazë të punës. Procesi i vazhdueshëm"zhvilloni, ndërtoni dhe testoni" gjithashtu redukton defektet ndërsa ciklet e përsëritjes vazhdojnë.

Të metat

1. Marrja e vazhdueshme e komenteve çon në një shtyrje të vazhdueshme të datës së përfundimit të projektit.

Me reagimet e menjëhershme që ofron Agile, ekziston një rrezik punë e gjatë. Përdoruesit përfundimtarë që shohin se këto kërkesa mund të përmbushen "lehtë" (ata shohin vetëm rezultatin, jo përpjekjen) do të kërkojnë veçori shtesë. Nëse menaxheri i projektit dhe zhvilluesit nuk mund të menaxhojnë pritshmëritë, përdoruesit përfundimtarë do të vazhdojnë të kërkojnë më shumë derisa i gjithë ekipi të ngarkohet me punë shtesë.

2. Dokumentacioni

Për shkak të natyrës fleksibël të Agile, dokumentacioni duhet të ndjekë kushtet e projektit që ndryshojnë me shpejtësi. Një kërkesë ndryshimi ose veçorie mund të diskutohet në detaje dhe të bihet dakord me përdoruesit përfundimtarë, zhvilluesit dhe testuesit, por nëse ekipi nuk është informuar, një dokument kritik si manuali i përdoruesit, dokumenti i arkitekturës ose kërkesë funksionale, do të bëhet i vjetëruar.

3. Takime të shpeshta

Ndërsa Agile rekomandon që këto takime të mbahen çdo ditë për të mbajtur të gjithë të përditësuar për përparimin e njëri-tjetrit, qëndrueshmëria e kësaj praktike ndikon në progresin e përsëritjeve. Zhvilluesit janë të përqendruar në atë që po bëjnë. Tërheqja e tyre për një takim që mund t'i shpërqendrojë ata të bëjnë punë aktuale, nuk është diçka që ata do ta pranojnë me kënaqësi.

Zbatimi i shkathët

1. Zgjedhja e metodologjisë. Ekzistojnë metodologji të ndryshme fleksibël që zhvillohen në kushte të caktuara. Hapi i parë në punën me Agile është të përcaktoni qëllimet e detyrës së punës, afatet, numrin e punonjësve dhe shumë më tepër dhe të zgjidhni një metodologji kaq fleksibël të menaxhimit të projektit që do të plotësojë të gjitha kërkesat.
2. Trajnimi. Trajnimi është i nevojshëm në mënyrë që punonjësit të kuptojnë parimet bazë të Agile dhe të dinë se si të punojnë me to. Pikërisht në këtë fazë identifikohen kurthet që mund të zvogëlohen Efikasiteti i shkathët. A është skuadra gati për ndryshim? A janë projektet e kompanisë të përshtatshme për praktika të shkathëta? Këto dhe shumë pyetje të tjera zakonisht marrin përgjigje nga trajnerët e biznesit Agile. Ndër të tjera do të hartohet edhe një listë trajnimesh dhe një plan, sipas të cilit do të realizohet zbatimi i Agile në kompani.
3. Demoja e shkathët. Një lloj test drive Agile, i cili kryhet nën mbikëqyrjen e një specialisti dhe tregon të gjitha fazat e punës, shpjegon funksionet e roleve, ndërveprimin brenda ekipit dhe midis ekipeve, etj.
4. Krijimi i një ekipi. Krahas përzgjedhjes së punonjësve, krijimi i një ekipi përfshin edhe përcaktimin e përgjegjësive, shpërndarjen e detyrave, krijimin e një orari takimesh etj. Çdo metodë është krijuar për një sasi të caktuar të person në ekip.
5. Zgjedhja e mjeteve të nevojshme për shpërndarjen e detyrave, raportimin, analitikën dhe më shumë.
6. Projekti i parë me Agile. Në projektin e parë do të ketë gabime, mospërputhje, refuzim të disa mjeteve dhe zgjedhje të të tjerëve. Çdo teknikë kërkon një lloj përshtatjeje me karakteristikat e kompanisë në të cilën po zbatohet.

Nëse gjeni një gabim, ju lutemi theksoni një pjesë të tekstit dhe klikoni Ctrl+Enter.

Është e vështirë të gjesh një person që nuk do të donte të trajtohej me respekt. Por duhet të ketë një arsye për këtë gjendje. Për shembull, kur një person është një specialist i njohur shumë i kualifikuar në fushën e zhvillimit të softuerit. Dhe për këtë ju duhet të studioni. Dhe në kuadrin e këtij artikulli, ne do të shqyrtojmë se çfarë është Agile, cili është përdorimi i tij dhe si ta kuptojmë këtë teknologji.

informacion i pergjithshem

Së pari, le të merremi me çështjet teknike. Çfarë është Agile? Përkthimi (fjalë për fjalë) i kësaj fjale nga të gjuhës angleze- "live, i lëvizshëm", "fleksibël" përmendet pak më rrallë. Dhe meqë ra fjala, është një shkurtim. Emri i plotë i kësaj qasjeje është I shkathët zhvillimin e softuerit. Por duke qenë se është shumë i gjatë, u vendos që të pritet. Dhe tani ata thjesht thonë Agile. Përkthimi si "fleksibël" përdoret për faktin se përputhet më shumë me situatën reale.

Çfarë përfshihet këtu?

Ne vazhdojmë të shqyrtojmë se çfarë është Agile. Këtu dua të përqendrohem në faktin se kjo është një qasje fleksibël, e cila bazohet në shumë të ndryshme XP, "Kanban", Lean). Për të kuptuar më mirë temën, le të bëjmë paralele. Le të themi se teknologjitë Agile janë procesi i lindjes së Universit. Produkti përfundimtar është vetë bota aktuale. Dhe shpërthimi i madh është problemi më i dhimbshëm me të cilin duhet të përballeni - ndryshimi i listës së kërkesave të produktit. Në mënyrë tipike, proceset e krijimit përfshijnë përdorimin modeli i ujëvarës. Në këtë rast, gjithçka shkon në mënyrë sekuenciale dhe në faza. Kjo qasje mund të shprehet shkurtimisht: Unë shoh qëllimin - shkoj drejt tij. Dhe nëse kërkesat për rezultatin përfundimtar ndryshojnë, atëherë ndonjëherë ju duhet të ribëni pothuajse gjithçka përsëri. Ajo që e ndërlikon më tej këtë situatë është përpjekja për të pretenduar se gjithçka është në rregull dhe se duhet të ecim përpara.

Dhe këtu është menaxhimi, i krijuar për t'u marrë me të gjitha këto falë fleksibilitetit të tij. Ky hodgepodge minimizon rreziqet e ndryshme nëpërmjet përdorimit të grupeve të parimeve. Të gjitha ato pasqyrohen në Manifestin Agile, të botuar në 2001. Shkurtimisht, ato tingëllojnë kështu:

1. Gjëja kryesore janë njerëzit, jo gjërat.
2. Bashkëpunoni, mos e lexoni kontratën.
3. Dokumentacioni nuk duhet të ndërhyjë në punë.
4. Ndryshoni sa më shpejt të jetë e mundur.

Mund të duket shumë e paqartë dhe jo e saktë, por le të detajojmë.

Dizajni i procesit

Duke marrë parasysh se çfarë është Agile, le të kthehemi tek një nga metodologjitë më të njohura të njohura si "Scrum" (Scrum). Çfarë ofron ajo? Për të filluar ju duhet:

1. Zgjidhni një pronar produkti. Ky rol është i përshtatshëm për një person që sheh se në cilin qëllim duhet të shkoni dhe çfarë do të ndodhë në fund.
2. Vendosni për një ekip. Kjo kërkon një grup prej tre deri në dhjetë persona që kanë aftësitë për të arritur rezultate.
3. Zgjidhni një person përgjegjës. Ky është një person që do të monitorojë zhvillimin e projektit dhe do të ndihmojë ekipin të kapërcejë vështirësitë.
4. Përballuni me vështirësitë. Të gjitha kërkesat ekzistuese të produktit duhet të mblidhen në një vend dhe të prioritizohen. Pronari i produktit duhet të mbledhë të gjitha dëshirat e tij këtu. Pastaj ekipi i vlerëson ato dhe kupton nëse mund të zbatohet dhe sa kohë nevojitet për këtë.
5. Ju duhet të ndani të gjithë fushën e punës në periudha kohore, një ose dy javë të gjata, gjatë të cilave ekipi do të kryejë grupe të caktuara detyrash.
6. Takimet duhet të mbahen çdo ditë, jo më shumë se pesëmbëdhjetë minuta. Rendi i ditës duhet të diskutojë se çfarë është bërë dje, cilat janë planet për sot dhe pengesat që na pengojnë të marrim lartësinë.
7. Bëni rishikime në fund të javës (dy), gjatë së cilës ekipi flet për atë që është bërë. Në të njëjtën kohë, është e nevojshme të demonstrohet performanca e pjesëve të produktit.
8. Pas çdo periudhe kohe, problemet duhet të diskutohen dhe të kërkohen zgjidhje. Për më tepër, të gjitha zhvillimet duhet të zbatohen menjëherë.

Si ta njohim Agile?

Metodologjia e menaxhimit, pavarësisht nga drejtimi i zgjedhur, gjithmonë ka karakteristikat e mëposhtme:

1. Minimizimi i rrezikut. atë objektivi kryesor që ndjek çdo qasje fleksibël.
2. Zhvillimi përsëritës. Në këtë rast, nënkuptohet puna në cikle të vogla.
3. Gjëja më e rëndësishme janë njerëzit dhe komunikimi mes tyre.

Le të imagjinojmë një lumë. Në njërën anë të klientit. E dyta është ekipi. Në këtë rast, metodologjia e zhvillimit të shkathët ka përparësi për të gjithë:

1. Klienti dëshiron një produkt minimal të qëndrueshëm. Në të njëjtën kohë, kushtet mund të ndryshojnë gjatë krijimit të tij.
2. Është e dobishme që ekipi të komunikojë me kolegët dhe klientin. Në këtë rast, rreziku për t'u keqkuptuar minimizohet, transparenca e proceseve rritet, problemet zgjidhen shpejt dhe zvogëlohen shanset që të ketë një surprizë gjatë krijimit të një produkti.

faktor social

Kur flasin për atë që është Agile, ata zakonisht flasin vetëm për gjëra pozitive. Në të vërtetë, komunikimi brenda ekipit po përmirësohet. Të gjithë njerëzit fokusohen në një ide, nuk krijojnë sekrete mes tyre, bëjnë angazhime. Si rezultat, ekipi punon në kushte komode dhe me ritme të shpejta. Kjo qasje ju lejon të thjeshtoni kaosin.

Që nga formimi i saj, ajo ka qenë në gjendje të gjejë njohje në industritë e teknologjisë. Aktualisht përdoret gjerësisht për dizajnimin e të rejave produkte softuerike. Por në praktikën e përgjithshme të biznesit, kjo qasje është ende pak e njohur. Prandaj, ata që nuk e kanë takuar Agile më parë janë të kujdesshëm për këtë. Duhet të kuptohet gjithashtu se duhet të përdoret vetëm në rastet kur njerëzit përballen me detyrën e punës intelektuale.

Shembull i vogël

Le të hedhim një vështrim se si funksionojnë këto metodologji të zhvillimit të softuerit. Le të themi se kemi Pjetrin, pronarin e produktit. Ai nuk i di detajet teknike, por ka një vizion të pamjes së madhe. Ai e di pse është i nevojshëm produkti, çfarë problemesh do të zgjidhë dhe kë do të kënaqë. Ka edhe të interesuar. Ata mund ta përdorin produktin, të mbështesin krijimin e tij ose ndryshe të përfshihen në krijimin e tij. Ju gjithashtu mund të shtoni histori përdoruesish që shprehin dëshirat e palëve të interesuara. Për shembull: sistemi për prenotimin e biletave për autobusët e rregullt Moskë-Shën Petersburg duhet të ketë një kërkim për fluturime. Pjetri do të ndihmojë personat e interesuar. Ai do të marrë kontrollin e zbatimit nga idetë e historisë së përdoruesit. Ekziston edhe një ekip zhvillimi. Këta janë njerëzit që do të ndërtojnë sistemin e punës.

Meqenëse metodologjia e zhvillimit është e shkathët, historitë e përdoruesve nuk grumbullohen deri në një publikim të madh, por lëshohen menjëherë pas përfundimit dhe sa më shpesh të jetë e mundur. Numri i kërkesave të përpunuara është xhiroja javore e ekipit. Për të mos humbur vrullin dhe për të mos zhytur në testimin manual, ekipi duhet të punojë në integrimin e automatizuar. Çfarë është ajo? Për çdo moment pune shkruhet një test automatik. Nëse ka shumë histori, atëherë mund të ketë nxitim, humbje të motivimit, humbje të produktivitetit dhe cilësisë. Për raste të tilla jepet metoda “moti i djeshëm”. Ai qëndron në faktin se ju duhet të vendosni kufizime të rrepta në sasinë e punës dhe të zgjidhni me kujdes se çfarë saktësisht do të zbatohet. "Kanban" i përmendur më parë sugjeron vendosjen e një kufiri detyrash.

Çfarë të bëni me radhën?

Mirë, kështu që ekipi vendosi që ata të mund të përpunonin katër histori në javë. Por si të lundroni në gjithçka që është? Le të themi se përdoruesit ngarkojnë dhjetë histori në javë. Katër janë duke u përpunuar. Kështu, radha do të rritet vazhdimisht. Në këtë rast, ekziston vetëm një metodë efektive- fjala "jo". Për pronarin e produktit, kjo është jashtëzakonisht e rëndësishme. Të thuash "po" nuk është e vështirë. Është shumë më e vështirë dhe më e rëndësishme të vendosësh se çfarë të mos bësh. Për më tepër, është gjithashtu e nevojshme të mbani përgjegjësi për këtë. Prandaj, është e nevojshme të vendosni se çfarë t'i kushtoni vëmendje tani dhe çfarë duhet të shtyhet. Për ta bërë atë të drejtë, pronari i produktit duhet të kuptojë vlerën dhe shtrirjen e çdo historie.

Ne marrim vendime

Disa nga historitë janë jashtëzakonisht të nevojshme. Të tjerët janë thjesht një bonus i mirë. Disa histori do të duhen disa orë për t'u zhvilluar. Të tjerave do të duhen muaj për t'u përfunduar. Shumë shpesh krijojnë një lidhje midis madhësisë së një historie dhe vlerës së saj. Por kjo nuk është gjithmonë e saktë. Më shumë nuk është njësoj si më mirë. Kompleksiteti dhe vlera e detyrës në fjalë e ndihmon Pjetrin të vendosë saktë përparësitë. Si mund të kuantifikohen këto karakteristika? Në asnjë mënyrë. Kjo është një lojë e vërtetë hamendësimi. Dhe për një efektivitet më të madh, është e nevojshme të përfshihen shumë njerëz në të. Ky është ekipi i zhvillimit, i cili do të informojë për qëllimin e punës dhe palët e interesuara. Por duhet kuptuar se të gjitha të dhënat e marra në këtë mënyrë janë supozime të përafërta. Këtu nuk ka shifra të sakta. Fillimisht do të ketë mungesa. Por ndërsa fitoni përvojë, numri dhe shkalla e tyre do të ulet.

Rreziqet e mundshme

Për të shmangur problemet, është e nevojshme të jepni përgjigje të sinqerta për një sërë pyetjesh. Ajo:

1. A po bëjmë gjërat e duhura? Ky është një rrezik biznesi.
2. A mund të zbatojmë atë që na nevojitet?
3. A do të funksionojë projekti në këtë platformë. Ky është një rrezik teknik.
4. A ka para të mjaftueshme dhe a do të kemi kohë? Këto janë rreziqe të kushteve të zbatimit dhe kostos.

Në këtë rast kërkohet njohuri. Ato mund të shihen si të kundërta të rreziqeve. Kur fiksohet një nivel i konsiderueshëm i pasigurisë, atëherë ne fitojmë njohuri - për shembull, krijojmë prototipe të ndërfaqes ose eksperimente teknike. Dhe tashmë duke i zotëruar ato, ne marrim vendime për drejtimin në të cilin duhet të lëvizim.

Si të mësoni?

Industria e IT po zhvillohet jashtëzakonisht shpejt dhe për të mos humbur në fund, është e nevojshme të mësoni vazhdimisht, të përmirësoni aftësitë dhe efikasitetin e punës. Prandaj, çështjet e trajnimit dhe zbatimit janë më të rëndësishme se kurrë. Ku të fillojë? Shumica opsioni më i mirë- ky është bashkëpunim me një kompani ku tashmë aplikohet Agile. Trajnimi në këtë rast do të kryhet nga njerëz që nuk e dinë nga thashethemet se çfarë është zhvillimi i shkathët. Por, mjerisht, kjo nuk është gjithmonë e mundur. Më shpesh, përfshihet një specialist i palës së tretë që e di se çfarë është Agile. Zbatimi i kësaj qasjeje kryhet nën mbikëqyrjen e tij. Vërtetë, shërbimet e një specialisti të tillë kushtojnë para. Por nëse merrni një person vërtet të ditur, atëherë të gjitha shpenzimet do të paguajnë shumë. Në fund të fundit, në bota moderne Performanca e punonjësve luan një rol të rëndësishëm.

Çfarë pret për të ardhmen?

Metodologjitë e zhvillimit të softuerit po zhvillohen vazhdimisht. Në kërkim të mënyrave dhe mundësive të reja për të përmirësuar efikasitetin e aktiviteteve dhe punës. Është mjaft problematike të thuhet se çfarë na pret e ardhmja. Ndoshta, sistemi fleksibël i zhvillimit do të integrohet me mjetet e automatizimit proceset e prodhimit. Për shembull, do të jetë e mundur të zgjidhni problemet edhe kur jeni në distancë nga vendndodhja e kompanisë. Në shumë mënyra, e ardhmja përcaktohet nga e reja Teknologjia e Informacionit. Në fund të fundit, kur ato lindin, ju duhet të zotëroni metoda të reja për të punuar me ta. Dhe në këtë rast ka një zhvillim të mbyllur në një cikël.

Së fundi

Pra, ekskursioni në ato fleksibël përfundoi, por duhet të kujtojmë se teoria është një gjë dhe praktika është krejt tjetër. Teknologjitë e reja të informacionit që po shfaqen vazhdimisht po sfidojnë komunitetin e madh të zhvilluesve. Si mund ta bëni ekipin tuaj më efikas? Përgjigjen për këtë pyetje të gjithë e gjen vetë. Informacioni i paraqitur këtu mund të përdoret për të formuar shtyllën kurrizore. Por në praktikë, do t'ju duhet të punoni me modelin ekzistues dhe të sillni gjendjen e punëve në një gjendje të përputhshmërisë me sfidat ekzistuese. Atëherë skuadra do të jetë në gjendje të përmbushë në mënyrë efektive qëllimet e saj.