Det høres kanskje rart ut, men omtrent 75 % av programvaren kommer ikke ut til folk i det hele tatt. På den annen side er det mange selskaper som produserer programvare i enorme mengder. Alt dette og mye mer forplikter programmerere til å redusere utviklingskostnadene. Og for dette må du forstå interessene til kunden, hele tiden samarbeide med ham for til slutt å skape nøyaktig det han trenger.

Programvareutviklingsmetodikk Ekstrem programmering(oppfinner - Kent Beck) får økende anerkjennelse for å maksimere enkelheten i designprosesser og direkte utvikling av programvareprodukter i et miljø med raskt skiftende krav.

Det er bare 5 verdier for ekstrem programmering: enkelhet, kommunikasjon, tilbakemelding, mot og respekt ("respekt" ble lagt til i den siste utgaven av XP). De 12 XP-praksisene er rettet mot å realisere disse kjerneverdiene. La oss se nærmere på dem. I tillegg til sannhetene som er kjent for mange, vil jeg legge til mine kommentarer om praksisene, basert på min praktiske erfaring.

Planleggingsspill I XP er planlegging en viktig del av utviklingen. Det at planene plutselig kan endres, tas med helt i starten. Kundens appetitt følger med å spise, og du må alltid holde situasjonen under kontroll. Kommunikasjon med kunden bør skje så ofte som mulig. Dette vil tillate deg å mer nøyaktig vurdere tidspunktet for oppgaver og gjøre de nødvendige justeringene om nødvendig.

Små utgivelser. Uansett hvor vakkert produktet er beskrevet, kan alle gledene ved bruken bare forstås ved å jobbe med det. Rapid Release-metodikken lar deg forstå hva kunden ønsker ved å gi tidlig utgivelse av fungerende versjoner av produktet.

Kommentar: Som praksis viser, den første tidlig versjon kan gjøres på 2-8 uker, uavhengig av forventet kompleksitet av produktet. Det er ønskelig at den første versjonen av produktet (minst de første iterasjonene) gjøres av 2 personer som bruker én datamaskin. I dette tilfellet kommer utformingen av systemet veldig raskt. Da kan du tiltrekke deg flere ved å omfordele par.

Metafor. Det er mye lettere for en person å huske forskjellene mellom to like objekter enn å kjenne strukturen til et objekt fullstendig. Metaformetodikken foreslår å sammenligne systemet (eller en av dets moduler) med dets motstykker for å lette kommunikasjonen i teamet og en dypere forståelse av systemet som helhet.

Kommentar: Nok vanskelig praksis, selv om det ved første øyekast virker enkelt. Å komme opp med metaforer for hovedmodulene i systemet er ikke lett, men veldig nyttig. Mange programmerere omtaler "systemmetaforen" som en ledelsespraksis, men det virker for meg som utviklere trenger det mer. Riktig valg metaforer hjelper til syvende og sist programmerere til å komme opp med gode navn på klasser og metoder, noe som alltid positivt påvirker utformingen av systemet som helhet.

Enkel implementering (enkel design). XP foreslår å holde programkoden enkel. Hvorfor gjøre livet vanskelig for deg selv når et enkelt program er lettere å forstå, vedlikeholde og mindre utsatt for feil.

Testdrevet utvikling Extreme Programming anbefaler å sjekke eksisterende kode så ofte som mulig. Det er derfor denne teknikken praktiseres. Tester skrives allerede før et stykke kode er skrevet. Dette lar deg bedre forstå oppgavene og gir mulighet til å sjekke koden så snart den er skrevet.

Kommentar: Det er mange fordeler med denne tilnærmingen.

For det første er det å skrive tester før du skriver kode en av de beste måtene å sikre at disse testene er på plass.

For det andre elimineres motvilje mot å teste noen "åpenbare" grener av programkjøring, om ikke annet fordi det ikke er noen kode ennå :). Vel, da, med parprogrammering, vil testene virkelig være lakoniske og av høy kvalitet.

For det tredje øker tester programmerernes selvtillit når de ønsker å refaktorisere.

Refaktorering (designforbedring).Å legge til ny funksjonalitet og øke mengden kode gjør det vanskeligere å utvikle og finne feil. Løsningen på dette problemet er konstant refaktorisering av koden. Refaktorering er en veldig kraftig og nyttig ting og fortjener ikke bare en egen artikkel, men hele bøker.

Kommentar: Ikke glem verdien av "mot" og ikke vær redd for å bryte systemet under refactoring. Tester vil vise hva som er ødelagt og du vil raskt fikse feilene. Selv om testene ikke dekket noen aspekter, og du vil ikke legge merke til noen potensielle problemer– det er greit, alt kan alltid fikses. Hovedsaken er at utformingen av systemet er blitt enklere og klarere, og et komplekst system er en kilde til mye mer forferdelige feil enn feil som har oppstått som følge av refaktorisering.

Parprogrammering Periodisk gjennomgang av andres kode har en positiv effekt på kvaliteten. Dette prinsippet er kjernen i parprogrammering. Den består i at to programmerere jobber samtidig på én datamaskin. Merkelig nok dobles ikke utviklingskostnadene, men holder seg på omtrent samme nivå. På den annen side forbedrer parprogrammering kvaliteten på koden, implisitt og eksplisitt overføring av kunnskap utføres, samt konstant kommunikasjon mellom utviklere.

Kollektivt kodeeierskap. Som oftest, når man utvikler programvareprodukter, er én person ansvarlig for en viss del av koden. Ferie, oppsigelse eller sykdom (Gud tilgi meg) til en av programmererne kan bremse produktutviklingen alvorlig. Det er derfor i XP minst to personer er ansvarlige for ett stykke kode, og enhver programmerer kan gjøre endringer i noen del av programkoden.

Kontinuerlig integrering. Team med XP-programmerere lager nye bygg av produktet flere ganger om dagen. Dette gjør at alle programmerere kan være klar over hva som skjer og forhindre integrasjonsproblemer med andre produkter og deler av koden.

Kommentar: I dag forårsaker denne praksisen et smil eller til og med misforståelse blant unge fagfolk, fordi det er svn, perforce, cvs og mye mer. Det pleide å være at to karer satte seg ned i nærheten av hoveddatamaskinen og manuelt fusjonerte med hovedgrenen av prosjektet.

Likevel er denne praksisen fortsatt relevant. Ingen kansellerte felleseie av koden: hvis du ikke vil kaste bort tid på en stor og kompleks fusjon, bruk tid på flere små fusjoner :).

40 timers uke (førti timers uke). For sakens skyld er folk i stand til mange ting, men ekstrem programmering er kategorisk mot selvoppofrelsen til utviklere. En person må hvile, det er da han når maksimal ytelse i arbeidstiden.

Send det gode arbeidet ditt i kunnskapsbasen er enkelt. Bruk skjemaet nedenfor

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

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

Innhold

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

Introduksjon

Ekstrem programmering, ofte referert til som XP, er en utviklingsdisiplin programvare og gjøre forretninger innen å lage programvareprodukter, som fokuserer innsatsen til begge parter (programmerere og forretningsmenn) på vanlige, ganske oppnåelige mål. XP-team produserer kvalitetsprogramvare med svært høy hastighet... Teknikkene som er en del av XP-disiplinen er valgt fordi de er basert på menneskelig kreativitet og aksepten av at en person er en ustabil og feilutsatt skapning.

XP presenteres ofte som en samling av teknikker, men XP i seg selv er ikke en målstrek. Det er ikke nødvendig å øve og utvikle XP bedre og bedre for å få den etterlengtede gullstjernen på slutten av denne prosessen. Tvert imot er XP startstreken. XP stiller spørsmålet: "Hvor minimal kan innsatsen vår være slik at vi kan fortsette å produsere kvalitetsprogramvare?"

Extreme Programming er en forenklet produksjonsmetodikk for små til mellomstore utviklingsteam. programvareprodukt i møte med uklare eller raskt skiftende krav.

1. Hva er XP?

Ekstremmlinprogrammrasjonering(eng. Ekstrem Programmering, XP) er en av de smidige programvareutviklingsmetodene. Forfatterne av metodikken er Kent Beck, Ward Cunningham, Martin Fowler og andre.

XP er en forenklet, effektiv, fleksibel, forutsigbar, vitenskapelig solid og svært fornøyelig måte å utvikle programvare på med lav risiko. XP skiller seg fra andre teknikker på følgende måter:

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

XP bruker inkrementell planlegging, noe som resulterer i at en overordnet prosjektplan dukker opp ganske raskt, men dette innebærer at denne planen utvikler seg gjennom hele prosjektets levetid.

XP bruker en fleksibel tidslinje for å levere funksjonalitet for å forbedre responsen på endrede virksomheter og endrede kundekrav.

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

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

XP er basert på en utviklende designprosess som varer like lenge som selve systemet.

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

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

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

XP-metodikken er utviklet for å jobbe med prosjekter som kan arbeides med av to til ti programmerere som ikke er begrenset av det stive rammeverket til det eksisterende datamiljøet, og hvor alt nødvendig arbeid knyttet til testing kan fullføres innen én dag.

2.Hvordan starte ekstrem programmering

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

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

Ekstrem programmering tilbyr en ferdig løsning: hold alt så enkelt som mulig, hold kunden hos deg eller hold deg til kunden selv, la ham aktivt følge utviklingsprosessen, ta godt imot endringene – og suksess er nesten garantert.

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

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

Ekstrem programmering spør oss: hvorfor ikke dyrke mot? Det er tross alt veldig viktig i jobben. Er det mulig, uten mot, å ta ansvar for gjennomføringen av en oppgave, og til og med innenfor en bestemt tidsramme? Er det mulig, uten mot, å innse at du har kommet til en blindvei, å ta et skritt tilbake og se etter en løsning? Og til slutt, hva vil tillate utvikleren å innrømme sin feil ved å evaluere oppgaven og advare andre om den i tide, i stedet for å konfrontere dem med et faktum når alle fristene har utløpt? Fordelene med mot er åpenbare, og enhver suksess, selv i den minste oppgaven, er i stand til å utvikle dette motet.

3. XP-teknikker

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

De grunnleggende prinsippene for "live" programvareutvikling er registrert i "live" utviklingsmanifestet, som dukket opp i 2000.

· Personene som er involvert i prosjektet og deres kommunikasjon er viktigere enn prosessene og verktøyene.

· Et arbeidsprogram er viktigere enn omfattende dokumentasjon.

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

· Å utarbeide endringer er viktigere enn å følge planer.

"Levende" metoder dukket opp som en protest mot overdreven byråkratisering av programvareutvikling, en overflod av sidedokumenter som ikke er nødvendige for å oppnå det endelige resultatet, som må utarbeides i løpet av et prosjekt i samsvar med de fleste "tunge" prosesser, ytterligere arbeide for å støtte en fast organisasjonsprosess, som dette kreves innenfor for eksempel CMM. De fleste av slike arbeider og dokumenter er ikke direkte relatert til programvareutvikling og kvalitetssikring, men er ment å overholde de formelle klausulene i kontrakter for utvikling, innhente og bekrefte sertifikater for samsvar med ulike standarder.

Live-metoder lar de fleste av utviklernes innsats fokusere på de faktiske utviklingsoppgavene og møte brukernes reelle behov. Fraværet av en haug med dokumenter og behovet for å opprettholde dem i en sammenhengende tilstand lar deg reagere raskere og mer effektivt på endringer i krav og i miljøet der det fremtidige programmet må fungere.

Ikke desto mindre har XP sitt eget utviklingsprosessdiagram (selv om, generelt sett, den mye brukte forståelsen av "utviklingsprosessen" som et ganske rigid handlingsplan motsier selve ideen om "livlighet" i utviklingen), vist i figur 1 .

I følge XP-forfatterne handler ikke denne teknikken så mye om å følge noen generelle ordninger handlinger, hvor mange bruk av en kombinasjon av følgende teknikker. Hver teknikk er imidlertid viktig, og uten den anses utvikling som ikke-XP, ifølge Kent Beck, en av forfatterne av denne tilnærmingen sammen med Ward Cunningham og Ron Jeffries.

· Boplanlegger (planleggerspill)

Hans oppgave er å finne ut så raskt som mulig hvor mye arbeid som må gjøres før neste versjon av programvaren. Beslutningen tas først og fremst på grunnlag av kundens prioriteringer (dvs. hans behov, hva han trenger fra systemet for å drive sin virksomhet mer vellykket) og for det andre på grunnlag av tekniske vurderinger(dvs. estimater av kompleksiteten i utviklingen, kompatibilitet med resten av systemet, etc.). Planer endres så snart de begynner å være uenige med virkeligheten eller kundens ønsker.

Ris.1 XP arbeidsflytdiagram

· Hyppigendringvversjon (litenutgivelser)

Den aller første fungerende versjonen bør være tilgjengelig så snart som mulig og bør brukes umiddelbart. Neste versjoner forberedt med ganske korte intervaller (fra flere timer med små endringer i lite program, opptil en måned eller to med seriøs behandling stort system). Utgivelser av et produkt bør utgis så ofte som mulig. Arbeidet med hver versjon bør ta så kort tid som mulig. Dessuten bør hver versjon være meningsfull nok ut fra et nyttesynspunkt for virksomheten.

· Metafor (metafor) systemer

Metaforen i en ganske enkel og forståelig form for kommandoen skal beskrive den grunnleggende mekanismen til systemet. Dette konseptet ligner arkitektur, men det burde være mye enklere, bare i form av en eller to setninger, beskriver hovedessensen av den vedtatte tekniske løsninger.

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

Systemmetaforen er analog med det de fleste teknikker kaller arkitektur. Systemmetaforen gir teamet en ide om hvordan systemet fungerer for øyeblikket, hvor nye komponenter legges til, og hvilken form de bør ha.

· Enkeldesignløsninger (enkeldesign)

Til enhver tid bør systemet utformes så enkelt som mulig. Det er ikke nødvendig å legge til funksjoner på forhånd - bare etter at du har bedt om det. All unødvendig kompleksitet fjernes så snart den er funnet.

XP går ut fra det faktum at under arbeidet kan betingelsene for problemet endres gjentatte ganger, noe som betyr at produktet som utvikles ikke bør være fullstendig og fullstendig utformet på forhånd. Hvis du helt i begynnelsen av arbeidet ditt prøver å designe systemet i detalj fra start til slutt, kaster du bort tid. XP forutsetter at design er en så viktig prosess at den må utføres kontinuerlig gjennom hele prosjektets varighet. Design bør utføres i små trinn, med hensyn til stadig skiftende krav. Til enhver tid prøver vi å bruke det enkleste designet som passer den aktuelle oppgaven. Samtidig endrer vi det etter hvert som betingelsene for problemet endres.

· Utvikling avpåbasistesting (test- kjørtutvikling)

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

XP fokuserer på to typer testing:

enhet testing;

b akseptansetesting.

ekstrem programmeringsprogramvare

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

Aksepttester sikrer at systemet faktisk fungerer som annonsert. I tillegg lar aksepttester deg kontrollere at produktet som utvikles fungerer korrekt.

For XP er en tilnærming kalt TDD (Test Driven Development) mer prioritert, først skrives det en test som ikke består, deretter skrives koden for å få testen til å bestå, og etter det refaktoreres koden.

· Konstantbehandling (refaktorisering)

Det er ingen hemmelighet at tillegget av hver ny funksjonalitet og veksten av koden kompliserer utviklingen, identifiserer feil og gjør påfølgende endringer. Et av triksene med ekstrem programmering er å kompensere for tillegg av funksjonalitet med kodeforbedringer. Dette er kodeomarbeiding, eller refaktorisering.

Programmerere omarbeider hele tiden systemet for å eliminere unødvendig kompleksitet, øke kodeforståelighet, øke fleksibiliteten, men uten endringer i oppførselen, som kontrolleres av en kjøring etter hver testomarbeiding. Samtidig foretrekkes mer elegante og fleksible løsninger, sammenlignet med å bare gi ønsket resultat. Ulykket omarbeidede komponenter bør identifiseres under testkjøring og rulles tilbake til den siste konsistente tilstanden (sammen med deres avhengige komponenter).

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

· Programmeringi par (parprogrammering)

Erfarne utviklere har lagt merke til at periodisk gjennomgang av andres kode har en positiv effekt på kvaliteten. Ekstreme programmeringsmestere har utviklet denne tilnærmingen: under utviklingen blir koden stadig revidert gjennom en teknikk som kalles parprogrammering.

Kodingen gjøres av to programmerere på én datamaskin. Sammenkobling er vilkårlig og varierer fra oppgave til oppgave. Den i hvis hender tastaturet prøver den beste måten løse dagens problem. Den andre programmereren analyserer arbeidet til den første og gir råd, tenker over konsekvensene av visse avgjørelser, nye tester, mindre direkte, men mer fleksible løsninger. Om nødvendig overføres tastaturet fritt fra det ene til det andre. Under arbeidet med prosjektet er ikke parene fikset: det anbefales å blande dem slik at hver programmerer i teamet har en god forståelse av hele systemet. Dermed forbedrer parprogrammering teamkommunikasjonen.

· Kollektivbesittelsekode (kollektiveie)

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

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

· Konstantintegrering (kontinuerligeintegrering)

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

Hvis du integrerer systemet under utvikling ofte nok, kan du unngå de fleste av de tilhørende problemene. I tradisjonelle metoder utføres integrasjon vanligvis helt på slutten av arbeidet med produktet, når det vurderes at alle bestanddeler av systemet som utvikles er helt klare. I XP utføres systemomfattende kodeintegrasjon flere ganger om dagen, etter at utviklerne har forsikret seg om at alle enhetstester fungerer som de skal.

Til tross for sin enkelhet har denne teknikken sine egne bruksregler, for eksempel suksessen til de eksisterende enhetstestene for den integrerte funksjonaliteten, tilstedeværelsen av funksjonelle eller aksepterte tester, og selvfølgelig muligheten til å rulle tilbake til tidligere tilstand... Som regel blir integrering og løsning av relaterte vanskeligheter utført på separat datamaskin et par programmerere. Dette minimerer risikoen for uønskede integrasjonskonsekvenser.

· 40 timerjobberen uke

Overtid blir sett på som et tegn på store problemer i prosjektet. Overtidsarbeid i 2 uker på rad er ikke tillatt - dette sliter ut programmerere og gjør arbeidet deres mye mindre produktivt.

En person, spesielt hvis han er en programmerer, er i stand til mange ting for virksomhetens skyld: å være sent på jobb, gå på jobb i helgene, gi opp ferie, holde seg våken i flere dager ved å sitte ved tastaturet ... Generelt , hva kan du ikke gjøre for favorittaktivitetens skyld. Men ekstrem programmering er kategorisk mot slik selvoppofrelse og brudd på akseptert arbeidslov.

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

Men det viktigste er at en person trenger god hvile for å opprettholde helse og ytelse. Åtte timers arbeidsdag og femdagers arbeidsuke er satt nøyaktig av hensyn til maksimal produktivitet. I mange vestlige bedrifter blir det å slutte for sent fra jobben sett på som dårlig fremgang eller manglende evne til å styre arbeidstiden på riktig måte. I de fleste tilfeller er dette tilfellet. Og fra et medisinsk synspunkt fører forsinkelser på jobben til konstant tretthet, irritabilitet og redusert hjerneaktivitet. Er det effektivt? Hvordan organisere konstant åpen kommunikasjon mellom utviklere i et slikt team, og vil parprogrammering være mulig? Svaret er negativt. Normene er normer, og de bør følges.

· Slå påkundevkommando (på- nettstedetkunde)

Hovedproblemet med programvareutvikling er mangelen på kunnskap hos programmerere i det utviklede fagområdet. Ekstrem programmering har også funnet en vei ut av denne situasjonen. Nei, dette er ikke et praksisopphold for en utvikler ved kundens bedrift - da vil han ikke programmere. Det er tvert imot kundens medvirkning i utviklingsprosessen.

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

Mange tviler på muligheten for å involvere kunden i utviklingsprosessen. Faktisk er kunder forskjellige. Hvis det ikke er mulig å tiltrekke seg en kunde eller hans representant, er det noen ganger tilrådelig å midlertidig ansette en spesialist i området som utvikles. Et slikt trinn vil redusere forvirring i arbeidet, øke hastigheten på utviklingen og bringe prosjektet nærmere det kunden ønsker å få. Dette kan også være gunstig fra et økonomisk synspunkt: Tross alt overstiger lønnen til en programmerer noen ganger betydelig lønnen til spesialister i andre bransjer.

· Brukkodehvordanmidlerkommunikasjon

Kode blir sett på som det viktigste kommunikasjonsmiddelet i et team. Klarhet i koden er en av våre toppprioriteringer. Overholdelse av kodestandarder som gir denne klarheten er avgjørende. Slike standarder, i tillegg til klarheten i koden, må sikre at uttrykk holdes på et minimum (ingen duplisering av kode og informasjon) og må aksepteres av alle teammedlemmer.

· Åpenjobberrom (åpenarbeidsområde)

Teamet holder til i ett rom som er stort nok til å lette kommunikasjon og idédugnad ved planlegging og viktige tekniske beslutninger.

· Forandringenreglerpåbehovet (bareregler)

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

Som du kan se av teknikkene som brukes, er XP utformet for å brukes i små team (ikke mer enn 10 programmerere), noe som også understrekes av forfatterne av denne teknikken. Den større teamstørrelsen ødelegger den enkle kommunikasjonen som er nødvendig for suksess og gjør mange av disse teknikkene umulige.

3.1 Grunnleggende XP-triks

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

Tilbakemelding i fin skala

o Testdrevet utvikling

o Planleggingsspill

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

o Parprogrammering

Kontinuerlig, ikke batch prosess

o Kontinuerlig integrasjon

o Refaktorering (designforbedring, Refaktorering)

o Hyppige små utgivelser

En forståelse som alle deler

o Enkelhet (enkel design)

o Systemmetafor

o Kollektivt eierskap Samlet kodeeierskap eller utvalgte kollektive mønstreeierskap

o Kodestandard eller Kodekonvensjoner

Programmerers velferd:

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

Spilletvplanlegger

Vår verden er for flyktig og uforutsigbar til å stole på situasjonens konstanthet. Det samme skjer i programvareutvikling: om et sjeldent system kan vi si at det endelige utseendet var kjent på forhånd i detalj helt i begynnelsen av utviklingen. Vanligvis kommer kundens appetitt med å spise: han ønsker hele tiden å endre noe, forbedre noe og kaste noe helt ut av systemet. Dette er volatiliteten i kravene som alle er så redde for. Heldigvis er en person gitt evnen til å forutsi mulige alternativer og dermed holde situasjonen under kontroll.

I ekstrem programmering er planlegging en integrert del av utviklingen og det tas hensyn til at planer kan endres helt fra starten. Planleggingsspillet er dette omdreiningspunktet, en teknikk som lar deg forutse situasjonen og smertefritt tåle endringer. I løpet av et slikt spill kan du raskt samle kjente krav til systemet, evaluere og planlegge deres utvikling i samsvar med prioriteringen.

Som alle andre spill har planlegging sine deltakere og sin hensikt. Nøkkelaktøren er selvfølgelig kunden. Det er han som informerer om behovet for denne eller hin funksjonaliteten. Programmerere, derimot, gir et grovt estimat for hver funksjonalitet. Det fine med planleggingsspillet ligger i enhet av formål og solidaritet mellom utvikleren og kunden: hvis de vinner, vinner alle, hvis de taper, taper alle. Men samtidig går hver deltaker sin egen vei til seier: kunden velger de viktigste oppgavene i samsvar med budsjettet, og programmereren evaluerer oppgavene i samsvar med hans evner for implementering.

Ekstrem programmering forutsetter at utviklere er i stand til å bestemme selv hvor lang tid de vil bruke på å fullføre oppgavene sine og hvem av dem som vil være mer villige til å løse en oppgave, og hvem som vil være mer villige til å løse en annen.

I en ideell situasjon bør et planleggingsspill som involverer en kunde og en programmerer gjennomføres hver 3.-6. uke, før neste utviklingsiterasjon starter. Dette gjør det enkelt å gjøre justeringer basert på suksesser og fiaskoer fra forrige iterasjon.

4. Fordeler og ulemper

Fordelene med XP, hvis det kan brukes, er stor fleksibilitet, evnen til raskt og nøyaktig å gjøre endringer i programvaren som svar på endrede krav og individuelle ønsker fra kundene, den høye kvaliteten på den resulterende koden og mangelen på behov for å overbevise kundene om at resultatet oppfyller deres forventninger.

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

5. Brukshistorie

XP som en samling av de beskrevne teknikkene ble først brukt under arbeidet med C3-prosjektet (Chrysler Comprehensive Compensation System, utvikling av et system for regnskapsføring av ansattes fordeler for Daimler Chrysler). Av de 20 deltakerne i dette prosjektet publiserte 5 (inkludert de 3 hovedforfatterne av XP nevnt ovenfor) 3 bøker og et stort antall artikler om XP under selve prosjektet og senere. Dataene nedenfor illustrerer utfordringene til noen XP-teknikker når de brukes på ganske komplekse prosjekter.

Prosjektet startet i januar 1995. Fra mars 1996, etter inkluderingen av Kent Beck, kjørte den med XP. På dette tidspunktet hadde han allerede gått utover budsjettet og planene for trinnvis implementering av funksjoner. Utviklingsteamet ble nedbemannet, og i rundt et halvt år etter det utviklet prosjektet seg ganske vellykket. I august 1998 dukket det opp en prototype som kunne betjene rundt 10 000 ansatte. Prosjektet var opprinnelig forventet å være fullført i midten av 1999, og den resulterende programvaren skulle brukes til å administrere betalinger til selskapets 87 000 ansatte. Den ble stoppet i februar 2000 etter 4 år med XP på grunn av fullstendig manglende overholdelse av tidslinjer og budsjett. Programvaren har aldri blitt brukt til å jobbe med data om mer enn 10 000 ansatte, selv om den har vist seg å takle dataene til 30 000 ansatte i selskapet. Personen som spilte rollen som kunden inkludert i teamet i prosjektet, sluttet etter noen måneder med slikt arbeid, ikke i stand til å tåle belastningen, og fikk ikke en tilstrekkelig erstatning før slutten av prosjektet.

Konklusjon

Alle de ovennevnte metodene er samlet av en grunn. Deres konsistente kombinasjon er i stand til å introdusere utviklingsprosessen i intellektuell resonans, øke kvaliteten på produktet betydelig og bringe tidspunktet for utgivelsen nærmere. Hovedsjarmen med all ekstrem programmering er forutsigbarhet og minimalisering av utviklingskostnader; å gi kunden produktet han ønsker å motta på utgivelsestidspunktet; og selvfølgelig kommunikasjon og opplæring av utviklere på jobb.

Meningene om den foreslåtte teknikken kan variere. Det er viktig å forstå at ekstrem programmering ikke er ment å erstatte eksisterende utviklingsteknologier. Tvert imot lar XP deg gi ekstra fart til lag som bruker tradisjonelle tilnærminger. Du bør ikke lete etter svar på alle spørsmålene som dukker opp her. Dette er ikke en programmeringsteknologi, men snarere en teknologi for organisering av arbeid, og det er i denne formen den har rett til å eksistere.

Skrevet på Allbest.ru

Lignende dokumenter

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

test, lagt til 06.04.2011


De viktigste stadiene av programvareutvikling (programvarepakke), analyse av systemkrav. Metode trinn for trinn detaljering... Programmeringsspråk på lavt nivå og høy level(imperativ, objektorientert, funksjonell, logisk).

presentasjon lagt til 13.10.2013


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

opplæring, lagt til 26.10.2013


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

presentasjon lagt til 30.04.2014


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

semesteroppgave lagt til 21.06.2014


Konseptet og nøkkelforskjellen til distribuert programvareutvikling, dens fordeler og ulemper. Konseptuell løsning og valg av type utbygging. Funksjoner av åpen kildekode-programvare. Open Source idé og utvikling.

semesteroppgave lagt til 14.12.2012


Konsept Livssyklus programvare. To typer aktiviteter differensiert i tekniske prosjekter: design og produksjon. Hovedprinsippene i det smidige manifestet. Grunnleggende prinsipper for ekstrem programmering.

presentasjon lagt til 14.08.2013


Internasjonal standard for programmeringsspråket Pascal. Objektorienterte programmeringsteknikker i Turbo Pascal. Symboler på språket, dets alfabet. Stadier av programutvikling. Konseptet med algoritmer og algoritmer. Strukturen til programmer i Pascal.

semesteroppgave, lagt til 28.02.2010


Moderne verktøy programvareutvikling for SUTP. Universelle programmeringsspråk og deres sammenligning med SCADA-systemer. Programvareutvikling ved hjelp av Sh9327 flerkanals måletransdusere.

avhandling, lagt til 13.07.2011


Grunnleggende teknikker for arbeid i miljøet Delphi programmering... Funksjoner av teknologien for å lage de enkleste applikasjonene. Arbeide med komponenter i applikasjonsutviklingsmiljøet. Inntasting, redigering, valg og utdata av informasjon. Aspekter ved bruk av forgreningsstrukturen.

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

Forfatteren av teknikken er den amerikanske utvikleren Kent Beck. På slutten av 1990-tallet ledet han Chrysler Comprehensive Compensation System-prosjektet og var banebrytende for praksisen med ekstrem programmering der. Han beskrev sin erfaring og konseptet han skapte i boken Extreme Programming Explained, utgitt i 1999. Andre bøker fulgte med detaljer om XP-praksis. Ward Cunningham, Martin Fowler og andre var også involvert i dannelsen av metodikken.

XP skiller seg fra andre smidige metoder ved at den er anvendelig bare innen programvareutvikling. Den kan ikke brukes i annen virksomhet eller Hverdagen som scrum, kanban eller lean.

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

XP-metodikken er bygget rundt fire prosesser: koding, testing, design og lytting. I tillegg har ekstrem programmering verdier: enkelhet, kommunikasjon, tilbakemeldinger, mot og respekt.

1. Hele laget

Alle prosjektdeltakere som bruker XP jobber som ett team. Det inkluderer nødvendigvis en representant for kunden, det er bedre hvis det er en reell sluttbruker av produktet, som forstår virksomheten. Kunden stiller krav til produktet og prioriterer implementering av funksjonalitet. Forretningsanalytikere kan hjelpe ham. På utøverens side inkluderer teamet utviklere og testere, noen ganger en trener som leder laget, og en leder som gir teamet ressurser.

2. Planleggingsspillet

Planlegging i XP er en to-trinns prosess – utgivelsesplanlegging og iterasjonsplanlegging.

Under utgivelsesplanleggingen møter teamet av programmerere kunden for å finne ut hvilken funksjonalitet han ønsker å få til neste utgivelse, det vil si om 2-6 måneder. Siden kundens krav ofte er vage, konkretiserer utviklerne dem og deler dem opp i deler, hvor implementeringen ikke tar mer enn én dag. Det er viktig at kunden forstår driftsmiljøet produktet skal operere i.

Oppgaver registreres på kort, og kunden bestemmer deres prioritet. Deretter anslår utviklerne hvor lang tid det vil ta for hver oppgave. Når oppgavene er beskrevet og evaluert, gjennomgår kunden dokumentasjonen og gir klarsignal til å komme i gang. For å lykkes med prosjektet, er det avgjørende at kunden og teamet av programmerere spiller på samme felt: kunden velger den virkelig nødvendige funksjonaliteten innenfor budsjettet, og programmererne matcher kundens krav tilstrekkelig med deres evner.

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

Iterasjonsplanlegging gjennomføres Hver andre uke, noen ganger mer eller sjeldnere. Kunden må være tilstede: han bestemmer funksjonaliteten for neste iterasjon og gjør endringer i kravene til produktet.

3. Hyppige versjonsutgivelser

I XP utgis versjoner ofte, men med lite funksjonalitet. For det første er den lille funksjonaliteten enkel å teste og holder hele systemet i gang. For det andre, hver iterasjon, mottar kunden en del av funksjonaliteten som gir forretningsverdi.

4. Tilpassede tester

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

5. Kollektivt eierskap til koden

I XP kan enhver utvikler redigere hvilken som helst kodebit. koden er ikke tildelt forfatteren. Hele teamet eier koden.

6. Kontinuerlig kodeintegrasjon

Dette betyr at nye deler av koden umiddelbart legges inn i systemet - XP-team laster opp et nytt bygg med noen få timers mellomrom og oftere. Først kan du umiddelbart se hvordan de siste endringene påvirker systemet. Hvis en ny kode knekker noe, er det mange ganger enklere å finne og fikse feilen enn etter en uke. For det andre jobber teamet alltid med siste versjon systemer.

7. Kodestandarder

Når alle eier koden, er det viktig å ta i bruk enhetlige kodestandarder slik at koden ser ut som den er skrevet av en enkelt fagperson. Du kan utarbeide dine egne standarder eller ta ferdige.

8. Metafor av systemet

Metaforen til et system er å sammenligne det med noe kjent for å forme teamets visjon. Vanligvis er systemmetaforen tenkt på av den som utvikler arkitekturen og representerer hele systemet.

9. Jevnt tempo

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

10. Testdrevet utvikling

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

11. Parprogrammering

Se for deg to utviklere ved samme datamaskin som jobber med ett stykke produktfunksjonalitet. Dette er parprogrammering, XPs mest kontroversielle praksis. Det gamle ordtaket "ett hode er bra, to er bedre" illustrerer essensen av tilnærmingen perfekt. Av de to alternativene for å løse problemet, velges det beste, koden optimaliseres umiddelbart, feil fanges opp selv før de blir begått. Som et resultat har vi ren kode, der to utviklere er godt kjent på en gang.

12. Enkel design

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

13. Refaktorering

Refaktorering er prosessen med å kontinuerlig forbedre utformingen av et system for å møte nye krav. Refaktorering inkluderer å fjerne duplikatkode, forbedre samhørighet og redusere paring. XP involverer konstante refactorings, så utformingen av koden holdes alltid enkel.

XP fordeler og ulemper

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

Fordelene med ekstrem programmering gir mening når et team utnytter minst én av XP-praksisene fullt ut. Så hva er det verdt å prøve:

• kunden mottar akkurat det produktet han trenger, selv om han i begynnelsen av utviklingen ikke selv representerer det endelige utseendet nøyaktig
• teamet gjør raskt endringer i koden og legger til ny funksjonalitet gjennom enkel kodedesign, hyppig planlegging og utgivelser
• kode fungerer alltid gjennom kontinuerlig testing og kontinuerlig integrasjon
• teamet vedlikeholder enkelt koden, fordi den er skrevet i henhold til en enkelt standard og refaktoreres konstant
• rask utviklingstakt på grunn av parprogrammering, ingen omarbeiding, tilstedeværelsen av kunden i teamet
• kode av høy kvalitet
• risikoen knyttet til utviklingen er redusert, siden Ansvaret for prosjektet er jevnt fordelt og avreise/ankomst av et teammedlem vil ikke forstyrre prosessen
• utviklingskostnadene er lavere pga teamet er fokusert på kode, ikke dokumentasjon og sammenstillinger

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

• prosjektets suksess avhenger av involvering av kunden, noe som ikke er lett å oppnå
• det er vanskelig å forutsi tidsbruken på prosjektet, fordi i begynnelsen vet ingen den komplette listen over krav
• XP-suksess avhenger sterkt av nivået på programmerere, metodikken fungerer bare med seniorspesialister
• ledelsen har en negativ holdning til parprogrammering, og forstår ikke hvorfor den skal betale to programmerere i stedet for én
• regelmessige møter med programmerere er kostbare for kundene
• krever for mye kulturell endring
• ikke egnet for store prosjekter på grunn av manglende struktur og dokumentasjon
• siden Smidige metodikker funksjonsorienterte, ikke-funksjonelle krav til produktkvalitet er vanskelig å beskrive i form av brukerhistorier.

XP-prinsipper

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

1. Enkelhet

I XP begynner utviklingen med den enkleste løsningen som dekker dagens behov for funksjonalitet. Teammedlemmer vurderer bare hva som må gjøres nå og koder ikke funksjonalitet som vil være nødvendig i morgen, om en måned eller aldri.

2. Kommunikasjon

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

3. Tilbakemelding

Tilbakemelding i XP implementeres i tre retninger samtidig:

1. tilbakemelding fra systemet under kontinuerlig testing av moduler
2. tilbakemelding fra kunden, pga han er en del av teamet og er med på å skrive akseptprøvene
3. Tilbakemelding fra teamet under utviklingstidsplanlegging.

4. Mot

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

5. Respekt

I ekstrem programmering blir respekt sett på i form av respekt for teamet og selvtillit. Teammedlemmer bør ikke laste opp endringer som bryter kompilering, enhetstester eller bremser kolleger. Alle streber etter topp kvalitet kode og design.

Algoritme for implementering av XP-metodikk og arbeidsprosess

Beck Kent anbefaler å implementere XP for å løse problemer i et prosjekt. Teamet velger det mest presserende problemet og løser det ved å bruke en av de ekstreme programmeringspraksisene. Deretter går han videre til neste oppgave ved å bruke en annen praksis. Med denne tilnærmingen motiverer problemene bruken av XP og teamet mestrer gradvis alle verktøyene i metodikken.

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

• testing
• designe
• planlegger
• ledelse
• utvikling

Testing.

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

Design.

Teamet vil gradvis refaktorere gammel kode, vanligvis før de legger til ny funksjonalitet. Som med testing, refaktoriserer du eldre kode bare når det er nødvendig. Ved å gjøre dette bør teamet formulere langsiktige mål for koderevisjonen og gradvis nå dem.

Planlegger.

Laget bør gå til nært samspill med kunden. På dette stadiet er det viktig å formidle til ham fordelene ved å jobbe på samme team med utviklerne og integrere ham i teamet.

Ledelse.

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

Utvikling.

Utviklingstransformasjonen begynner med opprettelsen av programmeringsarbeidsområder i par. Neste oppgave er å programmere i par i det meste av arbeidstiden, uansett hvor vanskelig det kan være for utviklerne.

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

Hvem bruker XP

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

Interessant nok, mens XP på ingen måte er den vanligste metodikken i sin reneste form, brukes den av de fleste Agile-selskaper. Dette er bevist av dataene fra den samme studien:

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

Pivotal Software, Inc.

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

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

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

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

Refaktorering: Forbedring av eksisterende kode / Martin Fowler

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

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

Applikasjoner for å implementere XP i et team

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

Gratis oppgavebehandling med åpen kildekode. Hovedfunksjoner: jobbe med flere prosjekter samtidig, fleksibelt oppgavestyringssystem, Gantt-diagram, tidskontroll, arbeid med dokumentasjon, lage oppgaver via mail m.m.

Enkel praktisk service for jobber sammen over prosjekter. Inkluderer oppgavebehandling, oppslagstavle, innebygd chat, fillagring, kalender

Jira

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

Å jobbe med prosjekter. Lar deg sette oppgaver og kontrollere utførelsesprosessen, utføre korrespondanse på oppgaven, sette opp filtre, ta hensyn til tid og penger brukt, jobbe med filer.

Kjennelse

Ekstrem programmering er en smidig metodikk sentrert om kvalitet, brukbar kode med en enkel arkitektur. Formålet er å redusere usikkerhetsnivået i prosjekter og å virkelig reagere fleksibelt på endringer i produktkrav.

Denne metodikken er utelukkende for sfæren programvare utvikling og kan ikke tilpasses for annen virksomhet.

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

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

Det er ingen forpliktelse til å implementere XP på alt-eller-ingenting-basis. Tross alt må smidige metoder være fleksible og når det gjelder anvendelse, tilpasse seg behovene til et bestemt team og prosjekt.

Ekstrem programmering er en metodikk for rask programvareutvikling. Består av et sett med teknikker og prinsipper som gjør det mulig, både individuelt og i et kompleks, å optimere utviklingsprosessen. Denne tilnærmingen styrer også rettighetene til utviklere og kunder.

Rettigheter og roller

I ekstrem programmering er alle roller tydelig beskrevet. Hver rolle har et særskilt sett med rettigheter og plikter. Det er to nøkkelroller her: kunde og utvikler.

Kunde

En person eller gruppe mennesker som er interessert i å lage et spesifikt programvareprodukt. Han har følgende rettigheter og plikter:

• fikse utgivelsesdatoene for produktversjoner;
• ta beslutninger om de planlagte komponentene i programmet;
• kjenne den estimerte kostnaden for hver funksjonell komponent;
• ta viktige forretningsbeslutninger;
• vet Nåværende tilstand systemer;
• endre systemkrav når det virkelig betyr noe.

For å lykkes med å utøve sine rettigheter, må kunden stole på dataene fra utviklerne.

Utvikler

En eller en gruppe på to til ti personer som er direkte involvert i programmering og relaterte tekniske spørsmål. Utbygger er utstyrt med følgende rettigheter og plikter:

• få tilstrekkelig kunnskap om problemene som skal programmeres;
• kunne avklare detaljer under utviklingsprosessen;
• gi veiledende, men ærlige estimater av lønnskostnader for hver funksjonell del eller brukerhistorie;
• justere estimater til fordel for mer nøyaktige i utviklingsprosessen;
• gi en vurdering av risiko knyttet til bruk av spesifikke teknologier.

Roller i en rolle

Hver av de grunnleggende rollene til ekstrem programmering kan foredles med mindre roller. I XP er det lov å kombinere roller innen samme person.

Kundesiden

Historiemaker- en spesialist på fagområdet, som har evnen til å tydelig angi og beskrive kravene til systemet som utvikles. Denne personen eller gruppen av personer er ansvarlig for å skrive brukerhistorier og rydde opp i misforståelser fra programmerere.

Mottaker- en person som kontrollerer at systemet fungerer korrekt. Har god beherskelse av fagområdet. Ansvaret inkluderer å skrive akseptprøver.

Stor sjef- overvåker arbeidet til alle lenker, fra utviklere til sluttbrukere... Han fører tilsyn med implementeringen av systemet og relaterte organisatoriske spørsmål. Kan også være investor i et prosjekt.

Utviklersiden

Programmerer- en person involvert i koding og design på lavt nivå. Han er kompetent nok til å løse aktuelle utviklingsproblemer og gi sanne estimater av planlagte oppgaver.

Instruktør- en erfaren utvikler som har god kontroll over hele utviklingsprosessen og dens metoder. Ansvarlig for å lære teamet aspekter av utviklingsprosessen. Implementerer og kontrollerer korrekt implementering av metodene for prosessen som brukes. Hender lagets oppmerksomhet på viktige, men av en eller annen grunn tapte utviklingspunkter. Samtidig er instruktøren, som enhver annen person, ikke allvitende og oppmerksom på ideene til andre teammedlemmer.

Observatør er medlem av utviklingsteamet som har tillit fra hele gruppen og overvåker utviklingen. Den sammenligner de foreløpige estimatene av lønnskostnader og faktisk brukt, og viser kvantitative indikatorer for teamets arbeid. Disse er f.eks gjennomsnittshastighet og prosentandelen av fullførte og planlagte oppgaver. Denne informasjonen gis til kunden for rettidig kontroll over situasjonen. Noe av denne informasjonen gis diskret til utviklere, for å vite statusen til prosjektet, stedene der vanskeligheter oppstår og hva annet som kan gjøres.

Diplomat- kommunikativ personlighet, initierer kommunikasjon mellom teammedlemmer. Siden arbeidsflyten er minimert, er konstant kommunikasjon og erfaringsoverføring innad i teamet viktig, samt en bedre forståelse av systemkravene. Diplomaten regulerer og forenkler kommunikasjonen mellom kunder og utviklere. Det er et viktig ledd i møtene. Han forhindrer misforståelser, høyden av lidenskaper og unødvendige krangler. En diplomat kan ikke påtvinge debattanten sin mening.

Eksterne roller

Konsulent- en spesialist med spesifikke tekniske ferdigheter for å hjelpe utviklere med vanskelige oppgaver. Vanligvis tiltrukket fra utsiden.

Ekstreme programmeringsregler

Kodekonvensjon

Du er i et team som har jobbet med dette prosjektet i lang tid. Folk kommer og går. Ingen koder alene og koden tilhører alle. Det vil alltid være tider når det vil være nødvendig å forstå og korrigere andres kode. Utviklere vil fjerne eller endre duplikatkode, analysere og forbedre andres klasser osv. Over tid vil det ikke være mulig å si hvem forfatteren av en bestemt klasse er.

Derfor må alle følge vanlige kodestandarder - kodeformatering, navngivning av klasser, variabler, konstanter, kommentarstil. Dermed vil vi være sikre på at ved å gjøre endringer i andres kode (som er nødvendig for aggressiv og ekstrem fremoverbevegelse), vil vi ikke gjøre den om til Babylonsk pandemonium.

Ovennevnte betyr at alle teammedlemmer må bli enige om felles kodestandarder. Det spiller ingen rolle hva. Regelen er at alle adlyder dem. De som ikke ønsker å rette seg etter dem forlater laget.

Kollektivt kodeeierskap

Delt kodeeierskap oppfordrer utviklere til å sende inn ideer for alle deler av prosjektet, ikke bare modulene deres. Enhver utvikler kan endre hvilken som helst kode for å utvide funksjonaliteten, fikse feil eller refaktorering.

Ved første øyekast ser det ut som kaos. Men tatt i betraktning at i det minste hvilken som helst kode ble laget av et par utviklere, at enhetstester lar deg sjekke riktigheten av endringene som er gjort, og at du i det virkelige liv fortsatt må forstå andres kode på en eller annen måte, det blir klart at kollektivt eierskap til koden i stor grad forenkler å gjøre endringer og reduserer risikoen forbundet med høy spesialisering av et eller annet teammedlem.

CRC-økt

Bruk kortene Klasse, Ansvar, Samarbeid (CRC) for å designe systemet som et team. Ved å bruke kort blir det lettere å venne seg til å tenke i objekter fremfor funksjoner og prosedyrer. Kort lar også flere delta i designprosessen (ideelt sett hele teamet), og jo flere som gjør designet, jo mer interessante ideer vil bli hentet inn.

Hvert CRC-kort er en objektforekomst. Objektklasse kan skrives på toppen, ansvar til venstre, interaksjoner til høyre. Vi sier "kan skrives" fordi når en CRC-økt pågår, trenger deltakerne vanligvis et lite antall klassenavnskort og trenger ikke fylles helt ut.

CRC-økten går slik: hver av deltakerne reproduserer systemet og sier hvilke meldinger han sender til hvilke objekter. Går gjennom hele prosessen melding for melding. Svakheter og problemer blir umiddelbart identifisert. Designalternativene er også godt synlige i prosesssimuleringen.

For å sette ting i orden, brukes ofte begrensningen av antallet to som samhandler samtidig.

Kunde

Et av XP-kravene er at kunden alltid er tilgjengelig. Han skal ikke bare hjelpe utviklingsteamet, men være medlem av det. Alle faser av et XP-prosjekt krever kommunikasjon med kunden, best av alt ansikt til ansikt – på stedet. Best av alt, bare tilordne en eller flere kunder til utviklingsteamet. Pass på, kunden vil ta lang tid, og kundens kontor kan prøve å gi deg en praktikant som ekspert. Du trenger en ekspert.

Brukerhistorier skrevet av kunden med hjelp av utviklerne. Kunden er med på å sørge for at de fleste av de ønskede systemfunksjonene dekkes av User Story.

Når du planlegger en utgivelse, må kunden diskutere valget av User Stories som skal inkluderes i den planlagte utgivelsen. Det kan også være nødvendig å avtale selve utgivelsesperioden. Kunden tar beslutninger knyttet til virksomhetens mål.

Velg den enkleste løsningen

Enkle design er alltid lettere å implementere enn komplekse design. Så lag alltid den enkleste løsningen som kan fungere. Hvis du finner noe vanskelig, bytt det ut med noe enkelt. Det er alltid raskere og billigere å erstatte kompleks kode med enkel kode før du begynner å forstå kompleks kode.

Refaktor andres kode hvis det virker komplisert for deg. Hvis noe ser komplisert ut, er det det sikkert tegn problemer i koden.

Hold løsningene så enkle som mulig så lenge som mulig. Legg aldri til funksjonalitet for fremtiden – før behovet melder seg. Men husk: å holde designet enkelt er hardt arbeid.

Funksjonstester

Akseptprøver (tidligere også kalt funksjonstester) er skrevet basert på User Story. De ser på systemet som en svart boks. Kunden er ansvarlig for å kontrollere at funksjonstestene er korrekte. Disse testene brukes til å verifisere helsen til systemet før det slippes ut i produksjon. Funksjonstester er automatiserte slik at du kan kjøre dem ofte. Resultatet kommuniseres til teamet og teamet er ansvarlig for å planlegge funksjonelle testfikser.

Hyppig integrasjon

Utviklere bør integrere og frigi koden med noen få timers mellomrom når det er mulig. I alle fall bør endringer aldri beholdes lenger enn én dag. Hyppig integrasjon unngår fremmedgjøring og fragmentering i utviklingen der utviklere ikke kan kommunisere i betydningen å dele ideer eller gjenbruke kode. Alle bør jobbe med den nyeste versjonen.

Hvert par utviklere bør gi ut koden sin så snart det er en rimelig mulighet til å gjøre det. Dette kan være når alle UnitTests består 100 %. Ved å sende inn endringer flere ganger om dagen reduserer du integrasjonsproblemer til nesten null. Integrering er en betal-nå-eller-betal-senere-aktivitet. Derfor, ved å integrere endringer daglig i små porsjoner, trenger du ikke å bruke en uke på å binde systemet til en helhet umiddelbart før levering av prosjektet. Arbeid alltid med siste versjon av systemet.

For lederen. Hvis en utvikler ikke sender inn endringer i mer enn én dag, er dette en klar indikator på et alvorlig problem. Du må umiddelbart finne ut hva saken er. All erfaring fra XP-team sier at årsaken til forsinkelsen alltid er dårlig design, og det må alltid gjøres om etterpå.

Planlegger en iterasjon

Et iterasjonsplanleggingsmøte kalles inn før starten av hver iterasjon for å planlegge oppgavene som skal utføres i den iterasjonen. For iterasjon velges User Stories som kunden valgte i utgivelsesplan starter med det viktigste for kunden og det verste (assosiert med risiko) for utviklerne. Ikke-fungerende funksjonstester er også inkludert i iterasjonen.

Brukerhistorier og mislykkede funksjonstester er delt inn i oppgaver. Oppgaver registreres på kort. Disse kortene er den detaljerte planen for iterasjonen. Hver oppgave bør være mellom 1 og 3 ideelle dager lang.

Utviklere demonterer oppgaver og anslår hvor lang tid det tar å fullføre dem. Dermed estimerer hver utvikler hvor lang tid oppgaven vil ta fra ham. Det er viktig at utbygger selv foretar det endelige overslaget over arbeidsomfanget.

Prosjekthastighet avgjør om oppgavene dine passer inn i iterasjon eller ikke. Den totale varigheten av oppgaver som er planlagt for en iterasjon bør ikke overstige hastigheten oppnådd i forrige iterasjon. Hvis du har skrevet for mange, må kunden bestemme hvilke User Stories som skal utsettes til neste iterasjon. Hvis du skrev for lite, må du legge til følgende brukerhistorie. I noen tilfeller kan du be kunden om å dele en av brukerhistoriene i to for å inkludere delen i den gjeldende iterasjonen.

Å utsette en brukerhistorie til neste iterasjon kan se skummelt ut, men ikke tillat deg selv å ofre refactoring og enhetstester for å få gjort mer. Gjeld i disse kategoriene vil raskt redusere hastigheten din. Ikke gjør det du tror er nødvendig i de neste iterasjonene - gjør bare det som er nødvendig for å fullføre de nåværende brukerhistoriene.

Hold oversikt over prosjekthastighet og ventende brukerhistorier. Det er mulig at utgivelsesplanen må gjøres om hver tredje til femte iterasjon. Dette er greit. Tross alt er utgivelsesplanen et blikk inn i fremtiden, og det er naturlig å forvente at spådommene dine må justeres.

Iterasjon

Iterativ utvikling øker fleksibiliteten i prosessen. Del opp planen din i iterasjoner av 2 til 3 ukers varighet. Oppretthold en konstant iterasjonsvarighet under prosjektets varighet. La iterasjon være pulsen på prosjektet ditt. Dette er rytmen som vil gjøre fremdriftsmåling og planlegging enkel og pålitelig.

Ikke planlegg oppgaver på forhånd. Samle i stedet Planlegger en iterasjon i begynnelsen av hver iterasjon for å planlegge hva som skal gjøres. Det anses også som et brudd på reglene å løpe videre og gjøre det som ikke er planlagt i denne iterasjonen. Dermed blir det mulig å holde kontroll over de skiftende kravene til kunden.

Ta iterasjonsfullføringsfrister på alvor. Mål fremgang mens du jobber. Hvis du kan se at du ikke kan fullføre alle de planlagte oppgavene innen fristen, så samle iterasjonsplanleggingen igjen og revurder oppgavene og utsett noen av oppgavene.

Konsentrer innsatsen om å fullføre de viktigste oppgavene valgt av kunden, i stedet for å ha noen få uferdige oppgaver valgt av utvikleren.

Endre oppgaver

Det er nødvendig med jevne mellomrom å endre oppgaver for utviklere for å redusere risikoen for konsentrasjon av kunnskap og flaskehalser i koden. Hvis bare én person i teamet ditt kan jobbe i et gitt område og den personen drar, eller du bare har mye å gjøre i dette segmentet programmet, vil du oppdage at prosjektet ditt knapt gjør fremskritt.

Cross Training er vanligvis et viktig aspekt i bedrifter som prøver å unngå å konsentrere kunnskap om én person. Flytte folk rundt koden i kombinasjon med parprogrammering lager diskret Cross Training for deg. I stedet for én person som kan alt om en gitt kodebit, vet alle i teamet mye om koden i hver modul.

Teamet blir mye mer fleksibelt hvis alle vet nok om hver del av systemet til å begynne å jobbe med det. I stedet for å vente på at "guruen" skal fullføre arbeidet med et kritisk stykke kode, kan flere programmerere jobbe med det samtidig.

Når du starter en ny iterasjoner hver utvikler bør gå til ny oppgave... Paring hjelper til med å overvinne tilpasningsproblemet (som betyr at en ny utvikler kan koble seg sammen med en erfaren utvikler i feltet).

Denne praksisen stimulerer også nye ideer og kodeforbedringer.

Lagre optimalisering til senere

Optimaliser aldri noe før du er ferdig med kodingen. Prøv aldri å gjette hvor de vil være trange steder etter ytelse. Måle!

Få det til å fungere, så gjør det riktig, så gjør det raskt.

Parprogrammering

All kode for et produksjonssystem (som betyr unntatt prøveløsninger) skrives i par. To utviklere sitter side om side. Den ene ringer, den andre ser. De endrer seg fra tid til annen. Det er ikke lov å jobbe alene. Hvis den andre av paret av en eller annen grunn gikk glipp av noe (ble syk, gikk bort, etc.), er han forpliktet til å gjennomgå alle endringene som er gjort av den første.

Høres uvanlig ut, men XP hevder at etter en kort periode med tilpasning, fungerer de fleste fint i par. De liker det til og med fordi arbeidet blir gjort mye raskere. Prinsippet «Ett hode er bra, men to er bedre» gjelder. Par finner vanligvis mer optimale løsninger... I tillegg økes kvaliteten på koden betydelig, antall feil reduseres og utvekslingen av kunnskap mellom utviklere akselereres.

Refaktorer hensynsløst!

Vi programmerere har en tendens til å holde oss til et design lenge etter at det blir vanskelig. Vi fortsetter å bruke den uhåndterlige koden på nytt fordi den fortsatt fungerer på en eller annen måte, og vi er redde for å rote den til. Men er det virkelig gunstig? XP mener at det ikke er lønnsomt. Når vi fjerner redundans, forbedrer utdatert design, fjerner ubrukte biter - refaktoriserer vi. Refaktorering sparer til syvende og sist tid og forbedrer produktkvaliteten.

Revider hensynsløst enhver kode for å holde designet enkelt mens du utvikler. Hold koden klar og forståelig slik at den er enkel å forstå, endre og utvide. Sørg for at alt er skrevet én gang og kun én gang. Til syvende og sist tar det mindre tid enn å finpusse et kronglete system.

Utgivelsesplan

Frigjøringsplanen utvikles på utgivelsesplanleggingsmøtet. Utgivelsesplaner beskriver en visning av hele prosjektet og brukes senere til å planlegge iterasjoner.

Det er viktig at tekniske folk tar tekniske beslutninger og forretningsfolk tar forretningsavgjørelser. Utgivelsesplanlegging definerer et sett med regler som lar alle ta sine egne avgjørelser. Disse reglene definerer metoden for å utvikle en arbeidsplan som tilfredsstiller alle.

Essensen av utgivelsesplanleggingsmøtet for utviklingsteamet er å evaluere hver brukerhistorie i ideelle uker. En ideell uke er hvor lang tid du tror det vil ta å fullføre en oppgave hvis ingenting distraherer deg lenger. Ingen avhengigheter, ingen tilleggsoppgaver, men inkludert tester. Kunden bestemmer da hvilke oppgaver som er viktigst eller har høyere prioritet.

Brukerhistorier registreres på kort. Utviklerne og kunden blander kortene sammen på bordet til de får et sett med brukerhistorier, som sammen utgjør den første (eller neste) utgivelsen. Alle ønsker å gi den ut så tidlig som mulig nyttig system som kan testes.

En utgivelse kan planlegges etter tid eller volum. For å finne ut hvor mange brukerhistorier som kan realiseres innen en bestemt dato eller hvor lang tid det vil ta i sanntid dette settet oppgaver bruker hastigheten på prosjektet. Hvis du planlegger i tide, multipliser antall iterasjoner med hastigheten på prosjektet for å finne ut hvor mange User Stories som kan implementeres. Når du planlegger etter volum, del det totale antallet ideelle uker som kreves for alle brukerhistorier med hastigheten på prosjektet, og du vil få antall iterasjoner som kreves for å fullføre utgivelsen.

Dersom ledelsen ikke er fornøyd med fristen for ferdigstillelse, kan det være fristende å redusere omfangsestimatene. Du bør aldri gjøre dette. Undervurderte rangeringer vil garantert skape mange problemer senere. I stedet forhandler du med ledere, utviklere og kunder til du har en akseptabel utgivelsesplan for alle.

Hyppige utgivelser

Utviklere bør gi ut versjoner av systemet til brukere (eller betatestere) så ofte som mulig.

Utgivelsesplanlegging brukes til å finne små funksjonelle fragmenter som har betydelig forretningssans og som kan slippes ut i det virkelige miljøet i de tidlige stadiene av utviklingen. Det er viktig å motta i tide nyttige anmeldelser for å kunne påvirke utviklingsprosessen. Jo mer du forsinker utgivelsen av en viktig del av systemet, jo mindre tid vil du ha til å fikse det.

Prøveløsning

Lag prøveløsninger for å svare på komplekse tekniske spørsmål, for å rettferdiggjøre visse teknologiske løsninger. Det er en risiko i enhver teknologibeslutning, og prøvebeslutninger er utformet for å redusere den.

Lag et program som gjengir problemet under etterforskning og ignorerer alt annet. De fleste prøveløsningene er ikke beregnet for fremtidig bruk, så forvent at de blir kastet. Hensikten med opprettelsen av dem er å redusere risikoen for å ta feil tekniske beslutninger eller å mer nøyaktig estimere tiden det tar å implementere en brukerhistorie.

Møte stående

Hver morgen holdes et møte for å diskutere problemer, deres løsninger og for å øke konsentrasjonen i teamet. Møtet holdes stående for å unngå lange diskusjoner som ikke er interessante for alle teammedlemmer.

I et typisk møte bidrar ikke de fleste deltakerne med noe, de deltar bare for å høre hva andre har å si. Et stort nummer av folks tid er bortkastet for å få en liten mengde kommunikasjon. Derfor tar deltakelse av alle personer i møtene ressurser fra prosjektet og skaper kaos i planleggingen.

For denne typen kommunikasjon er det nødvendig med et stående møte. Det er mye bedre å ha ett kort, obligatorisk møte enn mange lange som de fleste utviklere uansett må delta på.

Hvis du har daglige stående møter, bør alle andre møter kun delta på de personene som trengs og vil ta med noe. Dessuten er det til og med mulig å unngå noen møter. Med begrensede deltakere kan de fleste møter holdes spontant foran en monitor, hvor utvekslingen av ideer er mye mer intens.

Det daglige morgenmøtet er ikke enda et sløsing med tid. Det vil spare deg for mange andre møter og vil spare deg for mer tid enn bortkastet.

Metafor av systemet

Velg alltid System Metaphor - et enkelt og greit konsept for teammedlemmer å kalle alle ting samme navn. For å forstå systemet og unngå duplikatkode, er det ekstremt viktig hvordan du navngir objektene. Hvis du kan gjette hva som er navnet på et objekt i systemet (hvis du vet hva det gjør) og det virkelig heter det - vil du spare mye tid og krefter. Lag et navnesystem for objektene dine slik at alle i teamet kan bruke det uten spesiell kunnskap om systemet.

Enhetstester

Enhetstester spiller nøkkelrolle i XP. De lar deg raskt endre koden uten frykt for å gjøre nye feil. Enhetstest skrives for hver klasse, testen skal sjekke alle sider ved klassens arbeid – test alt som kanskje ikke fungerer.

Trikset her er at testen for klassen skal skrives før selve klassen. Dette betyr at så snart du slipper det første arbeidsresultatet, vil det støttes av testsystemet. For å gjennomføre tester, skriv spesialsystem testing med eget grensesnitt.

Enhetstest for en klasse lagres i et delt depot sammen med klassekoden. Ingen kode kan frigis uten en enhetstest. Før du sender inn koden, må utvikleren sørge for at alle tester består uten feil. Ingen kan gi en kode hvis alle ikke har bestått 100%. Med andre ord, siden alle testene bestod før endringene dine, hvis du har feil, så er dette resultatet av endringene dine. Du og fikse. Noen ganger er testkoden feil eller ufullstendig. I dette tilfellet må du korrigere det.

Det er en enorm fristelse å spare penger på enhetstester når tiden er knapp. Men med dette lurer du bare deg selv. Jo vanskeligere det er å skrive en test, jo mer tid vil det spare senere. Dette er bevist i praksis.

Enhetstester gir mulighet for kollektivt eierskap til koden. De gjør det relativt enkelt å revidere dårlig kode. Også enhetstester lar deg ha et stabilt arbeidssystem når som helst.

Brukerhistorie

User Story (noe som en brukerhistorie) er en beskrivelse av hvordan systemet skal fungere. Hver brukerhistorie er skrevet på et kort og representerer et stykke systemfunksjonalitet som gir logisk mening fra kundens synspunkt. Skjema - ett eller to avsnitt med tekst som er forståelig for brukeren (ikke særlig teknisk).

User Story er skrevet av kunden. De ligner på systembrukstilfeller, men er ikke begrenset til brukergrensesnitt... For hver historie skrives funksjonstester for å bekrefte at historien er korrekt implementert – de kalles også Akseptansetester.

Hver User Story er gitt en prioritet av virksomheten (bruker, kunde, markedsføring) og et estimat av ledetiden av utviklerne. Hver historie er delt opp i oppgaver og en tid er tildelt den når den skal begynne å bli implementert.

User Stories brukes i XP i stedet for tradisjonelle krav. Hovedforskjellen mellom User Story og krav er detaljnivået. Brukerhistorien inneholder minimumsinformasjonen som er nødvendig for å gjøre et rimelig estimat på hvor lang tid det vil ta å implementere den.

En typisk User Story tar 1-3 uker med ideell tid. En historie som krever mindre enn 1 uke er for detaljert. En historie som krever mer enn 3 uker kan deles inn i deler - separate historier.

Prosjekthastighet

Prosjekthastighet (eller ganske enkelt hastighet) er et mål på hvor raskt arbeidet blir gjort i prosjektet ditt.

For å måle hastigheten til et prosjekt, må du ganske enkelt beregne størrelsen på User Stories, eller hvor mange (i tid) oppgaver som ble fullført i en iterasjon. Bare beregn den totale tiden for å estimere arbeidsvolumet (ideell tid).

Under utgivelsesplanlegging brukes prosjekthastighet for å estimere hvor mange User Stories som kan produseres.

Under iterasjonsplanlegging brukes prosjekthastigheten i forrige iterasjon til å bestemme hvor mange User Stories som skal planlegges i gjeldende iterasjon.

Denne enkle mekanismen lar utviklere komme seg etter en vanskelig iterasjon. Hvis du har ledig tid etter restitusjon, gå til kunden og be om mer User Story. Som et resultat vil hastigheten øke igjen.

Ikke bruk denne parameteren som absolutt. Det er ikke egnet for å sammenligne produktiviteten til to prosjekter, siden hvert team har sine egne egenskaper. Denne parameteren er kun viktig for at laget skal holde den på "jevn kjøl".

Du bør forvente små endringer i prosjekthastigheten mens du jobber. Men hvis hastigheten endres mye, må du planlegge utgivelsen på nytt. Så snart det nye systemet går til brukerne, forvent at hastigheten på prosjektet endres ettersom du har støtteoppgaver.

Når en feil blir funnet

Hvis en feil blir funnet, opprettes en test for å forhindre at den oppstår igjen. En feil som oppstår på et produksjonssystem (allerede installert) krever skriving av en funksjonstest. Ved å lage en funksjonstest rett før diagnostisering av en feil kan kundene tydelig beskrive problemet og kommunisere problemet til utviklerne.

Uoppfylt funksjonstest krever opprettelsen Enhetstest... Dette hjelper med å fokusere feilsøkingsinnsatsen og viser tydelig når feilen er fikset.

Du trenger det ikke

Unngå å fylle systemet med ting du vil trenge i fremtiden. Bare 10 % av det du forventer vil faktisk være nødvendig i sin opprinnelige form, det vil si at 90 % av tiden din vil bli bortkastet.

Det er alltid en fristelse å legge til funksjonalitet nå og ikke senere, fordi vi ser hvordan vi legger det til nå og føler at systemet vil bli mye bedre. Men vi må alltid minne oss selv på at vi aldri vil trenge det. Ekstra funksjonalitet bremser bare fremdriften og spiser opp ressurser. Glem fremtidige krav og ekstra fleksibilitet. Konsentrer deg om det som må gjøres nå.

Ekstrem programmering(English Extreme Programming, XP) er en av de fleksible programvareutviklingsmetodene. Forfatterne av metodikken er Kent Beck, Ward Cunningham, Martin Fowler og andre. Navnet på metodikken kommer fra ideen om å bruke nyttig tradisjonelle metoder og programvareutviklingspraksis, som tar dem til et nytt "ekstremt" nivå. Så, for eksempel, praksisen med å utføre en koderevisjon, som innebærer å sjekke koden av én programmerer,
skrevet av en annen programmerer, i sin "ekstreme" versjon er "parprogrammering", når en programmerer koder, og partneren hans samtidig kontinuerlig ser på den nyskrevne koden.
De tolv grunnleggende ekstreme programmeringsteknikkene (i henhold til den første utgaven av boken Ekstrem programmering forklart) kan grupperes i fire grupper:

• Finskala tilbakemelding
  • Testdrevet utvikling
  • Planleggingsspill
  • Kunden er alltid der (hele teamet, kunde på stedet)
  • Parprogrammering
  • Kontinuerlig, ikke batchprosess
• Kontinuerlig integrering
  • Refaktorering
  • Små utgivelser
• Forståelse delt av alle
  • Enkelhet (enkel design)
  • Systemmetafor
  • Kollektivt kodeeierskap eller eierskap til utvalgte mønstre
  • Kodestandard eller Kodekonvensjoner
• Programmerers velferd:
  • 40-timers arbeidsuke (bærekraftig tempo, 40-timers uke)

XP innebærer å skrive automatiserte tester (programkode skrevet spesielt for å teste logikken til annen programkode). Spesiell oppmerksomhet fokuserer på to typer testing:

• enhetstesting av moduler;
• funksjonstesting.

En utvikler kan ikke være sikker på riktigheten av koden han har skrevet før absolutt alle tester av modulene til systemet han utvikler har fungert. Enhetstester (enhetstester) lar utviklere forsikre seg om at hver enkelt av dem fungerer riktig. De hjelper også andre utviklere med å forstå hvorfor en bestemt kodebit er nødvendig og hvordan den fungerer – mens du studerer testkoden, blir logikken til koden som testes tydelig, ettersom du kan se hvordan den fungerer.
burde bli brukt. Enhetstester lar også utvikleren refaktorere uten frykt.

Funksjonstester er designet for å teste funksjonen til logikk dannet av samspillet mellom flere (ofte ganske imponerende) deler. De er mindre detaljerte enn enhetstester, men dekker mye mer - det vil si for tester som, når de utføres, påvirker større volum kode, er sjansen for å oppdage feil oppførsel åpenbart større. Av denne grunn, i industriell programmering skrive funksjonstester
har ofte forrang fremfor å skrive enhetstester.
For XP kalles en mer prioritert tilnærming TDD (testdrevet utvikling). I samsvar med denne tilnærmingen skriver du først en test som i utgangspunktet ikke består (siden logikken som den skal sjekke rett og slett ikke eksisterer ennå), deretter implementeres logikken som er nødvendig for at testen skal bestå. TDD lar deg på en måte skrive kode som er mer praktisk å bruke - fordi når du skriver en test, når det ikke er noen logikk ennå,
den enkleste måten er å ta vare på det fremtidige systemets bekvemmelighet.

Hovedmålet med planleggingsspillet er å raskt lage en grov arbeidsplan og hele tiden oppdatere den etter hvert som betingelsene for problemet blir klarere. Artefaktene til planleggingsspillet er et sett med papirkort som inneholder kundehistorier og et grovt veikart for neste en eller flere mindre versjoner av produktet.

En kritisk faktor for å gjøre denne planleggingsstilen effektiv er det i dette tilfellet kunden er ansvarlig for å ta forretningsbeslutninger, og utviklingsteamet er ansvarlig for å ta tekniske beslutninger. Hvis denne regelen ikke følges, faller hele prosessen fra hverandre.