Send dit gode arbejde i videnbasen er enkel. Brug formularen nedenfor

Studerende, kandidatstuderende, unge forskere, der bruger videnbasen i deres studier og arbejde, vil være dig meget taknemmelig.

Udgivet på http://www.allbest.ru/

Indhold

• Introduktion
• 1. Hvad er XP?
• 3.1 Grundlæggende teknikkerXP
• 4. Fordele og ulemper
• 5. Brugshistorie
• Konklusion

Introduktion

Extreme Programming, ofte forkortet XP, er en disciplin inden for softwareudvikling og softwarevirksomhed, der fokuserer begge parters (programmører og forretningsfolk) indsats på fælles, opnåelige mål. Hold, der bruger XP, producerer kvalitetssoftware i et meget hurtigt tempo. De teknikker, der udgør HR-disciplinen, er valgt, fordi de er baseret på menneskelig kreativitet og accepten af, at mennesker er vægelsindede og fejlbarlige skabninger.

XP præsenteres ofte som et sæt teknikker, men XP i sig selv er ikke målstregen. Der er ingen grund til at øve sig og udvikle HR bedre og bedre for at modtage den længe ventede guldstjerne i slutningen af ​​denne proces. Tværtimod er XP startlinjen. XP stiller spørgsmålet: "Hvor minimal kan vores indsats være, så vi kan fortsætte med at producere kvalitetssoftware?"

Extreme Programming er en forenklet produktionsmetodologi til små og mellemstore teams af specialister, der udvikler et softwareprodukt under forhold med uklare eller hurtigt skiftende krav.

1. Hvad er XP?

Extremamlinnedprogrammroving(Engelsk) Ekstrem Programmering, XP) er en af ​​de fleksible softwareudviklingsmetoder. Forfatterne til metoden er Kent Beck, Ward Cunningham, Martin Fowler m.fl.

XP er en forenklet, effektiv, fleksibel, forudsigelig, videnskabsbaseret og yderst underholdende måde at udvikle software på med lav risiko. HR adskiller sig fra andre metoder på følgende måder:

Ved at bruge ekstremt korte udviklingscyklusser giver XP hurtig, reel og løbende feedback.

XP bruger inkrementel planlægning, hvilket resulterer i, at en overordnet projektplan opstår ret hurtigt, men det er underforstået, at denne plan udvikler sig gennem hele projektets levetid.

XP anvender en fleksibel tidsplan for implementering af denne eller hin funktionalitet, hvilket forbedrer responsen på forretningens skiftende karakter og de skiftende kundekrav i forbindelse hermed.

XP er baseret på automatiserede test udviklet af både programmører og kunder. Takket være disse tests er det muligt at overvåge udviklingsprocessen, sikre den korrekte udvikling af systemet og omgående opdage defekter, der eksisterer i systemet.

XP er baseret på mundtlig kommunikation, test og kildekode. Disse tre værktøjer bruges til at udveksle information om et systems struktur og adfærd.

XP er baseret på en udviklende designproces, der fortsætter, så længe selve systemet eksisterer.

XP er baseret på tæt interaktion mellem programmører med de mest almindelige færdigheder og evner.

XP er baseret på teknikker, der både tilfredsstiller de enkelte programmørers kortsigtede instinkter og hele projektets langsigtede interesser.

XP er en softwareudviklingsdisciplin. Dette er en disciplin, fordi der inden for XP er visse ting, du skal gøre, hvis du skal bruge XP. Du skal ikke vælge, om du vil skrive test eller ej, for hvis du ikke gør det, er den programmering, du laver, ikke ekstrem.

XP-metoden er designet til at arbejde på projekter, der kan arbejdes på af to til ti programmører, som ikke er begrænset af de stive begrænsninger i et eksisterende computermiljø, og hvor alt det nødvendige testarbejde kan afsluttes inden for en dag.

2. Hvor begynder ekstrem programmering?

Hvor begynder ekstrem programmering? Ud fra den forståelse, at den typiske position for en indenlandsk softwareudvikler forpligter til at reducere udviklingsomkostningerne så meget som muligt. Og for dette er det nødvendigt at samarbejde intensivt med kunden, forstå hans interesser og i sidste ende gøre præcis, hvad han vil: hverken mere eller mindre.

Ekstrem programmering er ikke baseret på specifikke teknikker, som det er almindeligt antaget, men kun på fire grundlæggende principper: kommunikation, enkelhed, feedback og mod. Det er her du skal starte.

Extreme Programming tilbyder en færdig løsning: hold alt så enkelt som muligt, hold kunden for dig selv eller bliv hos kunden, lad ham aktivt overvåge udviklingsprocessen, byd forandring velkommen - og succes er næsten garanteret.

I XP-teams opmuntres kommunikation altid - den hurtigste måde at dele information og erfaringer på. Dette er meget vigtigt, når der kræves maksimal udviklingshastighed. Men kommunikation, som enhver anden nyttig bestræbelse, kræver konstant støtte. Derfor skal en fra holdet tage ansvar for at overvåge kommunikationen, blive en såkaldt diplomat. Kommunikation og behovet for at forklare dine handlinger til andre teammedlemmer tvinger dig til at gøre alt så enkelt som muligt. Hvis det ikke lykkes første gang, arbejder de på forenkling igen og igen, indtil hovedmålet er nået - maksimal forståelighed af koden for andre udviklere.

Lige meget hvad vi gør - at tråde en nål eller tage til fest - stræber vi altid efter at nå et eller andet mål. Hvis vi bemærker, at vi afviger fra det, tilpasser vi vores handlinger derefter. Forestil dig nu, hvor meget sværere det er at tråde en nål med lukkede øjne eller at klæde sig smukt uden spejl! Men når man udvikler programmer, er det ofte det, der sker: Vi gør noget, som vi ikke kan se resultatet af. Derfor er det i ekstrem programmering en regel at se resultatet af dine handlinger så hurtigt som muligt. Eller teknisk set at give feedback så hurtigt som muligt.

Ekstrem programmering spørger os: hvorfor ikke udvikle mod? Hun er trods alt meget vigtig i sit arbejde. Uden mod, er det muligt at tage ansvar for at udføre en opgave, og inden for en bestemt tidsramme? Uden mod, er det muligt at indse, at du er nået til en blindgyde, tage et skridt tilbage og lede efter en løsning? Og endelig, hvad vil gøre det muligt for udvikleren at indrømme sin fejl ved at vurdere opgaven og advare andre om det i tide, i stedet for først at præsentere dem for et fait accompli, når alle deadlines er udløbet? Fordelene ved mod er indlysende, og enhver succes, selv i den mindste opgave, kan udvikle dette mod.

3. XP-teknikker

Extreme Programming (XP) opstod som en evolutionær metode til bottom-up softwareudvikling. Denne tilgang er et eksempel på den såkaldte Agile Development Method. Gruppen af ​​“live” metoder omfatter, udover ekstrem programmering, metoderne SCRUM, DSDM (Dynamic Systems Development Method, en metode til udvikling af dynamiske systemer), Feature-Driven Development (udvikling drevet af systemfunktioner) mv.

De grundlæggende principper for live softwareudvikling er nedfældet i live-udviklingsmanifestet, som udkom i 2000.

· De involverede i et projekt og deres kommunikation er vigtigere end processer og værktøjer.

· Et arbejdsprogram er vigtigere end omfattende dokumentation.

· Samarbejde med kunden er vigtigere end at diskutere detaljerne i kontrakten.

· At arbejde gennem forandringer er vigtigere end at holde sig til planer.

"Levende" metoder dukkede op som en protest mod den overdrevne bureaukratisering af softwareudvikling, overfloden af ​​sidedokumenter, der ikke er nødvendige for at opnå det endelige resultat, som skal udarbejdes, når et projekt udføres i overensstemmelse med de fleste "tunge" processer , yderligere arbejde for at understøtte den faste proces i organisationen, som dette kræves inden for for eksempel CMM. De fleste af sådanne arbejde og dokumenter er ikke direkte relateret til softwareudvikling og kvalitetssikring, men er beregnet til at overholde de formelle klausuler i udviklingskontrakter, opnå og bekræfte certifikater for overholdelse af forskellige standarder.

"Live"-metoder gør det muligt for udviklere at fokusere det meste af deres indsats på udviklingsopgaver og opfylde reelle brugerbehov. Fraværet af bunker af dokumenter og behovet for at vedligeholde dem i en sammenhængende tilstand giver dig mulighed for at reagere hurtigere og mere effektivt på ændringer i krav og i det miljø, hvor det fremtidige program skal fungere.

XP har dog sit eget udviklingsprocesdiagram (selvom generelt set den meget anvendte forståelse af "udviklingsprocessen" som et ret rigidt handlingsskema modsiger selve ideen om "livlig" udvikling), vist i fig. .

Ifølge forfatterne af XP følger denne teknik ikke så meget nogle generelle handlingsmønstre som at bruge en kombination af følgende teknikker. Hver teknik er dog vigtig, og uden dens brug anses udvikling for ikke at være XP, ifølge Kent Beck, en af ​​forfatterne til denne tilgang sammen med Ward Cunningham og Ron Jeffries.

· Direkteplanlægning (planlægningspil)

Dens opgave er så hurtigt som muligt at bestemme mængden af ​​arbejde, der skal udføres før den næste softwareversion. Beslutningen træffes først og fremmest på baggrund af kundens prioriteter (dvs. hans behov, hvad han har brug for fra systemet for at drive sin virksomhed mere succesfuldt) og for det andet på baggrund af tekniske vurderinger (dvs. skøn over kompleksiteten) udvikling, kompatibilitet med andre elementer i systemet osv.). Planer ændres, så snart de begynder at afvige fra virkeligheden eller kundens ønsker.

Ris.1 XP Workflow Diagram

· Hyppiglave omVversioner (lilleudgivelser)

Den allerførste fungerende version bør dukke op så hurtigt som muligt og bør straks begynde at blive brugt. Efterfølgende versioner udarbejdes med ret korte intervaller (fra flere timer for små ændringer i et lille program, til en måned eller to for en større omarbejdning af et stort system). Versioner (udgivelser) af produktet bør frigives i brug så ofte som muligt. Hver version bør tage så lidt tid som muligt at færdiggøre. Desuden skal hver version være tilstrækkelig meningsfuld med hensyn til anvendelighed for erhvervslivet.

· Metafor (metafor) systemer

Metaforen skal i en ret enkel og forståelig form for teamet beskrive systemets grundlæggende mekanisme. Dette koncept minder om arkitektur, men skal beskrive hovedessensen af ​​de tekniske beslutninger, der er truffet meget mere enkelt, i blot en eller to sætninger.

Arkitektur er en idé om komponenterne i et system, og hvordan de er forbundet. Udviklere bruger arkitektur til at forstå, hvor nogle nye funktioner bliver tilføjet til systemet, og hvad en ny komponent vil interagere med.

Systemmetaforen er en analog til det, der kaldes arkitektur i de fleste teknikker. Systemmetaforen giver teamet en fornemmelse af, hvordan systemet fungerer i øjeblikket, hvor nye komponenter tilføjes, og hvilken form de skal have.

· Enkeldesignløsninger (enkeldesign)

Systemet bør til enhver tid udformes så enkelt som muligt. Der er ingen grund til at tilføje funktioner på forhånd - kun efter en eksplicit anmodning om det. Al unødvendig kompleksitet fjernes, så snart den opdages.

XP går ud fra, at under arbejdets gang kan betingelserne for problemet ændre sig gentagne gange, hvilket betyder, at produktet, der udvikles, ikke skal designes på forhånd i sin helhed. Hvis du forsøger at designe et system i detaljer fra start til slut, når du starter første gang, spilder du din tid. XP antager, at design er en så vigtig proces, at det skal ske løbende gennem hele projektet. Design skal udføres i små trin under hensyntagen til konstant skiftende krav. I hvert øjeblik forsøger vi at bruge det enkleste design, der er egnet til at løse det aktuelle problem. Samtidig ændrer vi det i takt med, at problemets betingelser ændrer sig.

· Udviklingpåbasisafprøvning (prøve- drevetudvikling)

Udviklere skriver først test, og forsøger derefter at implementere deres moduler, så testene fungerer. Kunder skriver på forhånd test, der demonstrerer systemets vigtigste muligheder, så de kan se, at systemet rent faktisk fungerer.

XP lægger særlig vægt på to typer test:

ь enhed prøvning;

b accepttest.

ekstrem programmeringssoftware

En udvikler kan ikke være sikker på rigtigheden af ​​den kode, han har skrevet, før absolut alle test af modulerne i det system, han er ved at udvikle, har fungeret. Enhedstest giver udviklere mulighed for at verificere, at deres kode fungerer korrekt. De hjælper også andre udviklere med at forstå, hvorfor et bestemt stykke kode er nødvendigt, og hvordan det fungerer. Enhedstest giver også udvikleren mulighed for at refaktorere uden nogen bekymringer.

Accepttest sikrer, at systemet rent faktisk har de angivne muligheder. Derudover giver accepttest dig mulighed for at verificere den korrekte funktion af det produkt, der udvikles.

For XP er en højere prioritet tilgangen kaldet TDD (Test Driven Development), først skrives en test, der ikke består, derefter skrives koden, så testen består, og først derefter refaktoreres koden.

· Konstantgenbrug (refaktorering)

Det er ingen hemmelighed, at tilføjelsen af ​​hver ny funktionalitet og kodevækst komplicerer udviklingen, identificerer fejl og foretager efterfølgende ændringer. Et af trickene ved Extreme Programming er at kompensere for tilføjelse af funktionalitet med kodeforbedringer. Dette er kodebehandling eller refactoring.

Programmører omarbejder hele tiden systemet for at eliminere unødvendig kompleksitet, øge kodens forståelighed, øge dens fleksibilitet, men uden at ændre dets adfærd, hvilket verificeres ved at køre efter hver omarbejdelse af testene. Samtidig foretrækkes mere elegante og fleksible løsninger, sammenlignet med dem, der blot giver det ønskede resultat. Forgæves redesignede komponenter skal identificeres under testudførelsen og rulles tilbage til den sidste intakte tilstand (sammen med de komponenter, der afhænger af dem).

Refactoring er en teknik til at forbedre kode uden at ændre dens funktionalitet. XP betyder, at når først kode er skrevet, vil den næsten helt sikkert blive omskrevet flere gange i løbet af et projekt. XP-udviklere omarbejder hensynsløst tidligere skrevet kode for at forbedre den. Denne proces kaldes refactoring. Manglen på testdækning fremkalder et afslag på refactoring på grund af frygten for at bryde systemet, hvilket fører til gradvis nedbrydning af koden.

· Programmeringi par (parprogrammering)

Erfarne udviklere har bemærket, at periodisk gennemgang af andres kode har en positiv effekt på kvaliteten. Mestrene i Extreme Programming har udviklet denne tilgang ved konstant at gennemgå kode under udvikling gennem en teknik kaldet parprogrammering.

Kodning udføres af to programmører på én computer. Parring er vilkårlig og varierer fra opgave til opgave. Den i hvis hænder tastaturet forsøger at løse det aktuelle problem på den bedste måde. Den anden programmør analyserer den førstes arbejde og giver råd, overvejer konsekvenserne af bestemte beslutninger, nye tests, mindre direkte, men mere fleksible løsninger. Om nødvendigt overføres tastaturet frit fra det ene til det andet. Mens du arbejder på et projekt, er parrene ikke faste: det anbefales at blande dem, så hver programmør på holdet har en god forståelse af hele systemet. På denne måde forbedrer parprogrammering samarbejdet i teamet.

· Kollektivebesiddelsekode (kollektiveejendomsret)

Kollektive besiddelse betyder, at hvert teammedlem er ansvarlig for al kildekode. Alle har således ret til at foretage ændringer i enhver del af programmet. Parprogrammering understøtter denne praksis: arbejder i forskellige par, bliver alle programmører fortrolige med alle dele af systemets kode. En vigtig fordel ved delt kodeejerskab er, at det fremskynder udviklingsprocessen, da hvis der opstår en fejl, kan enhver programmør rette den.

Ved at give enhver programmør ret til at ændre koden, risikerer vi, at fejl introduceres af programmører, der tror, ​​de ved, hvad de laver, men som ikke overvejer visse afhængigheder. Veldefinerede UNIT-tests løser dette problem: Hvis uundersøgte afhængigheder genererer fejl, vil den næste kørsel af UNIT-tests mislykkes.

· Konstantintegration (sammenhængendeintegration)

Systemet samles og gennemgår integrationstest så ofte som muligt, flere gange om dagen, hver gang et par programmører er færdige med at implementere den næste funktion.

Hvis du integrerer det system, du er ved at udvikle, ofte nok, kan du undgå de fleste problemer, der er forbundet med det. I traditionelle metoder udføres integration som regel i slutningen af ​​arbejdet med et produkt, når det vurderes, at alle komponenter i systemet, der udvikles, er helt klar. I XP udføres kodeintegration af hele systemet flere gange om dagen, efter at udviklerne er sikre på, at alle enhedstests affyrer korrekt.

På trods af sin enkelhed har denne teknik sine egne brugsregler, såsom succesen med de eksisterende enhedstests for den funktionalitet, der skal integreres, tilstedeværelsen af ​​funktionelle tests eller accepttests og, selvfølgelig, evnen til at rulle tilbage til en tidligere tilstand . Typisk udføres integration og løsning af tilhørende vanskeligheder på en separat computer af et par programmører. Dette giver dig mulighed for at minimere risikoen for uønskede konsekvenser af integration.

· 40 timerarbejderen uge

Overarbejde ses som et tegn på større problemer i projektet. Overarbejde i 2 uger i træk er ikke tilladt - dette udmatter programmører og gør deres arbejde væsentligt mindre produktivt.

En person, især hvis han er en programmør, er i stand til at gøre meget for forretningens skyld: at blive sent på arbejde, gå på arbejde i weekenden, opgive ferier, holde sig vågen i flere dage, mens han sidder ved tastaturet... Generelt, hvad kan du gøre for din yndlingsaktivitets skyld. Men ekstrem programmering er kategorisk imod sådan selvopofrelse og overtrædelse af accepterede arbejdsretlige standarder.

Dette er ikke kun dikteret af hensyn til lovlighed og menneskelighed, men først og fremmest af behovet for at øge arbejdseffektiviteten og stram organisering. Når alt kommer til alt, er ekstrem programmering et kollektivt spil, der ikke er designet til enkeltpersoner, men for hele gruppen. Og sådan en ting som for eksempel parprogrammering er kun mulig, når biorytmerne for dens deltagere er synkroniseret. Og det er umuligt, hvis én person kommer på arbejde klokken ni, og den anden klokken tolv, eller man beslutter, at det er bedre for ham at arbejde lørdag og søndag, mens den anden er ubelejlig.

Men det vigtigste er, at for at opretholde sundhed og ydeevne har en person brug for ordentlig hvile. otte timers arbejdsdag og fem dages arbejdsuge er fastsat netop af hensyn til maksimal produktivitet. I mange vestlige virksomheder betragtes det at forlade arbejdet sent som manglende præstationer eller manglende evne til at styre sin arbejdstid ordentligt. I de fleste tilfælde er dette sandt. Og fra et medicinsk synspunkt fører forsinkelser på arbejdet til konstant træthed, irritabilitet og nedsat hjerneaktivitet. Er dette effektivt? Hvordan kan vi organisere konstant åben kommunikation mellem udviklere i sådan et team, og vil parprogrammering være mulig? Svaret er negativt. Standarder er standarder og bør følges.

· InklusionkundeVhold (på- webstedkunde)

Hovedproblemet i softwareudvikling er programmørernes manglende viden om det fagområde, der udvikles. Ekstrem programmering har fundet en vej ud af denne situation. Nej, dette er ikke et udviklerpraktik hos kundens virksomhed - så vil han ikke programmere. Tværtimod er det kundens deltagelse i udviklingsprocessen.

Udviklingsteamet omfatter altid en kunderepræsentant, som står til rådighed hele arbejdsdagen og er i stand til at svare på alle spørgsmål om systemet. Hans ansvar er straks at besvare spørgsmål af enhver art vedrørende systemets funktioner, dets grænseflade, påkrævet ydeevne, korrekt drift af systemet i vanskelige situationer, behovet for at opretholde kommunikation med andre applikationer osv.

Mange tvivler på muligheden for at inddrage kunden i udviklingsprocessen. Faktisk er kunderne forskellige. Hvis det ikke er muligt at tiltrække kunden eller dennes repræsentant, er det nogle gange tilrådeligt at midlertidigt ansætte en specialist på det område, der udvikles. Dette trin vil mindske uklarheder i arbejdet, øge udviklingshastigheden og bringe projektet tættere på det, kunden ønsker at modtage. Dette kan også være fordelagtigt fra den økonomiske side: Når alt kommer til alt, er lønnen for en programmør nogle gange betydeligt højere end lønnen for specialister i andre brancher.

· BrugkodeHvordanfaciliteterkommunikation

Kode ses som det vigtigste kommunikationsmiddel i et team. Kodeklarhed er en af ​​hovedprioriteterne. Det er bydende nødvendigt at følge kodningsstandarder, der giver denne klarhed. Sådanne standarder bør udover kodeklarhed sikre minimalt sprogbrug (ingen duplikering af kode og information) og bør accepteres af alle teammedlemmer.

· Åbenarbejderplads (åbenarbejdsrum)

Holdet er anbragt i et ret rummeligt rum for at lette kommunikationen og muliggøre gruppediskussioner, når de planlægger og træffer vigtige tekniske beslutninger.

· Lave omreglerVednødvendighed (ligeregler)

Hvert teammedlem skal acceptere de anførte regler, men hvis behovet opstår, kan teamet ændre dem, hvis alle dets medlemmer er enige om denne ændring.

Som det kan ses af de anvendte teknikker, er XP designet til brug inden for små teams (ikke mere end 10 programmører), hvilket understreges af forfatterne af denne teknik. En større teamstørrelse ødelægger den lette kommunikation, der er nødvendig for succes, og gør det umuligt at implementere mange af de nævnte teknikker.

3.1 Grundlæggende XP-teknikker

Tolv grundlæggende teknikker til ekstrem programmering (baseret på den første udgave af bogen Ekstrem programmering forklaret) kan kombineres i fire grupper:

· Kort feedback-cyklus (feedback i fin skala)

o Testdrevet udvikling

o Planlægningsspil

o Kunden er altid i nærheden (hele teamet, onsite kunde)

o Parprogrammering

Kontinuerlig frem for batch proces

o Kontinuerlig integration

o Refaktorering (Design Improvement, Refactor)

o Hyppige små udgivelser

· Forståelse deles af alle

o Enkelhed (simpelt design)

o Systemmetafor

o Kollektivt kodeejerskab eller udvalgte designmønstre (ejerskab af kollektive mønstre)

o Kodningsstandard eller Kodningskonventioner

· Programmer velfærd:

o 40-timers arbejdsuge (bæredygtigt tempo, 40 timers uge)

Et spilVplanlægning

Vores verden er for foranderlig og uforudsigelig til at stole på, at situationen er konstant. Det samme sker i softwareudvikling: med et sjældent system kan man sige, at dets endelige form var kendt på forhånd i detaljer i begyndelsen af ​​udviklingen. Typisk kommer kundens appetit, mens han spiser: han vil hele tiden ændre noget, forbedre noget eller helt smide noget ud af systemet. Dette er variationen af ​​krav, som alle er så bange for. Heldigvis får en person evnen til at forudsige mulige muligheder og dermed holde situationen under kontrol.

I Extreme Programming er planlægning en integreret del af udviklingen, og der tages højde for, at planer kan ændres helt fra begyndelsen. Omdrejningspunktet, teknikken, der giver dig mulighed for at forudsige situationen og smertefrit stille op med ændringer, er planlægningsspillet. Under et sådant spil kan kendte systemkrav hurtigt indsamles, vurderes og planlægges efter prioritet.

Som ethvert andet spil har planlægning sine deltagere og sit mål. Nøgletallet er naturligvis kunden. Det er ham, der kommunikerer behovet for denne eller hin funktionalitet. Programmører giver en omtrentlig vurdering af hver funktionalitet. Skønheden ved planlægningsspillet ligger i enhed af formål og solidaritet mellem udvikleren og kunden: i tilfælde af sejr vinder alle, i tilfælde af nederlag taber alle. Men samtidig går hver deltager sin egen vej til sejr: Kunden udvælger de vigtigste opgaver i overensstemmelse med budgettet, og programmøren vurderer opgaverne i overensstemmelse med sin evne til at implementere dem.

Ekstrem programmering antager, at udviklere er i stand til selv at bestemme, hvor lang tid det vil tage dem at fuldføre deres opgaver, og hvem af dem der ville være mere villige til at løse et problem, og hvem et andet.

I en ideel situation bør planlægningsspillet mellem kunden og programmøren spilles hver 3.-6. uge, indtil næste udviklingsiteration begynder. Dette gør det ret nemt at foretage justeringer baseret på succeser og fiaskoer fra den tidligere iteration.

4. Fordele og ulemper

Fordelene ved XP, hvis det kan implementeres, er større fleksibilitet, evnen til hurtigt og præcist at foretage ændringer i softwaren som reaktion på skiftende krav og individuelle kundeønsker, høj kvalitet af den resulterende kode og fraværet af behovet for at overbevise kunderne om, at resultatet lever op til deres forventninger.

Ulemperne ved denne tilgang er uigennemførligheden af ​​tilstrækkeligt store og komplekse projekter i denne stil, manglende evne til at planlægge timingen og kompleksiteten af ​​projektet på tilstrækkelig lang sigt og klart forudsige resultaterne af et langsigtet projekt i forhold til forholdet. af kvaliteten af ​​resultatet og omkostningerne til tid og ressourcer. Det kan også bemærkes, at XP ikke egner sig til de tilfælde, hvor mulige løsninger ikke umiddelbart findes på baggrund af tidligere opnåede erfaringer, men kræver forundersøgelser.

5. Brugshistorie

XP som et sæt af beskrevne teknikker blev først brugt under arbejdet med C3-projektet (Chrysler Comprehensive Compensation System, udvikling af et system til regnskabsføring af personalegoder hos Daimler Chrysler). Af de 20 deltagere i dette projekt udgav 5 (inklusive de ovennævnte 3 hovedforfattere af XP) 3 bøger og et stort antal artikler om XP under selve projektet og efterfølgende. Følgende data illustrerer problemerne med nogle XP-teknikker, når de anvendes på ret komplekse projekter.

Projektet startede i januar 1995. Siden marts 1996, efter at Kent Beck blev inkluderet, er det blevet kørt ved hjælp af XP. På dette tidspunkt var det allerede gået ud over budgettet og planerne for gradvis implementering af funktioner. Udviklingsteamet blev skåret ned, og i omkring seks måneder derefter udviklede projektet sig ganske vellykket. I august 1998 dukkede en prototype op, der kunne betjene omkring 10.000 medarbejdere. Projektet forventedes oprindeligt at være afsluttet i midten af ​​1999, og den resulterende software ville blive brugt til at administrere fordele for virksomhedens 87.000 ansatte. Det blev stoppet i februar 2000 efter 4 år med XP på grund af fuldstændig manglende overholdelse af tidsrammer og budget. Softwaren, der er lavet, er aldrig blevet brugt til at arbejde med data om mere end 10.000 ansatte, selvom det har vist sig, at den kan håndtere data om 30.000 virksomhedsansatte. Den person, der spillede rollen som kunden, der var inkluderet i projektteamet, sagde op efter et par måneders sådant arbejde, ude af stand til at modstå arbejdsbyrden og modtog aldrig en passende erstatning før projektets afslutning.

Konklusion

Alle de ovennævnte metoder er ikke bragt sammen tilfældigt. Deres konsekvente kombination kan bringe udviklingsprocessen i intellektuel resonans, hvilket væsentligt øger produktets kvalitet og fremskynder dets frigivelsestid. Den største skønhed ved al ekstrem programmering er forudsigelighed og minimering af udviklingsomkostninger; at give kunden det produkt, som han ønsker at modtage på tidspunktet for frigivelsen; og selvfølgelig kommunikation og træning af udviklere på jobbet.

Meningerne om den foreslåede metode kan variere. Det er vigtigt at forstå, at Extreme Programming ikke har til formål at erstatte eksisterende udviklingsteknologier. Tværtimod kan XP give yderligere impulser til teams, der bruger traditionelle tilgange. Du skal ikke lede her efter svar på alle dine spørgsmål. Dette er ikke en programmeringsteknologi, men derimod en teknologi til at organisere arbejdet, og det er i denne form, den har retten til livet.

Udgivet på Allbest.ru

Lignende dokumenter

Analyse af stadier og funktioner i udviklingen af ​​en optimal og funktionel ARIS-model - et softwareprodukt fra IDS Scheer til modellering af virksomhedens forretningsprocesser. Undersøgelse af de grundlæggende begreber, metoder og tilgange til ekstrem programmering.

test, tilføjet 06/04/2011


De vigtigste stadier af softwareudvikling (softwarepakke), analyse af systemkrav. Metode til trin-for-trin detaljering. Programmeringssprog på lavt niveau og højt niveau (imperativt, objektorienteret, funktionelt, logisk).

præsentation, tilføjet 13.10.2013


Udviklingssprog, implementeringsmiljø, udviklingsværktøjer. Funktioner i det virtuelle miljø til programimplementering og deres overvejelse i udviklingen af ​​et softwareprodukt. Systemmakroer og deres anvendelse i udviklingstekster. Visuelle programmeringsværktøjer.

tutorial, tilføjet 26/10/2013


Problemet med softwarepålidelighed, dets indikatorer og støttefaktorer. Metoder til overvågning af udviklingsprocessen af ​​programmer og dokumentation, fejlforebyggelse. Stadier af softwarefejlfindingsprocessen, strukturerede programmeringsteknikker og princippet om modularitet.

præsentation, tilføjet 30/04/2014


Maskinkoder og montør. De første programmeringssprog på højt niveau. FORTRAN programmeringssprog. Fordele og ulemper ved ALGOL. Videnskabelige og regnskabsmæssige programmer. De grundlæggende principper, der blev fulgt ved oprettelse af det grundlæggende programmeringssprog.

kursusarbejde, tilføjet 21/06/2014


Konceptet og nøgleforskellen ved distribueret softwareudvikling, dens fordele og ulemper. Konceptuel løsning og valg af udviklingstype. Funktioner i open source-software. Ideen og udviklingen af ​​Open Source.

kursusarbejde, tilføjet 14-12-2012


Begrebet software livscyklus. To typer aktiviteter skelnes i tekniske projekter: design og produktion. De vigtigste principper i manifestet af tilhængere af fleksible metoder. Grundlæggende principper for ekstrem programmering.

præsentation, tilføjet 14/08/2013


International standard for programmeringssproget Pascal. Teknikker til objektorienteret programmering i Turbo Pascal. Symboler på sproget, dets alfabet. Stadier af programudvikling. Begrebet algoritmer og algoritmisering. Struktur af programmer i Pascal.

kursusarbejde, tilføjet 28/02/2010


Moderne softwareudviklingsværktøjer til kontrolsystemer. Universelle programmeringssprog og deres sammenligning med SCADA-systemer. Softwareudvikling ved hjælp af multikanals måletransducere Ш9327.

afhandling, tilføjet 07/13/2011


Grundlæggende teknikker til at arbejde i Delphi-programmeringsmiljøet. Funktioner af teknologien til at skabe enkle applikationer. Arbejde med applikationsudviklingsmiljøkomponenter. Input, redigering, udvælgelse og output af information. Aspekter ved at bruge forgreningsstruktur.

Extreme Programming eller XP, eXtreme Programming er en fleksibel softwareudviklingsmetodologi. Ligesom andre agile metoder har den specifikke værktøjer, processer og roller. Selvom forfatteren af ​​XP ikke kom med noget nyt, men tog de bedste praksisser for agil udvikling og styrkede dem til det maksimale. Det er derfor programmering kaldes ekstrem.

Forfatteren til metoden er den amerikanske udvikler Kent Beck. I slutningen af ​​90'erne ledede han Chrysler Comprehensive Compensation System-projektet, og der var han pioner for praksis med ekstrem programmering. Han beskrev sin erfaring og det koncept, han skabte i bogen Extreme Programming Explained, udgivet i 1999. Det blev efterfulgt af andre bøger, der beskriver XP-praksis. Ward Cunningham, Martin Fowler og andre var også involveret i udviklingen af ​​metoden.

XP adskiller sig fra andre agile metoder ved, at det gælder kun inden for softwareudvikling. Det kan ikke bruges i en anden virksomhed eller hverdag som scrum, kanban eller lean.

Målet med XP-metoden er at klare konstant skiftende krav til et softwareprodukt og forbedre kvaliteten af ​​udviklingen. Derfor er XP velegnet til komplekse og usikre projekter

XP-metoden er bygget op omkring fire processer: kodning, test, design og lytning. Derudover har Extreme Programming værdierne enkelhed, kommunikation, feedback, mod og respekt.

1. Hele holdet

Alle projektdeltagere, der bruger XP, arbejder som ét team. Det skal omfatte en repræsentant for kunden; det er bedre, hvis dette er en reel slutbruger af produktet, der forstår forretningen. Kunden stiller krav til produktet og prioriterer implementering af funktionalitet. Forretningsanalytikere kan hjælpe ham. På udførelsessiden omfatter teamet udviklere og testere, nogle gange en coach, der guider teamet, og en leder, der forsyner teamet med ressourcer.

2. Planlægningsleg

Planlægning i XP udføres i to faser - releaseplanlægning og iterationsplanlægning.

Under udgivelsesplanlægningen mødes programmeringsteamet med kunden for at finde ud af, hvilken funktionalitet han ønsker at få til næste udgivelse, altså om 2-6 måneder. Da kundekrav ofte er vage, specificerer udviklere dem og opdeler dem i dele, hvis implementering ikke tager mere end en dag. Det er vigtigt, at kunden forstår det driftsmiljø, som produktet vil fungere i.

Opgaver skrives ned på kort, og kunden bestemmer deres prioritet. Dernæst estimerer udviklere, hvor meget tid hver opgave vil tage. Når opgaverne er beskrevet og vurderet, gennemgår kunden dokumentationen og giver grønt lys til, at arbejdet kan begynde. For projektets succes er det afgørende, at kunden og programmeringsteamet spiller på samme felt: Kunden vælger den funktionalitet, der virkelig er brug for inden for budgettet, og programmørerne sammenligner tilstrækkeligt kundens krav med deres evner.

I XP, hvis teamet ikke når at udføre alle opgaver inden udgivelsesdatoen, så skubbes udgivelsen ikke tilbage, men en del af den funktionalitet, der er mindst vigtig for kunden, skæres ned.

Iterationsplanlægning udføres hver anden uge, nogle gange mere eller mindre ofte. Kunden er altid til stede: han bestemmer funktionaliteten til den næste iteration og foretager ændringer i produktkravene.

3. Hyppige versionsudgivelser

I XP udgives versioner ofte, men med lidt funktionalitet. For det første er en lille mængde funktionalitet let at teste og vedligeholde funktionaliteten af ​​hele systemet. For det andet, hver iteration kunden modtager et stykke funktionalitet, der bærer forretningsværdi.

4. Brugertest

Kunden definerer selv automatiske accepttests for at kontrollere funktionaliteten af ​​den næste produktfunktion. Holdet skriver disse tests og bruger dem til at teste den færdige kode.

5. Kollektivt kodeejerskab

I XP kan enhver udvikler redigere et hvilket som helst stykke kode, fordi... Koden er ikke tildelt dens forfatter. Hele teamet ejer koden.

6. Kontinuerlig kodeintegration

Det betyder, at nye stykker kode straks bliver bygget ind i systemet - XP-teams uploader en ny build med få timers mellemrum eller oftere. For det første kan du med det samme se, hvordan de seneste ændringer påvirker systemet. Hvis et nyt stykke kode knækker noget, så er det meget nemmere at finde og rette fejlen end en uge senere. For det andet arbejder teamet altid med den nyeste version af systemet.

7. Kodningsstandarder

Når alle ejer koden, er det vigtigt at vedtage konsistente designstandarder, så koden ser ud som om den er skrevet af én fagmand. Du kan udvikle dine egne standarder eller vedtage færdige standarder.

8. Systemmetafor

En systemmetafor er en sammenligning af systemet med noget velkendt for at skabe en fælles vision blandt teamet. Normalt er systemmetaforen udtænkt af den person, der designer arkitekturen og forestiller sig systemet som en helhed.

9. Stadigt tempo

XP-teams arbejder med maksimal produktivitet, mens de holder et stabilt tempo. Samtidig har ekstrem programmering en negativ holdning til overarbejde og fremmer en 40-timers arbejdsuge.

10. Testdrevet udvikling

En af de sværeste metoder i metoden. I XP skrives test af programmørerne selv, FØR man skriver den kode, der skal testes. Med denne tilgang vil hvert stykke funktionalitet være 100% dækket af tests. Når et par programmører uploader kode til depotet, køres der straks enhedstests. Og de burde ALLE virke. Så vil udviklerne være sikre på, at de bevæger sig i den rigtige retning.

11. Parprogrammering

Forestil dig to udviklere ved én computer, der arbejder på ét stykke produktfunktionalitet. Dette er parprogrammering, den mest kontroversielle XP-praksis. Det gamle ordsprog "et hoved er godt, to er bedre" illustrerer perfekt essensen af ​​tilgangen. Den bedste vælges blandt to muligheder for at løse et problem, koden optimeres med det samme, og fejl fanges, før de opstår. Som et resultat har vi ren kode, som to udviklere er velbevandret i.

12. Enkelt design

Enkelt design i XP betyder, at du kun gør det, du har brug for nu, uden at forsøge at gætte fremtidig funktionalitet. Enkelt design og kontinuerlig refactoring har en synergistisk effekt - når koden er enkel, er den let at optimere.

13. Refaktorering

Refactoring er processen med løbende at forbedre et systems design for at imødekomme nye krav. Refaktorering involverer fjernelse af duplikatkode, øget sammenhængskraft og reduceret kobling. XP involverer konstante refactorings, så kodedesign forbliver altid enkelt.

XP fordele og ulemper

XP-metoden forårsager en masse kontroverser og kritik fra dem, der aldrig har været i stand til at implementere den i deres team.

Fordelene ved ekstrem programmering giver mening, når teamet fuldt ud udnytter mindst én af XP-praksis. Så hvad er værd at prøve:

• kunden modtager præcis det produkt, han har brug for, selvom han i begyndelsen af ​​udviklingen ikke selv forestiller sig dets endelige form
• teamet laver hurtigt kodeændringer og tilføjer ny funktionalitet gennem simpelt kodedesign, hyppig planlægning og udgivelser
• koden fungerer altid på grund af konstant test og kontinuerlig integration
• holdet vedligeholder nemt koden, fordi det er skrevet i henhold til en enkelt standard og bliver konstant refaktoreret
• hurtig udviklingshastighed på grund af parprogrammering, manglende omarbejdelse, tilstedeværelse af kunden i teamet
• høj kodekvalitet
• risiciene forbundet med udvikling reduceres, fordi ansvaret for projektet er jævnt fordelt, og et teammedlems afgang/ankomst vil ikke ødelægge processen
• udviklingsomkostningerne er lavere pga team er kodeorienteret, ikke dokumentation og møder

På trods af alle fordelene virker XP ikke altid og har en række svagheder. Så ekstrem programmering - ulemper:

• projektets succes afhænger af kundens involvering, hvilket ikke er så nemt at opnå
• Det er svært at forudsige den tid, der bruges på et projekt, fordi... i begyndelsen kender ingen den komplette liste over krav
• XPs succes afhænger stærkt af programmørernes niveau, metoden fungerer kun med seniorspecialister
• ledelsen har en negativ holdning til parprogrammering og forstår ikke, hvorfor det skal betale sig for to programmører i stedet for én
• Regelmæssige møder med programmører er dyre for kunderne
• kræver for meget kulturel forandring
• grundet manglende struktur og dokumentation, ikke egnet til store projekter
• fordi Agile metodikker er funktionelt orienterede, ikke-funktionelle krav til produktkvalitet er svære at beskrive i form af brugerhistorier.

XP-principper

I sin første bog formulerede Kent Beck principperne for ekstrem programmering: enkelhed, kommunikation, feedback og mod. I den nye udgave af bogen tilføjede han et femte princip – respekt.

1. Enkelhed

I XP starter udviklingen med den enkleste løsning, der vil tilfredsstille det aktuelle behov for funktionalitet. Teammedlemmer tager kun hensyn til, hvad der skal gøres nu, og lægger ikke ind i den kodefunktionalitet, der bliver brug for i morgen, om en måned eller aldrig.

2. Kommunikation

I XP udføres kommunikation mellem udviklere ikke gennem dokumentation, men live. Teamet kommunikerer aktivt med hinanden og med kunden.

3. Feedback

Feedback i XP implementeres i tre retninger på én gang:

1. feedback fra systemet under konstant test af moduler
2. feedback fra kunden, pga han er en del af teamet og deltager i at skrive accepttest
3. feedback fra teamet under planlægning vedrørende udviklingstid.

4. Mod

Nogle ekstreme programmeringsteknikker er så usædvanlige, at de kræver mod og konstant selvkontrol.

5. Respekt

I Extreme Programming ses respekt ud fra respekt for holdet og selvrespekt. Teammedlemmer bør ikke uploade ændringer, der vil ødelægge kompilering, enhedstests eller forsinke kollegernes arbejde. Alle stræber efter den højeste kvalitetskode og design.

Algoritme til implementering af XP metodikken og arbejdsprocessen

Beck Kent anbefaler at implementere XP til at løse problemer i et projekt. Holdet vælger det mest presserende problem og løser det ved hjælp af en af ​​de ekstreme programmeringsmetoder. Går derefter videre til næste problem med mere øvelse. Med denne tilgang fungerer problemer som motivation for at bruge XP, og teamet mestrer gradvist alle metodikkens værktøjer.

For at implementere XP i et eksisterende projekt skal du gradvist mestre dets teknikker på følgende områder:

• afprøvning
• design
• planlægning
• ledelse
• udvikling

Afprøvning.

Teamet opretter test, FØR du skriver ny kode og omarbejder gradvist gammel kode. For gammel kode skrives test efter behov: når du skal tilføje ny funktionalitet, rette en fejl eller omarbejde en del af den gamle kode.

Design.

Holdet refaktorerer gradvist gammel kode, normalt før de tilføjer ny funktionalitet. Som med test udføres refaktorisering af gammel kode kun, når det er nødvendigt. Samtidig bør teamet formulere langsigtede mål for kodeomarbejdelse og gradvist nå dem.

Planlægning.

Teamet skal skifte til tæt interaktion med kunden. På dette stadie er det vigtigt at formidle ham fordelene ved at arbejde i samme team med udviklere og integrere ham i teamet.

Ledelse.

Ledernes rolle under overgangen til XP er at sikre, at alle teammedlemmer arbejder efter de nye regler. Projektlederen beslutter, hvornår man skal skille sig af med et teammedlem, der ikke magter arbejdet i det nye miljø, eller for at finde et nyt og integrere ham ordentligt i arbejdet.

Udvikling.

Transformationer i udvikling begynder med organiseringen af ​​arbejdsstationer til programmering i par. Den næste udfordring er at programmere i par det meste af tiden, uanset hvor svært det kan være for udviklere.

I et projekt, der arbejder efter XP-metoden, er processen struktureret som følger:

Hvem bruger XP

Ifølge en undersøgelse fra Versionone fra 2016 bruger kun 1% af agile virksomheder ekstrem programmering i sin rene form. Yderligere 10 % arbejder ved hjælp af en hybrid scrum og XP-metode.

Interessant nok, selvom XP langt fra er den mest almindelige metode i sin rene form, bruges dens praksis af de fleste virksomheder, der arbejder med agile metoder. Dette fremgår af data fra samme undersøgelse:

Det er ikke let at finde information om hold, der bruger XP, men der er dem, der reklamerer for, at denne metode er årsagen til deres succes. Et eksempel på ekstrem programmering er Pivotal Software, Inc.

Pivotal Software, Inc.

En amerikansk softwarevirksomhed, der udvikler software til forretningsanalyse baseret på big data og leverer konsulentydelser. Pivotal-produkter bruges af Ford, Mercedes, BMW, GAP, Humana, store banker, offentlige myndigheder, forsikringsselskaber mv.

Pivotal er fortaler for agile metoder som de eneste mulige i moderne udvikling. Af alle mulighederne for fleksible metoder valgte virksomheden XP som en win-win tilgang for kunder og programmeringsteams. Hver arbejdsdag begynder med et møde på farten, og slutter præcis klokken 18:00 - ingen overarbejde. Pivotal bruger spilplanlægning, parprogrammering, kontinuerlig test, kontinuerlig integration og andre XP-praksis. For mange praksisser har de deres egen software.

Ekstrem programmering,
Ekstrem programmering: Planlægning,
Ekstrem programmering: Testdrevet udvikling / Kent Beck

Om ekstrem programmering fra skaberen af ​​metoden, Kent Beck. Start med den første, som beskriver XP-konceptet med eksempler og begrunder dets fordele. Senere udgav forfatteren flere bøger, hvor han detaljeret beskrev individuelle XP-praksis.

Refactoring: Forbedring af eksisterende kode / Martin Fowler

Ekstrem programmering: procesformulering. Fra de første skridt til den bitre ende / Ken Auer, Roy Miller

Da Extreme Programming stræber efter ren og let vedligeholdelig kode, inkluderer listen over bøger alle publikationer, der lærer dig, hvordan du programmerer bedre.

Applikationer til implementering af XP i et team

Teams, der arbejder på projekter, der bruger XP-metoden, bruger task managers og tjenester til agile projekter. Der er mange sådanne produkter på markedet, vi vil se på et par eksempler.

Gratis og open source task manager. Hovedfunktioner: arbejde på flere projekter på én gang, fleksibelt opgavestyringssystem, Gantt-diagram, tidsstyring, arbejde med dokumentation, oprettelse af opgaver via e-mail mv.

En enkel, bekvem service til at samarbejde om projekter. Indeholder en opgavehåndtering, opslagstavle, indbygget chat, fillagring, kalender

Jira

En kraftfuld service designet specielt til udviklere af agile projekter. Kombinerer en fejlsporer og en projektstyringstjeneste. Mange funktioner plus synkronisering med andre tjenester. Løsninger til teams i forskellige størrelser.

At arbejde med projekter. Giver dig mulighed for at sætte opgaver og styre udførelsesprocessen, korrespondere med hinanden på en opgave, opsætte filtre, tage hensyn til forbrug af tid og økonomi og arbejde med filer.

Dom

Extreme Programming er en fleksibel metode, der fokuserer på højkvalitets, brugbar kode med en enkel arkitektur. Dens formål er at reducere niveauet af usikkerhed i projekter og virkelig reagere fleksibelt på ændringer i produktkrav.

Denne metode er udelukkende beregnet til området softwareudvikling og kan ikke tilpasses til en anden virksomhed.

Dette er en af ​​de sværeste metoder at implementere, fordi den omfatter så mange som tretten praksisser!

Få virksomheder risikerer at arbejde på ren XP, men dens udviklingspraksis er den mest populære i agile projekter. Og dette er et stærkt argument til fordel for deres effektivitet.

Ingen tvinger dig til at implementere XP på alt-eller-intet-basis. I slutningen af ​​dagen skal agile metoder være fleksible i deres anvendelse - skræddersyet til behovene hos et specifikt team og projekt.

Udvikling (udvikling drevet af systemfunktioner) mv.

Ifølge forfatterne af XP følger denne teknik ikke så meget nogle generelle handlingsmønstre som at bruge en kombination af følgende teknikker. Hver teknik er dog vigtig, og uden dens brug anses udvikling for ikke at være XP, ifølge Kent Beck, en af ​​forfatterne til denne tilgang sammen med Ward Cunningham og Ron Jeffries.

• Live planlægningsspil

  Dens opgave er så hurtigt som muligt at bestemme mængden af ​​arbejde, der skal udføres før den næste softwareversion. Beslutningen træffes først og fremmest på baggrund af kundens prioriteter (dvs. hans behov, hvad han har brug for fra systemet for at drive sin virksomhed mere succesfuldt) og for det andet på baggrund af tekniske vurderinger (dvs. skøn over kompleksiteten) udvikling, kompatibilitet med andre elementer i systemet osv.). Planer ændres, så snart de begynder at afvige fra virkeligheden eller kundens ønsker.

• Hyppige versionsændringer (små udgivelser)

  Den allerførste fungerende version bør dukke op så hurtigt som muligt og bør straks begynde at blive brugt. Efterfølgende versioner udarbejdes med ret korte intervaller (fra flere timer for små ændringer i et lille program, til en måned eller to for en større omarbejdning af et stort system).

• Metafor af systemet

  Metaforen skal i en ret enkel og forståelig form for teamet beskrive systemets grundlæggende mekanisme. Dette koncept minder om arkitektur, men skal beskrive hovedessensen af ​​de tekniske beslutninger, der er truffet meget mere enkelt, i blot en eller to sætninger.

• Simple designløsninger

  Systemet bør til enhver tid udformes så enkelt som muligt. Der er ingen grund til at tilføje funktioner på forhånd - kun efter en eksplicit anmodning om det. Al unødvendig kompleksitet fjernes, så snart den opdages.

• Testdrevet udvikling

  Udviklere skriver først test, og forsøger derefter at implementere deres moduler, så testene fungerer. Kunder skriver på forhånd test, der demonstrerer systemets vigtigste muligheder, så de kan se, at systemet rent faktisk fungerer.

• Kontinuerlig refaktorering

  Programmører omarbejder hele tiden systemet for at eliminere unødvendig kompleksitet, øge kodens forståelighed, øge dens fleksibilitet, men uden at ændre dets adfærd, hvilket verificeres ved at køre efter hver omarbejdelse af testene. Samtidig foretrækkes mere elegante og fleksible løsninger, sammenlignet med dem, der blot giver det ønskede resultat. Forgæves redesignede komponenter skal identificeres under testudførelsen og rulles tilbage til den sidste intakte tilstand (sammen med de komponenter, der afhænger af dem).

• Par programmering

  Kodning udføres af to programmører på én computer. Parring er vilkårlig og varierer fra opgave til opgave. Den i hvis hænder tastaturet forsøger at løse det aktuelle problem på den bedste måde. Den anden programmør analyserer den førstes arbejde og giver råd, overvejer konsekvenserne af bestemte beslutninger, nye tests, mindre direkte, men mere fleksible løsninger.

• Kollektivt ejerskab af kode

  Ethvert teammedlem kan til enhver tid ændre enhver del af koden. Ingen bør have deres eget ansvarsområde; hele teamet som helhed er ansvarligt for al koden.

• Kontinuerlig integration

  Systemet samles og gennemgår integrationstest så ofte som muligt, flere gange om dagen, hver gang et par programmører er færdige med at implementere den næste funktion.

• 40 timers arbejdsuge

  Overarbejde ses som et tegn på større problemer i projektet. Overarbejde i 2 uger i træk er ikke tilladt - dette udmatter programmører og gør deres arbejde væsentligt mindre produktivt.

• Inklusive kunden i teamet (on-site kunde)

  Udviklingsteamet omfatter altid en kunderepræsentant, som står til rådighed hele arbejdsdagen og er i stand til at svare på alle spørgsmål om systemet. Hans ansvar er straks at besvare spørgsmål af enhver art vedrørende systemets funktioner, dets grænseflade, påkrævet ydeevne, korrekt drift af systemet i vanskelige situationer, behovet for at opretholde kommunikation med andre applikationer osv.

• Brug af kode som kommunikationsmiddel

  Kode ses som det vigtigste kommunikationsmiddel i et team. Kodeklarhed er en af ​​hovedprioriteterne. Det er bydende nødvendigt at følge kodningsstandarder, der giver denne klarhed. Sådanne standarder bør udover kodeklarhed sikre minimalt sprogbrug (ingen duplikering af kode og information) og bør accepteres af alle teammedlemmer.

• Åbent arbejdsområde

  Holdet er anbragt i et ret rummeligt rum for at lette kommunikationen og muliggøre gruppediskussioner, når de planlægger og træffer vigtige tekniske beslutninger.

• Ændring af reglerne efter behov (kun regler)

  Hvert teammedlem skal acceptere de anførte regler, men hvis behovet opstår, kan teamet ændre dem, hvis alle dets medlemmer er enige om denne ændring.

Som det kan ses af de anvendte teknikker, er XP designet til brug inden for små teams (ikke mere end 10 programmører), hvilket understreges af forfatterne af denne teknik. En større teamstørrelse ødelægger den lette kommunikation, der er nødvendig for succes, og gør det umuligt at implementere mange af de nævnte teknikker.

Fordelene ved XP, hvis det kan implementeres, er større fleksibilitet, evnen til hurtigt og præcist at foretage ændringer i softwaren som reaktion på skiftende krav og individuelle kundeønsker, høj kvalitet af den resulterende kode og fraværet af behovet for at overbevise kunderne om, at resultatet lever op til deres forventninger.

Ulemperne ved denne tilgang er uigennemførligheden af ​​tilstrækkeligt store og komplekse projekter i denne stil, manglende evne til at planlægge timingen og kompleksiteten af ​​projektet på tilstrækkelig lang sigt og klart forudsige resultaterne af et langsigtet projekt i forhold til forholdet. af kvaliteten af ​​resultatet og omkostningerne til tid og ressourcer. Det kan også bemærkes, at XP ikke egner sig til de tilfælde, hvor mulige løsninger ikke umiddelbart findes på baggrund af tidligere opnåede erfaringer, men kræver forundersøgelser.

XP som et sæt af beskrevne teknikker blev først brugt under arbejdet med C3-projektet (Chrysler Comprehensive Compensation System, udvikling af et system til regnskabsføring af personalegoder hos Daimler Chrysler). Af de 20 deltagere i dette projekt udgav 5 (inklusive de ovennævnte 3 hovedforfattere af XP) 3 bøger og et stort antal artikler om XP under selve projektet og efterfølgende. Dette projekt er gentagne gange nævnt i forskellige kilder som et eksempel på brugen af ​​denne teknik. Følgende data er samlet fra de nævnte artikler, minus anekdotiske beviser, og illustrerer problemerne med nogle XP-teknikker, når de anvendes på ret komplekse projekter.

Projektet startede i januar 1995. Siden marts 1996, efter at Kent Beck blev inkluderet, er det blevet kørt ved hjælp af XP. På dette tidspunkt var det allerede gået ud over budgettet og planerne for gradvis implementering af funktioner. Udviklingsteamet blev skåret ned, og i omkring seks måneder derefter udviklede projektet sig ganske vellykket. I august 1998 dukkede en prototype op, der kunne betjene omkring 10.000 medarbejdere. Projektet forventedes oprindeligt at være afsluttet i midten af ​​1999, og den resulterende software ville blive brugt til at administrere fordele for virksomhedens 87.000 ansatte. Det blev stoppet i februar 2000 efter 4 år med XP på grund af fuldstændig manglende overholdelse af tidsrammer og budget. Softwaren, der er lavet, er aldrig blevet brugt til at arbejde med data om mere end 10.000 ansatte, selvom det har vist sig, at den kan håndtere data om 30.000 virksomhedsansatte. Den person, der spillede rollen som kunden, der var inkluderet i projektteamet, sagde op efter et par måneders sådant arbejde, ude af stand til at modstå arbejdsbyrden og modtog aldrig en passende erstatning før projektets afslutning.

Extreme Programming (XP) er en af ​​de fleksible softwareudviklingsmetoder. Forfatterne til metoden er Kent Beck, Ward Cunningham, Martin Fowler m.fl.

Planlægning spil

Vores verden er for foranderlig og uforudsigelig til at stole på, at situationen er konstant. Det samme sker i softwareudvikling: med et sjældent system kan man sige, at dets endelige form var kendt på forhånd i detaljer i begyndelsen af ​​udviklingen. Typisk kommer kundens appetit, mens han spiser: han vil hele tiden ændre noget, forbedre noget eller helt smide noget ud af systemet. Dette er variationen af ​​krav, som alle er så bange for. Heldigvis får en person evnen til at forudsige mulige muligheder og dermed holde situationen under kontrol.
I Extreme Programming er planlægning en integreret del af udviklingen, og der tages højde for, at planer kan ændres helt fra begyndelsen. Omdrejningspunktet, teknikken, der giver dig mulighed for at forudsige situationen og smertefrit stille op med ændringer, er planlægningsspillet. Under et sådant spil kan kendte systemkrav hurtigt indsamles, vurderes og planlægges efter prioritet.
Som ethvert andet spil har planlægning sine deltagere og sit mål. Nøgletallet er naturligvis kunden. Det er ham, der kommunikerer behovet for denne eller hin funktionalitet. Programmører giver en omtrentlig vurdering af hver funktionalitet. Skønheden ved planlægningsspillet ligger i enhed af formål og solidaritet mellem udvikleren og kunden: i tilfælde af sejr vinder alle, i tilfælde af nederlag taber alle. Men samtidig går hver deltager sin egen vej til sejr: Kunden udvælger de vigtigste opgaver i overensstemmelse med budgettet, og programmøren vurderer opgaverne i overensstemmelse med sin evne til at implementere dem.
Ekstrem programmering antager, at udviklere er i stand til selv at bestemme, hvor lang tid det vil tage dem at fuldføre deres opgaver, og hvem af dem der ville være mere villige til at løse et problem, og hvem et andet.
I en ideel situation bør planlægningsspillet mellem kunden og programmøren spilles hver 3.-6. uge, indtil næste udviklingsiteration begynder. Dette gør det ret nemt at foretage justeringer baseret på succeser og fiaskoer fra den tidligere iteration.

Frigivelsesplan

Frigivelsesplanen definerer udgivelsesdatoer og brugererklæringer, der vil blive implementeret i hver af dem. Ud fra dette kan du vælge formuleringer til næste iteration. Under en iteration produceres og køres accepttests inden for den iteration og alle efterfølgende for at sikre, at programmet fungerer korrekt. Planen kan revideres, hvis der er en betydelig forsinkelse eller forspring i slutningen af ​​en af ​​gentagelserne.
Gentagelser. Iteration gør udviklingsprocessen dynamisk. Der er ingen grund til at planlægge dine softwareopgaver lang tid i forvejen. I stedet er det bedre at have et planlægningsmøde i begyndelsen af ​​hver iteration. Det nytter ikke at forsøge at implementere noget, der ikke var planlagt. Du vil stadig have tid til at implementere disse ideer, når de frigives i henhold til udgivelsesplanen.
Ved at vænne dig til ikke at tilføje funktionalitet på forhånd og bruge fremadrettet planlægning, kan du nemt tilpasse dig skiftende kundekrav.

Iterationsplanlægning

Iterationsplanlægning begynder med et møde i begyndelsen af ​​hver iteration for at udvikle en plan med trin til løsning af softwareproblemer. Hver iteration bør vare fra en til tre uger. Formuleringer inden for en iteration sorteres i rækkefølge efter deres betydning for kunden. Derudover tilføjes opgaver, der ikke kunne bestå acceptprøverne og kræver yderligere arbejde. Testerklæringer og resultater omsættes til softwareproblemer. Opgaver skrives ned på kort, der danner en detaljeret iterationsplan. Det tager fra en til tre dage at løse hvert problem. Opgaver, der kræver mindre end én dag, kan grupperes sammen, og store opgaver kan opdeles i flere mindre. Udviklere estimerer opgaver og deadlines for deres afslutning. Det er meget vigtigt for en udvikler nøjagtigt at bestemme udførelsestiden for en opgave. Det kan være nødvendigt at revurdere noget sprog og revidere udgivelsesplanen efter hver tredje eller femte iteration - dette er fuldstændig acceptabelt. Hvis du implementerer de vigtigste arbejdsområder først, så vil du altid have tid til at gøre det maksimale muligt for dine kunder. En iterativ udviklingsstil forbedrer udviklingsprocessen.

Møde stående

Hver morgen afholdes et møde for at diskutere problemer, deres løsninger og for at styrke holdets koncentration. Mødet holdes stående for at undgå lange diskussioner, som ikke er interessante for alle teammedlemmer.
I et typisk møde bidrager de fleste deltagere ikke med noget, bare deltage for at høre, hvad andre har at sige. En stor mængde af folks tid er spildt på at modtage en lille mængde kommunikation. At have alle til møder tager derfor ressourcer fra projektet og skaber kaos i planlægningen.
Denne form for kommunikation kræver et stående møde. Det er meget bedre at have et kort, obligatorisk møde end mange lange, som de fleste udviklere alligevel skal deltage i.
Hvis du har daglige stående møder, bør alle andre møder kun deltage af de personer, der er nødvendige og vil bringe noget på bordet. Desuden er det endda muligt at undgå nogle møder. Med begrænsede deltagere kan de fleste møder afholdes spontant foran en monitor, hvor udvekslingen af ​​ideer er meget mere intens.
Det daglige morgenmøde er ikke endnu et spild af tid. Det vil give dig mulighed for at undgå mange andre møder og spare dig mere tid, end du bruger på det.

Enkelhed

Et simpelt design tager altid mindre tid end et komplekst. Så gør altid de enkleste ting, der vil virke. Det er altid hurtigere og billigere at udskifte kompleks kode med det samme, inden du bruger meget tid på at arbejde på det. Hold tingene så enkle som muligt uden at tilføje funktionalitet før planlagt. Husk: At holde et design enkelt er hårdt arbejde.

Metaforsystem

Valget af et metaforsystem er nødvendigt for at holde holdet inden for samme rammer, når klasser og metoder skal navngives. Hvordan du navngiver dine objekter er meget vigtigt for at forstå det overordnede systemdesign og genbrug af kode. Hvis en udvikler er i stand til korrekt at forudsige, hvad et eksisterende objekt kan hedde, fører dette til tidsbesparelser. Brug et navngivningssystem til dine objekter, som alle kan forstå uden specifik systemviden.

Kunde på arbejdspladsen

Hovedproblemet i softwareudvikling er programmørernes manglende viden om det fagområde, der udvikles. Ekstrem programmering har fundet en vej ud af denne situation. Nej, dette er ikke et udviklerpraktik hos kundens virksomhed - så vil han ikke programmere. Tværtimod er det kundens deltagelse i udviklingsprocessen.
Kan en programmør, uden at forstå essensen af ​​problemet og ikke være en telepat, gætte, hvad kunden ønsker? Svaret er indlysende. Den nemmeste måde at overvinde denne ulejlighed - og Extreme Programming lærer os at finde de enkleste løsninger - er at stille kunden et direkte spørgsmål. Mere stringente tilgange kræver en omfattende foreløbig analyse af det område, der udvikles. I visse tilfælde er dette berettiget, selvom det er dyrere. Reel erfaring med at køre hverdagsagtige projekter viser, at det er umuligt at samle alle kravene på forhånd. Desuden, selvom vi antager, at alle kravene i øjeblikket er indsamlet, vil der stadig være én flaskehals: programmer, ligesom alt i naturen, oprettes ikke øjeblikkeligt, og i mellemtiden kan forretningsprocesser ændre sig. Dette bør tages i betragtning.
Mange tvivler på muligheden for at inddrage kunden i udviklingsprocessen. Faktisk er kunderne forskellige. Hvis det ikke er muligt at tiltrække kunden eller dennes repræsentant, er det nogle gange tilrådeligt at midlertidigt ansætte en specialist på det område, der udvikles. Dette trin vil mindske uklarheder i arbejdet, øge udviklingshastigheden og bringe projektet tættere på det, kunden ønsker at modtage. Dette kan også være fordelagtigt fra den økonomiske side: Når alt kommer til alt, er lønnen for en programmør nogle gange betydeligt højere end lønnen for specialister i andre brancher.
Brugerhistorie. User Story (noget som en brugers historie) er en beskrivelse af, hvordan systemet skal fungere. Hver brugerhistorie er skrevet på et kort og repræsenterer et stykke systemfunktionalitet, der giver logisk mening fra kundens synspunkt. Formularen er et eller to afsnit af tekst, der er forståeligt for brugeren (ikke særlig teknisk).
Brugerhistorie er skrevet af kunden. Disse ligner systembrugstilfælde, men er ikke begrænset til brugergrænsefladen. For hver historie bliver der skrevet funktionelle tests for at bekræfte, at denne historie er implementeret korrekt – de kaldes også accepttest.

Test før udvikling begynder

Testning er i sin klassiske forstand en ret kedelig procedure. Normalt hyrer de en tester, som med jævne mellemrum udfører de samme handlinger og venter på den dag, hvor han endelig bliver overført til en anden stilling, eller muligheden for at skifte job opstår.
I ekstrem programmering er testens rolle mere interessant: nu kommer testen først, og derefter koden. Hvordan tester man noget, der ikke eksisterer endnu? Svaret er enkelt og banalt: test dine tanker - hvad kan du forvente af et fremtidigt stykke program eller funktionalitet. Dette giver dig mulighed for bedre at forstå, hvad programmører skal gøre og kontrollere funktionaliteten af ​​koden, så snart den er skrevet.
Men testen virker måske heller ikke. Så hvad, skrive en test til en test? Og så test for test og så videre ad infinitum? Slet ikke. Testen til testen erstatter koden. Hvordan det? Men se: forestil dig, at du skal fastgøre møtrikken i midten af ​​bolten, så den ikke drejer. Hvad gør de for dette? Skru den anden møtrik tæt på den første, så hver møtrik forhindrer den tilstødende i at dreje. Det er det samme i programmering: testen tester koden, og koden tester testen.
Erfaringen viser, at denne tilgang ikke blot ikke bremser, men også fremskynder udviklingen. Når alt kommer til alt, vil det at vide, hvad der skal gøres og den nødvendige mængde arbejde spare tid ved at nægte at sælge dele, der ikke er efterspurgt i øjeblikket.

Par programmering

Al kode for produktionssystemet er skrevet i par. To udviklere sidder ved siden af ​​hinanden. Den ene skriver, den anden ser på. De skifter fra tid til anden. Det er ikke tilladt at arbejde alene. Hvis den anden af ​​parret af en eller anden grund gik glip af noget (syg, pensioneret osv.), er han forpligtet til at gennemgå alle ændringerne foretaget af den første.
Det lyder usædvanligt, men efter en kort tilpasningsperiode fungerer de fleste godt i par. De kan endda lide det, fordi arbejdet bliver gjort mærkbart hurtigere. Princippet "Et hoved er godt, men to er bedre" gælder. Par finder normalt bedre løsninger. Derudover øges kvaliteten af ​​koden markant, antallet af fejl falder, og udvekslingen af ​​viden mellem udviklere accelereres. Mens en person fokuserer på objektets strategiske vision, implementerer den anden dets egenskaber og metoder.

Skift stilling

I løbet af den næste iteration skal alle arbejdere flyttes til nye arbejdsområder. Sådanne bevægelser er nødvendige for at undgå videnisolering og eliminere flaskehalse. Særligt frugtbart er det at udskifte en af ​​udviklerne inden for parprogrammering.

Kollektivt kodeejerskab

Delt kodeejerskab tilskynder udviklere til at indsende ideer til alle dele af projektet, ikke kun deres egne moduler. Enhver udvikler kan ændre enhver kode for at udvide funktionaliteten og rette fejl.
Ved første øjekast ligner det kaos. Men når man tager i betragtning, at i det mindste enhver kode er skabt af et par udviklere, at test giver dig mulighed for at kontrollere rigtigheden af ​​de foretagne ændringer, og at du i det virkelige liv stadig skal forstå en andens kode på en eller anden måde, det bliver tydeligt, at kollektivt ejerskab af koden gør det meget nemmere at foretage ændringer og reducerer risikoen forbundet med den høje specialisering hos et eller andet teammedlem.

Kodningskonvention

Du er en del af et team, der har arbejdet på dette projekt i lang tid. Folk kommer og går. Ingen koder alene, og koden tilhører alle. Der vil altid være tidspunkter, hvor du har brug for at forstå og justere en andens kode. Udviklere vil fjerne eller ændre dubletkode, analysere og forbedre andres klasser osv. Med tiden vil det være umuligt at sige, hvem forfatteren til en bestemt klasse er.
Derfor skal alle overholde almindelige kodningsstandarder - kodeformatering, navngivning af klasser, variabler, konstanter, kommentarstil. På denne måde vil vi være sikre på, at når vi foretager ændringer i en andens kode (som er nødvendig for aggressive og ekstreme fremskridt), vil vi ikke omdanne den til Babel Pandemonium.
Ovenstående betyder, at alle teammedlemmer skal være enige om fælles kodningsstandarder. Det er lige meget hvilke. Reglen er, at alle adlyder dem. De, der ikke ønsker at overholde dem, forlader holdet.

Hyppig integration

Udviklere bør integrere og frigive deres kode med få timers mellemrum, hvis det er muligt. Under alle omstændigheder bør du aldrig opbevare ændringer i mere end én dag. Hyppig integration undgår fremmedgørelse og fragmentering i udviklingen, hvor udviklere ikke kan kommunikere i den forstand, at de deler ideer eller genbruger kode. Alle burde køre den nyeste version.
Hvert par udviklere bør bidrage med deres kode, så snart det er rimeligt muligt at gøre det. Dette kan være, når alle UnitTests består 100 %. Ved at indsende ændringer flere gange dagligt reducerer du integrationsproblemer til næsten nul. Integration er en "betal nu eller betal mere senere" aktivitet. Ved at integrere ændringer i små trin hver dag, vil du derfor ikke finde dig i at skulle bruge en uge på at forsøge at binde systemet sammen lige før projektet leveres. Arbejd altid på den nyeste version af systemet.

Fyrre timers arbejdsuge

En person, især hvis han er en programmør, er i stand til at gøre meget for forretningens skyld: at blive sent på arbejde, gå på arbejde i weekenden, opgive ferie, holde sig vågen i flere dage, mens han sidder ved tastaturet... Generelt, hvad kan du gøre for din yndlingsaktivitets skyld. Men ekstrem programmering er kategorisk imod sådan selvopofrelse og overtrædelse af accepterede arbejdsretlige standarder.
Dette er ikke kun dikteret af hensyn til lovlighed og menneskelighed, men først og fremmest af behovet for at øge arbejdseffektiviteten og stram organisering. Når alt kommer til alt, er ekstrem programmering et kollektivt spil, der ikke er designet til enkeltpersoner, men for hele gruppen. Og sådan en ting som for eksempel parprogrammering er kun mulig, når biorytmerne for dens deltagere er synkroniseret. Og det er umuligt, hvis én person kommer på arbejde klokken ni, og den anden klokken tolv, eller man beslutter, at det er bedre for ham at arbejde lørdag og søndag, mens den anden er ubelejlig.
Men det vigtigste er, at for at opretholde sundhed og ydeevne har en person brug for ordentlig hvile. otte timers arbejdsdag og fem dages arbejdsuge er fastsat netop af hensyn til maksimal produktivitet. I mange vestlige virksomheder betragtes det at forlade arbejdet sent som manglende præstationer eller manglende evne til at styre sin arbejdstid ordentligt. I de fleste tilfælde er dette sandt. Og fra et medicinsk synspunkt fører forsinkelser på arbejdet til konstant træthed, irritabilitet og nedsat hjerneaktivitet. Er dette effektivt? Hvordan kan vi organisere konstant åben kommunikation mellem udviklere i sådan et team, og vil parprogrammering være mulig? Svaret er negativt. Standarder er standarder og bør følges.

Konklusion

Disse metoder er ikke sat sammen tilfældigt. Deres konsekvente kombination kan bringe udviklingsprocessen i intellektuel resonans, hvilket væsentligt øger produktets kvalitet og fremskynder dets frigivelsestid. Den største skønhed ved al ekstrem programmering er forudsigelighed og minimering af udviklingsomkostninger; at give kunden det produkt, som han ønsker at modtage på tidspunktet for frigivelsen; og selvfølgelig kommunikation og træning af udviklere på jobbet.

Bibliografi:

Extreme Programming (XP) opstod som en evolutionær metode til bottom-up softwareudvikling. Denne tilgang er et eksempel på den såkaldte Agile Development Method. Gruppen af ​​“live” metoder omfatter, udover ekstrem programmering, metoderne SCRUM, DSDM (Dynamic Systems Development Method, en metode til udvikling af dynamiske systemer), Feature-Driven Development (udvikling drevet af systemfunktioner) mv.

De grundlæggende principper for live softwareudvikling er nedfældet i live-udviklingsmanifestet, som udkom i 2000.

• · De involverede i et projekt og deres kommunikation er vigtigere end processer og værktøjer.
• · Et arbejdsprogram er vigtigere end omfattende dokumentation.
• · Samarbejde med kunden er vigtigere end at diskutere detaljerne i kontrakten.
• · At arbejde gennem forandringer er vigtigere end at holde sig til planer.

"Levende" metoder dukkede op som en protest mod den overdrevne bureaukratisering af softwareudvikling, overfloden af ​​sidedokumenter, der ikke er nødvendige for at opnå det endelige resultat, som skal udarbejdes, når et projekt udføres i overensstemmelse med de fleste "tunge" processer , yderligere arbejde for at understøtte den faste proces i organisationen, som dette kræves inden for for eksempel CMM. De fleste af sådanne arbejde og dokumenter er ikke direkte relateret til softwareudvikling og kvalitetssikring, men er beregnet til at overholde de formelle klausuler i udviklingskontrakter, opnå og bekræfte certifikater for overholdelse af forskellige standarder.

"Live"-metoder gør det muligt for udviklere at fokusere det meste af deres indsats på udviklingsopgaver og opfylde reelle brugerbehov. Fraværet af bunker af dokumenter og behovet for at vedligeholde dem i en sammenhængende tilstand giver dig mulighed for at reagere hurtigere og mere effektivt på ændringer i krav og i det miljø, hvor det fremtidige program skal fungere.

XP har dog sit eget udviklingsprocesdiagram (selvom generelt set den meget anvendte forståelse af "udviklingsprocessen" som et ret rigidt handlingsskema modsiger selve ideen om "livlig" udvikling), vist i fig. .

Ifølge forfatterne af XP følger denne teknik ikke så meget nogle generelle handlingsmønstre som at bruge en kombination af følgende teknikker. Hver teknik er dog vigtig, og uden dens brug anses udvikling for ikke at være XP, ifølge Kent Beck, en af ​​forfatterne til denne tilgang sammen med Ward Cunningham og Ron Jeffries.

· Direkte planlægning spil)

Dens opgave er så hurtigt som muligt at bestemme mængden af ​​arbejde, der skal udføres før den næste softwareversion. Beslutningen træffes først og fremmest på baggrund af kundens prioriteter (dvs. hans behov, hvad han har brug for fra systemet for at drive sin virksomhed mere succesfuldt) og for det andet på baggrund af tekniske vurderinger (dvs. skøn over kompleksiteten) udvikling, kompatibilitet med andre elementer i systemet osv.). Planer ændres, så snart de begynder at afvige fra virkeligheden eller kundens ønsker.

Fig.1

· Hyppig lave om versioner (små udgivelser)

Den allerførste fungerende version bør dukke op så hurtigt som muligt og bør straks begynde at blive brugt. Efterfølgende versioner udarbejdes med ret korte intervaller (fra flere timer for små ændringer i et lille program, til en måned eller to for en større omarbejdning af et stort system). Versioner (udgivelser) af produktet bør frigives i brug så ofte som muligt. Hver version bør tage så lidt tid som muligt at færdiggøre. Desuden skal hver version være tilstrækkelig meningsfuld med hensyn til anvendelighed for erhvervslivet.

· Metafor af systemet

Metaforen skal i en ret enkel og forståelig form for teamet beskrive systemets grundlæggende mekanisme. Dette koncept minder om arkitektur, men skal beskrive hovedessensen af ​​de tekniske beslutninger, der er truffet meget mere enkelt, i blot en eller to sætninger.

Arkitektur er en idé om komponenterne i et system, og hvordan de er forbundet. Udviklere bruger arkitektur til at forstå, hvor nogle nye funktioner bliver tilføjet til systemet, og hvad en ny komponent vil interagere med.

Systemmetaforen er en analog til det, der kaldes arkitektur i de fleste teknikker. Systemmetaforen giver teamet en fornemmelse af, hvordan systemet fungerer i øjeblikket, hvor nye komponenter tilføjes, og hvilken form de skal have.

· Enkel design løsninger (enkle design)

Systemet bør til enhver tid udformes så enkelt som muligt. Der er ingen grund til at tilføje funktioner på forhånd - kun efter en eksplicit anmodning om det. Al unødvendig kompleksitet fjernes, så snart den opdages.

XP går ud fra, at under arbejdets gang kan betingelserne for problemet ændre sig gentagne gange, hvilket betyder, at produktet, der udvikles, ikke skal designes på forhånd i sin helhed. Hvis du forsøger at designe et system i detaljer fra start til slut, når du starter første gang, spilder du din tid. XP antager, at design er en så vigtig proces, at det skal ske løbende gennem hele projektet. Design skal udføres i små trin under hensyntagen til konstant skiftende krav. I hvert øjeblik forsøger vi at bruge det enkleste design, der er egnet til at løse det aktuelle problem. Samtidig ændrer vi det i takt med, at problemets betingelser ændrer sig.

· Udvikling på basis test (testdrevet udvikling)

Udviklere skriver først test, og forsøger derefter at implementere deres moduler, så testene fungerer. Kunder skriver på forhånd test, der demonstrerer systemets vigtigste muligheder, så de kan se, at systemet rent faktisk fungerer.

XP lægger særlig vægt på to typer test:

ь enhed prøvning;

b accepttest.

ekstrem programmeringssoftware

En udvikler kan ikke være sikker på rigtigheden af ​​den kode, han har skrevet, før absolut alle test af modulerne i det system, han er ved at udvikle, har fungeret. Enhedstest giver udviklere mulighed for at verificere, at deres kode fungerer korrekt. De hjælper også andre udviklere med at forstå, hvorfor et bestemt stykke kode er nødvendigt, og hvordan det fungerer. Enhedstest giver også udvikleren mulighed for at refaktorere uden nogen bekymringer.

Accepttest sikrer, at systemet rent faktisk har de angivne muligheder. Derudover giver accepttest dig mulighed for at verificere den korrekte funktion af det produkt, der udvikles.

For XP er en højere prioritet tilgangen kaldet TDD (Test Driven Development), først skrives en test, der ikke består, derefter skrives koden, så testen består, og først derefter refaktoreres koden.

· Konstant refaktorering

Det er ingen hemmelighed, at tilføjelsen af ​​hver ny funktionalitet og kodevækst komplicerer udviklingen, identificerer fejl og foretager efterfølgende ændringer. Et af trickene ved Extreme Programming er at kompensere for tilføjelse af funktionalitet med kodeforbedringer. Dette er kodebehandling eller refactoring.

Programmører omarbejder hele tiden systemet for at eliminere unødvendig kompleksitet, øge kodens forståelighed, øge dens fleksibilitet, men uden at ændre dets adfærd, hvilket verificeres ved at køre efter hver omarbejdelse af testene. Samtidig foretrækkes mere elegante og fleksible løsninger, sammenlignet med dem, der blot giver det ønskede resultat. Forgæves redesignede komponenter skal identificeres under testudførelsen og rulles tilbage til den sidste intakte tilstand (sammen med de komponenter, der afhænger af dem).

Refactoring er en teknik til at forbedre kode uden at ændre dens funktionalitet. XP betyder, at når først kode er skrevet, vil den næsten helt sikkert blive omskrevet flere gange i løbet af et projekt. XP-udviklere omarbejder hensynsløst tidligere skrevet kode for at forbedre den. Denne proces kaldes refactoring. Manglen på testdækning fremkalder et afslag på refactoring på grund af frygten for at bryde systemet, hvilket fører til gradvis nedbrydning af koden.

· Programmering par programmering)

Erfarne udviklere har bemærket, at periodisk gennemgang af andres kode har en positiv effekt på kvaliteten. Mestrene i Extreme Programming har udviklet denne tilgang ved konstant at gennemgå kode under udvikling gennem en teknik kaldet parprogrammering.

Kodning udføres af to programmører på én computer. Parring er vilkårlig og varierer fra opgave til opgave. Den i hvis hænder tastaturet forsøger at løse det aktuelle problem på den bedste måde. Den anden programmør analyserer den førstes arbejde og giver råd, overvejer konsekvenserne af bestemte beslutninger, nye tests, mindre direkte, men mere fleksible løsninger. Om nødvendigt overføres tastaturet frit fra det ene til det andet. Mens du arbejder på et projekt, er parrene ikke faste: det anbefales at blande dem, så hver programmør på holdet har en god forståelse af hele systemet. På denne måde forbedrer parprogrammering samarbejdet i teamet.

· Kollektive besiddelse kode (kollektiv ejendomsret)

Kollektive besiddelse betyder, at hvert teammedlem er ansvarlig for al kildekode. Alle har således ret til at foretage ændringer i enhver del af programmet. Parprogrammering understøtter denne praksis: arbejder i forskellige par, bliver alle programmører fortrolige med alle dele af systemets kode. En vigtig fordel ved delt kodeejerskab er, at det fremskynder udviklingsprocessen, da hvis der opstår en fejl, kan enhver programmør rette den.

Ved at give enhver programmør ret til at ændre koden, risikerer vi, at fejl introduceres af programmører, der tror, ​​de ved, hvad de laver, men som ikke overvejer visse afhængigheder. Veldefinerede UNIT-tests løser dette problem: Hvis uundersøgte afhængigheder genererer fejl, vil den næste kørsel af UNIT-tests mislykkes.

· Konstant integration (kontinuerlig integration)

Systemet samles og gennemgår integrationstest så ofte som muligt, flere gange om dagen, hver gang et par programmører er færdige med at implementere den næste funktion.

Hvis du integrerer det system, du er ved at udvikle, ofte nok, kan du undgå de fleste problemer, der er forbundet med det. I traditionelle metoder udføres integration som regel i slutningen af ​​arbejdet med et produkt, når det vurderes, at alle komponenter i systemet, der udvikles, er helt klar. I XP udføres kodeintegration af hele systemet flere gange om dagen, efter at udviklerne er sikre på, at alle enhedstests affyrer korrekt.

På trods af sin enkelhed har denne teknik sine egne brugsregler, såsom succesen med de eksisterende enhedstests for den funktionalitet, der skal integreres, tilstedeværelsen af ​​funktionelle tests eller accepttests og, selvfølgelig, evnen til at rulle tilbage til en tidligere tilstand . Typisk udføres integration og løsning af tilhørende vanskeligheder på en separat computer af et par programmører. Dette giver dig mulighed for at minimere risikoen for uønskede konsekvenser af integration.

· 40 timer arbejder en uge

Overarbejde ses som et tegn på større problemer i projektet. Overarbejde i 2 uger i træk er ikke tilladt - dette udmatter programmører og gør deres arbejde væsentligt mindre produktivt.

En person, især hvis han er en programmør, er i stand til at gøre meget for forretningens skyld: at blive sent på arbejde, gå på arbejde i weekenden, opgive ferier, holde sig vågen i flere dage, mens han sidder ved tastaturet... Generelt, hvad kan du gøre for din yndlingsaktivitets skyld. Men ekstrem programmering er kategorisk imod sådan selvopofrelse og overtrædelse af accepterede arbejdsretlige standarder.

Dette er ikke kun dikteret af hensyn til lovlighed og menneskelighed, men først og fremmest af behovet for at øge arbejdseffektiviteten og stram organisering. Når alt kommer til alt, er ekstrem programmering et kollektivt spil, der ikke er designet til enkeltpersoner, men for hele gruppen. Og sådan en ting som for eksempel parprogrammering er kun mulig, når biorytmerne for dens deltagere er synkroniseret. Og det er umuligt, hvis én person kommer på arbejde klokken ni, og den anden klokken tolv, eller man beslutter, at det er bedre for ham at arbejde lørdag og søndag, mens den anden er ubelejlig.

Men det vigtigste er, at for at opretholde sundhed og ydeevne har en person brug for ordentlig hvile. otte timers arbejdsdag og fem dages arbejdsuge er fastsat netop af hensyn til maksimal produktivitet. I mange vestlige virksomheder betragtes det at forlade arbejdet sent som manglende præstationer eller manglende evne til at styre sin arbejdstid ordentligt. I de fleste tilfælde er dette sandt. Og fra et medicinsk synspunkt fører forsinkelser på arbejdet til konstant træthed, irritabilitet og nedsat hjerneaktivitet. Er dette effektivt? Hvordan kan vi organisere konstant åben kommunikation mellem udviklere i sådan et team, og vil parprogrammering være mulig? Svaret er negativt. Standarder er standarder og bør følges.

· Inklusion kunde V hold (på stedet kunde)

Hovedproblemet i softwareudvikling er programmørernes manglende viden om det fagområde, der udvikles. Ekstrem programmering har fundet en vej ud af denne situation. Nej, dette er ikke et udviklerpraktik hos kundens virksomhed - så vil han ikke programmere. Tværtimod er det kundens deltagelse i udviklingsprocessen.

Udviklingsteamet omfatter altid en kunderepræsentant, som står til rådighed hele arbejdsdagen og er i stand til at svare på alle spørgsmål om systemet. Hans ansvar er straks at besvare spørgsmål af enhver art vedrørende systemets funktioner, dets grænseflade, påkrævet ydeevne, korrekt drift af systemet i vanskelige situationer, behovet for at opretholde kommunikation med andre applikationer osv.

Mange tvivler på muligheden for at inddrage kunden i udviklingsprocessen. Faktisk er kunderne forskellige. Hvis det ikke er muligt at tiltrække kunden eller dennes repræsentant, er det nogle gange tilrådeligt at midlertidigt ansætte en specialist på det område, der udvikles. Dette trin vil mindske uklarheder i arbejdet, øge udviklingshastigheden og bringe projektet tættere på det, kunden ønsker at modtage. Dette kan også være fordelagtigt fra den økonomiske side: Når alt kommer til alt, er lønnen for en programmør nogle gange betydeligt højere end lønnen for specialister i andre brancher.

· Brug kode Hvordan faciliteter kommunikation

Kode ses som det vigtigste kommunikationsmiddel i et team. Kodeklarhed er en af ​​hovedprioriteterne. Det er bydende nødvendigt at følge kodningsstandarder, der giver denne klarhed. Sådanne standarder bør udover kodeklarhed sikre minimalt sprogbrug (ingen duplikering af kode og information) og bør accepteres af alle teammedlemmer.

· Åben arbejder plads (åben arbejdsområde)

Holdet er anbragt i et ret rummeligt rum for at lette kommunikationen og muliggøre gruppediskussioner, når de planlægger og træffer vigtige tekniske beslutninger.

· Lave om regler Ved nødvendigt (bare regler)

Hvert teammedlem skal acceptere de anførte regler, men hvis behovet opstår, kan teamet ændre dem, hvis alle dets medlemmer er enige om denne ændring.

Som det kan ses af de anvendte teknikker, er XP designet til brug inden for små teams (ikke mere end 10 programmører), hvilket understreges af forfatterne af denne teknik. En større teamstørrelse ødelægger den lette kommunikation, der er nødvendig for succes, og gør det umuligt at implementere mange af de nævnte teknikker.