Ekstrem programmering – Ekstrem programmering. Metoder for programvareutvikling

Legg igjen en kommentar 6,950

Send ditt gode arbeid i kunnskapsbasen er enkelt. Bruk skjemaet nedenfor

Studenter, hovedfagsstudenter, unge forskere som bruker kunnskapsbasen i studiene og arbeidet vil være deg veldig takknemlig.

Lagt ut på http://www.allbest.ru/

Innhold

Introduksjon
1. Hva er XP?
3.1 Grunnleggende teknikkerXP
4. Fordeler og ulemper
5. Brukshistorie
Konklusjon

Introduksjon

Ekstrem programmering, ofte forkortet XP, er en disiplin innen programvareutvikling og programvarevirksomhet som fokuserer innsatsen til begge parter (programmerere og forretningsfolk) på felles, oppnåelige mål. Team som bruker XP produserer kvalitetsprogramvare i et veldig raskt tempo. Teknikkene som utgjør faget HR er valgt fordi de er basert på menneskelig kreativitet og aksepten av at mennesker er ustadige og feilbarlige skapninger.

XP presenteres ofte som et sett med teknikker, men XP i seg selv er ikke målstreken. Det er ingen grunn til å trene og utvikle HR bedre og bedre for å motta den etterlengtede gullstjernen på slutten av denne prosessen. Tvert imot er XP startstreken. XP stiller spørsmålet: "Hvor minimal kan innsatsen vår være slik at vi kan fortsette å produsere kvalitetsprogramvare?"

Extreme Programming er en forenklet produksjonsmetodikk for små og mellomstore team av spesialister som utvikler et programvareprodukt under forhold med uklare eller raskt skiftende krav.

1. Hva er XP?

Extremamsengetøyprogrammroving(Engelsk) Ekstrem Programmering, XP) er en av de fleksible programvareutviklingsmetodene. Forfatterne av metodikken er Kent Beck, Ward Cunningham, Martin Fowler og andre.

XP er en forenklet, effektiv, fleksibel, forutsigbar, vitenskapsbasert og svært hyggelig måte å utvikle programvare på med lav risiko. HR skiller seg fra andre metoder på følgende måter:

Ved å bruke ekstremt korte utviklingssykluser, gir XP rask, ekte og kontinuerlig tilbakemelding.

XP bruker inkrementell planlegging, noe som resulterer i at en overordnet prosjektplan dukker opp ganske raskt, men det er forstått at denne planen utvikler seg gjennom hele prosjektets levetid.

XP bruker en fleksibel tidsplan for implementering av denne eller hin funksjonaliteten, noe som forbedrer responsen på virksomhetens endrede karakter og endrede kundekrav i forbindelse med dette.

XP er basert på automatiserte tester utviklet av både programmerere og kunder. Takket være disse testene er det mulig å overvåke utviklingsprosessen, sikre riktig utvikling av systemet og umiddelbart oppdage defekter som eksisterer i systemet.

XP er basert på muntlig kommunikasjon, tester og kildekode. Disse tre verktøyene brukes til å utveksle informasjon om et systems struktur og oppførsel.

XP er basert på en utviklende designprosess som fortsetter så lenge selve systemet eksisterer.

XP er basert på nært samspill mellom programmerere med de vanligste ferdighetene og egenskapene.

XP er basert på teknikker som tilfredsstiller både de kortsiktige instinktene til individuelle programmerere og de langsiktige interessene til hele prosjektet.

XP er en programvareutviklingsdisiplin. Dette er en disiplin fordi innenfor XP er det visse ting du må gjøre hvis du skal bruke XP. Du bør ikke velge om du vil skrive tester eller ikke, for hvis du ikke gjør det, er ikke programmeringen du gjør ekstrem.

XP-metodikken er utviklet for å jobbe med prosjekter som kan arbeides med av to til ti programmerere, som ikke er begrenset av de stive rammene til et eksisterende datamiljø, og der alt nødvendig testarbeid kan fullføres i løpet av en dag.

2. Hvor begynner ekstrem programmering?

Hvor begynner ekstrem programmering? Fra forståelsen av at den typiske posisjonen til en innenlandsk programvareutvikler forplikter til å redusere utviklingskostnadene så mye som mulig. Og for dette er det nødvendig å intensivt samarbeide med kunden, forstå hans interesser og til slutt gjøre akkurat det han vil: ikke mer eller mindre.

Ekstrem programmering er ikke basert på spesifikke teknikker, slik man ofte tror, men kun på fire grunnleggende prinsipper: kommunikasjon, enkelhet, tilbakemelding og mot. Det er her du må begynne.

Extreme Programming tilbyr en ferdig løsning: hold alt så enkelt som mulig, hold kunden for deg selv eller bli hos kunden, la ham aktivt overvåke utviklingsprosessen, velkommen endring – og suksess er nesten garantert.

I XP-team oppmuntres alltid kommunikasjon – den raskeste måten å dele informasjon og erfaringer på. Dette er veldig viktig når det kreves maksimal utviklingshastighet. Men kommunikasjon, som alle andre nyttige forsøk, krever konstant støtte. Derfor må noen fra teamet ta ansvar for å overvåke kommunikasjonen, bli en såkalt diplomat. Kommunikasjon og behovet for å forklare handlingene dine til andre teammedlemmer tvinger deg til å gjøre alt så enkelt som mulig. Hvis det ikke fungerer første gang, jobber de med forenkling igjen og igjen til hovedmålet er oppnådd - maksimal forståelse av koden for andre utviklere.

Uansett hva vi gjør - å tre en nål eller gå på fest - streber vi alltid etter å oppnå et eller annet mål. Hvis vi merker at vi avviker fra det, justerer vi handlingene våre deretter. Tenk nå hvor mye vanskeligere det er å tre en nål med lukkede øyne eller å kle seg vakkert uten speil! Men når man utvikler programmer, er det ofte dette som skjer: vi gjør noe som vi ikke kan se resultatet av. Derfor er det i ekstrem programmering en regel å se resultatet av handlingene dine så raskt som mulig. Eller, teknisk sett, for å gi tilbakemelding så raskt som mulig.

Extreme Programming spør oss: hvorfor ikke utvikle mot? Hun er tross alt veldig viktig i arbeidet sitt. Uten mot, er det mulig å ta ansvar for å fullføre en oppgave, og innenfor en bestemt tidsramme? Uten mot, er det mulig å innse at du har kommet til en blindvei, ta et skritt tilbake og se etter en løsning? Og til slutt, hva vil tillate utvikleren å innrømme sin feil ved å vurdere oppgaven og advare andre om den i tide, i stedet for å presentere dem for et fait accompli først når alle fristene er utløpt? Fordelene med mot er åpenbare, og enhver suksess, selv i den minste oppgaven, kan utvikle dette motet.

3. XP-teknikker

Extreme Programming (XP) dukket opp som en evolusjonær metode for programvareutvikling nedenfra og opp. Denne tilnærmingen er et eksempel på den såkalte Agile Development Method. Gruppen av «live»-metoder inkluderer, i tillegg til ekstrem programmering, metodene SCRUM, DSDM (Dynamic Systems Development Method, en metode for å utvikle dynamiske systemer), Feature-Driven Development (utvikling drevet av systemfunksjoner), etc.

De grunnleggende prinsippene for utvikling av live programvare er nedfelt i live-utviklingsmanifestet, som dukket opp i 2000.

· Menneskene som er involvert i et prosjekt og deres kommunikasjon er viktigere enn prosesser og verktøy.

· Et arbeidsprogram er viktigere enn omfattende dokumentasjon.

· Samarbeid med kunden er viktigere enn å diskutere detaljene i kontrakten.

· Å jobbe gjennom endringer er viktigere enn å holde seg til planer.

"Levende" metoder dukket opp som en protest mot overdreven byråkratisering av programvareutvikling, overfloden av sidedokumenter som ikke er nødvendige for å oppnå det endelige resultatet, som må utarbeides når man utfører et prosjekt i samsvar med de fleste "tunge" prosesser , tilleggsarbeid for å støtte den faste prosessen i organisasjonen, som dette kreves innenfor for eksempel CMM. Det meste av slikt arbeid og dokumenter er ikke direkte relatert til programvareutvikling og kvalitetssikring, men er ment å overholde de formelle klausulene i utviklingskontrakter, innhente og bekrefte sertifikater for samsvar med ulike standarder.

«Live»-metoder lar utviklere fokusere mesteparten av innsatsen på utviklingsoppgaver og møte reelle brukerbehov. Fraværet av hauger med dokumenter og behovet for å opprettholde dem i en sammenhengende tilstand lar deg reagere raskere og mer effektivt på endringer i krav og i miljøet der det fremtidige programmet må fungere.

XP har imidlertid sitt eget utviklingsprosessdiagram (selv om, generelt sett, den mye brukte forståelsen av "utviklingsprosessen" som et ganske rigid handlingsplan motsier selve ideen om "livlig" utvikling), vist i fig. 1 .

I følge forfatterne av XP følger denne teknikken ikke så mye noen generelle handlingsmønstre som å bruke en kombinasjon av følgende teknikker. Hver teknikk er imidlertid viktig, og uten bruk anses utviklingen for ikke å være XP, ifølge Kent Beck, en av forfatterne av denne tilnærmingen sammen med Ward Cunningham og Ron Jeffries.

· Boplanlegger (planleggerspill)

Dens oppgave er å finne ut så raskt som mulig hvor mye arbeid som må gjøres før neste programvareversjon. Beslutningen tas først og fremst basert på kundens prioriteringer (dvs. hans behov, hva han trenger fra systemet for å drive virksomheten mer vellykket) og for det andre på grunnlag av tekniske vurderinger (dvs. estimater av kompleksiteten) utvikling, kompatibilitet med andre elementer i systemet, etc.). Planer endres så snart de begynner å avvike fra virkeligheten eller kundens ønsker.

Ris.1 XP arbeidsflytdiagram

· HyppigendringVversjoner (litenutgivelser)

Den aller første fungerende versjonen skal vises så raskt som mulig og bør umiddelbart begynne å brukes. Etterfølgende versjoner utarbeides med ganske korte intervaller (fra flere timer for små endringer i et lite program, til en måned eller to for en større omarbeiding av et stort system). Versjoner (utgivelser) av produktet bør tas i bruk så ofte som mulig. Hver versjon bør ta så kort tid som mulig å fullføre. Dessuten må hver versjon være tilstrekkelig meningsfull når det gjelder nytteverdi for virksomheten.

· Metafor (metafor) systemer

Metaforen, i en ganske enkel og forståelig form for teamet, skal beskrive den grunnleggende mekanismen til systemet. Dette konseptet minner om arkitektur, men skal beskrive hovedessensen av de tekniske beslutningene som er tatt mye enklere, i bare en eller to fraser.

Arkitektur er en idé om komponentene i et system og hvordan de henger sammen. Utviklere bruker arkitektur for å forstå hvor ny funksjonalitet legges til systemet, og hva en ny komponent vil samhandle med.

Systemmetaforen er en analog av det som kalles arkitektur i de fleste teknikker. Systemmetaforen gir teamet en følelse av hvordan systemet fungerer, hvor nye komponenter legges til, og hvilken form de bør ha.

· Enkeldesignløsninger (enkeldesign)

Til enhver tid bør systemet utformes så enkelt som mulig. Det er ikke nødvendig å legge til funksjoner på forhånd - bare etter en eksplisitt forespørsel om det. All unødvendig kompleksitet fjernes så snart den oppdages.

XP går ut fra det faktum at under arbeidsprosessen kan betingelsene for problemet endres gjentatte ganger, noe som betyr at produktet som utvikles ikke bør utformes på forhånd i sin helhet. Hvis du prøver å designe et system i detalj fra start til slutt når du først starter, kaster du bort tiden din. XP forutsetter at design er en så viktig prosess at det må gjøres kontinuerlig gjennom hele prosjektet. Design må utføres i små trinn, med hensyn til stadig skiftende krav. I hvert øyeblikk prøver vi å bruke det enkleste designet som er egnet for å løse det aktuelle problemet. Samtidig endrer vi det etter hvert som betingelsene for problemet endres.

· Utviklingpåbasistesting (test- drevetutvikling)

Utviklere skriver først tester, og prøver deretter å implementere modulene sine slik at testene fungerer. Kunder skriver tester på forhånd som demonstrerer hovedfunksjonene til systemet slik at de kan se at systemet faktisk fungerer.

XP legger særlig vekt på to typer testing:

ь enhetstesting;

b akseptansetesting.

ekstrem programmeringsprogramvare

En utvikler kan ikke være sikker på riktigheten av koden han har skrevet før absolutt alle tester av modulene til systemet han utvikler har fungert. Enhetstester lar utviklere verifisere at koden deres fungerer som den skal. De hjelper også andre utviklere å forstå hvorfor en bestemt kodebit er nødvendig og hvordan den fungerer. Enhetstester lar også utvikleren refaktorere uten bekymringer.

Aksepttester sikrer at systemet faktisk har de angitte egenskapene. I tillegg lar aksepttester deg verifisere riktig funksjon av produktet som utvikles.

For XP er en høyere prioritet tilnærmingen som kalles TDD (Test Driven Development), først skrives en test som ikke består, deretter skrives koden slik at testen består, og først da refaktoreres koden.

· Konstantresirkulering (refaktorisering)

Det er ingen hemmelighet at tillegget av hver ny funksjonalitet og kodevekst kompliserer utvikling, identifiserer feil og gjør påfølgende endringer. Et av triksene med Extreme Programming er å kompensere for å legge til funksjonalitet med kodeforbedringer. Dette er kodebehandling, eller refactoring.

Programmerere omarbeider hele tiden systemet for å eliminere unødvendig kompleksitet, øke forståelsen av koden, øke fleksibiliteten, men uten å endre oppførselen, som verifiseres ved å kjøre etter hver omarbeiding av testene. Samtidig foretrekkes mer elegante og fleksible løsninger, sammenlignet med de som rett og slett gir ønsket resultat. Ulykket redesignede komponenter bør identifiseres under testutførelse og rulles tilbake til den siste intakte tilstanden (sammen med komponentene som er avhengige av dem).

Refaktorering er en teknikk for å forbedre kode uten å endre funksjonaliteten. XP betyr at når koden er skrevet, vil den nesten helt sikkert bli skrevet om flere ganger i løpet av et prosjekt. XP-utviklere omarbeider nådeløst tidligere skrevet kode for å forbedre den. Denne prosessen kalles refactoring. Mangelen på testdekning provoserer avslag på refactoring på grunn av frykten for å bryte systemet, noe som fører til gradvis degradering av koden.

· Programmeringi par (parprogrammering)

Erfarne utviklere har lagt merke til at periodisk gjennomgang av andres kode har en positiv effekt på kvaliteten. Mesterne i ekstrem programmering har utviklet denne tilnærmingen ved å hele tiden gjennomgå kode under utviklingen gjennom en teknikk som kalles parprogrammering.

Koding utføres av to programmerere på én datamaskin. Sammenkobling er vilkårlig og varierer fra oppgave til oppgave. Den i hvis hender tastaturet prøver å løse det aktuelle problemet på beste måte. Den andre programmereren analyserer arbeidet til den første og gir råd, vurderer konsekvensene av visse beslutninger, nye tester, mindre direkte, men mer fleksible løsninger. Om nødvendig overføres tastaturet fritt fra det ene til det andre. Når du jobber med et prosjekt, er ikke parene fikset: det anbefales å blande dem slik at hver programmerer i teamet har en god forståelse av hele systemet. På denne måten forbedrer parprogrammering samarbeidet i teamet.

· Kollektivbesittelsekode (kollektiveie)

Kollektiv besittelse betyr at hvert teammedlem er ansvarlig for all kildekode. Dermed har alle rett til å gjøre endringer i hvilken som helst del av programmet. Parprogrammering støtter denne praksisen: ved å jobbe i forskjellige par, blir alle programmerere kjent med alle deler av systemets kode. En viktig fordel med delt kodeeierskap er at det fremskynder utviklingsprosessen, siden hvis det oppstår en feil, kan enhver programmerer fikse det.

Ved å gi enhver programmerer rett til å endre koden, risikerer vi feil introdusert av programmerere som tror de vet hva de gjør, men som ikke vurderer visse avhengigheter. Veldefinerte UNIT-tester løser dette problemet: hvis uundersøkte avhengigheter genererer feil, vil neste kjøring av UNIT-tester mislykkes.

· Konstantintegrering (kontinuerligeintegrering)

Systemet settes sammen og gjennomgår integrasjonstesting så ofte som mulig, flere ganger om dagen, hver gang et par programmerere fullfører implementeringen av neste funksjon.

Hvis du integrerer systemet du utvikler ofte nok, kan du unngå de fleste problemene knyttet til det. I tradisjonelle metoder utføres integrasjon vanligvis helt på slutten av arbeidet med et produkt, når det anses at alle komponentene i systemet som utvikles er helt klare. I XP utføres kodeintegrasjon av hele systemet flere ganger om dagen, etter at utviklerne er sikre på at alle enhetstester avfyrer riktig.

Til tross for sin enkelhet har denne teknikken sine egne bruksregler, for eksempel suksessen til de eksisterende enhetstestene for funksjonaliteten som integreres, tilstedeværelsen av funksjonelle eller aksepterte tester, og selvfølgelig muligheten til å rulle tilbake til en tidligere tilstand . Vanligvis utføres integrering og løsning av tilhørende vanskeligheter på en separat datamaskin av et par programmerere. Dette lar deg minimere risikoen for uønskede konsekvenser av integrering.

· 40 timerarbeideren uke

Å jobbe overtid blir sett på som et tegn på større problemer i prosjektet. Overtidsarbeid i 2 uker på rad er ikke tillatt - dette sliter ut programmerere og gjør arbeidet deres betydelig mindre produktivt.

En person, spesielt hvis han er programmerer, er i stand til å gjøre mye for virksomhetens skyld: å være sent på jobb, gå på jobb i helgene, gi opp ferier, holde seg våken i flere dager mens han sitter ved tastaturet ... Generelt, hva kan du gjøre for din favorittaktivitet. Men ekstrem programmering er kategorisk mot slik selvoppofrelse og brudd på aksepterte arbeidsrettslige standarder.

Dette er ikke bare diktert av hensynet til lovlighet og menneskelighet, men først og fremst av behovet for å øke arbeidseffektiviteten og streng organisering. Tross alt er ekstrem programmering et kollektivt spill, designet ikke for enkeltpersoner, men for hele gruppen. Og noe slikt som for eksempel parprogrammering er bare mulig når biorytmene til deltakerne er synkronisert. Og det er umulig hvis en person kommer på jobb klokken ni, og den andre klokken tolv, eller en bestemmer seg for at det er bedre for ham å jobbe på lørdag og søndag, mens den andre er ubeleilig.

Men det viktigste er at for å opprettholde helse og ytelse, trenger en person riktig hvile. Åtte timers arbeidsdag og fem dagers arbeidsuke er etablert nettopp av hensyn til maksimal produktivitet. I mange vestlige selskaper blir det å forlate jobben for sent sett på som manglende ytelse eller manglende evne til å styre arbeidstiden på riktig måte. I de fleste tilfeller er dette sant. Og fra et medisinsk synspunkt fører forsinkelser på jobben til konstant tretthet, irritabilitet og redusert hjerneaktivitet. Er dette effektivt? Hvordan kan vi organisere konstant åpen kommunikasjon mellom utviklere i et slikt team, og vil parprogrammering være mulig? Svaret er negativt. Standarder er standarder og bør følges.

· InkluderingkundeVteam (på- nettstedetkunde)

Utviklingsteamet har alltid en kunderepresentant som er tilgjengelig gjennom hele arbeidsdagen og kan svare på alle spørsmål om systemet. Hans ansvar er å umiddelbart svare på spørsmål av enhver type angående funksjonene til systemet, dets grensesnitt, nødvendig ytelse, korrekt drift av systemet i vanskelige situasjoner, behovet for å opprettholde kommunikasjon med andre applikasjoner, etc.

Mange tviler på muligheten for å involvere kunden i utviklingsprosessen. Faktisk er kunder forskjellige. Hvis det ikke er mulig å tiltrekke seg kunden eller hans representant, er det noen ganger tilrådelig å midlertidig ansette en spesialist på feltet som utvikles. Dette trinnet vil redusere uklarheter i arbeidet, øke hastigheten på utviklingen og bringe prosjektet nærmere det kunden ønsker å motta. Dette kan også være gunstig fra den økonomiske siden: tross alt er lønnen til en programmerer noen ganger betydelig høyere enn lønnen til spesialister i andre bransjer.

· BrukkodeHvordanfasiliteterkommunikasjon

Kode blir sett på som det viktigste kommunikasjonsmiddelet i et team. Kodeklarhet er en av hovedprioriteringene. Det er avgjørende å følge kodingsstandarder som gir denne klarheten. Slike standarder, i tillegg til kodeklarhet, bør sikre minimalt med språk (ingen duplisering av kode og informasjon) og bør aksepteres av alle teammedlemmer.

· Åpenarbeiderrom (åpenarbeidsområde)

Teamet er plassert i ett ganske romslig rom for å lette kommunikasjonen og muliggjøre gruppediskusjoner ved planlegging og viktige tekniske beslutninger.

· EndringreglerAvnødvendighet (bareregler)

Hvert teammedlem må godta reglene som er oppført, men hvis behovet oppstår, kan teamet endre dem hvis alle medlemmene er enige om denne endringen.

Som man kan se av teknikkene som brukes, er XP designet for bruk i små team (ikke mer enn 10 programmerere), noe som er understreket av forfatterne av denne teknikken. En større teamstørrelse ødelegger den enkle kommunikasjonen som er nødvendig for suksess og gjør det umulig å implementere mange av teknikkene som er oppført.

3.1 Grunnleggende XP-teknikker

Tolv grunnleggende teknikker for ekstrem programmering (basert på den første utgaven av boken Ekstrem programmering forklart) kan kombineres i fire grupper:

· Kort tilbakemeldingssyklus (tilbakemelding i finskala)

o Testdrevet utvikling

o Planleggingsspill

o Kunden er alltid i nærheten (hele teamet, kunde på stedet)

o Parprogrammering

Kontinuerlig i stedet for batch prosess

o Kontinuerlig integrasjon

o Refaktorering (Design Improvement, Refactor)

o Hyppige små utgivelser

· Forståelse delt av alle

o Enkelhet (enkel design)

o Systemmetafor

o Kollektivt kodeeierskap eller utvalgte designmønstre (eierskap av kollektive mønstre)

o Kodestandard eller Kodekonvensjoner

· Programmerers velferd:

o 40-timers arbeidsuke (bærekraftig tempo, førti timers uke)

Et spillVplanlegger

I Extreme Programming er planlegging en integrert del av utviklingen og det tas hensyn til at planer kan endres helt fra starten. Omdreiningspunktet, teknikken som lar deg forutse situasjonen og smertefritt tåle endringer, er planleggingsspillet. Under et slikt spill kan kjente systemkrav raskt samles inn, vurderes og planlegges etter prioritet.

Som alle andre spill har planlegging sine deltakere og sitt mål. Nøkkeltallet er selvfølgelig kunden. Det er han som kommuniserer behovet for denne eller den funksjonaliteten. Programmerere gir en omtrentlig vurdering av hver funksjonalitet. Skjønnheten i planleggingsspillet ligger i enheten av formål og solidaritet mellom utvikleren og kunden: i tilfelle seier vinner alle, i tilfelle tap taper alle. Men samtidig går hver deltaker sin egen vei til seier: kunden velger de viktigste oppgavene i samsvar med budsjettet, og programmereren evaluerer oppgavene i samsvar med hans evne til å implementere dem.

Ekstrem programmering forutsetter at utviklere er i stand til å bestemme selv hvor lang tid det vil ta dem å fullføre oppgavene sine, og hvem av dem som vil være mer villige til å løse ett problem og hvem et annet.

I en ideell situasjon bør planleggingsspillet mellom kunden og programmereren spilles hver 3.-6. uke, inntil neste utviklingsiterasjon starter. Dette gjør det ganske enkelt å gjøre justeringer basert på suksesser og fiaskoer fra forrige iterasjon.

4. Fordeler og ulemper

Fordelene med XP, hvis det kan implementeres, er større fleksibilitet, muligheten til å raskt og nøyaktig gjøre endringer i programvaren som svar på endrede krav og individuelle kundeønsker, høy kvalitet på den resulterende koden, og fraværet av behovet for å overbevise kundene om at resultatet oppfyller deres forventninger.

Ulempene med denne tilnærmingen er ugjennomførbarheten av tilstrekkelig store og komplekse prosjekter i denne stilen, manglende evne til å planlegge timingen og kompleksiteten til prosjektet på tilstrekkelig lang sikt og tydelig forutsi resultatene av et langsiktig prosjekt i forhold til forholdet. av kvaliteten på resultatet og kostnadene for tid og ressurser. Det kan også bemerkes at XP ikke egner seg for de tilfeller der mulige løsninger ikke umiddelbart finnes på bakgrunn av tidligere opparbeidede erfaringer, men krever forundersøkelser.

5. Brukshistorie

XP som et sett med beskrevne teknikker ble først brukt under arbeidet med C3-prosjektet (Chrysler Comprehensive Compensation System, utvikling av et system for regnskapsføring av ansattes fordeler hos Daimler Chrysler). Av de 20 deltakerne i dette prosjektet publiserte 5 (inkludert de ovennevnte 3 hovedforfatterne av XP) 3 bøker og et stort antall artikler viet til XP under selve prosjektet og senere. Følgende data illustrerer problemene med noen XP-teknikker når de brukes på ganske komplekse prosjekter.

Prosjektet startet i januar 1995. Siden mars 1996, etter inkluderingen av Kent Beck, har den blitt kjørt med XP. På dette tidspunktet hadde det allerede gått utover budsjettet og planene for trinnvis implementering av funksjoner. Utviklingsteamet ble kuttet, og i omtrent seks måneder etter det utviklet prosjektet seg ganske vellykket. I august 1998 dukket det opp en prototype som kunne betjene rundt 10 000 ansatte. Prosjektet var opprinnelig forventet å være fullført i midten av 1999, og den resulterende programvaren skulle brukes til å administrere fordelene for selskapets 87 000 ansatte. Den ble stoppet i februar 2000 etter 4 år med XP på grunn av fullstendig manglende overholdelse av tidsrammer og budsjett. Programvaren som er laget har aldri blitt brukt til å arbeide med data om mer enn 10.000 ansatte, selv om det har vist seg at den kan håndtere data om 30.000 bedriftsansatte. Personen som spilte rollen som kunden inkludert i prosjektteamet sluttet etter noen måneder med slikt arbeid, ikke i stand til å tåle arbeidsbelastningen, og fikk aldri en adekvat erstatning før slutten av prosjektet.

Konklusjon

Alle de ovennevnte metodene er ikke samlet ved en tilfeldighet. Deres konsistente kombinasjon kan bringe utviklingsprosessen inn i intellektuell resonans, øke kvaliteten på produktet betydelig og fremskynde utgivelsestiden. Det viktigste med all ekstrem programmering er forutsigbarhet og minimering av utviklingskostnader; å gi kunden produktet han ønsker å motta på utgivelsestidspunktet; og selvfølgelig kommunikasjon og opplæring av utviklere på jobben.

Meningene om den foreslåtte metoden kan variere. Det er viktig å forstå at Extreme Programming ikke tar sikte på å erstatte eksisterende utviklingsteknologier. Tvert imot kan XP gi ekstra drivkraft til team som bruker tradisjonelle tilnærminger. Du bør ikke lete her etter svar på alle spørsmålene dine. Dette er ikke en programmeringsteknologi, men snarere en teknologi for organisering av arbeid, og det er i denne formen den har livets rett.

Skrevet på Allbest.ru

Lignende dokumenter

Analyse av stadier og funksjoner i utviklingen av en optimal og funksjonell ARIS-modell - et programvareprodukt fra IDS Scheer for modellering av selskapets forretningsprosesser. Studie av grunnleggende konsepter, metoder og tilnærminger til ekstrem programmering.

test, lagt til 06.04.2011

De viktigste stadiene av programvareutvikling (programvarepakke), analyse av systemkrav. Metode for trinn-for-trinn detaljering. Programmeringsspråk på lavt nivå og høyt nivå (imperativt, objektorientert, funksjonelt, logisk).

presentasjon, lagt til 13.10.2013

Utviklingsspråk, implementeringsmiljø, utviklingsverktøy. Funksjoner i det virtuelle miljøet for programimplementering og deres vurdering i utviklingen av et programvareprodukt. Systemmakroer og deres bruk i utviklingstekster. Visuelle programmeringsverktøy.

opplæring, lagt til 26.10.2013

Problemet med programvarepålitelighet, dets indikatorer og støttefaktorer. Metoder for å overvåke utviklingsprosessen av programmer og dokumentasjon, feilforebygging. Stadier av programvarefeilsøkingsprosessen, strukturerte programmeringsteknikker og prinsippet om modularitet.

presentasjon, lagt til 30.04.2014

Maskinkoder og montør. De første programmeringsspråkene på høyt nivå. FORTRAN programmeringsspråk. Fordeler og ulemper med ALGOL. Vitenskapelige og regnskapsprogrammer. De grunnleggende prinsippene som ble fulgt når du opprettet det grunnleggende programmeringsspråket.

kursarbeid, lagt til 21.06.2014

Konseptet og nøkkelforskjellen til distribuert programvareutvikling, dens fordeler og ulemper. Konseptuell løsning og valg av utbyggingstype. Funksjoner av åpen kildekode-programvare. Ideen og utviklingen av åpen kildekode.

kursarbeid, lagt til 14.12.2012

Konseptet med programvarens livssyklus. To typer aktiviteter skilles i tekniske prosjekter: design og produksjon. Hovedprinsippene i manifestet til tilhengere av fleksible metoder. Grunnleggende prinsipper for ekstrem programmering.

presentasjon, lagt til 14.08.2013

Internasjonal standard for programmeringsspråket Pascal. Teknikker for objektorientert programmering i Turbo Pascal. Symboler på språket, dets alfabet. Stadier av programutvikling. Konseptet med algoritmer og algoritmisering. Struktur av programmer i Pascal.

kursarbeid, lagt til 28.02.2010

Moderne programvareutviklingsverktøy for kontrollsystemer. Universelle programmeringsspråk og deres sammenligning med SCADA-systemer. Programvareutvikling ved bruk av flerkanals måletransdusere Ш9327.

avhandling, lagt til 13.07.2011

Grunnleggende teknikker for å jobbe i programmeringsmiljøet Delphi. Funksjoner av teknologien for å lage enkle applikasjoner. Arbeide med applikasjonsutviklingsmiljøkomponenter. Inntasting, redigering, valg og utdata av informasjon. Aspekter ved bruk av forgreningsstruktur.

Extreme Programming eller XP, eXtreme Programming er en fleksibel programvareutviklingsmetodikk. Som andre smidige metoder har den spesifikke verktøy, prosesser og roller. Selv om forfatteren av XP ikke kom med noe nytt, men tok de beste praksisene for smidig utvikling og styrket dem maksimalt. Det er derfor programmering kalles ekstrem.

Forfatteren av metoden er den amerikanske utvikleren Kent Beck. På slutten av 90-tallet ledet han Chrysler Comprehensive Compensation System-prosjektet, og der var han banebrytende for praksisen med ekstrem programmering. Han beskrev sin erfaring og konseptet han skapte i boken Extreme Programming Explained, utgitt i 1999. Den ble fulgt av andre bøker som beskriver XP-praksis. Ward Cunningham, Martin Fowler og andre var også involvert i utviklingen av metodikken.

XP skiller seg fra andre smidige metoder ved at det gjelder bare innen programvareutvikling. Den kan ikke brukes i en annen virksomhet eller hverdag som scrum, kanban eller lean.

Målet med XP-metodikken er å takle stadig skiftende krav til et programvareprodukt og forbedre kvaliteten på utviklingen. Derfor er XP godt egnet for komplekse og usikre prosjekter

XP-metodikken er bygget rundt fire prosesser: koding, testing, design og lytting. I tillegg har Extreme Programming verdiene enkelhet, kommunikasjon, tilbakemelding, mot og respekt.

1. Hele laget

Alle prosjektdeltakere som bruker XP jobber som ett team. Det må inkludere en representant for kunden, det er bedre om dette er en reell sluttbruker av produktet som forstår virksomheten. Kunden stiller krav til produktet og prioriterer implementering av funksjonalitet. Forretningsanalytikere kan hjelpe ham. På utførelsessiden inkluderer teamet utviklere og testere, noen ganger en coach som veileder teamet, og en leder som gir teamet ressurser.

2. Planleggingslek

Planlegging i XP utføres i to trinn - utgivelsesplanlegging og iterasjonsplanlegging.

Under utgivelsesplanleggingen møter programmeringsteamet kunden for å finne ut hvilken funksjonalitet han ønsker å få til neste utgivelse, det vil si om 2-6 måneder. Siden kundekravene ofte er vage, spesifiserer utviklere dem og bryter dem ned i deler, hvis implementering ikke tar mer enn én dag. Det er viktig at kunden forstår driftsmiljøet produktet skal fungere i.

Oppgaver skrives ned på kort, og kunden bestemmer deres prioritet. Deretter anslår utviklere hvor mye tid hver oppgave vil ta. Når oppgavene er beskrevet og vurdert, gjennomgår kunden dokumentasjonen og gir klarsignal for at arbeidet kan starte. For å lykkes med prosjektet, er det avgjørende at kunden og programmeringsteamet spiller på samme felt: kunden velger funksjonaliteten som virkelig trengs innenfor budsjettet, og programmererne sammenligner på en adekvat måte kundens krav med deres evner.

I XP, hvis teamet ikke har tid til å fullføre alle oppgavene innen utgivelsesdatoen, skyves ikke utgivelsen tilbake, men en del av funksjonaliteten som er minst viktig for kunden kuttes.

Iterasjonsplanlegging gjennomføres Hver andre uke, noen ganger mer eller sjeldnere. Kunden er alltid til stede: han bestemmer funksjonaliteten for neste iterasjon og gjør endringer i produktkravene.

3. Hyppige versjonsutgivelser

I XP utgis versjoner ofte, men med lite funksjonalitet. For det første er en liten mengde funksjonalitet lett å teste og vedlikeholde funksjonaliteten til hele systemet. For det andre, hver iterasjon mottar kunden et stykke funksjonalitet som gir forretningsverdi.

4. Brukertester

Kunden definerer selv automatiserte aksepttester for å sjekke funksjonaliteten til neste produktfunksjon. Teamet skriver disse testene og bruker dem til å teste den ferdige koden.

5. Kollektivt kodeeierskap

I XP kan enhver utvikler redigere hvilken som helst kode, fordi... Koden er ikke tildelt forfatteren. Hele teamet eier koden.

6. Kontinuerlig kodeintegrasjon

Dette betyr at nye kodebiter umiddelbart bygges inn i systemet - XP-team laster opp en ny versjon med noen få timers mellomrom eller oftere. Først kan du umiddelbart se hvordan de siste endringene påvirker systemet. Hvis et nytt kodestykke bryter noe, er det mye enklere å finne og fikse feilen enn en uke senere. For det andre jobber teamet alltid med siste versjon av systemet.

7. Kodestandarder

Når alle eier koden, er det viktig å ta i bruk konsistente designstandarder slik at koden ser ut som den er skrevet av én fagperson. Du kan utvikle dine egne standarder eller ta i bruk ferdige.

8. Systemmetafor

En systemmetafor er en sammenligning av systemet med noe kjent for å skape en felles visjon blant teamet. Vanligvis er systemmetaforen tenkt ut av personen som designer arkitekturen og forestiller seg systemet som en helhet.

9. Jevnt tempo

XP-team opererer med maksimal produktivitet samtidig som de opprettholder et jevnt tempo. Samtidig har ekstrem programmering en negativ holdning til overtid og fremmer en 40-timers arbeidsuke.

10. Testdrevet utvikling

En av de vanskeligste praksisene i metodikken. I XP skrives tester av programmererne selv, FØR koden som skal testes skrives. Med denne tilnærmingen vil hver del av funksjonaliteten være 100 % dekket med tester. Når et par programmerere laster opp kode til depotet, kjøres enhetstester umiddelbart. Og de burde ALLE fungere. Da vil utviklerne være sikre på at de går i riktig retning.

11. Parprogrammering

Se for deg to utviklere ved én datamaskin som jobber med én produktfunksjonalitet. Dette er parprogrammering, den mest kontroversielle XP-praksisen. Det gamle ordtaket "ett hode er bra, to er bedre" illustrerer perfekt essensen av tilnærmingen. Den beste velges fra to alternativer for å løse et problem, koden optimaliseres umiddelbart, og feil fanges opp før de oppstår. Som et resultat har vi ren kode som to utviklere er godt kjent med.

12. Enkel design

Enkel design i XP betyr å bare gjøre det du trenger nå, uten å prøve å gjette fremtidig funksjonalitet. Enkel design og kontinuerlig refactoring har en synergistisk effekt - når koden er enkel, er den lett å optimalisere.

13. Refaktorering

Refaktorering er prosessen med å kontinuerlig forbedre et systems design for å imøtekomme nye krav. Refaktorering innebærer å fjerne duplikatkode, øke kohesjonen og redusere koblingen. XP involverer konstante refactorings, så kodedesign forblir alltid enkelt.

XP fordeler og ulemper

XP-metodikken forårsaker mye kontrovers og kritikk fra de som aldri har vært i stand til å implementere den i teamet sitt.

Fordelene med ekstrem programmering gir mening når teamet fullt ut bruker minst én av XP-praksisene. Så, hva er verdt å prøve:

kunden får akkurat det produktet han trenger, selv om han i begynnelsen av utviklingen selv ikke akkurat forestiller seg den endelige formen
teamet gjør raskt kodeendringer og legger til ny funksjonalitet gjennom enkel kodedesign, hyppig planlegging og utgivelser
koden fungerer alltid på grunn av konstant testing og kontinuerlig integrasjon
teamet vedlikeholder enkelt koden, fordi den er skrevet i henhold til en enkelt standard og refaktoreres konstant
rask utviklingstakt på grunn av parprogrammering, mangel på etterarbeid, tilstedeværelse av kunden i teamet
høy kodekvalitet
risikoen forbundet med utvikling reduseres, fordi ansvaret for prosjektet er jevnt fordelt og avreise/ankomst av et teammedlem vil ikke ødelegge prosessen
utviklingskostnadene er lavere pga team er kodeorientert, ikke dokumentasjon og møter

Til tross for alle fordelene, fungerer ikke XP alltid og har en rekke svakheter. Så ekstrem programmering - ulemper:

suksessen til prosjektet avhenger av kundens involvering, noe som ikke er så lett å oppnå
Det er vanskelig å forutsi tiden brukt på et prosjekt, fordi... i begynnelsen vet ingen den komplette listen over krav
suksessen til XP avhenger sterkt av nivået på programmerere; metodikken fungerer bare med seniorspesialister
ledelsen har en negativ holdning til parprogrammering, og forstår ikke hvorfor det skal betale for to programmerere i stedet for én
Regelmessige møter med programmerere er kostbare for kundene
krever for mye kulturell endring
grunnet manglende struktur og dokumentasjon, ikke egnet for store prosjekter
fordi Agile metodikk er funksjonelt orientert, ikke-funksjonelle krav til produktkvalitet er vanskelig å beskrive i form av brukerhistorier.

XP-prinsipper

I sin første bok artikulerte Kent Beck prinsippene for ekstrem programmering: enkelhet, kommunikasjon, tilbakemelding og mot. I den nye utgaven av boken la han til et femte prinsipp – respekt.

1. Enkelhet

I XP starter utviklingen med den enkleste løsningen som vil tilfredsstille dagens behov for funksjonalitet. Teammedlemmer tar kun hensyn til det som må gjøres nå, og legger ikke inn i kodefunksjonaliteten som vil være nødvendig i morgen, om en måned eller aldri.

2. Kommunikasjon

I XP utføres kommunikasjon mellom utviklere ikke gjennom dokumentasjon, men live. Teamet kommuniserer aktivt med hverandre og med kunden.

3. Tilbakemelding

Tilbakemelding i XP implementeres i tre retninger samtidig:

tilbakemelding fra systemet under konstant testing av moduler
tilbakemelding fra kunden, pga han er en del av teamet og er med på å skrive akseptprøver
tilbakemelding fra teamet under planlegging angående utviklingstid.

4. Mot

Noen ekstreme programmeringsteknikker er så uvanlige at de krever mot og konstant selvkontroll.

5. Respekt

I Extreme Programming blir respekt sett på i form av respekt for teamet og selvrespekt. Teammedlemmer bør ikke laste opp endringer som vil ødelegge kompilering, enhetstester eller senke arbeidet til kolleger. Alle streber etter kode og design av høyeste kvalitet.

Algoritme for implementering av XP-metodikk og arbeidsprosess

Beck Kent anbefaler å implementere XP for å løse problemer i et prosjekt. Teamet velger det mest presserende problemet og løser det ved hjelp av en av Ekstrem programmeringspraksis. Går så videre til neste problem med mer øvelse. Med denne tilnærmingen fungerer problemer som motivasjon for bruk av XP og teamet mestrer gradvis alle verktøyene i metodikken.

For å implementere XP i et eksisterende prosjekt, må du gradvis mestre teknikkene på følgende områder:

testing
design
planlegger
ledelse
utvikling

Testing.

Teamet lager tester FØR de skriver ny kode og omarbeider gradvis gammel kode. For gammel kode skrives tester etter behov: når du trenger å legge til ny funksjonalitet, fikse en feil eller omarbeide deler av den gamle koden.

Design.

Teamet refaktorerer gradvis gammel kode, vanligvis før de legger til ny funksjonalitet. Som med testing, refaktorisering av gammel kode gjøres bare når det er nødvendig. Samtidig bør teamet formulere langsiktige mål for kodeomarbeiding og gradvis nå dem.

Planlegger.

Teamet må gå over til tett samhandling med kunden. På dette stadiet er det viktig å formidle til ham fordelene ved å jobbe i samme team med utviklere og integrere ham i teamet.

Ledelse.

Rollen til ledere under overgangen til XP er å sikre at alle teammedlemmer jobber i henhold til de nye reglene. Prosjektlederen bestemmer når han skal skilles fra et teammedlem som ikke takler arbeidet i det nye miljøet, eller for å finne et nytt og integrere ham ordentlig i arbeidet.

Utvikling.

Transformasjoner i utvikling begynner med organisering av arbeidsstasjoner for programmering i par. Den neste utfordringen er å programmere i par mesteparten av tiden, uansett hvor vanskelig det kan være for utviklere.

I et prosjekt som jobber etter XP-metodikken er prosessen strukturert som følger:

Hvem bruker XP

I følge en studie fra 2016 av Versionone, bruker bare 1 % av smidige selskaper ekstrem programmering i sin rene form. Ytterligere 10 % jobber med en hybrid scrum og XP-metodikk.

Interessant nok, selv om XP er langt fra den vanligste metoden i sin rene form, brukes dens praksis av flertallet av selskaper som jobber med smidige metoder. Dette er bevist av data fra samme studie:

Det er ikke lett å finne informasjon om team som bruker XP, men det er de som annonserer at denne metodikken er årsaken til suksessen. Et eksempel på ekstrem programmering er Pivotal Software, Inc.

Pivotal Software, Inc.

Et amerikansk programvareselskap som utvikler programvare for forretningsanalyse basert på big data og leverer konsulenttjenester. Pivotal-produkter brukes av Ford, Mercedes, BMW, GAP, Humana, store banker, offentlige etater, forsikringsselskaper, etc.

Pivotal er en talsmann for smidige metoder som de eneste mulige i moderne utvikling. Av alle alternativene for fleksible metoder, valgte selskapet XP som en vinn-vinn-tilnærming for kunder og programmeringsteam. Hver arbeidsdag begynner med et møte på farten, og avsluttes nøyaktig klokken 18:00 – ingen overtid. Pivotal bruker spillplanlegging, parprogrammering, kontinuerlig testing, kontinuerlig integrasjon og annen XP-praksis. For mange praksiser har de sin egen programvare.

Ekstrem programmering,
Ekstrem programmering: Planlegging,
Ekstrem programmering: Testdrevet utvikling / Kent Beck

Om ekstrem programmering fra skaperen av metodikken, Kent Beck. Start med den første, som beskriver XP-konseptet med eksempler og begrunner fordelene. Senere publiserte forfatteren flere bøker, hvor han i detalj beskrev individuelle XP-praksiser.

Refaktorering: Forbedring av eksisterende kode / Martin Fowler

Ekstrem programmering: prosessformulering. Fra de første skritt til den bitre slutten / Ken Auer, Roy Miller

Siden Extreme Programming streber etter ren og lett vedlikeholdbar kode, inkluderer listen over bøker alle publikasjoner som lærer deg hvordan du programmerer bedre.

Applikasjoner for implementering av XP i et team

Team som jobber med prosjekter som bruker XP-metoden, bruker oppgavebehandlere og tjenester for smidige prosjekter. Det finnes mange slike produkter på markedet, vi skal se på noen få eksempler.

Gratis og åpen kildekode oppgavebehandling. Hovedfunksjoner: jobbe med flere prosjekter samtidig, fleksibelt oppgavestyringssystem, Gantt-diagram, tidskontroll, jobbe med dokumentasjon, lage oppgaver via e-post, etc.

En enkel, praktisk tjeneste for å samarbeide om prosjekter. Inkluderer en oppgavebehandling, oppslagstavle, innebygd chat, fillagring, kalender

Jira

En kraftig tjeneste designet spesielt for utviklere av smidige prosjekter. Kombinerer en feilsporer og en prosjektstyringstjeneste. Mange funksjoner pluss synkronisering med andre tjenester. Løsninger for team av forskjellige størrelser.

Å jobbe med prosjekter. Lar deg sette oppgaver og kontrollere utførelsesprosessen, korrespondere med hverandre på en oppgave, sette opp filtre, ta hensyn til tidsbruk og økonomi og arbeide med filer.

Kjennelse

Ekstrem programmering er en fleksibel metodikk som fokuserer på høykvalitets, brukbar kode med en enkel arkitektur. Formålet er å redusere usikkerhetsnivået i prosjekter og virkelig reagere fleksibelt på endringer i produktkrav.

Denne metodikken er utelukkende ment for feltet programvare utvikling og kan ikke tilpasses for annen virksomhet.

Dette er en av de vanskeligste metodene å implementere fordi den inkluderer så mange som tretten praksiser!

Få selskaper risikerer å jobbe med ren XP, men utviklingspraksisen er den mest populære i smidige prosjekter. Og dette er et sterkt argument for deres effektivitet.

Ingen tvinger deg til å implementere XP på alt-eller-ingenting-basis. Til syvende og sist må smidige metoder være fleksible i sin anvendelse - skreddersydd til behovene til et spesifikt team og prosjekt.

Utvikling (utvikling drevet av systemfunksjoner) etc.

Live planleggingsspill
Dens oppgave er å finne ut så raskt som mulig hvor mye arbeid som må gjøres før neste programvareversjon. Beslutningen tas først og fremst basert på kundens prioriteringer (dvs. hans behov, hva han trenger fra systemet for å drive virksomheten mer vellykket) og for det andre på grunnlag av tekniske vurderinger (dvs. estimater av kompleksiteten) utvikling, kompatibilitet med andre elementer i systemet, etc.). Planer endres så snart de begynner å avvike fra virkeligheten eller kundens ønsker.
Hyppige versjonsendringer (små utgivelser)
Den aller første fungerende versjonen skal vises så raskt som mulig og bør umiddelbart begynne å brukes. Etterfølgende versjoner utarbeides med ganske korte intervaller (fra flere timer for små endringer i et lite program, til en måned eller to for en større omarbeiding av et stort system).
Metafor for systemet
Metaforen, i en ganske enkel og forståelig form for teamet, skal beskrive den grunnleggende mekanismen til systemet. Dette konseptet minner om arkitektur, men skal beskrive hovedessensen av de tekniske beslutningene som er tatt mye enklere, i bare en eller to fraser.
Enkle designløsninger
Til enhver tid bør systemet utformes så enkelt som mulig. Det er ikke nødvendig å legge til funksjoner på forhånd - bare etter en eksplisitt forespørsel om det. All unødvendig kompleksitet fjernes så snart den oppdages.
Testdrevet utvikling
Utviklere skriver først tester, og prøver deretter å implementere modulene sine slik at testene fungerer. Kunder skriver tester på forhånd som demonstrerer hovedfunksjonene til systemet slik at de kan se at systemet faktisk fungerer.
Kontinuerlig refaktorering
Programmerere omarbeider hele tiden systemet for å eliminere unødvendig kompleksitet, øke forståelsen av koden, øke fleksibiliteten, men uten å endre oppførselen, som verifiseres ved å kjøre etter hver omarbeiding av testene. Samtidig foretrekkes mer elegante og fleksible løsninger, sammenlignet med de som rett og slett gir ønsket resultat. Ulykket redesignede komponenter bør identifiseres under testutførelse og rulles tilbake til den siste intakte tilstanden (sammen med komponentene som er avhengige av dem).
Parprogrammering
Koding utføres av to programmerere på én datamaskin. Sammenkobling er vilkårlig og varierer fra oppgave til oppgave. Den i hvis hender tastaturet prøver å løse det aktuelle problemet på beste måte. Den andre programmereren analyserer arbeidet til den første og gir råd, vurderer konsekvensene av visse beslutninger, nye tester, mindre direkte, men mer fleksible løsninger.
Kollektivt eierskap til kode
Ethvert teammedlem kan når som helst endre hvilken som helst del av koden. Ingen skal ha sitt eget ansvarsområde; hele teamet som helhet er ansvarlig for all koden.
Kontinuerlig integrering
Systemet settes sammen og gjennomgår integrasjonstesting så ofte som mulig, flere ganger om dagen, hver gang et par programmerere fullfører implementeringen av neste funksjon.
40 timers arbeidsuke
Å jobbe overtid blir sett på som et tegn på større problemer i prosjektet. Overtidsarbeid i 2 uker på rad er ikke tillatt - dette sliter ut programmerere og gjør arbeidet deres betydelig mindre produktivt.
Inkludere kunden i teamet (kunde på stedet)
Utviklingsteamet har alltid en kunderepresentant som er tilgjengelig gjennom hele arbeidsdagen og kan svare på alle spørsmål om systemet. Hans ansvar er å umiddelbart svare på spørsmål av enhver type angående funksjonene til systemet, dets grensesnitt, nødvendig ytelse, korrekt drift av systemet i vanskelige situasjoner, behovet for å opprettholde kommunikasjon med andre applikasjoner, etc.
Bruke kode som kommunikasjonsmiddel
Kode blir sett på som det viktigste kommunikasjonsmiddelet i et team. Kodeklarhet er en av hovedprioriteringene. Det er avgjørende å følge kodingsstandarder som gir denne klarheten. Slike standarder, i tillegg til kodeklarhet, bør sikre minimalt med språk (ingen duplisering av kode og informasjon) og bør aksepteres av alle teammedlemmer.
Åpent arbeidsområde
Teamet er plassert i ett ganske romslig rom for å lette kommunikasjonen og muliggjøre gruppediskusjoner ved planlegging og viktige tekniske beslutninger.
Endre reglene etter behov (bare regler)
Hvert teammedlem må godta reglene som er oppført, men hvis behovet oppstår, kan teamet endre dem hvis alle medlemmene er enige om denne endringen.

Fordelene med XP, hvis det kan implementeres, er større fleksibilitet, muligheten til å raskt og nøyaktig gjøre endringer i programvaren som svar på endrede krav og individuelle kundeønsker, høy kvalitet på den resulterende koden, og fraværet av behovet for å overbevise kundene om at resultatet oppfyller deres forventninger.

XP som et sett med beskrevne teknikker ble først brukt under arbeidet med C3-prosjektet (Chrysler Comprehensive Compensation System, utvikling av et system for regnskapsføring av ansattes fordeler hos Daimler Chrysler). Av de 20 deltakerne i dette prosjektet publiserte 5 (inkludert de ovennevnte 3 hovedforfatterne av XP) 3 bøker og et stort antall artikler viet til XP under selve prosjektet og senere. Dette prosjektet er gjentatte ganger nevnt i ulike kilder som et eksempel på bruken av denne teknikken. Følgende data er samlet fra de nevnte artiklene, minus anekdotisk bevis, og illustrerer problemene med noen XP-teknikker når de brukes på ganske komplekse prosjekter.

Extreme Programming (XP) er en av de fleksible programvareutviklingsmetodene. Forfatterne av metodikken er Kent Beck, Ward Cunningham, Martin Fowler og andre.

Planleggingsspill

Vår verden er for foranderlig og uforutsigbar til å stole på situasjonens konstanthet. Det samme skjer i programvareutvikling: med et sjeldent system kan du si at den endelige formen var kjent på forhånd i detalj helt i begynnelsen av utviklingen. Vanligvis kommer kundens appetitt mens han spiser: han ønsker hele tiden å endre noe, forbedre noe eller kaste noe helt ut av systemet. Dette er variasjonen av krav som alle er så redde for. Heldigvis får en person muligheten til å forutsi mulige alternativer og dermed holde situasjonen under kontroll.
I Extreme Programming er planlegging en integrert del av utviklingen og det tas hensyn til at planer kan endres helt fra starten. Omdreiningspunktet, teknikken som lar deg forutse situasjonen og smertefritt tåle endringer, er planleggingsspillet. Under et slikt spill kan kjente systemkrav raskt samles inn, vurderes og planlegges etter prioritet.
Som alle andre spill har planlegging sine deltakere og sitt mål. Nøkkeltallet er selvfølgelig kunden. Det er han som kommuniserer behovet for denne eller den funksjonaliteten. Programmerere gir en omtrentlig vurdering av hver funksjonalitet. Skjønnheten i planleggingsspillet ligger i enheten av formål og solidaritet mellom utvikleren og kunden: i tilfelle seier vinner alle, i tilfelle tap taper alle. Men samtidig går hver deltaker sin egen vei til seier: kunden velger de viktigste oppgavene i samsvar med budsjettet, og programmereren evaluerer oppgavene i samsvar med hans evne til å implementere dem.
Ekstrem programmering forutsetter at utviklere er i stand til å bestemme selv hvor lang tid det vil ta dem å fullføre oppgavene sine, og hvem av dem som vil være mer villige til å løse ett problem og hvem et annet.
I en ideell situasjon bør planleggingsspillet mellom kunden og programmereren spilles hver 3.-6. uke, inntil neste utviklingsiterasjon starter. Dette gjør det ganske enkelt å gjøre justeringer basert på suksesser og fiaskoer fra forrige iterasjon.

Utgivelsesplan

Utgivelsesplanen definerer utgivelsesdatoer og brukeruttalelser som skal implementeres i hver av dem. Basert på dette kan du velge formuleringer for neste iterasjon. Under en iterasjon produseres og kjøres aksepttester innenfor den iterasjonen og alle påfølgende for å sikre at programmet fungerer som det skal. Planen kan revideres hvis det er et betydelig etterslep eller forsprang på slutten av en av iterasjonene.
Iterasjoner. Iterasjon gjør utviklingsprosessen dynamisk. Det er ikke nødvendig å planlegge programvareoppgavene dine lenge i forveien. I stedet er det bedre å ha et planleggingsmøte i begynnelsen av hver iterasjon. Det nytter ikke å prøve å gjennomføre noe som ikke var planlagt. Du vil fortsatt ha tid til å implementere disse ideene når de er utgitt i henhold til utgivelsesplanen.
Ved å bli vane med å ikke legge til funksjonalitet på forhånd og bruke fremtidsplanlegging, kan du enkelt tilpasse deg endrede kundekrav.

Iterasjonsplanlegging

Iterasjonsplanlegging begynner med et møte i begynnelsen av hver iterasjon for å utvikle en plan med trinn for å løse programvareproblemer. Hver iterasjon bør vare fra én til tre uker. Formuleringer innenfor en iterasjon er sortert i rekkefølge etter deres betydning for kunden. I tillegg kommer oppgaver som ikke klarte akseptanseprøvene og krever videre arbeid. Testerklæringer og resultater blir oversatt til programvareproblemer. Oppgaver skrives ned på kort som danner en detaljert iterasjonsplan. Det tar fra én til tre dager å løse hvert problem. Oppgaver som krever mindre enn én dag kan grupperes sammen, og store oppgaver kan deles inn i flere mindre. Utviklere estimerer oppgaver og tidsfrister for gjennomføringen. Det er svært viktig for en utvikler å nøyaktig bestemme utførelsestiden for en oppgave. Det kan være nødvendig å revurdere noe språk og revidere utgivelsesplanen etter hver tredje eller femte iterasjon - dette er helt akseptabelt. Hvis du implementerer de viktigste arbeidsområdene først, vil du alltid ha tid til å gjøre maksimalt mulig for kundene dine. En iterativ utviklingsstil forbedrer utviklingsprosessen.

Møte stående

Hver morgen holdes et møte for å diskutere problemer, deres løsninger og for å styrke teamets konsentrasjon. Møtet holdes stående for å unngå lange diskusjoner som ikke er interessante for alle teammedlemmer.
I et typisk møte bidrar de fleste deltakerne med ingenting, bare delta for å høre hva andre har å si. En stor mengde menneskers tid er bortkastet for å motta en liten mengde kommunikasjon. Det å ha alle i møter tar derfor ressurser fra prosjektet og skaper kaos i planleggingen.
Denne typen kommunikasjon krever et stående møte. Det er mye bedre å ha ett kort, obligatorisk møte enn mange lange som de fleste utviklere uansett må delta på.
Hvis du har daglige stående møter, bør alle andre møter kun delta av de personene som er nødvendige og vil bringe noe til bordet. Dessuten er det til og med mulig å unngå noen møter. Med begrensede deltakere kan de fleste møter holdes spontant foran en monitor, hvor utvekslingen av ideer er mye mer intens.
Det daglige morgenmøtet er ikke enda et sløsing med tid. Det vil tillate deg å unngå mange andre møter og spare deg for mer tid enn du bruker på det.

Enkelhet

En enkel design tar alltid kortere tid enn en kompleks. Så gjør alltid de enkleste tingene som vil fungere. Det er alltid raskere og billigere å erstatte kompleks kode med en gang, før du bruker mye tid på å jobbe med det. Hold ting så enkelt som mulig uten å legge til funksjonalitet før planlagt. Husk: å holde et design enkelt er hardt arbeid.

Metaforsystem

Valget av et metaforsystem er nødvendig for å holde teamet innenfor samme ramme ved navngivning av klasser og metoder. Hvordan du navngir objektene dine er veldig viktig for å forstå den generelle systemdesignen og gjenbruk av kode. Hvis en utvikler er i stand til å forutsi riktig hva et eksisterende objekt kan kalles, fører dette til tidsbesparelser. Bruk et navnesystem for objektene dine som alle kan forstå uten spesifikk systemkunnskap.

Kunde på arbeidsstedet

Hovedproblemet i programvareutvikling er mangelen på kunnskap hos programmerere innen fagområdet som utvikles. Ekstrem programmering har funnet en vei ut av denne situasjonen. Nei, dette er ikke et utviklerpraksis hos kundens bedrift - da vil han ikke programmere. Tvert imot er det kundens deltakelse i utviklingsprosessen.
Kan en programmerer, uten å forstå essensen av problemet og ikke være en telepat, gjette hva kunden ønsker? Svaret er åpenbart. Den enkleste måten å overvinne denne ulempen - og Extreme Programming lærer oss å finne de enkleste løsningene - er å stille kunden et direkte spørsmål. Mer strenge tilnærminger krever en omfattende foreløpig analyse av området som utvikles. I visse tilfeller er dette berettiget, selv om det er dyrere. Ekte erfaring med å drive hverdagslige prosjekter viser at det er umulig å samle alle kravene på forhånd. Dessuten, selv om vi antar at alle kravene for øyeblikket er samlet, vil det fortsatt være en flaskehals: programmer, som alt i naturen, opprettes ikke umiddelbart, og i mellomtiden kan forretningsprosesser endres. Dette bør tas i betraktning.
Mange tviler på muligheten for å involvere kunden i utviklingsprosessen. Faktisk er kunder forskjellige. Hvis det ikke er mulig å tiltrekke seg kunden eller hans representant, er det noen ganger tilrådelig å midlertidig ansette en spesialist på feltet som utvikles. Dette trinnet vil redusere uklarheter i arbeidet, øke hastigheten på utviklingen og bringe prosjektet nærmere det kunden ønsker å motta. Dette kan også være gunstig fra den økonomiske siden: tross alt er lønnen til en programmerer noen ganger betydelig høyere enn lønnen til spesialister i andre bransjer.
Brukerhistorie. User Story (noe som en brukers historie) er en beskrivelse av hvordan systemet skal fungere. Hver brukerhistorie er skrevet på et kort og representerer et stykke systemfunksjonalitet som gir logisk mening fra kundens synspunkt. Skjemaet er ett eller to avsnitt med tekst som er forståelig for brukeren (ikke særlig teknisk).
User Story er skrevet av kunden. Disse ligner på systembrukstilfeller, men er ikke begrenset til brukergrensesnittet. For hver historie skrives det funksjonstester for å bekrefte at denne historien er implementert riktig – de kalles også aksepttester.

Testing før utviklingen starter

Testing, i sin klassiske forstand, er en ganske kjedelig prosedyre. Vanligvis ansetter de en tester som med jevne mellomrom utfører de samme handlingene og venter på dagen da han endelig blir overført til en annen stilling eller muligheten til å bytte jobb oppstår.
I ekstrem programmering er testens rolle mer interessant: nå kommer testen først, og deretter koden. Hvordan teste noe som ikke eksisterer ennå? Svaret er enkelt og banalt: test tankene dine - hva du kan forvente av et fremtidig program eller funksjonalitet. Dette vil tillate deg å bedre forstå hva programmerere trenger å gjøre og sjekke funksjonaliteten til koden så snart den er skrevet.
Men testen fungerer kanskje heller ikke. Så hva, skrive en test for en test? Og så teste for test og så videre i det uendelige? Ikke i det hele tatt. Testen for testen vil erstatte koden. Hvordan det? Men se: forestill deg at du må fikse mutteren i midten av bolten slik at den ikke snur seg. Hva gjør de for dette? Skru den andre mutteren inntil den første, slik at hver mutter hindrer den tilstøtende i å dreie. Det er det samme i programmering: testen tester koden, og koden tester testen.
Erfaring viser at denne tilnærmingen ikke bare bremser ned, men også fremskynder utviklingen. Tross alt vil det å vite hva som må gjøres og den nødvendige mengden arbeid spare tid ved å nekte å selge deler som for øyeblikket ikke er etterspurt.

Parprogrammering

All kode for produksjonssystemet skrives i par. To utviklere sitter ved siden av hverandre. Den ene skriver, den andre ser på. De endrer seg fra tid til annen. Det er ikke lov å jobbe alene. Hvis den andre av paret av en eller annen grunn savnet noe (syk, pensjonert, etc.), er han forpliktet til å gjennomgå alle endringene som er gjort av den første.
Det høres uvanlig ut, men etter en kort periode med tilpasning fungerer de fleste godt i par. De liker det til og med fordi arbeidet blir gjort merkbart raskere. Prinsippet "Ett hode er bra, men to er bedre" gjelder. Par finner vanligvis bedre løsninger. I tillegg øker kvaliteten på koden betydelig, antall feil reduseres, og utvekslingen av kunnskap mellom utviklere akselereres. Mens en person fokuserer på den strategiske visjonen til objektet, implementerer den andre dets egenskaper og metoder.

Endre posisjoner

I løpet av neste iterasjon skal alle arbeidere flyttes til nye arbeidsområder. Slike bevegelser er nødvendige for å unngå kunnskapsisolasjon og eliminere flaskehalser. Spesielt fruktbart er det å erstatte en av utviklerne innen parprogrammering.

Kollektiv kodeeierskap

Delt kodeeierskap oppfordrer utviklere til å sende inn ideer for alle deler av prosjektet, ikke bare sine egne moduler. Enhver utvikler kan endre hvilken som helst kode for å utvide funksjonaliteten og fikse feil.
Ved første øyekast ser det ut som kaos. Men tatt i betraktning at i det minste hvilken som helst kode er laget av et par utviklere, at tester lar deg sjekke riktigheten av endringene som er gjort, og at du i det virkelige liv fortsatt må forstå andres kode på en eller annen måte, blir tydelig at kollektivt eierskap til koden gjør det mye enklere å gjøre endringer og reduserer risikoen knyttet til høy spesialisering hos et eller annet teammedlem.

Kodekonvensjon

Du er en del av et team som har jobbet med dette prosjektet i lang tid. Folk kommer og går. Ingen koder alene og koden tilhører alle. Det vil alltid være tider når du trenger å forstå og justere andres kode. Utviklere vil fjerne eller endre duplikatkode, analysere og forbedre andres klasser osv. Over tid vil det være umulig å si hvem forfatteren av en bestemt klasse er.
Derfor må alle følge vanlige kodestandarder - kodeformatering, navngivning av klasser, variabler, konstanter, kommentarstil. På denne måten vil vi være sikre på at når vi gjør endringer i andres kode (som er nødvendig for aggressiv og ekstrem fremgang fremover), vil vi ikke gjøre den om til Babel Pandemonium.
Ovennevnte betyr at alle teammedlemmer må bli enige om felles kodestandarder. Det spiller ingen rolle hvilke. Regelen er at alle adlyder dem. De som ikke ønsker å rette seg etter dem forlater laget.

Hyppig integrasjon

Utviklere bør integrere og frigi koden med noen få timers mellomrom hvis mulig. I alle fall bør du aldri beholde endringer i mer enn én dag. Hyppig integrasjon unngår fremmedgjøring og fragmentering i utviklingen, der utviklere ikke kan kommunisere i betydningen å dele ideer eller gjenbruke kode. Alle bør kjøre den nyeste versjonen.
Hvert par utviklere bør bidra med sin kode så snart det er rimelig mulig å gjøre det. Dette kan være når alle UnitTests består 100 %. Ved å sende inn endringer flere ganger om dagen reduserer du integrasjonsproblemer til nesten null. Integrering er en "betal nå eller betal mer senere"-aktivitet. Derfor, ved å integrere endringer i små trinn hver dag, vil du ikke finne deg selv å måtte bruke en uke på å prøve å binde sammen systemet rett før prosjektet leveres. Arbeid alltid med siste versjon av systemet.

Førti timers arbeidsuke

En person, spesielt hvis han er programmerer, er i stand til å gjøre mye for virksomhetens skyld: å være sent på jobb, gå på jobb i helgene, gi opp ferie, holde seg våken i flere dager mens han sitter ved tastaturet ... Generelt, hva kan du gjøre for din favorittaktivitet. Men ekstrem programmering er kategorisk mot slik selvoppofrelse og brudd på aksepterte arbeidsrettslige standarder.
Dette er ikke bare diktert av hensynet til lovlighet og menneskelighet, men først og fremst av behovet for å øke arbeidseffektiviteten og streng organisering. Tross alt er ekstrem programmering et kollektivt spill, designet ikke for enkeltpersoner, men for hele gruppen. Og noe slikt som for eksempel parprogrammering er bare mulig når biorytmene til deltakerne er synkronisert. Og det er umulig hvis en person kommer på jobb klokken ni, og den andre klokken tolv, eller en bestemmer seg for at det er bedre for ham å jobbe på lørdag og søndag, mens den andre er ubeleilig.
Men det viktigste er at for å opprettholde helse og ytelse, trenger en person riktig hvile. Åtte timers arbeidsdag og fem dagers arbeidsuke er etablert nettopp av hensyn til maksimal produktivitet. I mange vestlige selskaper blir det å forlate jobben for sent sett på som manglende ytelse eller manglende evne til å styre arbeidstiden på riktig måte. I de fleste tilfeller er dette sant. Og fra et medisinsk synspunkt fører forsinkelser på jobben til konstant tretthet, irritabilitet og redusert hjerneaktivitet. Er dette effektivt? Hvordan kan vi organisere konstant åpen kommunikasjon mellom utviklere i et slikt team, og vil parprogrammering være mulig? Svaret er negativt. Standarder er standarder og bør følges.

Konklusjon

Disse metodene er ikke satt sammen ved en tilfeldighet. Deres konsistente kombinasjon kan bringe utviklingsprosessen inn i intellektuell resonans, øke kvaliteten på produktet betydelig og fremskynde utgivelsestiden. Det viktigste med all ekstrem programmering er forutsigbarhet og minimering av utviklingskostnader; å gi kunden produktet han ønsker å motta på utgivelsestidspunktet; og selvfølgelig kommunikasjon og opplæring av utviklere på jobben.

Bibliografi:

De grunnleggende prinsippene for utvikling av live programvare er nedfelt i live-utviklingsmanifestet, som dukket opp i 2000.

· Menneskene som er involvert i et prosjekt og deres kommunikasjon er viktigere enn prosesser og verktøy.
· Et arbeidsprogram er viktigere enn omfattende dokumentasjon.
· Samarbeid med kunden er viktigere enn å diskutere detaljene i kontrakten.
· Å jobbe gjennom endringer er viktigere enn å holde seg til planer.

XP har imidlertid sitt eget utviklingsprosessdiagram (selv om, generelt sett, den mye brukte forståelsen av "utviklingsprosessen" som et ganske rigid handlingsplan motsier selve ideen om "livlig" utvikling), vist i fig. 1 .

· Bo planlegger spill)

Figur 1

· Hyppig endring versjoner (små utgivelser)

· Metafor for systemet

Metaforen, i en ganske enkel og forståelig form for teamet, skal beskrive den grunnleggende mekanismen til systemet. Dette konseptet minner om arkitektur, men skal beskrive hovedessensen av de tekniske beslutningene som er tatt mye enklere, i bare en eller to fraser.

Arkitektur er en idé om komponentene i et system og hvordan de henger sammen. Utviklere bruker arkitektur for å forstå hvor ny funksjonalitet legges til systemet, og hva en ny komponent vil samhandle med.

Systemmetaforen er en analog av det som kalles arkitektur i de fleste teknikker. Systemmetaforen gir teamet en følelse av hvordan systemet fungerer, hvor nye komponenter legges til, og hvilken form de bør ha.

· Enkel design løsninger (enkle design)

Til enhver tid bør systemet utformes så enkelt som mulig. Det er ikke nødvendig å legge til funksjoner på forhånd - bare etter en eksplisitt forespørsel om det. All unødvendig kompleksitet fjernes så snart den oppdages.

· Utvikling på basis testing (testdrevet utvikling)

Utviklere skriver først tester, og prøver deretter å implementere modulene sine slik at testene fungerer. Kunder skriver tester på forhånd som demonstrerer hovedfunksjonene til systemet slik at de kan se at systemet faktisk fungerer.

XP legger særlig vekt på to typer testing:

ь enhetstesting;

b akseptansetesting.

ekstrem programmeringsprogramvare

Aksepttester sikrer at systemet faktisk har de angitte egenskapene. I tillegg lar aksepttester deg verifisere riktig funksjon av produktet som utvikles.

· Konstant refaktorisering

· Programmering par programmering)

· Kollektiv besittelse kode (kollektiv eie)

· Konstant integrasjon (kontinuerlig integrering)

Systemet settes sammen og gjennomgår integrasjonstesting så ofte som mulig, flere ganger om dagen, hver gang et par programmerere fullfører implementeringen av neste funksjon.

· 40 timer arbeider en uke

· Inkludering kunde V team (på stedet kunde)

· Bruk kode Hvordan fasiliteter kommunikasjon

· Åpen arbeider plass (åpen arbeidsområde)

Teamet er plassert i ett ganske romslig rom for å lette kommunikasjonen og muliggjøre gruppediskusjoner ved planlegging og viktige tekniske beslutninger.

· Endring regler Av nødvendig (bare regler)

Hvert teammedlem må godta reglene som er oppført, men hvis behovet oppstår, kan teamet endre dem hvis alle medlemmene er enige om denne endringen.

Ekstrem programmering – Ekstrem programmering. Metoder for programvareutvikling

Send ditt gode arbeid i kunnskapsbasen er enkelt. Bruk skjemaet nedenfor

Introduksjon

Extreme Programming er en forenklet produksjonsmetodikk for små og mellomstore team av spesialister som utvikler et programvareprodukt under forhold med uklare eller raskt skiftende krav.

1. Hva er XP?

Extremamsengetøyprogrammroving(Engelsk) Ekstrem Programmering, XP) er en av de fleksible programvareutviklingsmetodene. Forfatterne av metodikken er Kent Beck, Ward Cunningham, Martin Fowler og andre.

XP er en forenklet, effektiv, fleksibel, forutsigbar, vitenskapsbasert og svært hyggelig måte å utvikle programvare på med lav risiko. HR skiller seg fra andre metoder på følgende måter:

Ved å bruke ekstremt korte utviklingssykluser, gir XP rask, ekte og kontinuerlig tilbakemelding.

XP bruker inkrementell planlegging, noe som resulterer i at en overordnet prosjektplan dukker opp ganske raskt, men det er forstått at denne planen utvikler seg gjennom hele prosjektets levetid.

XP bruker en fleksibel tidsplan for implementering av denne eller hin funksjonaliteten, noe som forbedrer responsen på virksomhetens endrede karakter og endrede kundekrav i forbindelse med dette.

XP er basert på automatiserte tester utviklet av både programmerere og kunder. Takket være disse testene er det mulig å overvåke utviklingsprosessen, sikre riktig utvikling av systemet og umiddelbart oppdage defekter som eksisterer i systemet.

XP er basert på muntlig kommunikasjon, tester og kildekode. Disse tre verktøyene brukes til å utveksle informasjon om et systems struktur og oppførsel.

XP er basert på en utviklende designprosess som fortsetter så lenge selve systemet eksisterer.

XP er basert på nært samspill mellom programmerere med de vanligste ferdighetene og egenskapene.

XP er basert på teknikker som tilfredsstiller både de kortsiktige instinktene til individuelle programmerere og de langsiktige interessene til hele prosjektet.

XP er en programvareutviklingsdisiplin. Dette er en disiplin fordi innenfor XP er det visse ting du må gjøre hvis du skal bruke XP. Du bør ikke velge om du vil skrive tester eller ikke, for hvis du ikke gjør det, er ikke programmeringen du gjør ekstrem.

XP-metodikken er utviklet for å jobbe med prosjekter som kan arbeides med av to til ti programmerere, som ikke er begrenset av de stive rammene til et eksisterende datamiljø, og der alt nødvendig testarbeid kan fullføres i løpet av en dag.

2. Hvor begynner ekstrem programmering?

Ekstrem programmering er ikke basert på spesifikke teknikker, slik man ofte tror, ​​men kun på fire grunnleggende prinsipper: kommunikasjon, enkelhet, tilbakemelding og mot. Det er her du må begynne.

Extreme Programming tilbyr en ferdig løsning: hold alt så enkelt som mulig, hold kunden for deg selv eller bli hos kunden, la ham aktivt overvåke utviklingsprosessen, velkommen endring – og suksess er nesten garantert.

3. XP-teknikker

De grunnleggende prinsippene for utvikling av live programvare er nedfelt i live-utviklingsmanifestet, som dukket opp i 2000.

· Menneskene som er involvert i et prosjekt og deres kommunikasjon er viktigere enn prosesser og verktøy.

· Et arbeidsprogram er viktigere enn omfattende dokumentasjon.

· Samarbeid med kunden er viktigere enn å diskutere detaljene i kontrakten.

· Å jobbe gjennom endringer er viktigere enn å holde seg til planer.

XP har imidlertid sitt eget utviklingsprosessdiagram (selv om, generelt sett, den mye brukte forståelsen av "utviklingsprosessen" som et ganske rigid handlingsplan motsier selve ideen om "livlig" utvikling), vist i fig. 1 .

· Boplanlegger (planleggerspill)

Ris.1 XP arbeidsflytdiagram

· HyppigendringVversjoner (litenutgivelser)

· Metafor (metafor) systemer

Metaforen, i en ganske enkel og forståelig form for teamet, skal beskrive den grunnleggende mekanismen til systemet. Dette konseptet minner om arkitektur, men skal beskrive hovedessensen av de tekniske beslutningene som er tatt mye enklere, i bare en eller to fraser.

Arkitektur er en idé om komponentene i et system og hvordan de henger sammen. Utviklere bruker arkitektur for å forstå hvor ny funksjonalitet legges til systemet, og hva en ny komponent vil samhandle med.

Systemmetaforen er en analog av det som kalles arkitektur i de fleste teknikker. Systemmetaforen gir teamet en følelse av hvordan systemet fungerer, hvor nye komponenter legges til, og hvilken form de bør ha.

· Enkeldesignløsninger (enkeldesign)

Til enhver tid bør systemet utformes så enkelt som mulig. Det er ikke nødvendig å legge til funksjoner på forhånd - bare etter en eksplisitt forespørsel om det. All unødvendig kompleksitet fjernes så snart den oppdages.

· Utviklingpåbasistesting (test- drevetutvikling)

Utviklere skriver først tester, og prøver deretter å implementere modulene sine slik at testene fungerer. Kunder skriver tester på forhånd som demonstrerer hovedfunksjonene til systemet slik at de kan se at systemet faktisk fungerer.

XP legger særlig vekt på to typer testing:

ь enhetstesting;

b akseptansetesting.

3.1 Grunnleggende XP-teknikker

Tolv grunnleggende teknikker for ekstrem programmering (basert på den første utgaven av boken Ekstrem programmering forklart) kan kombineres i fire grupper:

· Kort tilbakemeldingssyklus (tilbakemelding i finskala)

o Testdrevet utvikling

o Planleggingsspill

o Kunden er alltid i nærheten (hele teamet, kunde på stedet)

o Parprogrammering

Kontinuerlig i stedet for batch prosess

o Kontinuerlig integrasjon

o Refaktorering (Design Improvement, Refactor)

o Hyppige små utgivelser

· Forståelse delt av alle

o Enkelhet (enkel design)

o Systemmetafor

o Kollektivt kodeeierskap eller utvalgte designmønstre (eierskap av kollektive mønstre)

o Kodestandard eller Kodekonvensjoner

· Programmerers velferd:

o 40-timers arbeidsuke (bærekraftig tempo, førti timers uke)

Et spillVplanlegger

Ekstrem programmering forutsetter at utviklere er i stand til å bestemme selv hvor lang tid det vil ta dem å fullføre oppgavene sine, og hvem av dem som vil være mer villige til å løse ett problem og hvem et annet.

I en ideell situasjon bør planleggingsspillet mellom kunden og programmereren spilles hver 3.-6. uke, inntil neste utviklingsiterasjon starter. Dette gjør det ganske enkelt å gjøre justeringer basert på suksesser og fiaskoer fra forrige iterasjon.

4. Fordeler og ulemper

5. Brukshistorie

Konklusjon

Lignende dokumenter

XP skiller seg fra andre smidige metoder ved at det gjelder bare innen programvareutvikling. Den kan ikke brukes i en annen virksomhet eller hverdag som scrum, kanban eller lean.

1. Hele laget

2. Planleggingslek

Planlegging i XP utføres i to trinn - utgivelsesplanlegging og iterasjonsplanlegging.

Iterasjonsplanlegging gjennomføres Hver andre uke, noen ganger mer eller sjeldnere. Kunden er alltid til stede: han bestemmer funksjonaliteten for neste iterasjon og gjør endringer i produktkravene.

3. Hyppige versjonsutgivelser

4. Brukertester

5. Kollektivt kodeeierskap

6. Kontinuerlig kodeintegrasjon

7. Kodestandarder

8. Systemmetafor

9. Jevnt tempo

10. Testdrevet utvikling

11. Parprogrammering

Ekstrem programmering er ikke basert på spesifikke teknikker, slik man ofte tror, men kun på fire grunnleggende prinsipper: kommunikasjon, enkelhet, tilbakemelding og mot. Det er her du må begynne.

Ekstrem programmering,
Ekstrem programmering: Planlegging,
Ekstrem programmering: Testdrevet utvikling / Kent Beck