lankstus kūrimas ( agile )

Lankstus Kūrimas (Agile)

1Chapter 3 Agile software development

Temos Lankstūs metodai Planu paremtas ir lankstus kūrimas Ekstremalus programavimas Lankstaus projekto valdymas Lankstaus metodo taikomumas


Greitas programų kūrimas Greitas programų sistemų kūrimas ir pateikimas yra labai

svarbus reikalavimas Verslo aplinka labai greitai keičiasi ir praktiškai neįmanoma turėti

stabilius reikalavimus Programas reikia labai greitai keisti, kad patenkinti verslo

poreikius.

Greitas programų kūrimas pasižymi: Specifikavimo, projektavimo ir įgyvendinimo sluoksniavimu Sistemos yra kuriamos kaip versijų eilė įtraukiant suinteresuotus

asmenis jų įvertinimui Vartotojo sąsajos yra kuriamos naudojant integruotą kūrimo

aplinką ir grafinių įrankių aibę


Lankstūs metodai Nepasitenkinimas programų kūrimo pridėtinėmis išlaidomis iššaukė lanksčių metodų sukūrimą. Šie metodai:

Labiau orientuojasi į programos kodą negu į projektavimą. Remiasi iteratyviniais programų kūrimo būdais Skirti greitai pateikti veikiančias programas ir jas tobulinti, kad išpildyti besikeičiančius reikalavimus

Lanksčių metodų tikslas yra sumažinti programinės įrangos kūrimo pridėtines išlaidas ( apribojant dokumentaciją) ir be didelių perdirbimų išpildyti pasikeitusius reikalavimus


Lanksčių metodų manifestas Mes atskleidžiame geresnius programinės įrangos

kūrimo būdus ją kurdami ir padėdami kitiems tą daryti. Per šį darbą išsikristalizavo svarbumai: Individai ir bendravimas yra svarbiau negu procesai ir įrankiai Veikianti programinė įranga yra svarbiau negu išsami

dokumentacija Bendravimas su užsakovu yra svarbiau negu derybos dėl

kontrakto Pakeitimų išpildymas yra svarbiau už jų planavimą

Chapter 3 Agile software development 5

Lanksčių metodų principai Principai AprašymasUžsakovo įtraukimas Užsakovai turi būti tampriai įtraukti į kūrimo procesą. Jie turėtų

pateikti ir nustatyti prioritetus naujų reikalavimų ir įvertinti sistemos iteracijas.

Laipsniškas pateikimas The software is developed in increments with the customer specifying the requirements to be included in each increment. Programinė įranga yra kuriama žingsniais, kai užsakovas apibrėžia reikalavimus kiekvienam žingsniui.

Žmonės ne procesas Kūrimo komandos sugebėjimai turi būti pripažinti ir išnaudoti. Reikia leisti komandos nariams dirbti savo būdu be priskirto proceso.

Keitimų numatymas Tikėtis, kad sistemos reikalavimai keisis ir projektuoti sistemą numatant keitimus

Išlaikyti paprastumą Koncentruotis į kūrimo proceso ir kuriamos programinės įrangos paprastumą. Visur kur tik galima stengtis eliminuoti sistemos sudėtingumą.


Lanksčių metodų taikomumas

Programinės įrangos kūrimo kompanijoms, kurios kuria mažos arba vidutinės apimties produktus padavimui.

Programinės įrangos kūrimas organizacijoms, kurios turi aiškų įsipareigojimą, kad užsakovai įsitrauks į kūrimo procesą ir kurios neturi daug išorinių reguliavimų, kurie gali įtakoti kuriamą programinę įrangą.

Kadangi orientuojamasi į mažas tampriai susijusias kūrimo komandas, gali būti problemų naudojant lanksčius metodus didelių sistemų kūrimui


Lanksčių metodų problemos Gali būti sunku išlaikyti užsakovo suinteresuotumą dalyvauti programinės įrangos kūrimo procese Komandos nariai gali būti nepasiruošę intensyviam dalyvavimui, kuo pasižymi lankstūs metodai Gali būti sunku nustatyti keitimo prioritetus, kai yra daug suinteresuotų asmenų Paprastumo palaikymas reikalauja papildomo darbo Kontrakto sudarymas yra problematiškas kaip ir su kitais iteratyvaus kūrimo metodais


Lankstūs metodai ir programinės įrangos priežiūra

Dauguma organizacijų išleidžia daugiau lėšų turimų programinių sistemų priežiūrai negu naujos programinės įrangos kūrimui. Kad lankstūs metodai būtų naudingi jie turi remti programų priežiūrą kaip ir kiti metodai.

Du esminiai klausimai: Ar sistemos sukurtos naudojant lanksčius metodus yra

prižiūrimos, turint omenyje, kad kūrimo metu buvo minimizuota formali dokumentacija?

Ar gali lankstūs metodai būti efektyviai naudojami kai reikia išpildyti užsakovo prašymus?

Problemų gali kilti, jei originali kūrimo komanda negali būti išsaugota.


Paremtas planu ir lankstus kūrimas

Paremtas planu kūrimas Planu paremtas inžinerijos būdas remiasi atskirais kūrimo

etapais, kurių pabaigoje gaunama šiame etape iš anksto planuota produkcija.

Nebūtinai planu paremtas kūrimas naudoja krioklio modelį, požingsninis kūrimas taip pat yra galimas.

Iteracijos vyksta veiklos viduje.

Lankstus kūrimas Specifikacija, projektavimas, įgyvendinimas ir testavimas yra

tarpusavyje susipynę ir apie kūrimo proceso rezultatus sprendžiama per derybų procesą programinės įrangos kūrimo proceso metu

10chpter 3 Agile software development

Planu paremtas ir lankstus specifikavimas


Techniniai, žmoniškieji ir organizaciniai aspektai

Dauguma projektų turi planu paremto ir lankstaus proceso elementus. Sprendimas dėl jų balanso priklauso nuo : Ar labai svarbu turėti detalią specifikaciją prieš įgyvendinimą?

Jeigu taip tai geriau naudoti planu paremto kūrimo būdą. Ar strategija pažingsninio pateikimo programinės įrangos

užsakovams ir jų greito grįžtamo ryšio yra reali? Jei taip tai geriau naudoti lankstų kūrimo būdą.

Kokio dydžio yra kuriama sistema? Lankstus metodas yra labiausiai efektyvus kai sistema gali būti sukurta su maža, toje pačioje vietoje neformaliai bendraujančia komanda. Tai neįmanoma kuriant dideles sistemas, kurioms sukurti reikia daug darbuotojų ir tokiu atveju planu paremtas metodas turėtų būti naudojamas.



Kokio tipo sistema yra kuriama? • Planu paremtas būdas gali būti naudojamas sistemoms, kurios

reikalauja daug analizės prieš įgyvendinimą (tai yra realaus laiko sistemos su sudėtingais laiko reikalavimais)

Koks turėtų būti sistemos gyvavimo ciklas? • Sistemos su ilgu gyvavimo ciklu reikalauja daugiau dokumentacijos

bendravimui dėl pradinių ketinimų tarp kūrėjų ir palaikymo komandos Kokiomis technologijomis galima naudotis kuriant sistemą?

• Lankstūs metodai remiasi gerais įrankiais skirtais sekti kaip plečiasi projektas

Kaip yra organizuota kūrimo komanda? • Jeigu kūrimo komanda yra paskirstyta arba dalis darbų atliekama

išorėje, tai matyt reikia projekto dokumentacijos bendravimui tarp kūrimo komandų.



Ar yra kultūriniai ir organizaciniai aspektai kurie įtakoja sistemos kūrimą?

• Tradiciškai inžinerinės organizacijos turi planu paremto kūrimo kultūrą ir tai yra normalu inžinerijoje.

Kaip geri yra projektuotojai ir programuotojai kūrimo komandoje?• Kartais argumentuojama, kad lankstūs metodai reikalauja

aukštesnių sugebėjimų negu planu paremti būdai, kuriuose programuotojai paprasčiausiai transliuoja detalų projektą į kodą.

Ar kuriama sistema yra išorinio reguliavimo objektu? • Jeigu sistema turi būti patvirtinta pagal išorinio reguliavimo taisykles,

tam reikia detalios dokumentacijos.


Ekstremalus programavimas Tai plačiausiai žinomas ir labiausiai paplitęs lankstus kūrimo metodas Ekstremalus programavimas (XP) naudoja forsuotą būdą iteratyviam kūrime.

Per dieną gali būti sukurtos kelios naujos versijos; Žingsniai pateikiami užsakovui kas dvi savaitės; Visi testai turi būti vykdomi kiekvienai versijai ir versija yra priimama jei visi testai atlikti sėkmingai.


XP ir lankstūs principai Pažingsninis kūrimas remiasi mažai pakeistomis ir dažnomis sistemos versijomis Užsakovo įtraukimas suprantamas kaip jų darbuotojo įtraukimas į komandą pilnu etatu. Žmonės nenaudoja porinio programavimo, kolektyvinė atsakomybė ir procesas, kad būtų išvengta ilgų darbo valandų Pakeitimai vykdomi per dažnas ir reguliarias sistemos versijas. Paprastumas palaikomas per nuolatinį kodo pertvarkymą.


Ekstremalaus programavimo versijos ciklas


Ekstremalaus programavimo praktika (a) Principai Aprašymas

Pažingsninis planavimas

Reikalavimai yra surašomi į pasakojimų korteles ir pasakojimai turi būti įtraukti į versijas nurodant galimą laiką ir santykinius prioritetus. Kūrėjai pasakojimus sudalina į kūrimo užduotis

Mažos versijos Minimalus naudingas rinkinys funkcijų, kurios suteikia verslo vertę turi būti sukurtas pirmas. Išleidžiamos sistemos dažnai ir palaipsniui prideda funkcionalumą prie pirmojo išleidimo.

Smulkūs projektai Atliekamas tik pakankamas projektavimas siekiant patenkinti dabartinius reikalavimus ir ne daugiau.

Pirmiausia testavimas Automatizuota vienetų testavimo sistema naudojama rašyti testus naujo funkcionalumo gabalo prieš šios funkcijos įgyvendinimą.

Perdarymas Visi kūrėjai turėtų perdaryti kodą nuolat ir kuo greičiau kai tik kodo patobulinimai rasti. Tai išsaugo kodą paprastą ir lengvai aptarnaujamą.


Ekstremalaus programavimo praktika (b)

Porinis programavimas Kūrėjai dirba poromis, tikrinant vienas kito darbą ir teikiant paramą visada gerai atlikti darbą.

Kolektyvinė atsakomybė

Kūrėjų poros dirba visose sistemos srityse, kad nebūtų jokių žinių salų ir visi kūrėjai prisiima atsakomybę už visą kodą. Kiekvienas gali bet ką pakeisti.

Nuolatinis integravimas Kaip tik užduoties darbas yra baigtas, jis yra integruojamas į visą sistemą. Po tokios integracijos, visi sistemos vienetų testavimai turi būti atlikti.

Tvarus tempas Dideli viršvalandžių nėra laikomi leistinais, nes galutinis poveikis yra sumažėjusi kodo kokybė ir našumas.

Užsakovas vietoje Galutinio naudotojo sistemos (užsakovo) atstovas turi būti prieinamas XP komandai visą laiką. Ekstremalaus programavimo procese, klientas yra vystymo grupės narys ir atsakingas už sistemos reikalavimų perdavimą komandai, kad juos įgyvendinti.


Reikalavimų scenarijai Ekstremaliam programavime klientas ar vartotojas yra dalis XP komandos ir yra atsakingas už sprendimus dėl reikalavimų. Vartotojo reikalavimai yra išreikšti kaip scenarijai arba naudotojo pasakojimai. . Tai yra užrašoma ant kortelių ir kūrėjų komanda sudalina juos į vykdymo užduotis. Šios užduotys yra grafiko ir išlaidų sąmatos pagrindas. Klientas pasirenka pasakojimus įtraukimui į kitą versiją remiantis jų prioritetais ir tvarkaraščio įvertinimu.


Pasakojimas apie vaistų paskyrimą


Pavyzdžiai užduočių kortelių vaistų paskyrimui


XP ir keitimai Tradiciniai yra išminga programinės įrangos inžinerijoje kurti programas numatant pokyčius. Tam verta skirti laiko ir pastangų, numatyti pokyčius, nes tai sumažina išlaidas vėliau gyvavimo cikle Tačiau XP teigia, kad tai nėra naudinga, kadangi pokyčiai negali būti patikimai numatyti. Greičiau, XP siūlo pastovų kodo gerinimą (pertvarkymą) siekiant padaryti pakeitimus lengvesnius, kai jie bus įgyvendinami.


Perdarymas (Refactoring) Programavimo komanda ieško galimų programinės

įrangos patobulinimų ir atlieka šiuos patobulinimus net kai nėra skubios būtinybės jiems.

Tai padidina programinės įrangos suprantamumą ir taip mažina būtinybę rengti dokumentus.

Pokyčius yra lengviau atlikti, nes kodas yra gerai struktūruotas ir aiškus.

Tačiau kai kurie pokyčiai reikalauja architektūros pertvarkymo ir tai yra daug brangiau.


Pertvarkymo pavyzdžiai Perorganizavimas klasių hierarchijos pašalinant

pasikartojantį kodą. Deramai sutvarkyti ir pervadinti atributus ir metodus, kad

juos būtų galima lengviau suprasti Vidinio kodo keitimas su kreipiniais į metodus, kurie

buvo įtraukti į programos biblioteką.


Esminiai aspektai Lankstūs metodai yra pažingsniniai kūrimo metodai, kurie orientuoti

į spartų kūrimą, dažnas programinės įrangos versijas, siekiant sumažinti proceso išlaidas ir gauti aukštos kokybės kodą. Jie tiesiogiai susįję su užsakovo įtraukimu į kūrimo procesą.

Sprendimas, ar naudoti lankstų ar planu paremtą požiūrį į kūrimą, turi priklausyti nuo kuriamos programinės įrangos tipo, kūrimo komandos galimybių ir įmonės kultūros plėtojant šią sistemą

Ekstremalus programavimas yra gerai žinomas lankstus metodas, kuris apjungia daug gerų programavimo praktikų, kaip dažnai išleidžiamus programinės įrangos versijos, programinės įrangos nuolatinis gerinimas ir klientų dalyvavimas kūrimo grupėje.


Lankstus programinės įrangos kūrimas

Dalis 2


Testavimas ekstremaliam programavime

Testavimas yra pagrindinis XP ir programa yra išbandoma po kiekvieno atlikto pakeitimo. XP testavimas pasižymi:

Pirmiausia testavimas. Pažingsninis testo kūrimas iš scenarijaus Vartotojų įtraukimas į testų sudarymą ir atestavimą Komponentų testai paleidžiami automatiškai, kiekvieną kartą, kai sukuriama nauja versija


Pirmiausia testavimas Rašymas testų prieš kodo įgyvendinimą. Testai rašomi kaip programos, o ne kaip duomenys, kad būtų galima juos įvykdyti automatiškai. Testai apima patikrinimą ar jie korektiškai įvykdyti

Paprastai remiamasi testavimo sistema, kaip antai Junit. Visi ankstesni ir nauji testai paleidžiami automatiškai, kai yra pridedama nauja funkcija, siekiant patikrinti, ar nauja funkcija neįnešė klaidų.


Užsakovo įtraukimas Užsakovo vaidmuo testavimo procese yra padėti

sudaryti priėmimo testus tų istorijų, kurios turi būti įgyvendintos sekančios versijos sistemoje.

Užsakovas, kuris yra dalis komandos rašo testus kūrimo eigoje. Tokiu būdu visas naujas kodas yra atestuojamas siekiant užtikrinti, kad tai yra ko užsakovui reikia

Tačiau žmonės atliekantys užsakovo vaidmenį turi ribotą laiką, ir ne visuomet gali dirbti visą darbo dieną su kūrėjų komanda. Jie gali jausti, kad teikimas reikalavimų buvo pakankamas įnašas ir todėl gali būti nelinkę įsitraukti į testavimo procesą


Testiniai atvejai vaistų dozės tikrinimui


Testavimo automatizavimas Testų automatizavimas reiškia, kad testai parašyti kaip

vykdomieji komponentai iki užduoties realizavimo Šie testų komponentai turi būti savarankiški, turi imituoti įvesties

pateikimą, turi išbandyti ir patikrinti ar rezultatas atitinka programos specifikaciją. Automatinio testavimo sistema (pvz., Junit) yra sistema, kuri leidžia lengvai rašyti vykdomus testus ir pateikti testų rinkinį vykdymui.

Kai testavimas yra automatizuotas, visada yra rinkinys testų, kuriuos galima greitai ir lengvai įvykdyti. Kai naujas funkcionalumas yra pridėtas prie sistemos, testai gali

būti vykdomi ir problemos dėl naujo kodo įvedimo gali būti sugautos iš karto


XP testavimo sunkumai

Programuotojai renkasi pirmenybę programavimo negu testavimo ir kartais jie trumpina rašomus testus. Pavyzdžiui, jie gali rašyti neišsamius testus, kurie nepatikrina visų galimų išimčių, kurios gali atsirasti.

Kai kuriuos testus gali būti labai sunku rašyti palaipsniui. Pavyzdžiui, sudėtinga vartotojo sąsaja, jai dažnai yra sunku rašyti vieneto testus kodui, kuris įgyvendina ‚rodyti logiką "ir darbo eigą tarp ekranų

Sunku spręsti apie testų išsamumą. Net ir turint daug testų negalima garantuoti, kad testų rinkinys suteikia visišką aprėptį.


Porinis programavimas XP programuotojai dirba poromis, sėdi kartu kurdami kodą. Tai padeda plėtoti bendrą atsakomybę už kodą ir platinti žinias visai komandai Tai tarnauja kaip neformalus peržiūros procesas, nes kiekviena kodo eilutė yra peržvelgta daugiau kaip 1 asmens. Tai skatina pertvarkymą ir gali būti naudinga visai komandai. Matavimai rodo, kad porinio programavimo kūrimo produktyvumas yra panašus į dviejų žmonių dirbančių nepriklausomai.


Porinis programavimas Poriniam programavime, programuotojai sėdi kartu prie

tos pačios darbo vietos kuriant programinę įrangą. Poros sudaromos dinamiškai, kad visi komandos nariai

bendradarbiautų vieni su kitais kūrimo procese. Dalijimasis žiniomis poriniam programavime yra labai

svarbus, nes tai sumažina bendrą projekto riziką, kai komandos nariai palieka.

Porinis programavimas nebūtinai neefektyvus ir yra įrodymų, kad darbas endrai yra efektyvesnis nei 2 programuotojai dirbtų atskirai


Porinio programavimo privalumai Tai remia idėją kolektyvinės nuosavybės ir atsakomybės

už sistemą Asmenys nėra atsakingi dėl problemų su kodu. Vietoj to,

komanda turi kolektyvinę atsakomybę dėl šių problemų.

Tai veikia kaip neformalus peržiūros procesas, nes kiekviena kodo eilutė yra peržvelgiama mažiausiai dviejų žmonių

Tai padeda remti pertvarkymus, kas yra programinės įrangos tobulinimo procesas. Kai naudojamas porinis programavimas ir kolektyvinė

nuosavybė naudojama, kiti programuotojai mato pertvarkymo naudą ir todėl jie yra linkę remti šį procesą.


Lankstaus projekto valdymas

Pagrindinė atsakomybė programinės įrangos projekto vadovo yra valdyti projektą, kad programinė įranga būtų pateikta laiku ir neviršijant numatyto projekto biudžeto.

Standartinis požiūris į projektų valdymą yra orientuotas į planavimą. Vadovai parengia projektui planą, kuriame parodyta, kas turėtų būti pristatyta, kada tai turi būti pateikta ir kas pateiks projekto rezultatus.

Lanksčių projektų valdymas reikalauja kitokio požiūrio, kuris yra pritaikytas pažingsniniam kūrimui ir kitiems lankstaus kūrimo metodo privalumams.


Scrum Scrum požiūris yra bendras lankstus metodas, tačiau jo

dėmesys skiriamas valdymui aktyviu bendradarbiavimu, o ne konkrečiai lanksčiai praktikai.

Yra trys Scrum etapai: Pradžioje yra metmenų planavimo etapas, kurio metu nustatomi

bendrieji projekto tikslai ir programinės įrangos architektūra Po to seka eilė sprinto ciklų, kur kiekvienas ciklas plėtoja

sistemos prieauglį. Baigiamasis projekto etapas apjungia projektą, užbaigia

reikalingą dokumentaciją, pavyzdžiui, sistemos vartotojo vadovą ir pagalbą ir įvertina pamokas iš projekto.


Scrum procesas


Sprinto ciklai Sprintas yra fiksuoto ilgio, paprastai 2-4 savaitės. Jie

atitinka priimtus XP sistemos išleidimo versijas. Planavimo atspirties taškas yra produkto apibrėžimas,

kuris yra sąrašas darbų, kurie turi būti padaryti projekte. Atrankos etapas apima visus tuos iš projekto komandos,

kurie dirba su užsakovu, kad pasirinkti funkcijas ir funkcionalumą, kurios turi būti įgyvendintos per sprintą.


Sprinto ciklas Kai funkcionalumas suderintas, komanda organizuojasi

kurti programinę įrangą. Šiame etape komanda yra izoliuota nuo užsakovo ir jo organizacijos, visos komunikacijos teikiama per vadinamąjį "Scrum meistrą".

Scrum meistro vaidmuo yra apsaugoti kūrimo grupę nuo išorės trukdžių.

Sprinto pabaigoje, darbas yra peržiūrimas ir pateikiamas suinteresuotosioms šalims. Kitas sprinto ciklas tada prasideda.


Scrum komandinis darbas

"Scrum meistras" yra pagalbininkas, kuris organizuoja kasdieninius susitikimus, stebi daromą pažangą ir galimą vilkinimą, užrašo sprendimus ir bendrauja su klientais ir išore.

. Visa komanda lanko trumpus kasdienius susitikimus, kur visi komandos nariai dalinasi informacija, apibūdina jų pažangą po paskutinio susitikimo, problemas, kurios iškilo ir kas planuojama kitą dieną. Tai reiškia, kad visi iš komandos žino, kas vyksta ir, jei iškyla

problemų, gali iš naujo planuoti trumpalaikį darbą su problemomis greit susidoroti.


Scrum nauda Produktas yra suskirstomas į valdomus ir suprantamus

gabaliukus. Nestabilūs reikalavimai nestabdo progreso. Visa komanda viską mato ir todėl komandos

komunikavimas yra geresnis Užsakovai mato laiku pristatomus gabaliukus ir gauna

grįžtamąjį ryšį apie tai, kaip produktas veikia Atsiranda pasitikėjimas tarp užsakovų ir kūrėjų ir

sukuriama teigiama atmosfera, kur visi tiki projekto sėkme.


Lanksčių metodų mastelis Lankstūs metodai pasiteisino dėl mažų ir vidutinių

projektų, kurie gali būti sukurti mažos bendrai esančios komandos.

Tai kartais teigiama, kad šių metodų sėkmė ateina dėl geresnių ryšių, kurie yra įmanomi, kai visi dirba kartu.

Scaling up lanksčių metodų apima jų keitimą siekiant susidoroti su didesniais, ilgiau trunkančiais projektais, kuriuose yra didesnės kūrimo komandos, galbūt, dirbančios skirtingose vietose.


Didelių sistemų kūrimas Didelės sistemos paprastai yra kolekcijos atskirų,

bendraujančių sistemų, kur atskiros komandos plėtoja kiekvieną sistemą. Dažnai šios komandos dirba skirtingose vietose, kartais net skirtingose laiko zonose.

Didelės sistemos yra „liktinės sistemos", kurios apima ir bendravimą su esamomis sistemomis. Daugelis sistemos reikalavimų yra susiję su šią sąveika ir tikrai ne skirti lankstumui ir pažingsniniam kūrimui.

Jei kelios sistemos yra integruotos kad sukurti naują sistemą, nemenka plėtros dalis yra susijusi su sistemos konfigūraciją, o ne originalaus kodo kūrimu.


Didelių sistemų kūrimas Dideles sistemas ir jų kūrimo procesus dažnai riboja

išorės taisykles ir reglamentai, kurie riboja būdus kaip jie galėtų būti sukurti.

Didelės sistemos turi ilgus įsigijimo ir kūrimo laikus. Sunku išlaikyti nuoseklią komandą, kuri žino apie sistemą per tą laikotarpį, neišvengiamai, žmonės turi pereiti į kitus darbus ir projektus.

Didelės sistemos paprastai turi labai įvairų rinkinį suinteresuotų asmenų. Tai praktiškai neįmanoma jų visų įtraukti į dalyvavimą kūrimo procese.


Scaling out and scaling up

‘Scaling up’ yra susijęs su naudojimu lanksčių metodų kuriant dideles programinės įrangos sistemas, kurios negali būti sukurtas mažų komandų.

‘Scaling out‘ yra susijęs su tuo, kaip lankstūs metodai gali būti įdiegti didelėse organizacijose su ilgamete programinės įrangos kūrimo patirtimi.

Kai plečiamas lanksčių metodų naudojimas yra labai svarbu išlaikyti judrumo pagrindus Lankstus planavimas, dažnos sistemos versijos, nuolatinis

integravimas, testavimu grindžiamas kūrimas ir geras komandos bendravimas.


Išplėtimas didelėms sistemoms

Kuriant dideles sistemas neįmanoma sutelkti dėmesį tik į sistemos kodą. Joms reikia padaryti daugiau dėl projekto ir sistemos dokumentacijos

Kryžminiai komandos bendravimo mechanizmai turi būti suprojektuoti ir naudojami. Tai turėtų apimti įprastas telefono ir vaizdo konferencijas tarp komandos narių ir dažnus, trumpus elektroninius susitikimus, kur komandos praneša viena kitai apie pažangą.

Nuolatinė integracija, kur visa sistema yra išbandoma kiekvieną kartą atlikus pakeitimus yra praktiškai neįmanoma. Tačiau būtina išlaikyti dažnus sistemos versijų išbandymus.


Išplėtimas didelėms organizacijoms Projektų vadovai, kurie neturi patirties lanksčių metodų gali būti

nelinkę priimti riziką naujo požiūrio. Didelės organizacijos dažnai turi kokybės procedūras ir

standartus, kurių visi projektai turėtų laikytis ir dėl savo biurokratinio pobūdžio, tai gali būti nesuderinama su lanksčiais metodais.

Lankstūs metodai, atrodo, veikia geriausiai, kai komandos nariai turi santykinai aukštą meistriškumo lygį. Tačiau didelėse organizacijose, yra tikėtina, kad yra įvairių įgūdžių ir gebėjimų darbuotojų.

.Čia gali būti tradicinis pasipriešinimas lankstiems metodams, ypač tose organizacijose, kurios turi ilgą istoriją, naudojant tradicinius sistemų inžinerijos procesus.


Esminiai aspektai Ypatingas stiprumas ekstremalaus programavimo yra

automatizuotų testų kūrimas iki programos funkcija bus sukurta. Visi testai turi būti sėkmingai įvykdyti, kai pridedama dalis yra integruota į sistemą.

Scrum metodas yra lankstus metodas, kuris teikia projekto valdymo schemą. Jo esmė yra aibė sprintų, kurie turi nustatytus laikotarpius pridedamų dalių sukūrimui.

Išplėsti lanksčius metodus didelėms sistemoms yra sunku. Didelės sistemos turi turėti projektą ir kai kuriuos dokumentus.


Klausimas 1 Kas būdinga lankstiems metodams?


Klausimas 2 Kas būdinga ekstremaliam programavimui?


Klausimas 3 Kaip vykdomas testavimas ekstremaliam programavime


Klausimas 4 Kuo pasižymi Scrum metodas?


Klausimas 5 Kokios lanksčių metodų išplečiamumo didelėms

sistemoms ir organizacijoms galimybės?


lankstus kūrimas ( agile )

Documents