Wikipedia

Zhvillimi i shkathët i softuerit

Zhvillimi i shkathët i programit kompjuterik është një term mbulim për qasjet ndaj zhvillimit të softuerit që pasqyrojnë vlerat dhe parimet e miratuara nga The Agile Alliance, një grup prej 17 praktikuesish të softuerit, në vitin 2001.[1] Siç dokumentohet në Manifestin e tyre për Zhvillimin e Softuerit të shkathët, praktikuesit i japin rëndësi:[2]

  • Individët dhe ndërveprimet mbi proceset dhe mjete
  • Softueri funksional mbi dokumentimin e plotë
  • Bashkëpunimi me klientin mbi negociatat e kontratave
  • Reagimi ndaj ndryshimeve mbi ndjekjen e një plani

Praktikuesit marrin frymëzim nga praktikat e reja në atë kohë, si: programimin ekstrem, scrum, metodën dinamike të zhvillimit të sistemeve, zhvillimin adaptiv të softuerit dhe të qenit i hapur ndaj nevojës për një alternativë ndaj proceseve të zhvillimit të softuerit të bazuara në dokumentacion.[3]

Shumë praktika të zhvillimit të softuerit dolën nga mendësia e shkathët. Këto praktika të bazuara në shkathtësi, të quajtura ndonjëherë Agile (me shkronjën A)[4] përfshijnë përcaktimin e kërkesave, eksplorimin dhe përmirësimin e zgjidhjeve përmes përpjekjeve bashkëpunuese nga ekipe vetë-organizuese dhe ndërfunksionale, në partneritet me klientët dhe përdoruesit përfundimtarë.[5] [6]

Megjithëse ekzistojnë shumë prova anekdotike që mendësia e shkathët dhe praktikat e bazuara në shkathtësi përmirësojnë procesin e zhvillimit të softuerit, provat empirike janë të kufizuara dhe më pak se përfundimtare.[7] [8] [9]

Historia

Redakto

Metodat përsëritëse dhe rritëse të zhvillimit të softuerit mund të gjurmohen qysh në vitin 1957, me menaxhimin evolucionar të projektit [10] [11] dhe zhvillimin adaptiv të softuerit [12] të cilat filluan të shfaqen në fillim të viteve 1970".[13]

Në vitet 1990,disa qasje të lehta për zhvillimin e softuerit evoluan si reagim ndaj metodave mbizotëruese të peshave të rënda (shpesh të referuara kolektivisht si ujëvarë ) që kritikët i përshkruan si tepër të rregulluara, të planifikuara dhe të mikromenaxhuara .[14] Këto metoda të lehta përfshinin: zhvillimin e shpejtë të aplikacioneve (RAD), nga viti 1991;[15] [16] procesi i unifikuar (UP) dhe metoda dinamike e zhvillimit të sistemeve (DSDM), të dyja nga viti 1994; Scrum, nga viti 1995; Crystal Clear dhe programim ekstrem (XP), të dyja nga viti 1996; dhe zhvillimi i drejtuar nga tiparet (FDD), nga 1997.Edhe pse të gjitha këto kanë nisur përpara publikimit të Manifestit të Agile, tani ato njihen së bashku si metoda të zhvillimit të softuerit agil.[3]

Që nga viti 1991, ndryshime të ngjashme ishin duke u zhvilluar në prodhim dhe në të menduarit e menaxhimit [17] që rrjedhin nga Menaxhimi i Lean .

Në vitin 2001, shtatëmbëdhjetë zhvillues softuerësh u mblodhën në një vendpushim në Snowbird, Utah për të diskutuar metodat e lehta të zhvillimit. Anëtarët e grupit ishin: Kent Beck (Programim Ekstrem), Ward Cunningham (Programim Ekstrem), Dave Thomas ( Programim Pragmatik, Ruby), Jeff Sutherland (Scrum), Ken Schwaber (Scrum), Jim Highsmith (Zhvillim Adaptive Software), Alistair Cockburn (Crystal ), Robert C. Martin ( SOLID ), Mike Beedle (Scrum), Arie van Bennekum, Martin Fowler ( OOAD dhe UML ), James Grenning, Andrew Hunt (Programim Pragmatik, Ruby), Ron Jeffries (Programim Ekstrem), Jon Kern, Brian Marick (Ruby, zhvillim i drejtuar nga testi ) dhe Steve Mellor ( OOA ). Grupi, The Agile Alliance, publikoi Manifestin për Zhvillimin e Softuerit Agile .[2]

Në vitin 2005, një grup i udhëhequr nga Cockburn dhe Highsmith përgatiti një shtojcë të parimeve të menaxhimit të projektit, Deklaratën PM të Ndërvarësisë,[18] për të udhëhequr menaxhimin e projekteve të softuerit sipas metodave të shkathët të zhvillimit të softuerit.

Në vitin 2009, një grup që bashkëpunonte me Martin shkroi një shtrirje të parimeve të zhvillimit të softuerit, Manifestin e mjeshtërisë së softuerit, për të udhëhequr zhvillimin e shkathët të softuerit sipas sjelljes dhe zotërimit profesional .

Në vitin 2011, Aleanca Agile përgatiti udhëzuesin Guide to Agile Practices (i riemërtuar në Fjalorthin Agile në 2016),[19] një përmbledhje në zhvillim me burim të hapur të përkufizimeve të punës të praktikave, termave dhe elementeve të shkathët, së bashku me interpretimet dhe udhëzimet e përvojës nga komuniteti mbarëbotëror i praktikuesve të shkathët.

Vlerat dhe parimet

Redakto

Vlerat

Redakto

Po kërkojmë mënyra më të mira për të zhvilluar softuer duke e bërë atë dhe duke ndihmuar të tjerët ta bëjnë atë. Nëpërmjet kësaj pune ne kemi arritur të vlerësojmë:

  • Njerëzit dhe bashkëveprimi mbi proceset dhe mjetet.
  • Software funksional mbi dokumentacionin e plotë.
  • Bashkëpunimi me klientin mbi negociatën e kontratës.
  • Përgjigjja ndaj ndryshimeve mbi ndjekjen e një plani.

Kjo do të thotë se, ndonëse ka vlerë në artikujt në të djathtë, ne i vlerësojmë më shumë artikujt në të majtë.

Scott Ambler shpjegoi:[20]

  • Mjetet dhe procedurat kanë rëndësi, por është më e rëndësishme të kesh njerëz kompetentë që punojnë së bashku në mënyrë efektive.
  • Dokumentacioni i qartë ndihmon njerëzit të kuptojnë se si është ndërtuar softueri dhe si ta përdorin atë, por pika kryesore e zhvillimit është krijimi i softuerit dhe jo dokumentacionit.
  • Një kontratë është e nevojshme, por nuk është një zëvendësim për të punuar ngushtë me klientët për të zbuluar atë që ata kanë nevojë.
  • Një plan projekti është thelbësor, por ai nuk duhet të jetë shumë i ngurtë për të përshtatur ndryshimet në teknologji ose mjedis, prioritetet e palëve të interesuara dhe të kuptuarit e njerëzve për problemin dhe zgjidhjen e tij.

Në emër të Aleancës Agile, Jim Highsmith prezantoi Manifestin dhe tha:

Agile nuk është kundër metodologjive, në fakt shumë prej nesh duan të rikthejnë besueshmërinë në fjalën metodologji. Ne duam të rikthejmë një ekuilibër. Ne përqafojmë modelimin, por jo për ta futur në një dosje dhe për ta arkivuar në një depo korporate të pluhurosur. Ne përqafojmë dokumentimin, por jo qindra faqe dokumentesh që kurrë nuk përditësohen dhe që përdoren rrallë. Ne planifikojmë, por e kuptojmë kufizimin e planifikimit në një mjedis të turbullt. Ata që etiketojnë mbështetësit e XP, SCRUM, ose çdo metodologji tjetër Agile si "hacker" janë të paditur për të dyja, metodologjitë dhe përkufizimin origjinal të fjalës hacker.

--Jim Highsmith, History: The Agile Manifesto[21]

 

Parimet

Redakto

Vlerat bazohen në këto parime:[22] Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber (2001). "Principles behind the Agile Manifesto" (në anglisht). Agile Alliance. Arkivuar nga origjinali më 14 qershor 2010. Marrë më 6 qershor 2010.{{cite web}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)</ref>

  1. Kënaqësia e klientit me dorëzimin i shpejtë dhe i vazhdueshëm të softuerit të vlefshëm.
  2. Pranon kërkesat që ndryshojnë, madje edhe në zhvillim të vonshëm.
  3. Siguroni softuer që funksionon shpesh (javë dhe jo muaj).
  4. Bashkëpunim i ngushtë, i përditshëm mes biznesmenëve dhe zhvilluesve.
  5. Projektet krijohen rreth individëve të motivuar, të cilëve duhet t'u besohet.
  6. Biseda ballë për ballë është forma më e mirë e komunikimit (bashkëvendndodhja).
  7. Softueri i punës është masa kryesore e progresit.
  8. Zhvillim i qëndrueshëm, i aftë për të mbajtur një ritëm konstant.
  9. Kujdesi i vazhdueshëm për përsosmërinë teknike dhe dizajnin e mirë.
  10. Thjeshtësia - arti i maksimizimit të sasisë së punës not bërë - është thelbësor.
  11. Arkitekturat, kërkesat dhe dizajnet më të mira dalin nga ekipet vetë-organizuese.
  12. Rregullisht, ekipi reflekton se si të bëhet më efektiv dhe përshtatet në përputhje me rrethanat.

Vështrim i përgjithshëm

Redakto

Iterative, rritëse dhe evolucionare

Redakto

Shumica e metodave të zhvillimit të shkathët e thyejnë punën e zhvillimit të produktit në rritje të vogla që minimizojnë sasinë e planifikimit dhe dizajnit paraprak. Përsëritjet, ose sprintet, janë korniza të shkurtra kohore ( kuti kohore ) [23] që zakonisht zgjasin nga një deri në katër javë.[24] :20Çdo përsëritje përfshin një ekip ndërfunksional që realizon të gjitha aktivitetet: planifikim, analizë, projektim, kodim, testim dhe testim pranimi. Në fund, demonstrohet një produkt funksional për palët e interesuara, duke reduktuar rrezikun dhe mundësuar përshtatjen shpejtë me ndryshimet [23] [25] Një përsëritje mund të mos shtojë funksionalitet të mjaftueshëm për të garantuar një lëshim të menjëhershëm në treg, por qëllimi është të kemi një version funksional (me sa më pak gabime) në fund të çdo përsëritjeje.[26] Përmes zhvillimit të vazhdueshëm, produktet kanë mundësinë të "dështojnë shpesh dhe herët" gjatë çdo faze përsëritëse, në vend që të ndodhin ndodhi drastike në një datë të caktuar përfundimtare të lëshimit.[27] Mund të kërkohen përsëritje të shumta për të nxjerrë një produkt ose veçori të reja. Softueri i punës është masa kryesore e progresit.[22]

Një avantazh kryesor i qasjeve të shkathëta është shpejtësia në treg dhe menaxhimi i rrezikut. Rritje më të vogla zakonisht lëshohen në treg, duke zvogëlon rreziqet e kohës dhe kostos së inxhinierisë së një produkti që nuk i plotëson kërkesat e përdoruesit.

Komunikim efikas dhe ballë për ballë

Redakto

Rregulli i 6-të i manifestit të shkathët për zhvillimin e softuerit thotë ".Mënyra më produktive dhe funksionale për të përcjellë informacionin tek dhe brenda një ekipi zhvillimi është komunikimi ballë për ballë. Manifesti, i shkruar në vitin 2001, kur video-konferencat nuk ishin përdorur gjerësisht, thekson këtë lidhur me komunikimin e informacionit, pa e bërë të domosdoshme që ekipi të jetë gjithmonë i bashkëvendosur.

Parimi i bashkëvendosjes është që bashkëpunëtorët në të njëjtin ekip duhet të vendosen së bashku për të krijuar më mirë identitetin si ekip dhe për të përmirësuar komunikimin.[28] Kjo mundëson ndërveprimin ballë për ballë, idealisht para një dërrase të bardhë, që përshpejton procesin krahasuar me ndërmjetësimin e pyetjeve dhe përgjigjeve përmes telefonit, chat-it, wiki-t ose email-it. [29] Me miratimin e gjerë të punës në distancë gjatë pandemisë COVID-19 dhe ndryshimet në mjete, janë realizuar më shumë studime [30] rreth bashkëvendosjes dhe punës së shpërndarë, të cilat tregojnë se bashkëvendndodhja është gjithnjë e më pak e rëndësishme.

Pavarësisht qasjes së zhvillimit që ndiqet, çdo ekip duhet të përfshijë një përfaqësues të klientit (i njohur si pronar produkti në Scrum). Ky përfaqësues është i pranuar nga palët e interesuara për të vepruar në emër të tyre dhe angazhohet personalisht për t'u qenë i disponueshëm zhvilluesve për t'iu përgjigjur pyetjeve gjatë gjithë ciklit të zhvillimit. Në fund të çdo cikli, palët e interesuara, së bashku me përfaqësuesin e klientit, rishikojnë përparimin dhe rivlerësojnë prioritetet, me qëllimin për të optimizuar kthimin e investimit (ROI) dhe për të siguruar që produkti të përmbushë nevojat e klientëve dhe objektivat e kompanisë. Rëndësia e kënaqësisë së palëve të interesuara, e cila sigurohet përmes ndërveprimeve dhe rishikimeve të shpeshta në fund të çdo faze, është arsyeja pse kjo qasje shpesh konsiderohet si një metodologji e përqendruar te klienti.[31]

Radiator informacioni

Redakto

Në zhvillimin e softuerit të shkathët,jë radiator informacioni është një ekran fizik (zakonisht i madh), një tabelë me shënime ngjitëse ose një mjet tjetër të ngjashëm, i vendosur në një zonë të dukshme pranë ekipit të zhvillimit, ku kalimtarët mund ta shohin dhe të aksesojnë informacionin e shfaqur.[23] Ai paraqet një përmbledhje të përditësuar të statusit të zhvillimit të produktit.[32] Një tregues i dritës së ndërtimit mund të përdoret gjithashtu për të informuar një ekip për statusin aktual të zhvillimit të produktit të tyre.

Cikli shumë i shkurtër i reagimit dhe cikli i përshtatjes

Redakto

Një karakteristikë e zakonshme në zhvillimin e softuerit të shkathët është stand-up-i ditor (i njohur si scrum ditor në kornizën Scrum). Në një seancë të shkurtër (p.sh., 15 minuta), anëtarët e grupit shqyrtojnë së bashku përparimin e tyre në arritjen e qëllimeve dhe vendosin nëse duhet të modifikojnë qasjen e tyre.. Për të mbajtur afatin kohor të rënë dakord, ekipet shpesh përdorin pyetje të thjeshta të koduara (siç janë ato që kanë përfunduar një ditë më parë, çfarë synojnë të plotësojnë atë ditë dhe nëse ka ndonjë pengesë ose rrezik për përparimin) dhe vonojnë diskutimet dhe problemin e detajuar zgjidhje deri pas ngritjes.[33]

Fokusi në cilësi

Redakto
 
Programimi i çifteve, një teknikë e shkathët zhvillimi e përdorur në XP

Mjetet dhe metodat e veçanta, të tilla si integrimi i vazhdueshëm, testimi i automatizuar i njësive, programimi i çifteve, zhvillimi i drejtuar nga testet, modelet e projektimit, zhvillimi i drejtuar nga sjellja, dizajni i drejtuar nga domeni, rifaktorimi i kodit dhe teknika të tjera përdoren shpesh për të përmirësuar cilësinë dhe për të përmirësuar zhvillimin e produktit shkathtësia.[34] Kjo bazohet në dizajnimin dhe ndërtimin e cilësisë që nga fillimi dhe aftësinë për të paraqitur softuer për klientët në çdo moment, ose të paktën në fund të çdo përsëritjeje.[35]

Filozofia

Redakto

Krahasuar me inxhinierinë tradicionale të softuerit, zhvillimi i shkathët i softuerit synon kryesisht sisteme komplekse dhe zhvillimin e produkteve me veti dinamike, indeterministe dhe jolineare.Vlerësimet e sakta, planet e qëndrueshme dhe parashikimet shpesh janë të vështira për t'u realizuar në fazat e hershme, dhe besimi në to pritet të jetë i ulët. Praktikuesit e shkathët përdorin lirinë e tyre për të zvogëluar "hapjen e besimit" që kërkohet përpara se të bëhen ndonjë provë me vlerë .[36] Kërkesat dhe dizajni konsiderohen si emergjente . Specifikimet e mëdha paraprake ndoshta do të shkaktonin shumë mbetjet e panevojshme në raste të tilla, dmth. nuk janë ekonomikisht të shëndosha. Këto argumente bazë dhe përvojat e mëparshme të industrisë, të mësuara nga vitet e sukseseve dhe dështimeve, kanë ndihmuar në formimin e favorit të zhvillimit të shkathët ndaj zhvillimit adaptues, përsëritës dhe evolucionar.[37]

Përshtatës kundrejt parashikues

Redakto

Metodat e zhvillimit ekzistojnë në një vazhdimësi nga adaptive në parashikuese .[38] Metodat e zhvillimit të softuerit të shkathët qëndrojnë në anën e përshtatshme të kësaj vazhdimësie. Një çelës i metodave adaptive të zhvillimit është një qasje <i id="mwAS4">me valë rrotulluese</i> për planifikimin e orarit, e cila identifikon dëshira kryesore, por lë fleksibilitet në rrugën për t'i arritur ato, dhe gjithashtu lejon që vetë piketat të ndryshojnë.[39]

Metodat adaptive fokusohen në përshtatjen e shpejtë me realitetet në ndryshim. Kur nevojat e një projekti ndryshojnë, një ekip adaptiv gjithashtu ndryshon. Një ekip adaptiv ka vështirësi të përshkruajë saktësisht se çfarë do të ndodhë në të ardhmen. Sa më larg të jetë një datë, aq më e paqartë është një metodë adaptive për atë që do të ndodhë në atë datë. Një ekip adaptiv nuk mund të informoj me saktësi se cilat detyra do të bëjnë javën e ardhshme, por vetëm cilat veçori planifikojnë për muajin e ardhshëm. Kur pyetet për një lëshim pas gjashtë muajsh, një ekip përshtatës mund të jetë në gjendje të raportojë vetëm deklaratën e misionit për lëshimin, ose një deklaratë të vlerës së pritur kundrejt kostos.

Metodat parashikuese, në të kundërt, përqendrohen në analizimin dhe planifikimin e së ardhmes në detaje dhe kujdesen për rreziqet e njohura. Në ekstremet, një ekip parashikues mund të figurojnë informacion të saktë se cilat veçori dhe detyra janë planifikuar për të gjithë gjatësinë e procesit të zhvillimit. Metodat parashikuese mbështeten në analizën efektive të fazës së hershme, dhe nëse kjo shkon shumë keq, projekti mund të ketë vështirësi në ndryshimin e drejtimit. Ekipet parashikuese shpesh krijojnë një bord kontrolli të ndryshimeve për të siguruar që ata marrin parasysh vetëm ndryshimet më të vlefshme.

Analiza e rrezikut mund të shfrytëzohet për të bërë një zgjedhje midis metodave adaptive ( të shkathëta ose të drejtuara nga vlera ) dhe parashikuese ( të drejtuara nga plani ).[40] Barry Boehm dhe Richard Turner sugjerojnë që secila anë e vazhdimësisë ka terrenin e vet, si më poshtë:[41]

Bazat shtëpiake të metodave të ndryshme të zhvillimit
Metodat e drejtuara nga vlera (të shkathëta) Metodat e drejtuara nga plani (ujëvara) Metodat formale
Kriticitet i ulët Kriticitet i lartë Kriticitet ekstrem
Zhvilluesit e vjetër Zhvilluesit e rinj (?) Zhvilluesit e vjetër
Kërkesat ndryshojnë shpesh Kërkesat nuk ndryshojnë shpesh Kërkesa të kufizuara, veçori të kufizuara, shihni ligjin e Wirth[nevojitet qartësim]
Një numër i vogël zhvilluesish Një numër i madh zhvilluesish Kërkesat që mund të modelohen
Kultura që i përgjigjet ndryshimit Kulturë që kërkon rregull Cilësi ekstreme

Agile kundrejt ujëvarës

Redakto

Një ndryshim midis metodave të zhvillimit të softuerit të shkathët dhe ujëvarës është qasja ndaj cilësisë dhe testimit. Në modelin e ujëvarës, puna kalon nëpër fazat e ciklit jetësor të zhvillimit të softuerit (SDLC), ku faza e testimit është e ndarë pas ndërtimit. Ndërsa në zhvillimin e softuerit të shkathët, testimi bëhet brenda të njëjtës përsëritje si programimi.

Për shkak se verifikimi bëhet në çdo përsëritje - që ndërton një pjesë të vogël të softuerit - përdoruesit mund t'i përdorin shpesh ato pjesë të reja të softuerit dhe të vërtetojnë vlerën.Kur klientët njohin vlerën e vërtetë të përditësimit të softuerit, ata mund të marrin vendime më të mira për të ardhmen e tij. Pasi çdo përsëritje përfshin një sesion retrospektiv për vlerësim dhe ri-planifikim, ekipet mund të përshtatin planet për të maksimizuar vlerën që ofrohet. Ky proces është i ngjashëm me ciklin PDCA, ku puna planifikohet, realizohet, kontrollohet dhe veprohet sipas rezultateve të analizës.

Kjo metodë e përsëritur mbështet një artikull dhe jo një mentalitet projekti . Kjo ofron fleksibilitet gjatë gjithë procesit të zhvillimit, ndërsa në projektet me kërkesa të përcaktuara që në fillim, është e vështirë t’i ndryshosh ato më vonë. Zhvillimi i përsëritur lejon softuerin të evoluojë sipas ndryshimeve në mjedisin e biznesit ose kërkesat e tregut.

Kodi kundrejt dokumentacionit

Redakto

Në një letër drejtuar IEEE Computer, Steven Rakitin shprehu dyshim për zhvillimin e shkathët, duke e quajtur atë "një përpjekje tjetër për të ulur disiplinën e inxhinierisë softuerike" dhe duke interpretuar "softuerin që funksionon mbi dokumentacionin gjithëpërfshirës" si "ne duam të kalojmë gjithë kohën duke koduar. Mos harroni, programuesit e vërtetë nuk shkruajnë dokumentacion."[42]

Ithtarët e zhvillimit të softuerit të shkathët kundërshtojnë këtë, duke thënë se zhvilluesit duhet të shkruajnë dokumentacion kur është e nevojshme, por shpesh ka mënyra më të efektshme për të arritur qëllimet sesa shkrimi i dokumentacionit statik.[43] Scott Ambler thekson se dokumentacioni duhet të jetë "mezi mjaftueshëm i mirë" (JBGE),[44] se dokumentacioni i tepërt ose gjithëpërfshirës zakonisht do të shkaktonte humbje dhe zhvilluesit rrallë i besojnë dokumentacionit të detajuar sepse zakonisht nuk është i pasqyruar me kodin,[43] megjithatë, shumë pak dokumentacion mund të shkaktojë probleme në mirëmbajtje, komunikim, mësim dhe shkëmbim njohurish. Alistair Cockburn shkroi për metodën Crystal Clear:

Alistair Cockburn[45]


Metodat

Redakto
 
Mbështetja e ciklit jetësor të zhvillimit të softuerit
 
Procesi i unifikuar i shkathët (AUP) bazohet në një proces të unifikuar (një kuadër procesi i zhvillimit të softuerit përsëritës dhe në rritje).

Metodat e zhvillimit të softuerit të shkathët favorizojnë një gamë të gjerë të ciklit jetësor të zhvillimit të softuerit .

Kornizat e njohura të zhvillimit të softuerit të shkathët përfshijnë:

Korniza Kontribuesit kryesorë
Zhvillimi adaptiv i softuerit (ASD) Jim Highsmith, Sam Bayer
Modelimi i shkathët Scott Ambler, Robert Cecil Martin
Procesi i unifikuar i shkathët (AUP) Scott Ambler
Ofrimi i shkathët i disiplinuar Scott Ambler
Metoda e zhvillimit të sistemeve dinamike (DSDM) Jennifer Stapleton
Programim ekstrem (XP) Kent Beck, Robert Cecil Martin
Zhvillimi i drejtuar nga veçoritë (FDD) Jeff De Luca
Zhvillimi i dobët i softuerit Mary Poppendieck, Tom Poppendieck
Fillimi i dobët Eric Ries
Kanban Taiichi Ohno
Zhvillimi i shpejtë i aplikacioneve (RAD) James Martin
Scrum Ken Schwaber, Jeff Sutherland
Scrumban

Praktikat e zhvillimit të softuerit të shkathët

Redakto

Zhvillimi i softuerit të shkathët mbështetet në praktika të ndryshme që mbulojnë fusha si kërkesat, dizajni, modelimi, kodimi, testimi, planifikimi, menaxhimi i rrezikut, procesi dhe cilësia. Disa mënyra pune të dukshme të zhvillimit të softuerit të shkathët përfshijnë:[46]

Praktikoni Kontribuesit kryesorë
Zhvillimi i drejtuar nga testi i pranimit (ATDD) Ken Pugh
Modelimi i shkathët Scott Ambler
Testimi i shkathët Lisa Crispin, Janet Gregory
Mbështetjet (Produkti dhe Sprinti) Ken Schwaber, Jeff Sutherland
Zhvillimi i drejtuar nga sjellja (BDD) Dan North, Liz Keogh
Integrimi i vazhdueshëm (CI) Grady Booch
Ekipi ndërfunksional
Stand-up ditor / Daily Scrum James O Coplien
Dizajni i drejtuar nga domeni (DDD) Eric Evans
Zhvillimi përsëritës dhe rritës (IID)
Programimi në çift Kent Beck
Planifikimi i pokerit James Grenning, Mike Cohn
Rifaktorimi Martin Fowler
Retrospektive Esther Derby, Diana Larsen, Ben Linders, Luis Gonçalves
Ngjarjet Scrum (planifikimi i sprintit, rishikimi i sprintit dhe retrospektiva) Ken Schwaber, Jeff Sutherland
Specifikimi me shembull
Modelimi i drejtuar nga historia Albert Zündorf
Zhvillimi i drejtuar nga testi (TDD) Kent Beck
Timeboxing
Historia e përdoruesit Alistair Cockburn
Ndjekja e shpejtësisë

Zhvillimi i drejtuar nga testi i pranimit

Redakto

Zhvillimi i bazuar në testet e pranueshmërisë (ATDD) është një metodologji zhvillimi e bazuar në komunikimin midis klientëve të biznesit, zhvilluesve dhe testuesve.[47] ATDD përfshin shumë nga praktikat e ngjashme me specifikimin përmes shembujve (SBE),[48] zhvillimin e bazuar në sjellje (BDD),[49] zhvillimin e bazuar në shembuj (EDD)[50] dhe zhvillimin e mbështetur, i quajtur gjithashtu zhvillimi i bazuar në testet e tregimeve (SDD).[51] Të gjitha këto procese ndihmojnë zhvilluesit dhe testuesit të kuptojnë nevojat e klientëve para implementimit dhe lejojnë klientët të mund të komunikojnë në gjuhën e tyre të domain-it.

Modelimi Agile (AM) është një metodologji për modelimin dhe dokumentimin e sistemeve softuerikë, e bazuar në praktikat më të mira. Ajo është një koleksion vlerash dhe parimesh që mund të aplikohen në një projekt zhvillimi softuerik (agil). Kjo metodologji është më fleksibël se metodat tradicionale të modelimit, duke e bërë atë më të përshtatshme në një mjedis që ndryshon shpejt.[52] Ajo është pjesë e paketës së mjeteve për zhvillimin softuerik agil.

Testimi i shkathët

Redakto

Testimi Agile është një praktikë e testimit të softuerit që ndjek parimet e zhvillimit agil të softuerit. Testimi Agile përfshin të gjithë anëtarët e një ekipi agil të ndërkufizuar, me ekspertizën speciale të kontribuar nga testuesit, për të siguruar dorëzimin e vlerës së biznesit që kërkohet nga klienti në intervale të shpeshta, duke punuar me një ritëm të qëndrueshëm. Specifikimi përmes shembujve përdoret për të kapur shembuj të sjelljeve të dëshiruara dhe të padëshiruara dhe për të udhëhequr kodimin.

Backlogs

Në menaxhimin e projekteve agile, backlog-u i produktit i referohet një liste të renditur sipas prioriteteve të funksionaliteteve që një produkt duhet të përmbushë. Ndonjëherë quhet si një listë për të bërë,[53] dhe konsiderohet si një "objekt" (një formë dokumentimi) brenda kuadrit të zhvillimit softuerik Scrum.[54] Backlog-u i produktit ka emra të ndryshëm në kuadër të metodologjive të ndryshme të menaxhimit të projekteve, siç janë backlog-u i produktit në Scrum,[55] lista e elementeve të punës në Disciplined Agile,[56] dhe pishina e opsioneve në Lean.[55] Në kuadrin e Scrum, krijimi dhe mirëmbajtja e vazhdueshme e backlog-ut të produktit është pjesë e përgjegjësisë së pronarit të produktit.

Zhvillimi i drejtuar nga sjellja

Redakto

Zhvillimi i bazuar në sjellje (BDD) përfshin emërtimin e testeve të softuerit duke përdorur gjuhën e domain-it për të përshkruar sjelljen e kodit.

Integrim i vazhdueshëm

Redakto

Integrimi i vazhdueshëm (CI - Continuous Integration) është praktika e integrimit të ndryshimeve të kodit burimor shpesh dhe sigurimi që baza e kodit të integruar të jetë në një gjendje të punueshme.

Ekipi ndërfunksional

Redakto

Një ekip ndër-funksional (XFN), i njohur gjithashtu si ekip multidisiplinar ose interdisiplinar,[57] është një grup njerëzish me ekspertizë të ndryshme funksionale që punojnë drejt një qëllimi të përbashkët.[58] Ai mund të përfshijë njerëz nga departamentet e financës, marketingut, operacioneve dhe burimeve njerëzore. Zakonisht, ai përfshin punonjës nga të gjitha nivelet e një organizate. Anëtarët mund të vijnë gjithashtu nga jashtë organizatës (sidomos nga furnizuesit, klientët kyç, ose konsulentët).

Stand up ditor

Redakto

Në literaturë, përdoren terma të ndryshëm për përshtatjen e metodës, si "përshtatja e metodës", "përshtatja e pjesëve të metodës" dhe "inxhinieria e metodës së situatës". Përshtatja e metodës përcaktohet si:

Përshtatshmëria ndaj situatës është një veçori e rëndësishme e metodave të shkathëta, që u lejon ekipeve të zhvillimit të përshtatin metodat e punës sipas nevojave të produkteve individuale, në krahasim me metodat më të orientuara nga plani.[59] Potencialisht, shumica e metodave të shkathëta mund të jenë të përshtatshme për përshtatjen e metodave, siç është DSDM e përshtatur në një kontekst CMM . dhe XP të përshtatura me teknikën e praktikave të përshkrimit të rregullave (RDP).[60] Jo të gjithë mbështetësit e shkathët pajtohen, megjithatë, me Schwaber që vëren "kështu u futëm në telashe në radhë të parë, duke menduar se problemi nuk ishte të kishim një metodologji të përsosur. Përpjekjet [duhet] të përqendrohen në ndryshimet [të nevojshme] në ndërmarrje". Bas Vodde e përforcoi këtë këndvështrim, duke sugjeruar që ndryshe nga metodologjitë tradicionale, të mëdha që kërkojnë nga ju të zgjidhni dhe zgjidhni elementë, Scrum ofron bazat mbi të cilat shtoni elementë shtesë për të lokalizuar dhe kontekstualizuar përdorimin e tij. Përgjithësisht, praktikuesit nuk i përdorin metodat e zhvillimit të sistemeve, ose metodat e shkathëta specifikisht, në përputhje me udhëzimet e librit, shpesh duke zgjedhur të lënë jashtë ose të përshtatin disa nga praktikat e një metode për të krijuar një metodë të brendshme.

Në praktikë, metodat mund të përshtaten duke përdorur mjete të ndryshme. Gjuhët gjenerike të modelimit të proceseve, si gjuha e unifikuar e modelimit, mund të përdoren për të përshtatur metodat e zhvillimit të softuerit. Sidoqoftë, ekzistojnë gjithashtu mjete të dedikuara për inxhinierinë e metodave, siç është Koncepti iThelbit dhe Inxhinierisë Softuerike të SEMAT .

Në shkallë të gjerë, në det të hapur dhe të shpërndarë

Redakto

Zhvillimi i softuerit të shkathët është parë gjerësisht si shumë i përshtatshëm për disa lloje mjedisesh, duke përfshirë grupe të specializuara të zhvilluesve që punojnë në projekte të reja,[41] [61] dhe sfidat dhe kufizimet që hasen në adoptimin e metodave të zhvillimit të softuerit të shkathët në një organizatë të madhe, me infrastrukturë të trashëguar, janë të dokumentuara dhe të kuptuara mirë.[62]

Si përgjigje, një sërë strategjish dhe modelesh ka përparuar për të tejkaluar sfidat me përpjekje zhvillimi në shkallë të gjerë (>20 zhvillues) ose ekipe zhvillimi të shpërndara (jo të vendosura),[63] [64] mes sfidave të tjera, tani ka disa struktura të njohura që synojnë të zbusin ose shmangin këto sfida.

Ka shumë mendime të kundërta nëse të gjitha këto janë efektive apo me të vërtetë përshtaten me përkufizimin e zhvillimit të shkathët, dhe kjo mbetet një fushë kërkimore aktive dhe e vazhdueshme.

Kur zhvillimi i shkathët i softuerit zbatohet në një ambient të shpërndarë (me ekipe të shpërndara nëpër vende të shumta biznesi), ai zakonisht quhet zhvillim i shkathët i softuerit të shpërndarë. Qëllimi është të shfrytëzohen përfitimet unike të ofruara nga çdo qasje. Zhvillimi i shpërndarë i mundëson organizatave të ndërtojnë softuer duke ngritur në mënyrë strategjike ekipe në pjesë të ndryshme të globit, duke ndërtuar praktikisht softuer gjatë gjithë orarit (më shpesh i referuar si modeli ndjekës i diellit). Nga ana tjetër, zhvillimi i shkathët siguron rritje të dukshmërisë, reagime të vazhdueshme dhe më shumë fleksibilitet kur iu përgjigjet ndryshimeve.

Domenet e rregulluara

Redakto

Metodat e zhvillimit të softuerit të shkathët fillimisht janë konsideruar si më të përshtatshmet për zhvillime jo kritike të produkteve, duke përjashtuar kështu përdorimin në fusha të rregulluara si pajisjet mjekësore, farmaceutike, financiare, sistemet bërthamore, automobilat dhe sektorët e avionikës, etj.Sidoqoftë, gjatë viteve të fundit, ka pasur disa iniciativa për përshtatjen e metodave të shkathëta për këto fusha.[65] [66] [67] [68]

Ekzistojnë shumë standarde që mund të zbatohen në fusha të rregulluara, siç janë: ISO 26262, ISO 9000, ISO 9001 dhe ISO/IEC 15504 . Një numër shqetësimesh kryesore janë të një rëndësie të veçantë në fushat e rregulluara:[69]

  • Sigurimi i cilësisë (QA): Menaxhimi sistematik dhe i natyrshëm i cilësisë që mbështet një proces të kontrolluar profesional dhe besueshmërinë dhe korrektësinë e produktit.
  • Siguria dhe siguria: Planifikimi formal dhe menaxhimi i rrezikut për të ulur kërcënimet ndaj sigurisë për përdoruesit dhe për të mbrojtur në mënyrë të sigurt përdoruesit nga keqpërdorimi i paqëllimshëm dhe me qëllim të keq.
  • Gjurmueshmëria : Dokumentacioni që ofron dëshmi të auditueshme të përputhshmërisë rregullatore dhe lehtëson gjurmueshmërinë dhe hetimin e problemeve.
  • Verifikimi dhe vlefshmëria (V&V): pjesëmarrja e këtyre aktiviteteve gjatë gjithë procesit të zhvillimit të softuerit (p.sh. specifikimet e kërkesave të përdoruesit, specifikimet funksionale, specifikimet e dizajnit, rishikimi i kodit, testet e njësisë, testet e integrimit, testet e sistemit).

Përvoja dhe adoptimi

Redakto

Megjithëse praktikat e zhvillimit të softuerit të shkathët mund të përdoren me çdo paradigmë ose gjuhë programimi në praktikë, ato fillimisht ishin të lidhura ngushtë me mjedise të orientuara nga objekti si Smalltalk, Lisp dhe më vonë Java, C#. Përdoruesit fillestarë të metodave të shkathëta ishin zakonisht ekipe të vogla dhe të mesme që punonin në sisteme të paprecedentë me kërkesa që ishin të vështira për t'u finalizuar dhe me gjasë që të ndryshonin gjatë sistemit po zhvillohej. [70]

Matja e shkathtësisë

Redakto

Vlerësimet e brendshme

Redakto

Indeksi i matjes së shkathtësisë vlerëson, ndër të tjera, zhvillimet në raport me pesë aspekte të rëndësishme të zhvillimit të produktit: kohëzgjatjen, rrezikun, risinë, përpjekjet dhe ndërveprimin. Teknika të tjera mbështetet në qëllime të matshme[71] dhe një studim sugjeron që shpejtësia mund të përdoret si një metrikë e shkathtësisë. Ekzistojnë gjithashtu vetë-vlerësime të shkathëta për të përcaktuar nëse një grup po përdor praktika të shkathët të zhvillimit të softuerit (testi i Nokia-s,[72] testi Karlskrona,[73] testi me 42 pikë).[74]

Sondazhet publike

Redakto

Një nga studimet i mëparshëm që raportoi fitime në cilësi, produktivitet dhe kënaqësi të biznesit duke përdorur metoda të shkathëta të zhvillimit të softuerit ishte një sondazh i realizuar nga Shine Technologies nga nëntori 2002 deri në janar 2003.[75]

Një sondazh i ngjashëm, State of Agile, zhvillohet çdo vit që nga viti 2006 dhe përfshin mijëra pjesëmarrës nga komuniteti global i zhvilluesve të softuerit. Ky sondazh monitoron tendencat në lidhje me përfitimet e perceptuara të shkathtësisë, mësimet e nxjerra dhe praktikat më të mira. Çdo vit, sondazhi raporton një rritje të numrit të atyre që thonë se zhvillimi i shkathët i ndihmon ata të dorëzojnë softuer më shpejt, përmirëson aftësinë për të menaxhuar ndryshimet në prioritetet e klientëve dhe rrit produktivitetin.[76] Sondazhet gjithashtu kanë treguar vazhdimisht rezultate më të mira me metodat e zhvillimit të produktit të shkathët në krahasim me menaxhimin klasik të projektit.[77] Në ekuilibër, ka raporte që disa mendojnë se metodat e zhvillimit të shkathët janë ende shumë të reja për të mundësuar kërkime të gjera akademike të suksesit të tyre.[78]

Grackat e zakonshme të zhvillimit të softuerit të shkathët

Redakto

Organizatat dhe ekipet që adoptojnë zhvillimin e softuerit të shkathët shpesh hasin vështirësi kur kalojnë nga metodat tradicionale, si zhvillimi në ujëvarë, në procese më fleksibël, ku ekipet duhet të ndjekin një qasje të shkathët që mund të jetë shumë më e detajuar dhe e ndërlikuar.[79] Këto shpesh quhen antimodele të shkathëta ose më shpesh erëra të shkathëta . Më poshtë janë disa shembuj të zakonshëm:

Mungesa e dizajnit të përgjithshëm të produktit

Redakto

Një nga qëllimet kryesore të zhvillimit të softuerit të shkathët është të fokusohet më shumë në krijimin e softuerit funksional dhe më pak në krijimin e dokumentacionit të detajuar. Kjo është në kundërshtim me modelet tradicionale si zhvillimi në ujëvarë, ku procesi është shumë i kontrolluar dhe çdo ndryshim i vogël kërkon përditësime të mëdha të dokumentacionit mbështetës. Megjithatë, kjo nuk do të thotë që nuk duhet të bëhet analiza apo dizajni. Moskryerja e një analize të thelluar mund të çojë në një zhvillim të shpejtë fillestar, por më pas të krijojë nevojën për ripunim të rëndësishëm kur sistemi zgjerohet. Një nga veçoritë e rëndësishme të zhvillimit të softuerit të shkathët është përsëritshmëria, që do të thotë se dizajni evoluon gjatë zhvillimit të softuerit. Kjo i mundëson ekipeve të zbulojnë mundësi për ripërdorim dhe të shmangin zgjidhjet që mund të krijojnë probleme më vonë.[80]

Shtimi i tregimeve në një përsëritje në vazhdim

Redakto

Në zhvillimin e softuerit të shkathët, tregimet (të ngjashme me përshkrimet e rasteve të përdorimit ) zakonisht përdoren për të përcaktuar kërkesat dhe një përsëritje është një periudhë e shkurtër kohore gjatë së cilës ekipi fokusohet në qëllime specifike.[81] Shtimi i tregimeve në një përsëritje në vazhdim është e dëmshme për një rrjedhë të qetë të punës. Këto duhet t'i shtohen sasisë së mbetur të produktit dhe t'i jepen përparësi për një përsëritje të mëvonshme ose në raste të rralla përsëritja mund të anulohet.[82]

Kjo nuk do të thotë që një histori nuk mund të zgjerohet. Ekipet shpesh duhet të përballen me informacion të ri, i cili mund të krijojë detyra shtesë për një histori. Nëse ky informacion i ri pengon përfundimin e historisë brenda një përsëritjeje, ai duhet të shtyhet për një përsëritje të mëvonshme. Megjithatë, ky informacion i ri duhet të marrë përparësi ndaj të gjitha histori të tjera të mbetura, pasi mund të ketë ndryshuar prioritetin e fillestar të historisë, duke e bërë atë më të rëndësishme për zhvillimin e mëtejshëm.

Mungesa e mbështetjes nga sponsorët

Redakto

Zhvillimi i shkathët i softuerit shpesh zbatohet nga ekipet e zhvillimit të softuerit në organizata, që synojnë optimizimin e proceseve të tyre të zhvillimit dhe sigurinë e stabilitetit në ciklin jetësor të zhvillimit të softuerit. Pa mbështetje nga sponsorët, këto ekipe mund të hasin vështirësi dhe rezistencë nga partnerët e biznesit, ekipet e tjera të zhvillimit dhe menaxhmenti. Po ashtu, ato mund të vuajnë nga mungesa e financimit dhe burimeve të nevojshme për të realizuar qëllimet e përcaktuara.[83] Kjo rrit rastin e dështimit.[84]

Trajnim i pamjaftueshëm

Redakto

Një sondazh i realizuar nga VersionOne zbuloi se të anketuarit theksuan trajnimin e pamjaftueshëm si shkakun më të rëndësishëm për zbatimin e dështuar të shkathët[85] Ekipet mund të mendojnë se zhvillimi i shkathët është më i thjeshtë dhe më i shpejtë se metodat si ujëvara, duke menduar se nuk ka rregulla të qarta. Megjithatë, zhvillimi i shkathët ka parime dhe praktika të qarta që udhëhojnë ekipet për të arritur efikasitet dhe cilësi, duke u fokusuar në fleksibilitet dhe bashkëpunim.

Roli i pronarit të produktit nuk është plotësuar siç duhet

Redakto

Pronari i produktit ka përgjegjësinë për të përfaqësuar biznesin në aktivitetin e zhvillimit dhe shpesh është roli më kërkues.[86]

Një gabim i zakonshëm është që roli i pronarit të produktit të mbulohet nga dikush nga ekipi i zhvillimit. Kjo e bën ekipin të marrë vendime për prioritizimin pa pasur reagime të drejtpërdrejta nga biznesi, duke i detyruar ata të zgjidhin çështje biznesi brenda ekipit ose të vonojnë punën për të marrë drejtim nga jashtë. Kjo shpesh çon në shpërqendrim dhe dëmton bashkëpunimin.[87]

Skuadrat nuk janë të fokusuara

Redakto

Zhvillimi i softuerit të shkathët kërkon që ekipet të angazhohen plotësisht për produktin dhe të përqendrohen vetëm në atë punë. Megjithatë, anëtarët e ekipit që duket se kanë kapacitet të lirë shpesh pritet të marrin përsipër detyra të tjera, duke bërë të vështirë për ta që të kontribuojnë në përfundimin e punës për të cilën ekipi ishte angazhuar.[88]

Përgatitje/planifikim i tepruar

Redakto

Ekipet mund të bien në grackën e shpenzimit të tepërt të kohës në përgatitje ose planifikim. Ky është një gabim i zakonshëm për ekipet që nuk janë mjaft të njohura me zhvillimin e softuerit të shkathët, ku ata ndihen të detyruar të kenë një kuptim dhe specifikim të plotë të të gjitha historive. Në të vërtetë, ekipet duhet të jenë të gatshme të përparojnë vetëm me ato histori për të cilat kanë besim dhe të vazhdojnë të zbulojnë dhe përgatisin punën për përsëritjet e ardhshme, duke i konsideruar këto si përpunim ose rregullim të mbeturinave.

Zgjidhja e problemeve në standupin e përditshëm

Redakto

Një qëndrim i përditshëm duhet të jetë një takim i fokusuar dhe në kohë ku të gjithë anëtarët e ekipit ndajnë informacion. Nëse ndodhin probleme, shpesh mund të kërkojnë vetëm përfshirjen e disa anëtarëve të ekipit dhe mund të mos jetë përdorimi më efikas i kohës së të gjithë grupit. Nëse ekipi fillon të zhytet në zgjidhjen e këtyre problemeve gjatë aktiviteteve të përditshme, është më mirë t'i shtyhet zgjidhja për një moment të dytë, kur një nën-ekip mund të diskutojë dhe të merret me to, zakonisht menjëherë pas përfundimit të punëve të planifikuara.[89]

Caktimi i detyrave

Redakto

Një nga përfitimet kryesore të zhvillimit të softuerit të shkathët është fuqizimi i ekipit për të marrë vendime, duke qenë më afër problemit dhe situatës. Për më tepër, ekipet duhet të bëjnë zgjedhje sa më afër momentit të zbatimit, për të përdorur informacionin më të saktë dhe të përditësuar për vendimmarrjen. Nëse detyrat u caktohen anëtarëve të ekipit nga jashtë ose shumë herët në proces, kjo mund të minojë përfitimet e vendimmarrjes lokale dhe të shpejtë, duke e bërë procesin më të ngadalshëm dhe më pak efikas.[90]

Duke u caktuar detyra të caktuara, anëtarëve të ekipit u vihet një kufizim i roleve (p.sh., anëtari i ekipit A duhet të kryejë gjithmonë punën e bazës së të dhënave), duke i kufizuar mundësitë për trajnime dhe zhvillim të mëtejshëm ndërmjet tyre. Kjo mund të pengojë fleksibilitetin dhe mundësitë për t’u rritur si një ekip, duke ngushtuar mundësitë për ndihmën e ndërsjellë dhe krijimin e njohurive të përbashkëta.[90] Vetë anëtarët e ekipit mund të zgjedhin të marrin përsipër detyra që zgjerojnë aftësitë e tyre dhe ofrojnë mundësi ndër-trajnimi.

Scrum master si kontribues

Redakto

Në kornizën Scrum, roli i masterit të Scrum është i fokusuar në sigurinë që procesi Scrum ndiqet në mënyrë të saktë dhe që ekipi i Scrum ka mbështetje për të përfunduar detyrat e tij. Një gabim i zakonshëm është që masteri i Scrum të përfshihet drejtpërdrejt në zhvillimin e produktit, duke kontribuar si një zhvillues. Edhe pse kjo nuk është ndaluar shprehimisht nga korniza Scrum, roli kryesor i masterit të Scrum është të sigurojë që ekipi të ndiqet procesin dhe të ndihmojë në heqjen e pengesave, dhe jo të marrë pjesë aktivisht në krijimin e produktit. Kjo i mundëson masterit të Scrum të fokusohet në lehtësimin e procesit dhe udhëheqjen e ekipit drejt suksesit.[91]

Një master scrum, si një ekspert i multitasking-ut, shpesh përballet me ndërrime të shpeshta të kontekstit, gjë që mund ta bëjë sfiduese ruajtjen e produktivitetit. Për më tepër, duke qenë përgjegjës për heqjen e pengesave që pengojnë ekipin të përparojë, përfitimi nga përparimi në detyrat individuale mund të mos ketë të njëjtën peshë me vonesat e shkaktuara nga mungesa e burimeve apo kapacitetit për të adresuar ato pengesa.[92]

Mungesa e automatizimit të testit

Redakto

Për shkak të natyrës përsëritëse të metodologjisë Agile, shpesh kërkohen cikle të shumta testimi. Automatizimi i testimit luan një rol kyç në zvogëlimin e ndikimit të testeve të përsëritura, si ato të njësisë, integrimit dhe regresionit, duke u mundësuar zhvilluesve dhe testuesve të përqendrohen në detyra që ofrojnë më shumë vlerë.[93]

Automatizimi i testimit mbështet gjithashtu rifaktorimin e vazhdueshëm, i cili është thelbësor në zhvillimin e përsëritur të softuerit. Ai i mundëson zhvilluesit të ekzekutojë shpejt teste për të konfirmuar se rifaktorimi nuk ka ndikuar në funksionalitetin e aplikacionit, duke zvogëluar ngarkesën e punës dhe rritur besimin se procesi i pastrimit nuk ka sjellë defekte të reja.

Lejimi i rritjes së borxhit teknik

Redakto

Përqendrimi i tepërt në zhvillimin e funksionaliteteve të reja mund të çojë në akumulimin e borxhit teknik. Për të shmangur këtë, është e rëndësishme që ekipi të planifikojë kohë për të adresuar dhe rifaktoruar defektet ekzistuese. Borxhi teknik dëmton aftësinë për të planifikuar me saktësi, duke shtuar punën e paplanifikuar, pasi problemet në prodhim shpesh shpërqendrojnë ekipin dhe ngadalësojnë përparimin e mëtejshëm.[94]

Ndërsa sistemi zhvillohet, është e rëndësishme të rifaktohet .[95] Me kalimin e kohës, mungesa e mirëmbaajtjes së vazhdueshme rezulton në një rritje të numrit të defekteve dhe kostove të zhvillimit, duke ndikuar negativisht në efikasitetin dhe cilësinë e përgjithshme të produktit.[96]

Përpjekja për të marrë shumë në një përsëritje

Redakto

Një keqkuptim i zakonshëm është se zhvillimi i softuerit të shkathët lejon ndryshime të vazhdueshme pa kufizime. Megjithatë, backlog-u i përsëritjes përfaqëson një marrëveshje të qartë për punën që duhet të përfundohet brenda një përsëritjeje, duke ofruar një strukturë dhe fokus për ekipin gjatë asaj periudhe.[97] Posedimi i shumë punëve të papërfunduara (WIP) rezulton në paefikasitet siç janë kalimet e kontekstit dhe formimi i grumbujve.[98] Ekipi duhet të shmangë ndjenjën e presionit për të marrë punë shtesë.[99]

Koha, burimet, shtrirja dhe cilësia e fiksuar

Redakto

Zhvillimi i softuerit të shkathët rregullon paraprakisht kohëzgjatjen e përsëritjes, cilësinë dhe zakonisht burimet, edhe pse ruajtja e burimeve fikse mund të jetë sfiduese kur zhvilluesit ndërpriten shpesh për të trajtuar incidente të prodhimit. Ndërkohë, qëllimi mbetet fleksibël dhe i ndryshueshëm. Klienti ose pronari i produktit shpesh kërkon një afat të fiksuar për një përsëritje. Megjithatë, ekipet duhet të shmangin angazhimin për një kohë, burime dhe shtrirje të mbyllur njëkohësisht (të njohur si trekëndëshi i menaxhimit të projektit). Përpjekjet për të zgjeruar shtrirjen pa rritur burimet ose kohën në mënyrë proporcionale mund të çojnë në ulje të cilësisë.[100]

Djegia e zhvilluesve

Redakto

Për shkak të ritmit të shpejtë dhe natyrës së vazhdueshme të praktikave të shkathëta, ekziston një rrezik i shtuar i lodhjes dhe djegies (burnout) midis anëtarëve të ekipit të zhvillimit. Presioni për të përmbushur afatet dhe për t’u përshtatur vazhdimisht me ndryshimet mund të ndikojë negativisht në mirëqenien dhe performancën e ekipit.[101]

Menaxhimi i shkathët

Redakto

Menaxhimi i shkathët i projektit është një proces i përsëritur zhvillimi, ku reagimet mblidhen vazhdimisht nga përdoruesit dhe palët e interesuara për të krijuar përvojën e duhur të përdoruesit. Metoda të ndryshme mund të përdoren për të kryer një proces të shkathët, këto përfshijnë scrum, programim ekstrem, lean dhe kanban .[102] Termi "menaxhim i shkathët" zbatohet për një metodë përsëritëse, e cila përqendrohet në menaxhimin e projektimit dhe ndërtimit të aktiviteteve të inxhinierisë, teknologjisë së informacionit, dhe fushave të tjera të biznesit. Ky qasje synon ofrimin e zhvillimit të produkteve ose shërbimeve të reja në mënyrë fleksibile dhe ndërvepruese, duke u bazuar në parimet e shprehura në Manifestin për Zhvillimin e Softuerit të Shkathët. Ajo thekson vlerësimin e reagimeve të vazhdueshme, bashkëpunimin e ngushtë të ekipit, dhe përshtatjen e shpejtë ndaj ndryshimeve për të krijuar produkte që plotësojnë nevojat e përdoruesve.[103]

Metrikat e shkathëta të menaxhimit ndihmojnë në reduktimin e konfuzionit, identifikimin e pikave të dobëta dhe matjen e performancës. Shkathtësia e zinxhirit të furnizimit lejon përshtatje të shpejtë me variacionet e ofertës dhe kërkesës. Shkathtësia strategjike është aftësia për të ndryshuar drejtimin ndërsa mjedisi evoluon, duke identifikuar dhe alokuar burimet për t'u adaptuar me ndryshimet e jashtme.[104]

Teknikat Agile X mund të quhen gjithashtu menaxhimi ekstrem i projektit . Është një variant i ciklit jetësor iterativ [105] ku dorëzimet dorëzohen në faza. Dallimi kryesor midis zhvillimit të shkathët dhe atij iterativ është se metodat e shkathëta plotësojnë pjesë të vogla të dorëzuesve në çdo cikël shpërndarjeje (përsëritje),[106] ndërsa metodat përsëritëse evoluojnë të gjithë grupin e dërgesave me kalimin e kohës, duke i përfunduar ato afër fundit të projektit.Si metodat përsëritëse, ashtu edhe ato të shkathëta, u zhvilluan si përgjigje ndaj sfidave që u shfaqën gjatë zhvillimit të modeleve të organizimit të projekteve më lineare. Për shembull, ndërsa projektet teknologjike bëhen gjithnjë e më komplekse, përdoruesit përfundimtarë shpesh hasin vështirësi në përcaktimin e kërkesave afatgjata pa pasur mundësinë të shohin prototipe që zhvillohen gradualisht. Projektet që zhvillohen në cikle të përsëritura mund të mbledhin vazhdimisht reagime, duke ndihmuar në përmirësimin dhe përsosjen e këtyre kërkesave.

Menaxhimi i shkathët ofron gjithashtu një kornizë të thjeshtë që promovon këmbimi i mendimeve mbi përparimin e kaluar midis anëtarëve të ekipit .[107]Ekipet që përdornin metodën tradicionale të planifikimit të ujëvarës dhe kaluan në mënyrën e shkathët të zhvillimit shpesh kalojnë një fazë transformimi dhe zakonisht kërkojnë mbështetje nga trajnerë të shkathët, të cilët i ndihmojnë në udhëheqjen e ekipit drejt një kalimi më të lehtë. Zakonisht ekzistojnë dy stile trajnimi të shkathët: trajnimi i bazuar në shtytje dhe i bazuar në tërheqje. Në këtë kuadër, një "sistem shtytjeje" mund të nënkuptojë një vlerësim paraprak të detyrave që mund të përshtaten në një sprint (punë shtytjeje), si në metodën tradicionale të Scrum, ndërsa një "sistem tërheqës" mund të nënkuptojë një mjedis ku detyrat kryhen vetëm kur kapaciteti është i disponueshëm .[108] Qasjet e menaxhimit të shkathët janë përdorur gjithashtu dhe janë adoptimi në sektorët e biznesit dhe administratën shtetërore. Për shembull, brenda qeverisë federale të Shteteve të Bashkuara, Agjencia e Shteteve të Bashkuara për Zhvillim Ndërkombëtar (USAID) po përdor një qasje bashkëpunuese të menaxhimit të projektit që fokusohet në përfshirjen e strategjive të bashkëpunimit, të mësuarit dhe përshtatjes (CLA) për të përsëritur dhe përshtatur programimin.

Metodat e shkathëta përfshihen në Udhëzuesin për Trupin e Njohurive të Menaxhimit të Projektit ( PMBOK Guide Edition 6 ) nën përkufizimin e ciklit jetësor të zhvillimit të produktit :

Brenda ciklit të jetës së një projekti, zakonisht ka një ose më shumë faza që lidhen me zhvillimin e produktit, shërbimit, ose rezultatit. Këto quhen cikle zhvillimi (...) Ciklet adaptuese janë të tilla që përshtaten, janë të përsëritshme ose të incremental. Fusha e hollësishme caktohet dhe miratohet para fillimit të një iteracioni. Ciklet adaptuese quhen gjithashtu cikle agile ose cikle të drejtuara nga ndryshimi.

 
Konferenca Agile Brazil 2014

Sipas Jean-Loup Richet (bashkëpunëtor kërkimor në Institutin për Inovacionin dhe Shërbimet Strategjike ESSEC ) "kjo mënyrë veprimi mund të aplikohet në mënyrë efektive për produktet jo-softuerike dhe për menaxhimin e projekteve në përgjithësi, veçanërisht në fushat e inovacionit dhe pasigurisë".Rezultati është një produkt ose projekt që i përgjigjet më mirë nevojave të aktuale të klientëve, duke u ofruar atyre me kosto më të ulëta, humbje më të vogla dhe më pak kohë, duke mundësuar kështu që kompanitë të arrijnë fitime më shpejt se me qasjet tradicionale .

Teknikat e krijimit të softuerit të shkathët janë zbatuar gjerësisht për zhvillimin e produkteve softuerike dhe disa prej tyre përdorin veçori të caktuara të softuerit, siç janë teknologjitë e objekteve .[109] Megjithatë, këto teknika mund të përdoren gjithashtu në krijimin e produkteve jo-softuerike, si kompjuterët, pajisjet mjekësore, ushqimi, veshmbathja dhe muzika.[110] Disa nga parimet më të gjera të zhvillimit të softuerit të shkathët kanë gjetur aplikim edhe në menaxhimin e përgjithshëm[111] (p.sh., strategjia, qeverisja, rreziku, financa) nën termat shkathtësia e biznesit ose menaxhim i shkathët i biznesit.Metodologjitë e zhvillimit të softuerit të shkathët janë miratuar gjithashtu për t'u përdorur në procesin e inxhinierisë mësimore, një proces i përsëritur dhe i mbështetur në të dhëna që përdor shkencat e të mësuarit, dizajnin e fokusuar te njeriu dhe vendimmarrjen e bazuar në të dhëna për të udhëhequr nxënësit dhe zhvillimin e aftësive të tyre.[112]

Paradigmat e krijimit të softuerit të shkathët mund të aplikohen në fusha të tjera të jetës si rritja e fëmijëve.Suksesi i tij në zhvillimin e fëmijëve mund të mbështetet në disa parime kyçe të menaxhimit: komunikimi, fleksibiliteti dhe ndërgjegjësimi. Në një fjalim TED, Bruce Feiler shpjegoi se si ai i aplikoi parimet thelbësore të shkathësisë për menaxhimin e familjes dhe rritjen e fëmijëve.[113]

Kritika

Redakto

Metodat e shkathëta janë cituar si potencialisht jo të suksesshme në organizata të mëdha dhe lloje të caktuara zhvillimi.[114] Shumë organizata besojnë se metodologjitë e zhvillimit të softuerit të shkathët janë shumë ekstreme dhe miratojnë një qasje hibride[115] që përzien elementet e zhvillimit të softuerit të shkathët dhe qasjet e drejtuara nga plani.[116] Disa metoda, si Metoda Dinamike e Zhvillimit të Sistemeve (DSDM), përpiqen ta arrijnë këtë në një mënyrë të disiplinuar, pa komprometuar parimet thelbësore.

Adoptimi në rritje i praktikave të shkathëta është vlerësuar negativisht gjithashtu si një modë menaxhimi që thjesht përshkruan praktikat e mira ekzistuese nën terminologjinë e re, promovon një mendim të vetëm për strategjitë e zhvillimit dhe thekson gabimisht metodën mbi rezultatet.[117]

Alistair Cockburn drejtoi një festë të 10-vjetorit të Manifestit për Zhvillimin e Softuerit të shkathët në Snowbird, Jutah më 12 shkurt 2011, duke grumbulluar rreth 30 persona që ishin përfshirë në takimin fillestar dhe që atëherë. U krijua një listë prej rreth 20 "elefantësh në dhomë" (temat/çështjet e padiskutueshme të shkathësisë), duke përfshirë aspekte si aleancat, dështimet dhe kufizimet e praktikave dhe kontekstit të zhvillimit të softuerit të shkathët. Shkaqet e mundshme për këto probleme përfshijnë interesat komerciale, dekontekstualizimin, mungesën e një mënyre të qartë për të arritur përparim pas dështimeve, dëshmitë e kufizuara objektive, paragjykimet njohëse dhe gabimet e arsyetimit, si dhe ndikimet e politikës dhe kulturës.[118] Siç shkroi Philippe Kruchten :

Lëvizja Agile, në disa aspekte, është si një adoleshent: shumë i vetëdijshëm për veten, duke kontrolluar vazhdimisht pamjen e tij në pasqyrë, duke pranuar pak kritika, duke qenë vetëm i interesuar për shoqërinë me të njëjtët të rinj, duke refuzuar totalisht çdo mençuri të së kaluarës vetëm sepse vjen nga e kaluara, duke adoptuar trende dhe terminologji të reja, shpesh herë kokëfortë dhe arrogant. Por nuk kam dyshime se do të rritet më tej, do të bëhet më i hapur ndaj botës së jashtme, më reflektues dhe, për pasojë, më efektiv.

--Philippe Kruchten[119]

"Manifesti" mund të ketë pasur një pasoj negativ në menaxhimin dhe drejtimin e arsimit të lartë,ku u rekomandua administratorëve që proceset tradicionale më të ngadalta dhe debatuese të zëvendësohen me ato më "të shkathëta". Koncepti rrallë gjente pranim në fakultetin e universitetit.

Një tjetër kritikë është se në shumë mënyra, menaxhimi i shkathët dhe praktikat tradicionale të menaxhimit përfundojnë në kundërshtim me njëra-tjetrën. Një kritikë e zakonshme ndaj kësaj praktike është se koha e shpenzuar për të mësuar dhe implementuar metodat e reja është shumë e kushtueshme, pavarësisht përfitimeve të mundshme. Kalimi nga menaxhimi tradicional në menaxhimin agil kërkon angazhim të plotë ndaj shkathtësisë dhe një përkushtim të palëkundur nga të gjithë anëtarët e organizatës për të realizuar procesin. Çështje si rezultatet e pabarabarta në nivel organizativ, ndryshime të shumta që ndikojnë aftësinë e punonjësve për t'u adaptuar, ose mungesa e sigurisë përfundimtare pas transformimit janë disa nga shqetësimet kryesore. [120]

Shihni gjithashtu

Redakto
  • Automatizimi i shkathët
  • Ekip ndërfunksional
  • Scrum (zhvillimi i softuerit)
  • Dështoni shpejt (biznes), një lëndë e lidhur në menaxhimin e biznesit
  • Kanban
  • Udhëheqje e shkathët
  • Kontratat e shkathëta
  • Procesi racional i unifikuar

Referime

Redakto

[[Kategoria:Faqe me përkthime të pashqyrtuara]]

  1. ^ "What is Agile?". Agile Alliance (në anglisht). Marrë më 16 korrik 2024.
  2. ^ a b Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber (2001). "Manifesto for Agile Software Development" (në anglisht). Agile Alliance. Marrë më 14 qershor 2010.
  3. ^ a b Larman, Craig (2004). Agile and Iterative Development: A Manager's Guide (në anglisht). Addison-Wesley. fq. 27. ISBN 978-0-13-111155-4.
  4. ^ Rally (2010). "Agile With a Capital "A" Vs. agile With a Lowercase "a"" (në anglisht). Arkivuar nga origjinali më 5 janar 2016. Marrë më 9 shtator 2015.{{cite web}}: Mirëmbajtja CS1: Adresë e papërshtatshme (lidhja)
  5. ^ Collier 2011.
  6. ^ "What is Agile Software Development?" (në anglisht). Agile Alliance. 8 qershor 2013. Marrë më 4 prill 2015.
  7. ^ Dybå, Tore; Dingsøyr, Torgeir (1 gusht 2008). "Empirical studies of agile software development: A systematic review". Information and Software Technology (në anglisht). 50 (9–10): 833–859. doi:10.1016/j.infsof.2008.01.006. ISSN 0950-5849 – nëpërmjet shqip.
  8. ^ Lee, Gwanhoo; Xia, Weidong (2010). "Toward Agile: An Integrated Analysis of Quantitative and Qualitative Field Data on Software Development Agility". MIS Quarterly (në anglisht). 34 (1): 87–114. doi:10.2307/20721416. JSTOR 20721416.
  9. ^ Kroll, J.; Richardson, I.; Prikladnicki, R.; Audy, J. L. (2018). "Empirical evidence in follow the Sun software development: A systematic mapping study". Information and Software Technology (në anglisht). 93: 30–44. doi:10.1016/j.infsof.2017.08.011. {{cite journal}}: |hdl-access= ka nevojë për |hdl= (Ndihmë!)
  10. ^ "Evolutionary Project Management (Original page, external archive)" (në anglisht). Gilb. Arkivuar nga origjinali më 27 mars 2016. Marrë më 2017-04-30.
  11. ^ "Evolutionary Project Management (New page)" (në anglisht). Gilb. Arkivuar nga origjinali më 7 shkurt 2018. Marrë më 2017-04-30.
  12. ^ Edmonds, E. A. (1974). "A Process for the Development of Software for Nontechnical Users as an Adaptive System". General Systems (në anglisht). 19: 215–18.
  13. ^ Gilb, Tom (1981-04-01). "Evolutionary development". ACM SIGSOFT Software Engineering Notes (në anglisht). 6 (2): 17. doi:10.1145/1010865.1010868.
  14. ^ Swamidass, P. M., red. (2000), "Heavyweight project organizationHEAVYWEIGHT PROJECT ORGANIZATION", Encyclopedia of Production and Manufacturing Management (në anglisht), Boston, MA: Springer US, fq. 261–262, doi:10.1007/1-4020-0612-8_400, ISBN 978-1-4020-0612-8, marrë më 2022-06-22
  15. ^ Martin, James (1991). Rapid Application Development (në anglisht). Macmillan. ISBN 978-0-02-376775-3.
  16. ^ Kerr, James M.; Hunter, Richard (1993). Inside RAD: How to Build a Fully Functional System in 90 Days or Less (në anglisht). McGraw-Hill. fq. 3. ISBN 978-0-07-034223-1.
  17. ^ Sanchez, Luis (nëntor 2010). "A Review of Agile Manufacturing Systems". International Journal of Production Research (në anglisht) (39(16):3561-3600).
  18. ^ Anderson, David (2005). "Declaration of Interdependence" (në anglisht). Arkivuar nga origjinali më 27 janar 2018. Marrë më 4 tetor 2018.
  19. ^ McDonald, Kent (1 nëntor 2016). "How You Can Help Agile Alliance Help You". Agile Alliance Blog (në anglisht). Marrë më 4 korrik 2017.
  20. ^ "Examining the Agile Manifesto" (në anglisht). Ambysoft Inc. Marrë më 6 prill 2011.
  21. ^ Jim Highsmith (2001). "History: The Agile Manifesto". agilemanifesto.org.
  22. ^ a b Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber (2001). "Principles behind the Agile Manifesto" (në anglisht). Agile Alliance. Arkivuar nga origjinali më 14 qershor 2010. Marrë më 6 qershor 2010.{{cite web}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  23. ^ a b c Project Management Institute 2021.
  24. ^ Rubin 2013.
  25. ^ Moran, A. (2014). Agile Risk Management (në anglisht). Springer Verlag. ISBN 978-3319050072.
  26. ^ Beck, Kent (1999). "Embracing Change with Extreme Programming". Computer (në anglisht). 32 (10): 70–77. doi:10.1109/2.796139.
  27. ^ Mergel, Ines (korrik 2016). "Agile innovation management in government: A research agenda". Government Information Quarterly (në anglisht). 33 (3): 516–523. doi:10.1016/j.giq.2016.07.004.
  28. ^ Preuss, Deborah Hartmann (13 tetor 2006). "Study: Co-Located Teams vs. the Cubicle Farm". InfoQ (në anglisht). Marrë më 2018-10-23.
  29. ^ Cockburn, Alistair (2007). "Agile Software Development: The Cooperative Game". www.pearson.com (në anglisht) (bot. 2nd). Addison-Wesley Professional. Marrë më 2018-10-23.
  30. ^ "Management Transformed | Research" (në anglisht).
  31. ^ Jain, Parita; Sharma, Arun; Ahuja, Laxmi (gusht 2018). "The Impact of Agile Software Development Process on the Quality of Software Product". 2018 7th International Conference on Reliability, Infocom Technologies and Optimization (Trends and Future Directions) (ICRITO) (në anglisht). Noida, India: IEEE. fq. 812–815. doi:10.1109/ICRITO.2018.8748529. ISBN 978-1-5386-4692-2.
  32. ^ Ambler, Scott (12 prill 2002). Agile Modeling: Effective Practices for EXtreme Programming and the Unified Process (në anglisht). John Wiley & Sons. fq. 12, 164, 363. ISBN 978-0-471-20282-0.
  33. ^ Vasiliauskas, Vidas (2014). "Developing agile project task and team management practices" (në anglisht). Eylean. Arkivuar nga origjinali më 15 shtator 2014. Marrë më 15 shtator 2014.{{cite web}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  34. ^ Jeffries, Ron; Anderson, Ann; Hendrickson, Chet (2001). Extreme Programming installed (në anglisht). Addison-Weslsy. fq. 72–147. ISBN 978-0201-70842-4.
  35. ^ Lisa Crispin; Janet Gregory (2009). Agile Testing: A Practical Guide for Testers and Agile Teams (në anglisht). Addison-Wesley.
  36. ^ Mitchell, Ian (2016). Agile Development in Practice (në anglisht). Tamare House. fq. 11. ISBN 978-1-908552-49-5.
  37. ^ Larman, Craig (2004). Agile and Iterative Development: A Manager's Guide (në anglisht). Addison-Wesley. fq. 27. ISBN 978-0-13-111155-4.
  38. ^ Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed (në anglisht). Boston, MA: Addison-Wesley. ISBN 978-0-321-18612-6.Appendix A, pages 165–194
  39. ^ Larman, Craig (2004). "Chapter 11: Practice Tips". Agile and Iterative Development: A Manager's Guide (në anglisht). Addison-Wesley Professional. fq. 253. ISBN 9780131111554. Marrë më 14 tetor 2013.
  40. ^ Sliger, Michele; Broderick, Stacia (2008). The Software Project Manager's Bridge to Agility (në anglisht). Addison-Wesley. fq. 46. ISBN 978-0-321-50275-9.
  41. ^ a b Boehm, B.; R. Turner (2004). Balancing Agility and Discipline: A Guide for the Perplexed (në anglisht). Boston, MA: Addison-Wesley. fq. 55–57. ISBN 978-0-321-18612-6.
  42. ^ Rakitin, Steven R. (2001). "Manifesto Elicits Cynicism: Reader's letter to the editor by Steven R. Rakitin". IEEE Computer (në anglisht). 34: 4. doi:10.1109/MC.2001.10095. The article titled 'Agile Software Development: The Business of Innovation' ... is yet another attempt to undermine the discipline of software engineering ... We want to spend all our time coding. Remember, real programmers don't write documentation.
  43. ^ a b Scott Ambler (16 prill 2023). "Agile/Lean Documentation: Strategies for Agile Software Development" (në anglisht).
  44. ^ Scott Ambler. "Just Barely Good Enough Models and Documents: An Agile Best Practice" (në anglisht). Arkivuar nga origjinali më 8 tetor 2014. Marrë më 24 janar 2014.
  45. ^ Geoffrey Wiseman (18 July 2007). "Do Agile Methods Require Documentation?". InfoQ. Quoting Cooper, Ian (6 July 2007). "Staccato Signals: Agile and Documentation". WordPress.com.
  46. ^ "Guide to Agile Practices" (në anglisht). the Agile Alliance. Arkivuar nga origjinali më 9 shkurt 2014.
  47. ^ Pugh, Ken (2011). Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration. Addison-Wesley. ISBN 978-0321714084.
  48. ^ Adzic, Gojko (2009). Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing. Neuri Limited. Adzic, Gojko (2011). Specification by Example: How Successful Teams Deliver the Right Software. Manning. ISBN 978-0-321-27865-4.
  49. ^ Chelimsky, David; Dave Astels; Zach Dennis; Aslak Hellesøy; Bryan Helmkamp; Dan North. The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends. The Pragmatic Bookshelf.
  50. ^ "Example Driven Design". Retrieved 15 April 2013.
  51. ^ "Story Test-Driven Development" (PDF). Retrieved 15 April.
  52. ^ "Agile Modeling (AM) Home Page: Effective Practices for Modeling and Documentation".
  53. ^ Atlassian. "The product backlog: your ultimate to-do list". Atlassian. Retrieved 19 December 2021.
  54. ^ "What is a Product Backlog?" Scrum.org. Retrieved 19 December 2021.
  55. ^ a b "Agile Core Practice: Prioritized Requirements". agilemodeling.com. Retrieved 19 December 2021.
  56. ^ "Agile Core Practice: Prioritized Requirements". agilemodeling.com. Retrieved 19 December 2021. "Artifact: Work Items List". www.utm.mx. Retrieved 19 December 2021.
  57. ^ What is a Cross-functional Team? Definition and meaning. Use of XFN as abbreviation. A leadership blog named XFN.
  58. ^ Krajewski, L. J., & Ritzman, L. P. (2005). Operations Management: Processes and Value Chains. Pearson Education. Upper Saddle River.
  59. ^ Morris, David (2015). The Paradox of Agile Transformation: Why trying too hard to be Agile stops organisations from becoming truly agile (në anglisht). NZ: University of Auckland. doi:10.13140/RG.2.2.32698.08640.
  60. ^ Mirakhorli, M.; Rad, A.K.; Shams, F.; Pazoki, M.; Mirakhorli, A. (2008). "RDP technique: a practice to customize xp". Proceedings of the 2008 international workshop on Scrutinizing agile practices or shoot-out at the agile corral (APOS '08) (në anglisht). ACM. fq. 23–32. doi:10.1145/1370143.1370149. ISBN 978-1-60558-021-0.
  61. ^ Beck, K. (1999). Extreme Programming Explained: Embrace Change (në anglisht). Boston, MA: Addison-Wesley. ISBN 978-0-321-27865-4.
  62. ^ Evans, Ian. "Agile Delivery at British Telecom" (në anglisht). Marrë më 21 shkurt 2011.
  63. ^ "Bridging the Distance" (në anglisht). Sdmagazine.com. Marrë më 1 shkurt 2011.
  64. ^ Fowler, Martin. "Using an Agile Software Process with Offshore Development" (në anglisht). Martinfowler.com. Marrë më 6 qershor 2010.
  65. ^ Cawley, Oisín; Wang, Xiaofeng; Richardson, Ita (2010). "Lean/Agile Software Development Methodologies in Regulated Environments – State of the Art". përmbledhur nga Abrahamsson, Pekka; Oza, Nilay (red.). Lean Enterprise Software and Systems. Lecture Notes in Business Information Processing (në anglisht). Vëll. 65. fq. 31–36. doi:10.1007/978-3-642-16416-3_4. hdl:10344/683. ISBN 978-3-642-16415-6.
  66. ^ McHugh, Martin; McCaffery, Fergal; Coady, Garret (2014-11-04). "An Agile Implementation within a Medical Device Software Organisation". përmbledhur nga Mitasiunas, Antanas; Rout, Terry; O'Connor, Rory V.; etj. (red.). Software Process Improvement and Capability Determination. Communications in Computer and Information Science (në anglisht). Vëll. 477. fq. 190–201. doi:10.1007/978-3-319-13036-1_17. ISBN 978-3-319-13035-4.
  67. ^ Wang, Yang; Ramadani, Jasmin; Wagner, Stefan (2017-11-29). "An Exploratory Study on Applying a Scrum Development Process for Safety-Critical Systems". Product-Focused Software Process Improvement. Lecture Notes in Computer Science (në anglisht). Vëll. 10611. fq. 324–340. Bibcode:2017arXiv170305375W. doi:10.1007/978-3-319-69926-4_23. ISBN 9783319699257.
  68. ^ "SafeScrum - SINTEF" (në anglisht). Sintef.no. Marrë më 2019-03-26.
  69. ^ Fitzgerald, B.; Stol, K.-J.; O'Sullivan, R.; O'Brien, D. (maj 2013). "Scaling agile methods to regulated environments: An industry case study". 2013 35th International Conference on Software Engineering (ICSE) (në anglisht). fq. 863–872. doi:10.1109/ICSE.2013.6606635. hdl:10344/3055. ISBN 978-1-4673-3076-3.
  70. ^ Beck, Kent (2000). Extreme Programming Explained (në anglisht). Addison-Wesley. fq. 1–24. ISBN 978-0201616415.
  71. ^ Peter Lappo; Henry C.T. Andrew. "Assessing Agility" (PDF) (në anglisht). Arkivuar nga origjinali (PDF) më 15 shtator 2009. Marrë më 6 qershor 2010.
  72. ^ Joe Little (2 dhjetor 2007). "Nokia test, A scrum-specific test" (në anglisht). Agileconsortium.blogspot.com. Marrë më 6 qershor 2010.
  73. ^ Mark Seuffert; Mayberg, Sweden. "Karlskrona test, A generic agile adoption test" (në anglisht). Mayberg.se. Marrë më 5 prill 2014.
  74. ^ "How Agile Are You? (Take This 42 Point Test)" (në anglisht). allaboutagile.com/. Arkivuar nga origjinali më 5 maj 2014. Marrë më 3 prill 2014.
  75. ^ "Agile Methodologies Survey Results" (PDF) (në anglisht). Shine Technologies. janar 2003. Arkivuar nga origjinali (PDF) më 21 gusht 2010. Marrë më 3 qershor 2010. 95% stated that there was either no effect or a cost reduction ... 93% stated that productivity was better or significantly better ... 88% stated that quality was better or significantly better ... 83% stated that business satisfaction was better or significantly better
  76. ^ "2013 State of Agile report: Why Agile?" (në anglisht). stateofagile.com. 27 janar 2014. Arkivuar nga origjinali më 28 gusht 2014. Marrë më 13 gusht 2014.{{cite web}}: Mirëmbajtja CS1: Datë e përkthyer automatikisht (lidhja)
  77. ^ Ambler, Scott (3 gusht 2006). "Survey Says: Agile Works in Practice". Dr. Dobb's (në anglisht). Marrë më 3 qershor 2010. Only 6% indicated that their productivity was lowered ... No change in productivity was reported by 34% of respondents and 60% reported increased productivity ... 66% [responded] that the quality is higher ... 58% of organizations report improved satisfaction, whereas only 3% report reduced satisfaction.
  78. ^ "Answering the "Where is the Proof That Agile Methods Work" Question" (në anglisht). Agilemodeling.com. 19 janar 2007. Marrë më 2 prill 2010.
  79. ^ Shore & Warden 2008
  80. ^ Beck, Kent (2000). Extreme Programming Explained (në anglisht). Addison-Wesley. fq. 48–49. ISBN 978-0201616415.
  81. ^ Rouse, Margaret. "Sprint (software development) definition". searchsoftwarequality.tech_target.com (në anglisht). Marrë më 2 tetor 2015.
  82. ^ Goldstein, Ilan (11 tetor 2011). "Sprint issues – when sprints turn into crawls". www.axisagile.com.au (në anglisht). Marrë më 2014-06-08.
  83. ^ "Project Roles and Responsibility Distribution". agile-only.com (në anglisht). Marrë më 2014-06-15.
  84. ^ Bourne, Lynda. "What Does a Project Sponsor Really Do?". blogs.pmi.org (në anglisht). Arkivuar nga origjinali më 7 qershor 2014. Marrë më 2014-06-08.
  85. ^ "9th State of Agile Report". Stage of Agile Survey (në anglisht). VersionOne. Arkivuar nga origjinali më 12 janar 2015. Marrë më 2014-06-08.
  86. ^ Sims, Chris; Johnson, Hillary Louise (2011-02-15). The Elements of Scrum (në anglisht) (bot. Kindle). Dymaxicon. fq. 73.
  87. ^ Rothman, Johanna Rothman (25 gusht 2011). "When You Have No Product Owner at All". www.jrothman.com (në anglisht). Marrë më 2014-06-08.
  88. ^ Fox, Alyssa (8 prill 2014). "Working on Multiple Agile Teams". techwhirl.com/ (në anglisht). Marrë më 2014-06-14.
  89. ^ "Daily Scrum Meeting". www.mountaingoatsoftware.com (në anglisht). Marrë më 2014-06-14.
  90. ^ a b May, Robert. "Effective Sprint Planning". www.agileexecutives.org (në anglisht). Arkivuar nga origjinali më 28 qershor 2014. Marrë më 2014-06-14.
  91. ^ Berczuk, Steve. "Mission Possible: ScrumMaster and Technical Contributor". www.agileconnection.com (në anglisht). Marrë më 2014-06-14.
  92. ^ "How to Implement Agile Scrum" (në anglisht). Marrë më 2022-01-04.
  93. ^ Namta, Rajneesh. "Thoughts on Test Automation in Agile". www.infoq.com (në anglisht). Marrë më 2014-06-14.
  94. ^ Band, Zvi (22 mars 2014). "Technical Debt + Red October" (në anglisht). Marrë më 8 qershor 2014.
  95. ^ Shore, James. "The Art of Agile Development: Refactoring". www.jamesshore.com (në anglisht). Marrë më 2014-06-14.
  96. ^ Band, Zvi (22 mars 2014). "Technical Debt + Red October" (në anglisht). Marrë më 8 qershor 2014.
  97. ^ "Step 4: Sprint Planning (Tasks)". www.allaboutagile.com (në anglisht). Arkivuar nga origjinali më 29 qershor 2014. Marrë më 2014-06-14.
  98. ^ George, Claire (3 mars 2014). "Why Limiting Your Work-in-Progress Matters". leankit.com (në anglisht). Marrë më 2014-06-14.
  99. ^ George, Claire (3 mars 2014). "Why Limiting Your Work-in-Progress Matters". leankit.com (në anglisht). Marrë më 2014-06-14.
  100. ^ McMillan, Keith (13 maj 2010). "Time, Resources, Scope... and Quality". www.adeptechllc.com (në anglisht). Marrë më 2014-06-15.
  101. ^ "Current study on limitations of Agile". Procedia Computer Science (në anglisht). 78: 291–297. janar 2016. doi:10.1016/j.procs.2016.02.056.
  102. ^ "The Procurement Call for Agile, What does it mean?" (në anglisht). 1 nëntor 2019.
  103. ^ Moran, Alan (2015). Managing Agile: Strategy, Implementation, Organisation and People (në anglisht). Springer. ISBN 978-3-319-16262-1.
  104. ^ "The Procurement Call for Agile, What does it mean?" (në anglisht). 1 nëntor 2019.
  105. ^ "Which Life Cycle Is Best for Your Project?". PMHut (në anglisht). 2008-10-22. Marrë më 2009-10-23.
  106. ^ "Agile Project Management". VersionOne (në anglisht). Marrë më 1 qershor 2015.
  107. ^ "What is Agile Management?" (në anglisht). Project Laneways. Marrë më 1 qershor 2015.
  108. ^ Benson, Jim; De Maria Barry, Tonianne (2011). Personal Kanban: mapping work, navigating life (në anglisht) (bot. 1st). Seattle, WA: Modus Cooperandi Press. fq. 38. ISBN 978-1-4538-0226-7.
  109. ^ Smith, Preston G (2007). Flexible Product Development (në anglisht). Jossey-Bass. fq. 25. ISBN 978-0-7879-9584-3.
  110. ^ Newton Lee (2014). "Getting on the Billboard Charts: Music Production as Agile Software Development," Digital Da Vinci: Computers in Music (në anglisht). Springer Science+Business Media. ISBN 978-1-4939-0535-5.
  111. ^ Moran, Alan (2015). Managing Agile: Strategy, Implementation, Organisation and People (në anglisht). Springer Verlag. ISBN 978-3-319-16262-1.
  112. ^ Barrett, M.; Goodell, J. (2022), "Lean-Agile Development Tools", Learning Engineering Toolkit, Routledge, fq. 269–278, doi:10.4324/9781003276579-16, ISBN 978-1-003-27657-9 {{citation}}: Mungon ose është bosh parametri |language= (Ndihmë!)
  113. ^ "Agile programming – for your family".
  114. ^ Larman, Craig; Bas Vodde (2009-08-13). Top Ten Organizational Impediments to Large-Scale Agile Adoption (në anglisht). InformIT.
  115. ^ "Introduction to Hybrid project management" (në anglisht). 20 korrik 2016.
  116. ^ Barlow, Jordan B.; Justin Scott Giboney; Mark Jeffery Keith; David W. Wilson; Ryan M. Schuetzler; Paul Benjamin Lowry; Anthony Vance (2011). "Overview and Guidance on Agile Development in Large Organizations". Communications of the Association for Information Systems (në anglisht). 29 (1): 25–44. doi:10.17705/1CAIS.02902.
  117. ^ Kupersmith, Kupe (4 korrik 2011). "Agile is a Fad" (në anglisht).
  118. ^ Kruchten, Philippe (2011-06-20). "Agile's Teenage Crisis?" (në anglisht). InfoQ.
  119. ^ Krajewski, L. J., & Ritzman, L. P. (2005). Operations Management: Processes and Value Chains. Pearson Education. Upper Saddle River.
  120. ^ Cohn, Mike (2015). Succeeding With Agile (në anglisht). Pearson. fq. 5–10. ISBN 978-0-321-57936-2.
Marrë nga "https://sq.wikipedia.org/w/index.php?title=Zhvillimi_i_shkathët_i_softuerit&oldid=2733591"
  NODES
admin 2
Association 1
chat 1
Idea 1
idea 1
innovation 2
INTERN 4
Note 3
Project 14
todo 14
USERS 1