Du er bekendt med programmering, men Extreme Programming (forkortet XP) er stadig lidt af et mysterium for dig.
Lad ikke navnet afskrække dig, du risikerer at gå glip af nyttig information.
I denne artikel kommer vi til at dække alt, hvad du behøver at vide om ekstrem programmering, så du kan bruge det til din fordel.
Ekstrem programmering er en softwareudviklingsmetodologi, der er en del af det, der tilsammen er kendt som agile metoder. XP er bygget på værdier, principper og praksis, og dets mål er at gøre det muligt for små og mellemstore teams at producere software af høj kvalitet og tilpasse sig konstant skiftende og skiftende krav.
Det, der adskiller XP fra andre agile metoder, er, at XP lægger vægt på de tekniske aspekter af softwareudvikling. Ekstrem programmering handler præcist om, hvordan ingeniører arbejder, da det at følge ingeniørpraksis giver teams mulighed for at levere kode af høj kvalitet i et bæredygtigt tempo.
Ekstrem programmering er i en nøddeskal, god praksis taget til det ekstreme. Da parprogrammering er godt, lad os gøre det hele tiden. Da det er godt at teste på forhånd, tester vi før produktionskoden overhovedet er skrevet.
XP, i modsætning til andre metoder, er baseret på værdier og principper, der er vigtige og relevante, hvad angår ingeniørpraksis.
Værdier giver teams formål. De fungerer som en "nordstjerne" til at guide dine beslutninger på et højt niveau. Værdierne er dog abstrakte og for uklare til specifik vejledning. For eksempel: At sige, at du værdsætter kommunikation, kan føre til mange forskellige resultater.
Praksis er på en måde det modsatte af værdier. De er konkrete og jordnære, defiat indstille detaljerne for, hvad der skal gøres. Praksis hjælper teams med at holde sig selv ansvarlige for værdier. For eksempel fremmer praktiseringen af informationsarbejdspladser gennemsigtig og enkel kommunikation.
Principper er domænespecifikke retningslinjer, der bygger bro mellem praksis og værdier.
XP værdier: kommunikation, enkelhed, feedback, mod og respekt. Lad os se på hver af dem mere detaljeret.
udarbejdelse BlogInnovazione.det af billedet alexsoft. com
kommunikation: Mangel på kommunikation forhindrer viden i at flyde inden for et team. Ofte, når der er et problem, ved nogen allerede, hvordan man løser det. Men mangel på kommunikation forhindrer dem i at lære om problemet eller bidrage til dets løsning. Dermed ender problemet med at blive løst to gange, hvilket genererer affald.
Enkelhed: Enkelhed siger, at du altid stræber efter at gøre det enkleste, der virker. Det bliver ofte misforstået og taget som den enkleste ting, punktum, idet man ignorerer "der virker"-delen.
Det er også vigtigt at huske, at enkelhed er meget kontekstuel. Hvad der er enkelt for et hold, er komplekst for et andet og afhænger helt af det enkelte holds færdigheder, erfaring og viden.
Feedback: Feedback i mere traditionelle, kaskadende softwareudviklingsmetoder er ofte "for lidt, for sent".
XP omfavner imidlertid forandring, og XP-teams stræber efter rettidig og konstant feedback. Hvis kurskorrektion er nødvendig, vil XPere gerne vide det så hurtigt som muligt.
udarbejdelse BlogInnovazione.det af billedet alexsoft. com
Feedback kommer i mange former og størrelser. Når du er partner med programmering, er kommentarer fra din kollega afgørende feedback. Det samme er andre teammedlemmers meninger om en idé, herunder kunden, som ideelt set er medlem af teamet.
Tests er en anden kilde til værdifuld feedback, der går ud over testresultater. Uanset om det er let eller svært at skrive test, er det også feedback. Hvis du har problemer med at skrive test, er dit projekt sandsynligvis for komplekst. Lyt til feedback og strømline dit design.
Noget, der lyder som en god idé, fungerer måske ikke så godt i praksis. Derfor er færdig kode også en kilde til feedback, ligesom et distribueret produkt.
Husk endelig på, at der er for meget feedback. Hvis et team genererer mere feedback, end det kan håndtere, kan vigtig feedback falde af radaren. Så det er vigtigt at sætte farten ned og finde ud af, hvad der forårsager den overskydende feedback og rette op på det.
coraggio: Kent Beck defimod fremstår som "effektiv handling over for frygt". Som softwareingeniør har du meget at frygte og derfor masser af muligheder for at vise mod.
Det kræver mod at fortælle sandheden, især de ubehagelige, såsom ærlige skøn. At give og modtage feedback kræver også mod. Og det kræver mod at undgå at falde ind i fejltagelsen i sunk cost-fejlen og kassere en fejlagtig løsning, der har modtaget betydelige investeringer.
respekt: En grundlæggende forudsætning for XP er, at alle bekymrer sig om deres arbejde. Ingen mængde af teknisk ekspertise kan redde et projekt, hvis der ikke er omsorg og respekt.
Enhver person er værdig til værdighed og respekt, og det inkluderer selvfølgelig de mennesker, der er involveret i et softwareudviklingsprojekt. Når du og dine teammedlemmer respekterer og plejer hinanden, kunden, projektet og dets fremtidige brugere, får alle gavn af det
Principper giver mere specifik vejledning end værdier. Det er retningslinjer, der belyser værdierne og gør dem mere eksplicitte og mindre tvetydige.
udarbejdelse BlogInnovazione.det af billedet alexsoft. com
For eksempel, baseret på værdien af mod alene, kan du konkludere, at det er tilrådeligt at foretage en stor ændring i din tidsplan med det samme. Baby Steps-princippet fortæller os dog, at store ændringer er risikable. Så foretrækker de små i stedet.
Umanita: Mennesker skaber software til mennesker, en ofte overset kendsgerning. Men at tage hensyn til grundlæggende menneskelige behov, styrker og svagheder skaber produkter, som mennesker ønsker at bruge. Og et arbejdsmiljø, der giver dig mulighed for opfyldelse og vækst, følelsen af tilhørsforhold og grundlæggende tryghed, er et sted, hvor du lettere tager hensyn til andres behov.
Economy: I XP er teams altid opmærksomme på de økonomiske realiteter i softwareudvikling, evaluerer konstant økonomiske risici og projektbehov.
For eksempel ville de implementere brugerhistorier baseret på deres forretningsværdi snarere end tekniske bekymringer.
Fælles fordel: Efter XP undgår du løsninger, der gavner én part på bekostning af en anden. For eksempel kan udvidede specifikationer hjælpe en anden til at forstå det, men det distraherer dig fra at implementere det og forsinker det for dine brugere.
En gensidig fordelagtig løsning er at bruge automatiserede accepttests. Få øjeblikkelig feedback på din implementering, dine peers får præcise specifikationer i koden, og brugerne får deres funktioner først. Derudover vil I alle have et sikkerhedsnet mod regression.
Fordel (gensidig fordel): Hvis en given løsning virker på et niveau, kan den også fungere på et højere eller lavere niveau. For eksempel er det i forskellig grad at få tidlig og konstant feedback på spil i XP.
Forbedring: Ifølge forbedringsprincippet sigter teams ikke efter perfektion i en indledende implementering, men efter en implementering der er god nok, og lærer og forbedrer den så løbende med feedback fra rigtige brugere.
Mangfoldighed: Du og dine kolleger nyder godt af en mangfoldighed af perspektiver, færdigheder og holdninger. En sådan mangfoldighed fører ofte til konflikter, men det er okay.
Konflikter og uenighed er muligheder for, at bedre ideer kan opstå, når alle spiller efter værdierne mod og respekt. Mod til at udtrykke modsatrettede synspunkter, respekt ved at udtrykke dem på en civil og empatisk måde. Og alt dette er en effektiv kommunikationsøvelse.
Afspejling: Fantastiske teams reflekterer over deres arbejde og analyserer, hvordan man bliver bedre. XP giver mange muligheder for dette. Ikke kun i dets ugentlige og kvartalsvise cyklusser, men i enhver praksis det fremmer.
Følelser er vigtige at overveje ud over logisk analyse. Din mavefornemmelse kan informere dig, før du kan ræsonnere om noget. Og så han kan tale med ikke-tekniske folk, de kan stille spørgsmål, der åbner helt nye muligheder.
Flyde: Traditionelle softwareudviklingsmetoder har adskilte faser, som varer længe og har ringe mulighed for feedback og kursuskorrektion. I stedet foregår softwareudvikling i XP i aktiviteter, der foregår kontinuerligt, i en konsistent "strøm" af værdi.
Chance: Problemer er uundgåelige i softwareudvikling. Ethvert problem er dog en mulighed for forbedring. Lær at se på dem på denne måde, og du er meget mere tilbøjelig til at komme med kreative og målorienterede løsninger, der også tjener til at forhindre dem i at ske igen.
Redundans: Princippet om redundans siger, at hvis et givent problem er kritisk, skal du bruge mange taktikker for at imødegå det.
Tag fejlene. Der er ingen enkelt taktik, der kan forhindre alle defekter i at undslippe produktionen.
Så XP's løsning er at stable et sæt kvalitetsmål. Parprogrammering, test, kontinuerlig integration. Hver en enkelt forsvarslinje, tilsammen en praktisk talt uigennemtrængelig mur.
Fiasko: fiasko er ikke spild, når det omsættes til viden. At handle og hurtigt lære, hvad der ikke virker, er meget mere produktivt end passivitet forårsaget af ubeslutsomhed, når man skal vælge blandt mange muligheder.
qualità: Folk tror ofte, at der er et dilemma mellem kvalitet og hastighed.
Det er omvendt: at presse på for at forbedre kvaliteten er det, der får dig til at gå hurtigere.
For eksempel er refactoring - at ændre kodes struktur uden at ændre dens adfærd - en praksis, der gør kode lettere at forstå og ændre. Som et resultat er det mindre sandsynligt, at du introducerer kodefejl, hvilket giver dig mulighed for at levere mere værdi først ved ikke at skulle rette fejl.
Små skridt: Store ændringer er risikable. XP mindsker denne risiko ved at foretage ændringer i små trin på alle niveauer.
Programmører skriver kode i små trin ved hjælp af testdrevet udvikling. De integrerer deres kode i hovedlinjen flere gange om dagen, i stedet for blot hver par uger eller endda måneder. Selve projektet foregår i korte cyklusser frem for langvarige faser.
Ansvar accepteret: I XP bør ansvar accepteres, aldrig tildeles.
Ansvarlighed bør følge med autoriteten til at træffe beslutninger om, hvad du er ansvarlig for. Det modsatte er også sandt. Du vil ikke have, at folk træffer beslutninger, hvis de ikke skal leve med deres konsekvenser.
Ekstrem programmering, som er en agil metode, kan accepteres og begynde at adoptere den uden at følge stive planer. Dette er et iterativt design snarere end et stort indledende projekt.
XP adskiller sig væsentligt fra traditionelle metoder, det vil sige cascading, hvilket undgår langvarige faser.
Hvordan adskiller XP sig fra andre agile metoder?
Ekstrem programmering har i sagens natur meget til fælles med andre agile metoder, men er også unik blandt dem.
De fleste andre udviklingsmetoder siger ikke meget, om noget, om, hvordan man får arbejdet gjort. XP, på den anden side, er meget påstået, når det kommer til dette og lægger stor vægt på software engineering praksis.
Scrum er en ramme, der hjælper teams med at udvikle komplekse projekter på en adaptiv måde. Scrum dikterer ikke, hvordan udviklere udfører deres arbejde. XP lægger som nævnt meget vægt på god programmeringspraksis.
udarbejdelse BlogInnovazione.da billede netløsninger
Desuden handler XP åbenbart om programmering. Scrum, på den anden side, kan anvendes på ethvert projekt, der drager fordel af en iterativ tilgang.
XP accepterer ændringer af dets komponenter. Teams er bemyndiget og endda opfordret til at ændre praksis baseret på deres specifikke behov. Scrum Guiden er på den anden side stejlt på, at "Selvom kun dele af Scrum kan implementeres, er resultatet ikke Scrum".
Scrum er også en ramme, der skal suppleres med metoder og praksis for at få arbejdet gjort.
Det betyder, at arbejde i ekstrem programmering og Scrum kan varmt anbefales.
Ifølge Kent Beck bør et modent XP-hold ikke tildele stive roller, men erkende, at roller kan være nyttige for nystartede hold, indtil de begynder at sænke farten eller gøre samarbejde vanskeligt.
Lad os se på nogle nøgleroller:
Dette er den praksis, der er vedtaget i XP. De er opdelt i tre hovedgrupper: software engineering, arbejdsplads og projektledelse.
Par programmering: I XP skriver du kode parvis siddende på en maskine. Du og dit par taler med hinanden, mens I analyserer, implementerer og tester den funktion, I arbejder på. Parprogrammering er især god til at producere kode med færre fejl, mens den stadig er engagerende, sjov og trættende.
Ti minutters grænse: Påkrævet Giver 10 minutter til at bygge hele projektet, inklusive at køre alle automatiserede test, på højst ti minutter. Denne grænse er for at holde testning strømlinet og effektiv.
Tester før programmering: implementer funktioner ved hjælp af test-først tilgang, også kaldet testdrevet udvikling (TDD). TDD består af udvikling ved hjælp af en simpel iterativ procedure:
TDD giver flere fordele.
Først feedback. Hvis det er svært at skrive en test, er det design, du leder efter, eller som du har arvet, sandsynligvis for komplekst, og du skal forenkle det.
For det andet giver TDD programmører mulighed for at stole på den kode, de skriver, og skaber en flot looping-rytme, hvor det næste trin altid er klart.
Sidst men ikke mindst sikrer brug af TDD fra starten 100 % kodedækning. Testpakken bliver så i sandhed et sikkerhedsnet for fremtidige ændringer, der opmuntrer koderefaktorering og skaber en god cirkel af kvalitet.
Inkrementelt design: Praksis med inkrementelt design betyder, at du skal investere i dit applikationsdesign hver dag, på udkig efter muligheder for at fjerne dobbeltarbejde og lave små forbedringer for at opnå det bedst mulige design til det, dit system har brug for i dag.
Kontinuerlig integration: I XP integrerer du dit arbejde i det delte hovedlager flere gange om dagen, hvilket udløser en automatisk opbygning af hele systemet. Integrering så tidligt og så ofte som muligt reducerer dramatisk omkostningerne ved integration, da det gør fusioner og logiske konflikter mindre tilbøjelige til at opstå. Det afslører også miljø- og afhængighedsproblemer.
Delt kode (kollektivt ejerskab): XP fremmer delt kode eller kollektivt ejerskab: hver udvikler er ansvarlig for al kode. Det tilskynder til informationsudveksling, reducerer teambus-faktoren og øger den overordnede kvalitet af hvert modul, hvis vi overvejer princippet om mangfoldighed.
Enkelt kodebase: Enkelt kodebase er også kendt som "trunk-baseret udvikling". Det betyder, at der kun er én kilde til sandhed. Så i stedet for at udvikle sig isoleret i lange perioder, flet dine bidrag til en enkelt strøm tidligt og ofte. Funktionsflag hjælper med at begrænse din brug af funktioner, indtil de er færdige.
Daglig uddeling: udrulning i produktionen mindst én gang om dagen er en logisk konsekvens af kontinuerlig integration:. Faktisk går mange teams i dag endnu længere og praktiserer løbende implementering. Det vil sige, når nogen slutter sig til hovedlinjen, implementeres applikationen til produktion.
Kode og test: Denne praksis betyder, at kildekoden, inklusive tests, er den eneste permanente artefakt i et softwareprojekt. At engagere sig i generering af andre typer artefakter, herunder dokumentation, er ofte spild, fordi det ikke genererer reel værdi for kunden.
Hvis du har brug for andre artefakter eller dokumenter, så gør en indsats for at generere dem fra produktionskode og test.
Grundårsagsanalyse: Når en defekt kommer i produktion, skal du ikke bare rette fejlen. Sørg for at finde ud af, hvad der forårsagede det i første omgang, hvorfor du og dine holdkammerater ikke formåede at forhindre udskridningen. Tag derefter skridt til at sikre, at det ikke sker igen.
Sid sammen: I XP foretrækker teams at arbejde sammen i et åbent rum. Denne praksis fremmer kommunikation og en følelse af at høre til et team.
Hele holdet: Alle, der er nødvendige for projektets succes, er en del af XP-teamet. Dette er meget kontekstuelt – forskelligt for hvert team – og dynamisk, det kan ændre sig inden for et team.
Informationsarbejdspladser: Et informationsarbejdsområde bruger teamets fysiske rum til at vise information, der gør det muligt for enhver med et øjeblik at kende projektets fremskridt. Hvordan dette gøres kan variere, fra fysiske noter og grafer til skærmbilleder, der viser Kanban-tavler og dashboards fra projektstyringssoftware.
Energisk arbejde: I XP arbejder du kun, så længe du kan udføre energisk arbejde. Arbejdstiden må højst være begrænset til 40 om ugen.
Analisi- Skriv brugerkrav i et format kendt som brugeranalyse. En brugeranalyse har et kort, beskrivende navn og også en kort beskrivelse af, hvad der skal implementeres.
Slack: Når du planlægger en cyklus, tilføj mindre opgaver, som teamet kan opgive, hvis behovet opstår. Flere historier kan altid tilføjes, hvis holdet leverer for meget.
cyklusser (månedlig og ugentlig): Udvikling i XP sker i to hovedcyklusser: den ugentlige cyklus og den månedlige cyklus.
Møder, cyklusser, planlagte udgivelser: Udvikling i XP fungerer i to hovedcyklusser: den ugentlige cyklus og den kvartalsvise cyklus. Oprindeligt anbefalede Kent Beck en to-ugers cyklus, men ændrede det i anden udgave af sin bog.
Ugentlig cyklus: den ugentlige cyklus er "pulsen" i et XP-projekt. Cyklussen starter med et møde, hvor klienten vælger, hvilke historier han vil skabe i løbet af ugen. Derudover gennemgår teamet deres arbejde, inklusive sidste uges fremskridt, og tænker på måder at forbedre deres proces på.
Månedlig cyklus: Hver måned reflekterer og identificerer teamet forbedringsmuligheder i deres proces. Klienten vælger et eller flere temaer for den pågældende måned sammen med analyserne i disse temaer.
Hvordan begynder man at arbejde med ekstrem programmering?
Tekniske færdigheder og XP-vaner kan være svære at lære. Nogle af praksisserne kan virke fremmede for programmører, der ikke er vant til dem.
Ercole Palmeri
Coveware by Veeam vil fortsætte med at levere responstjenester til cyberafpresning. Coveware vil tilbyde kriminaltekniske og afhjælpende funktioner...
Forudsigende vedligeholdelse revolutionerer olie- og gassektoren med en innovativ og proaktiv tilgang til anlægsstyring...
Det britiske CMA har udsendt en advarsel om Big Techs adfærd på markedet for kunstig intelligens. Der…
Dekretet om "grønne huse", der er formuleret af Den Europæiske Union for at øge bygningers energieffektivitet, har afsluttet sin lovgivningsproces med...
