Extreme Programming er en programvare utviklingen metodikk utviklet for å forbedre kvaliteten på programvaren og dens evne til riktig tilpasse seg de stadig skiftende behovene til kunden eller klienten. Under midten og slutten av nittitallet, mens du arbeider på Chrysler Omfattende Kompensasjon System (C3) for å hjelpe til med å administrere selskapets lønn, software engineer Ken Beck først utviklet Extreme Programming metodikk., I oktober 1999, publiserte han Extreme Programming Forklart, detaljering hele metode for andre, og kort tid etter den offisielle nettsiden ble lansert som godt.

Lik andre Smidige Metoder for utvikling, Extreme Programming har som mål å gi iterativ og hyppige små utgivelser gjennom hele prosjektet, slik at både medarbeidere og kunder til å undersøke og gjennomgå prosjektets fremdrift gjennom hele SDLC.,

i denne artikkelen vil vi undersøke nøyaktig hva som Extreme Programming er og hvordan det fungerer, fra de verdier og prinsipper som ligger bak det, regler og fremgangsmåter for beste praksis som er brukt til å implementere en ny Extreme Programming project, så la oss komme i gang!,/td>

Rational Unified Process Big Bang-Modellen V-Modellen Konseptuelle Modellen Kaizen Modell Kanban-Modellen Spiral Model

Ekstreme Verdier

Disse fem grunnleggende verdier som gir det grunnlaget som den helhet av Extreme Programming paradigme er bygget, slik at folk som er involvert i prosjektet til å føle seg trygg i retning prosjektet er å ta og å forstå deres personlige tilbakemeldinger og innsikt som er nødvendig og velkommen som alle andre.,

Enkelhet: Vi vil gjøre hva som er nødvendig og spurte etter, men ikke mer. Dette vil maksimere verdien som er skapt for de investeringer som er gjort hittil. Vi vil ta små enkle trinn for å målet vårt, og redusere feil som de skjer. Vi vil skape noe vi er stolte av og opprettholde det lang sikt for rimelige kostnader.

Kommunikasjon: Alle er en del av teamet, og vi kommuniserer ansikt til ansikt daglig. Vi vil jobbe sammen på alt fra krav til kode. Vi vil skape den beste løsningen på vårt problem at vi kan sammen.,

Tilbakemelding: Vi vil ta hver iterasjon engasjement på alvor ved å levere fungerende programvare. Vi viser vår programvare tidlig og så ofte du vil lytte nøye og gjøre eventuelle endringer som er nødvendig. Vi vil snakke om prosjektet og tilpasse prosessen til det, ikke den andre veien rundt.

Respekt: Alle gir og føles den respekten de fortjener som et verdsatt medlem av teamet. Alle bidrar verdi selv om det er bare entusiasme. Utviklere respektere kompetanse til kunder og vice versa. Ledelsen respekterer vår rett til å ta ansvar og få myndighet over vårt eget arbeid.,

Mot: Vi vil fortelle sannheten om utvikling og anslag. Vi trenger ikke dokumentet unnskyldninger for ikke fordi vi planlegger å lykkes. Vi trenger ikke frykte noe, fordi ingen har noensinne fungerer alene. Vi vil tilpasse seg endringene når de skjer.

Extreme Regler

Først publisert av Don Brønner i 1999, innehaver av Extreme Programming nettstedet, er dette sett av Extreme Programming Reglene var opprinnelig ment å bidra til å møte de krav som Extreme Programming unnlater å støtte noen av de fremste disipliner som er nødvendig for moderne utvikling.,

Planlegging

• Bruker historier er skrevet.
• Frigi planlegging skaper utgivelsesplan.
• Ta hyppige små utgivelser.
• prosjektet er delt inn i iterasjoner.
• Iterasjon planlegging starter hver iterasjon.

Administrere

• Gi laget en dedikert åpne arbeidsområdet.
• Angi en bærekraftig tempo.
• En stå-opp møtet starter hver dag.
• Prosjektet Hastighet er målt.
• Flytt folk rundt.
• Korriger Extreme Programming når det bryter.

Design

• Enkelhet.,
• Velg et system som metafor.
• Bruk CRC-kort for design økter.
• Opprett spike løsninger for å redusere risiko.
• Ingen funksjonalitet er lagt tidlig.
• Refactor når og hvor det er mulig.

Koding

• kunden er alltid tilgjengelig.
• – Koden må være skrevet til avtalt standarder.
• Code unit-test først.
• All produksjon koden er par programmert.
• Bare ett par integrerer koden på en gang.
• Integrere ofte.
• Sette opp en dedikert integrering datamaskinen.
• Bruk kollektivt eierskap.,

– Testing

• Alle-koden må ha unit tester.
• Alle-koden må bestå alle unit tester før det kan bli gitt ut.
• Når en feil er funnet testene er opprettet.
• Aksept tester kjøres ofte, og resultatet er publisert.

Extreme Praksis

Laget med hva som ble vurdert som beste praksis for programvare utviklingen på den tiden, disse tolv Extreme Programming Beste Praksis detalj hvilke rutiner som skal følges ved implementering av et prosjekt ved hjelp av Extreme Programming.,

Fin-skala tilbakemelding

Pair programming

I hovedsak, par programmering betyr at to personer som arbeider i tandem på det samme systemet når du utvikler noen produksjon kode. Ved hyppig roterende partnere over hele teamet, Extreme Programming fremmer bedre kommunikasjon og team-building.

Planlegging spillet

Ofte dette tar form av et møte på en hyppig og godt definerte intervall (hver en eller to uker), der flertallet av planlegging for prosjektet finner sted.,

Innenfor denne prosedyren finnes Utgivelsen planleggingsstadiet, hvor avgjørelsene er laget om hva som er nødvendig for kommende utgivelser. Deler av Utgivelsen Planlegging inkluderer:

• letefasen: Historie kort er brukt til detalj mest verdifulle krav fra kunder.
• Forpliktelse Fase: Planlegging og forpliktelser fra team er laget for å møte behovene til den neste planen slippe og få det ut på tid.,
• Kontroll Fase: Dette gjør det mulig for tidligere utviklet planer om å bli justert basert på behov for utvikling av prosjektet, i likhet med mange andre Smidig Modell metoder.

Etter Utgivelsen Planlegging er også Iterasjon Planlegging delen, som består av de samme tre sub-faser av sin egen, men med varianter på implementeringer:

• letefasen: Alle prosjektets krav er skrevet ned.
• Forpliktelse Fase: Nødvendige oppgaver ennå ikke er gjennomført for å møte den kommende utgaven utgivelsen er tilordnet til utviklere og planlagt måte.,
• Kontroll Fase: Utvikling finner sted, og ved ferdigstillelse, noe som resulterer iterasjon er i forhold til de som er skissert historie kort som er opprettet ved starten av Planleggingen prosedyre.

Test-drevet utvikling

Mens en hele artikkelen kan være skrevet om test-drevet utvikling, konseptet er ganske godt kjent blant utviklere, og betyr i realiteten at testene er generert for hver og alle krav av prosjektet, og bare da er kode som er utviklet som vellykket passere disse testene.,

Hele team

Som med mange andre SDLC metoder og praksis, Extreme Programming fremmer inkludering av kunder og klienter gjennom hele prosessen, med deres tilbakemeldinger for å bidra til å forme prosjektet til alle tider.

Kontinuerlig prosess

Kontinuerlig integrasjon

en Annen vanlig praksis i moderne utvikling, ideen bak kontinuerlig integrasjon er at all kode som er utviklet på tvers av hele teamet er slått sammen til en felles depot mange ganger om dagen., Dette sørger for at eventuelle problemer med integrasjon på tvers av hele prosjektet blir lagt merke til og behandles så snart som mulig.

– Koden refactoring

en Annen svært vanlig praksis, ideen bak koden refactoring er rett og slett for å forbedre og videreutvikle strukturen av allerede eksisterende kode, uten å endre sin grunnleggende atferd. Enkle eksempler på refactoring inkluderer fikse feil navn variabler eller metoder, og å redusere gjentatt kode ned til en enkelt metode eller funksjon.,

Små utgivelser

Veldig mye i tråd med praksis i Iterativ Modell, dette konseptet sikrer at prosjektet har iterated, små utgivelser på en hyppig basis, slik at kunden så godt som alle gruppens medlemmer, for å få en følelse av hvordan prosjektet utvikler seg.

Felles forståelse

Koding standarder

koding standard er rett og slett et sett av beste praksis innenfor selve koden, for eksempel formatering og stil, som hele teamet følger gjennom hele prosjektets livssyklus., Dette fremmer bedre forståelse og lesbarhet av code-ikke bare for medlemmene, men for fremtidige utviklere så vel.

Kollektiv kode eierskap

Denne praksis gjør for enhver utvikler hele teamet for å endre noen del av koden som er nødvendig. Mens denne praksisen kan høres farlig for noen, det hastigheter opp utviklingen tid, og noen potensielle problemer som kan være kvalte med riktig unit testing.

Enkel design

Det er liten grunn til å komplisere ting når et enklere alternativ er tilgjengelig., Denne grunnleggende praksis av å holde alle komponenter og kode så enkelt som kan være sikrer at hele teamet er alltid vurdere om ting kunne gjøres på en enklere måte.

System metafor

Best tenkt på som en del av koding standarder, systemet metafor er ideen om at hver person på laget skal være i stand til å se på høyt nivå koden som er utviklet, og har en klar forståelse av hvilken funksjonalitet som koden er utført.,

Programmerer velferd

Bærekraftig tempo

En viktig konsept for bedre balanse mellom jobb og fritid med utviklere på en Ekstrem Programmering prosjektet er forestillingen om at ingen må bli pålagt å arbeide i overkant av normal planlagt arbeid uke. Overtid er mislikt, som er det begrepet «crunch tid», hvor utviklere er forventet å arbeide ekstreme timer nær slutten av en slipper å få alt ferdig i tide.