Lankstus Kūrimas ( Agile )

1. Lankstus Kūrimas (Agile) Chapter 3 Agile software development

2. Temos • Lankstūs metodai • Planu paremtas ir lankstus kūrimas • Ekstremalus programavimas • Lankstaus projekto valdymas • Lankstaus metodo taikomumas Chapter 3 Agile software development

3. 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ę Chapter 3 Agile software development

4. 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 Lankstūs metodai Chapter 3 Agile software development

5. 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

6. Lanksčių metodų principai Chapter 3 Agile software development

7. 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 Chapter 3 Agile software development

8. 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 Lanksčių metodų problemos Chapter 3 Agile software development

9. 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. Chapter 3 Agile software development

10. 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 chpter 3 Agile software development

11. Planu paremtas ir lankstus specifikavimas Chapter 3 Agile software development

12. 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. Chapter 3 Agile software development

13. Techniniai, žmoniškieji ir organizaciniai aspektai • 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ų. Chapter 3 Agile software development

14. Techniniai, žmoniškieji ir organizaciniai aspektai • 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. Chapter 3 Agile software development

15. 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. Ekstremalus programavimas Chapter 3 Agile software development

16. 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ą. XP ir lankstūs principai Chapter 3 Agile software development

17. Ekstremalaus programavimo versijos ciklas Chapter 3 Agile software development

18. Ekstremalausprogramavimopraktika (a) Chapter 3 Agile software development

19. Ekstremalausprogramavimopraktika (b) Chapter 3 Agile software development

20. 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. Reikalavimų scenarijai Chapter 3 Agile software development

21. Pasakojimas apie vaistų paskyrimą Chapter 3 Agile software development

22. Pavyzdžiai užduočių kortelių vaistų paskyrimui Chapter 3 Agile software development

23. 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. XP ir keitimai Chapter 3 Agile software development

24. 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. Chapter 3 Agile software development

25. 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ą. Chapter 3 Agile software development

26. Esminiai aspektai • Lankstūs metodai yra pažingsniniaikū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. Chapter 3 Agile software development

27. Lankstus programinės įrangos kūrimas Dalis 2 Chapter 3 Agile software development

28. 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 Testavimas ekstremaliam programavime Chapter 3 Agile software development

29. 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ų. Pirmiausia testavimas Chapter 3 Agile software development

30. Užsakovo įtraukimas • Užsakovo vaidmuo testavimo procese yra padėti sudaryti priėmimo testus tų istorijų, kurios turi būti įgyvendintos sekančios versijossistemoje. • 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ėsatliekantys 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ą Chapter 3 Agile software development

31. Testiniai atvejai vaistų dozės tikrinimui Chapter 3 Agile software development

32. 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 Chapter 3 Agile software development

33. 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į. Chapter 3 Agile software development

34. 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 Chapter 3 Agile software development

35. 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 endraiyra efektyvesnis nei 2 programuotojai dirbtų atskirai Chapter 3 Agile software development

36. 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ų. • Taiveikia kaip neformalus peržiūros procesas, nes kiekviena kodo eilutė yra peržvelgiama mažiausiai dviejų žmonių • Taipadeda 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ą. Chapter 3 Agile software development

37. 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. Chapter 3 Agile software development

38. Scrum • Scrumpožiūris yra bendras lankstus metodas, tačiau jo dėmesys skiriamas valdymui aktyviu bendradarbiavimu, o ne konkrečiai lanksčiai praktikai. • YratrysScrum 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. Chapter 3 Agile software development

39. Scrum procesas Chapter 3 Agile software development

40. 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ą. Chapter 3 Agile software development

41. 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į "Scrummeistrą". • Scrummeistro 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. Chapter 3 Agile software development

42. Scrum komandinis darbas • "Scrummeistras" 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. Chapter 3 Agile software development

43. 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. Chapter 3 Agile software development

44. 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. Chapter 3 Agile software development

45. 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. Chapter 3 Agile software development

46. 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. Chapter 3 Agile software development

47. 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. Chapter 3 Agile software development

48. 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. Chapter 3 Agile software development

49. 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ūsmetodai, 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. Chapter 3 Agile software development

50. 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ą. • Scrummetodas 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. Chapter 3 Agile software development