Du er kjent med programmering, men Extreme Programming (forkortet XP) er fortsatt litt av et mysterium for deg.
Ikke la navnet skremme deg, du risikerer å gå glipp av nyttig informasjon.
I denne artikkelen skal vi dekke alt du trenger å vite om ekstrem programmering, slik at du kan bruke det til din fordel.
Ekstrem programmering er en programvareutviklingsmetodikk som er en del av det som til sammen kalles smidige metoder. XP er bygget på verdier, prinsipper og praksis, og målet er å gjøre det mulig for små og mellomstore team å produsere høykvalitets programvare og tilpasse seg stadig skiftende og utviklende krav.
Det som skiller XP fra andre smidige metoder er at XP legger vekt på de tekniske aspektene ved programvareutvikling. Ekstrem programmering handler nøyaktig om hvordan ingeniører jobber, ettersom å følge ingeniørpraksis gjør det mulig for team å levere kode av høy kvalitet i et bærekraftig tempo.
Ekstrem programmering er, i et nøtteskall, god praksis tatt til det ekstreme. Siden parprogrammering er bra, la oss gjøre det hele tiden. Siden forhåndstesting er bra, tester vi før produksjonskoden i det hele tatt er skrevet.
XP, i motsetning til andre metoder, er basert på verdier og prinsipper som er viktige og relevante, når det gjelder ingeniørpraksis.
Verdier gir formål til team. De fungerer som en "nordstjerne" for å veilede beslutningene dine på et høyt nivå. Verdiene er imidlertid abstrakte og for uklare for spesifikk veiledning. For eksempel: Å si at du verdsetter kommunikasjon kan føre til mange forskjellige resultater.
Praksis er på en måte det motsatte av verdier. De er konkrete og jordnære, defiangi spesifikasjonene for hva som skal gjøres. Praksis hjelper team med å holde seg ansvarlige for verdier. For eksempel fremmer praktiseringen av informasjonsarbeidsområder transparent og enkel kommunikasjon.
Prinsipper er domenespesifikke retningslinjer som bygger bro mellom praksis og verdier.
XP-verdier: kommunikasjon, enkelhet, tilbakemelding, mot og respekt. La oss se på hver av dem mer detaljert.
Drafting BlogInnovazione.det av bildet alexsoft.com
kommunikasjon: Mangel på kommunikasjon hindrer kunnskap i å flyte innenfor et team. Ofte, når det er et problem, vet noen allerede hvordan de skal fikse det. Men mangel på kommunikasjon hindrer dem i å lære om problemet eller bidra til å løse det. Dermed ender problemet opp med å bli løst to ganger, og genererer avfall.
enkelhet: Enkelhet sier at du alltid streber etter å gjøre det enkleste som fungerer. Det blir ofte misforstått og tatt som det enkleste, punktum, og ignorerer "som fungerer"-delen.
Det er også viktig å huske at enkelhet er svært kontekstuell. Hva som er enkelt for ett lag er komplekst for et annet og avhenger helt av ferdighetene, erfaringen og kunnskapen til hvert lag.
Tilbakemelding: Tilbakemelding i mer tradisjonelle, gjennomgripende programvareutviklingsmetoder er ofte "for lite, for sent".
XP omfavner imidlertid endring og XP-team streber etter rettidig og konstant tilbakemelding. Hvis kurskorrigering er nødvendig, vil XPere vite det så snart som mulig.
Drafting BlogInnovazione.det av bildet alexsoft.com
Tilbakemeldinger kommer i mange former og størrelser. Når du samarbeider med programmering, er kommentarer fra kollegaen din viktig tilbakemelding. Det samme er andre teammedlemmers meninger om en idé, inkludert kunden som ideelt sett er medlem av teamet.
Tester er en annen kilde til verdifull tilbakemelding som går utover testresultater. Om det er enkelt eller vanskelig å skrive tester, er det også tilbakemeldinger. Hvis du har problemer med å skrive tester, er prosjektet sannsynligvis for komplekst. Lytt til tilbakemeldinger og strømlinjeform designen din.
Noe som høres ut som en god idé fungerer kanskje ikke så bra i praksis. Derfor er ferdig kode også en kilde til tilbakemelding, det samme er et distribuert produkt.
Til slutt, husk at det er for mye tilbakemelding. Hvis et team genererer mer tilbakemelding enn det kan håndtere, kan viktig tilbakemelding falle av radaren. Så det er viktig å bremse ned og finne ut hva som forårsaker overflødig tilbakemelding og fikse det.
Mot: Kent Beck defimot fremstår som "effektiv handling i møte med frykt". Som programvareingeniør har du mye å frykte og derfor mange muligheter til å vise mot.
Det krever mot å fortelle sannheten, spesielt de ubehagelige, for eksempel ærlige anslag. Å gi og motta tilbakemelding krever også mot. Og det kreves mot for å unngå å falle inn i feiltakelsen for sunk cost-feilen og forkaste en sviktende løsning som har mottatt betydelige investeringer.
Respekt: Et grunnleggende premiss for XP er at alle bryr seg om arbeidet sitt. Ingen mengde teknisk fortreffelighet kan redde et prosjekt hvis det ikke er omsorg og respekt.
Hver person er verdig verdighet og respekt, og det inkluderer selvfølgelig menneskene som er involvert i et programvareutviklingsprosjekt. Når du og teammedlemmene dine respekterer og bryr seg om hverandre, kunden, prosjektet og dets fremtidige brukere, har alle fordeler
Prinsipper gir mer spesifikk veiledning enn verdier. De er retningslinjer som belyser verdiene og gjør dem mer eksplisitte og mindre tvetydige.
Drafting BlogInnovazione.det av bildet alexsoft.com
For eksempel, basert på verdien av mot alene, kan du konkludere med at det er tilrådelig å gjøre en stor endring i timeplanen din med en gang. Baby Steps-prinsippet forteller oss imidlertid at store endringer er risikable. Så foretrekk de små i stedet.
Umanita: Mennesker lager programvare for mennesker, et faktum som ofte overses. Men å ta hensyn til grunnleggende menneskelige behov, styrker og svakheter skaper produkter som mennesker ønsker å bruke. Og et arbeidsmiljø som gir deg mulighet til oppfyllelse og vekst, følelsen av tilhørighet og grunnleggende trygghet, er et sted hvor du lettere tar hensyn til andres behov.
Økonomi: I XP tar team alltid hensyn til de økonomiske realitetene ved programvareutvikling, evaluerer stadig økonomiske risikoer og prosjektbehov.
For eksempel vil de implementere brukerhistorier basert på deres forretningsverdi snarere enn tekniske bekymringer.
Gjensidig nytte: Etter XP slipper du løsninger som gagner en part på bekostning av en annen. For eksempel kan utvidede spesifikasjoner hjelpe noen andre til å forstå det, men det distraherer deg fra å implementere det og forsinker det for brukerne dine.
En gjensidig fordelaktig løsning er å bruke automatiserte aksepttester. Få umiddelbar tilbakemelding på implementeringen din, kollegaene dine får presise spesifikasjoner i koden, og brukerne får funksjonene sine først. I tillegg vil dere alle ha et sikkerhetsnett mot regresjoner.
Fordel (gjensidig nytte): Hvis en gitt løsning fungerer på ett nivå, kan den også fungere på et høyere eller lavere nivå. For eksempel er det i ulik grad å få tidlig og konstant tilbakemelding på spill i XP.
Forbedring: I henhold til forbedringsprinsippet sikter ikke teamene mot perfeksjon i en innledende implementering, men etter en implementering som er god nok, for så å lære og forbedre den kontinuerlig med tilbakemeldinger fra reelle brukere.
Mangfold: Du og dine kolleger drar nytte av et mangfold av perspektiver, ferdigheter og holdninger. Slikt mangfold fører ofte til konflikt, men det er greit.
Konflikt og uenighet er muligheter for at bedre ideer kan dukke opp når alle spiller etter verdiene mot og respekt. Mot til å uttrykke motstridende synspunkter, respekt ved å uttrykke dem på en sivil og empatisk måte. Og alt dette er en effektiv kommunikasjonsøvelse.
refleksjon: Flotte team reflekterer over arbeidet sitt og analyserer hvordan de kan bli bedre. XP gir mange muligheter for dette. Ikke bare i sine ukentlige og kvartalsvise sykluser, men i hver praksis det fremmer.
Følelser er viktige å vurdere i tillegg til logisk analyse. Magen din kan informere deg før du kan resonnere om noe. Og så han kan snakke med ikke-tekniske folk, de kan stille spørsmål som åpner for helt nye muligheter.
Strømme: Tradisjonelle programvareutviklingsmetoder har distinkte faser, som varer lenge og har liten mulighet for tilbakemelding og kurskorrigering. I stedet skjer programvareutvikling i XP i aktiviteter som skjer kontinuerlig, i en konsistent "strøm" av verdi.
muligheter: Problemer er uunngåelige i programvareutvikling. Hvert problem er imidlertid en mulighet for forbedring. Lær å se på dem på denne måten, og du er mye mer sannsynlig å komme opp med kreative og målrettede løsninger som også tjener til å forhindre at de skjer igjen.
Overflødighet: Prinsippet om redundans sier at hvis et gitt problem er kritisk, må du bruke mange taktikker for å motvirke det.
Ta feilene. Det er ingen enkelt taktikk som kan forhindre at alle defekter slipper ut produksjonen.
Så XPs løsning er å stable et sett med kvalitetsmål. Parprogrammering, testing, kontinuerlig integrasjon. Hver en enkelt forsvarslinje, sammen en praktisk talt ugjennomtrengelig vegg.
Failure: fiasko er ikke bortkastet når det omsettes til kunnskap. Å handle og raskt lære hva som ikke fungerer er mye mer produktivt enn passivitet forårsaket av ubesluttsomhet når du velger blant mange alternativer.
qualità: Folk tenker ofte at det er et dilemma mellom kvalitet og hastighet.
Det er omvendt: press for å forbedre kvaliteten er det som får deg til å gå raskere.
For eksempel er refactoring – å endre strukturen til kode uten å endre atferden – en praksis som gjør kode lettere å forstå og endre. Som et resultat er det mindre sannsynlig at du introduserer kodedefekter, noe som lar deg levere mer verdi først ved å slippe å fikse feil.
Små skritt: Store endringer er risikabelt. XP reduserer denne risikoen ved å gjøre endringer i små trinn, på alle nivåer.
Programmerere skriver kode i små trinn ved hjelp av testdrevet utvikling. De integrerer koden sin i hovedlinjen flere ganger om dagen, i stedet for bare noen få uker eller måneder. Selve prosjektet foregår i korte sykluser fremfor langvarige faser.
Ansvar akseptert: I XP bør ansvar aksepteres, aldri tildeles.
Ansvar bør komme med myndighet til å ta beslutninger om hva du er ansvarlig for. Det motsatte er også sant. Du vil ikke at folk skal ta avgjørelser hvis de ikke må leve med konsekvensene sine.
Ekstrem programmering, som er en smidig metodikk, kan aksepteres og begynne å ta i bruk den uten å følge rigide planer. Dette er et iterativt design snarere enn et stort innledende prosjekt.
XP skiller seg betydelig fra tradisjonelle metoder, dvs. cascading, og unngår langvarige faser.
Hvordan er XP forskjellig fra andre smidige metoder?
Ekstrem programmering har i sin natur mye til felles med andre smidige metoder, men er også unik blant dem.
De fleste andre utviklingsmetodikk sier ikke mye, om noe, om hvordan jobben skal gjøres. XP, på den annen side, er veldig selvbevisst når det kommer til dette og legger stor vekt på programvareutviklingspraksis.
Scrum er et rammeverk for å hjelpe team med å utvikle komplekse prosjekter på en adaptiv måte. Scrum dikterer ikke hvordan utviklere gjør arbeidet sitt. XP legger som nevnt mye vekt på god programmeringspraksis.
Drafting BlogInnovazione.no Bilde nettløsninger
Dessuten handler XP åpenbart om programmering. Scrum, på den annen side, kan brukes på ethvert prosjekt som drar nytte av en iterativ tilnærming.
XP godtar endringer i komponentene. Teamene er bemyndiget og til og med oppfordret til å endre praksis basert på deres spesifikke behov. Scrum-guiden på sin side er fast på at "Selv om bare deler av Scrum kan implementeres, er ikke resultatet Scrum."
Scrum er også et rammeverk som må kompletteres med metoder og praksis for å få jobben gjort.
Dette betyr at arbeid i ekstrem programmering og Scrum er sterkt anbefalt.
Ifølge Kent Beck bør ikke et modent XP-team tildele stive roller, men innse at roller kan være nyttige for nye lag inntil de begynner å bremse eller gjøre samarbeid vanskelig.
La oss se på noen nøkkelroller:
Dette er praksisen som er tatt i bruk i XP. De er delt inn i tre hovedgrupper: programvareutvikling, arbeidsplass og prosjektledelse.
Parprogrammering: I XP skriver du kode i par som sitter på en maskin. Du og paret ditt snakker med hverandre mens dere analyserer, implementerer og tester funksjonen dere jobber med. Parprogrammering er spesielt god til å produsere kode med færre feil samtidig som den er engasjerende, morsom og slitsom.
Ti minutters grense: Påkrevd Gir 10 minutter å bygge hele prosjektet, inkludert å kjøre alle automatiserte tester, på maksimalt ti minutter. Denne grensen er for å holde testingen strømlinjeformet og effektiv.
Tester før programmering: implementer funksjoner ved å bruke test-først-tilnærmingen, også kalt testdrevet utvikling (TDD). TDD består av utvikling ved hjelp av en enkel iterativ prosedyre:
TDD gir flere fordeler.
Først tilbakemelding. Hvis det er vanskelig å skrive en test, er designet du leter etter eller som du har arvet sannsynligvis for komplekst, og du må forenkle det.
For det andre lar TDD programmerere stole på koden de skriver og skaper en fin looping-rytme der neste trinn alltid er klart.
Sist men ikke minst, å bruke TDD fra starten sikrer 100 % kodedekning. Testpakken blir da virkelig et sikkerhetsnett for fremtidige endringer, og oppmuntrer til koderefaktorering og skaper en god sirkel av kvalitet.
Inkrementell design: Praksisen med inkrementell design betyr at du må investere i applikasjonsdesignet hver dag, se etter muligheter for å fjerne duplisering og gjøre små forbedringer for å oppnå best mulig design for det systemet ditt trenger i dag.
Kontinuerlig integrering: I XP integrerer du arbeidet ditt i det delte hovedlageret flere ganger om dagen, og utløser en automatisk oppbygging av hele systemet. Integrering så tidlig og så ofte som mulig reduserer kostnadene ved integrering dramatisk ettersom det gjør fusjoner og logiske konflikter mindre sannsynlighet for å oppstå. Den avslører også miljø- og avhengighetsproblemer.
Delt kode (kollektivt eierskap): XP fremmer delt kode, eller kollektivt eierskap: hver utvikler er ansvarlig for all kode. Det oppmuntrer til informasjonsutveksling, reduserer teambus-faktoren og øker den generelle kvaliteten på hver modul hvis vi vurderer prinsippet om mangfold.
Enkel kodebase: Enkel kodebase er også kjent som "trunk-basert utvikling". Det betyr at det bare er én kilde til sannhet. Så i stedet for å utvikle seg isolert over lange perioder, slå sammen bidragene dine til én enkelt strøm tidlig og ofte. Funksjonsflagg bidrar til å begrense bruken av funksjoner til de er ferdige.
Daglig utdeling: utplassering i produksjon minst én gang om dagen er en logisk konsekvens av kontinuerlig integrasjon:. Faktisk går mange team i dag enda lenger og praktiserer kontinuerlig implementering. Det vil si at når noen blir med på hovedlinjen, distribueres applikasjonen til produksjon.
Kode og tester: Denne praksisen betyr at kildekoden, inkludert tester, er den eneste permanente artefakten til et programvareprosjekt. Å engasjere seg i generering av andre typer artefakter, inkludert dokumentasjon, er ofte bortkastet fordi det ikke genererer reell verdi for kunden.
Hvis du trenger andre artefakter eller dokumenter, gjør en innsats for å generere dem fra produksjonskode og tester.
Årsaksanalyse: Når en defekt kommer i produksjon, ikke bare korriger feilen. Sørg for at du finner ut hva som forårsaket det i utgangspunktet, hvorfor du og lagkameratene dine ikke klarte å forhindre skrens. Ta deretter skritt for å sikre at det ikke skjer igjen.
Sitt sammen: I XP foretrekker team å jobbe sammen i en åpen plass. Denne praksisen fremmer kommunikasjon og en følelse av å tilhøre et team.
Hele laget: Alle som trengs for å lykkes med prosjektet er en del av XP-teamet. Dette er svært kontekstuelt – forskjellig for hvert lag – og dynamisk, det kan endre seg i et team.
Informasjonsarbeidsområder: Et informasjonsarbeidsområde bruker det fysiske rommet til teamet til å vise informasjon som lar hvem som helst vite, med et øyeblikk, fremdriften til prosjektet. Hvordan dette gjøres kan variere, fra fysiske notater og grafer til skjermbilder som viser Kanban-tavler og dashbord fra prosjektstyringsprogramvare.
Energisk arbeid: I XP jobber du bare så lenge du kan gjøre energisk arbeid. Arbeidstiden skal begrenses til maks 40 per uke.
Analisi- Skriv brukerkrav i et format kjent som brukeranalyse. En brukeranalyse har et kort, beskrivende navn og også en kort beskrivelse av hva som skal implementeres.
Slack: Når du planlegger en syklus, legg til mindre oppgaver som teamet kan forlate hvis behovet oppstår. Flere historier kan alltid legges til hvis teamet leverer for mye.
Sykluser (månedlig og ukentlig): Utvikling i XP skjer i to hovedsykluser: den ukentlige syklusen og den månedlige syklusen.
Møter, sykluser, planlagte utgivelser: Utvikling i XP fungerer i to hovedsykluser: den ukentlige syklusen og den kvartalsvise syklusen. Opprinnelig anbefalte Kent Beck en to-ukers syklus, men endret det i den andre utgaven av boken.
Ukentlig syklus: den ukentlige syklusen er "pulsen" til et XP-prosjekt. Syklusen starter med et møte der klienten velger hvilke historier han vil lage i løpet av uken. I tillegg vurderer teamet arbeidet sitt, inkludert forrige ukes fremgang, og tenker på måter å forbedre prosessen på.
Månedlig syklus: Hver måned reflekterer og identifiserer teamet forbedringsmuligheter i prosessen deres. Oppdragsgiver velger ett eller flere temaer for den måneden, sammen med analysene i disse temaene.
Hvordan begynne å jobbe med ekstrem programmering?
Tekniske ferdigheter og XP-vaner kan være vanskelig å lære. Noen av praksisene kan virke fremmede for programmerere som ikke er vant til dem.
Ercole Palmeri
Coveware by Veeam vil fortsette å tilby responstjenester for cyberutpressing. Coveware vil tilby kriminaltekniske og utbedringsmuligheter...
Prediktivt vedlikehold revolusjonerer olje- og gasssektoren, med en innovativ og proaktiv tilnærming til anleggsledelse...
UK CMA har utstedt en advarsel om Big Techs oppførsel i markedet for kunstig intelligens. Der…
"Green Houses"-dekretet, formulert av EU for å forbedre energieffektiviteten til bygninger, har avsluttet sin lovgivningsprosess med...
