Planlegging Spillet

XP planlegging adresser to viktige spørsmål i programvare utvikling: å forutsi hva som vil oppnås ved forfall, og bestemme hva du skal gjøre neste. Det legges vekt på styring av prosjektet – noe som er ganske grei – snarere enn på nøyaktig prediksjon av hva som vil være nødvendig, og hvor lang tid det vil ta – noe som er ganske vanskelig., Det er to viktige planlegging trinnene i XP, å ta opp disse to spørsmål:

Frigi Planlegging er en praksis hvor Kunden presenterer de ønskede funksjonene til programmerere og programmerere anslå deres problemer. Med anslag over kostnadene i hånd, og med kunnskap om betydningen av funksjoner, Kunden legger ut en plan for prosjektet. Første utgivelse planer er nødvendigvis upresis: verken prioriteringer heller estimatene er virkelig solid, og til teamet begynner å arbeide, kan vi ikke vet akkurat hvor fort de vil gå., Selv den første utgivelsen plan er nøyaktige nok for beslutningstaking, imidlertid, og XP lag revidere utgivelsen plan regelmessig.

Iterasjon Planlegging er praksis der teamet er gitt retning hver par uker. XP lag bygge programvare i to-ukers «spill», levere kjører nyttig programvare på slutten av hver iterasjon. I løpet av en Iterasjon Planlegging, Kunden presenterer de har ønsket for de neste to ukene. Programmerere bryte dem ned til oppgaver, og anslår kostnadene (på et finere nivå av detaljer enn i Release Planning)., Basert på mengden av arbeid som er utført i forrige iterasjon, team tegn opp for hva som vil bli foretatt i den nåværende utgaven.

Disse planlegging fremgangsmåten er veldig enkel, men de gir svært god informasjon og god kontroll i hendene på Kunden. Hver par uker, mengden av fremgang er synlig. Det er ingen «nitti prosent ferdig» i XP: en funksjon historie var avsluttet, eller det var det ikke., Dette fokuset på sikt resulterer i en fin liten paradoks: på den ene siden, med så mye synlighet, om Kunden er i en posisjon til å avbryte prosjektet dersom fremdriften er ikke tilstrekkelig. På den annen side, fremgang er så synlig, og evnen til å avgjøre hva som vil bli gjort ved siden av er så fullstendig, at XP-prosjekter har en tendens til å levere mer av det som er nødvendig, med mindre press og stress.

Kunden Tester

Som en del av å presentere hvert ønsket funksjon, XP Kunden definerer ett eller flere automatiserte aksept tester for å vise at funksjonen fungerer., Teamet bygger disse testene, og bruker dem for å bevise for seg selv, og til kunden, at funksjonen er riktig implementert. Automatisering er viktig fordi i pressen tid, manuelle tester som er hoppet over. Det er som å slå av lysene når natt blir mørkeste.

Den beste XP lag behandler sine kunder tester samme måte som de gjør programmerer, tester: når testen kjøres, team holder det å kjøre som det skal etterpå. Dette betyr at systemet bare forbedrer, alltid faste fremover, aldri frafall.,

Små Utgivelser

XP lag praksis små utgivelser i to viktige måter:

Første, team utgivelser kjører, testet programvare, levere forretningsverdi som er valgt av Kunden, hver iterasjon. Kunden kan bruke denne programvaren for alle hensikt, om evaluering eller selv slipper til sluttbrukere (sterkt anbefalt). Den mest viktig aspekt er at programvaren er synlig, og gis til kunden på slutten av hver iterasjon. Dette holder alt åpent og konkret.

Andre, XP lag slipper til sine sluttbrukere ofte som godt., XP Web-prosjekter slipp så ofte som hver dag, i huset prosjekter månedlig eller oftere. Selv pakkede produkter som sendes så ofte som en gang i kvartalet.

Det kan virke umulig å skape gode versjoner dette ofte, men XP lagene over gjør det hele tiden. Se Kontinuerlig Integrasjon for mer om dette, og legg merke til at disse utgivelser holdes pålitelig med XP besettelse med testing, som beskrevet her i Kunden Tester og Test-Drevet Utvikling.

Enkel Design

XP lag bygge programvare til en enkel, men alltid tilstrekkelig design., De begynner enkelt, og gjennom programmerer testing og design forbedring, de holder det på den måten. En XP-teamet holder design akkurat egnet for den aktuelle funksjonaliteten til systemet. Det er ingen bortkastet bevegelse, og programvaren er alltid klar for hva som er neste.

Design i XP er ikke en engangs ting, eller en up-front ting, det er en alt-i-gang ting. Det er design trinnene i release planlegging og iterasjon planlegging, pluss lag engasjere seg i rask design økter og design revisjoner gjennom refactoring, i løpet av hele prosjektet., I en trinnvis, iterativ prosess som Extreme Programming, god design er viktig. Det er derfor det er så mye fokus på design i løpet av hele utviklingen.

Pair Programming

All produksjon programvare i XP er bygd av to programmerere, sitter ved siden av hverandre, på samme maskin. Denne praksis sikrer at all produksjon koden er vurdert av minst en annen programmerer, og resulterer i bedre design, bedre testing, og bedre kode.

Det kan virke ineffektivt å ha to programmerere å gjøre «en programmerer jobb», men det motsatte er sant., Forskning i par-programmering viser at koblingen gir bedre koden i omtrent på samme tid som programmerere arbeider enkeltvis. Det er riktig: to hoder egentlig er bedre enn ett!

Noen programmerere objekt til et par-programmering uten noen gang å prøve det. Det tar litt praksis, for å gjøre det bra, og du trenger å gjøre det bra i et par uker for å se resultatene. Nitti prosent av programmerere som lærer par-programmering foretrekker det, så vi anbefaler det til alle lagene.

Sammenkobling, i tillegg til å gi bedre kode og tester, tjener også til å formidle kunnskap til hele teamet., Som par bytte får alle fordelene av alles spesialisert kunnskap. Programmerere lære, forbedre sine ferdigheter, de blir mer verdifull for laget og til selskapet. Sammenkobling, selv på egen hånd, utenfor XP, er en stor seier for alle.

Test-Drevet Utvikling

Extreme Programming er besatt med tilbakemeldinger, og i programvare utvikling, gode tilbakemeldinger krever god testing. Topp XP lag praksis «test-drevet utvikling», som arbeider i svært korte sykluser av å legge til en test, så gjør det arbeidet., Nesten uanstrengt, lag skrive kode med nesten 100 prosent test dekning, som er et stort skritt fremover i de fleste butikker. (Hvis programmerere allerede gjør enda mer avanserte testing, mer makt til deg. Holde det opp, det kan bare hjelpe!)

Det er ikke nok til å skrive tester: du har til å kjøre dem. Her, også, Extreme Programming er ekstrem. Disse «programmerer, tester», eller «unit tester» er alle samlet sammen, og hver gang noen programmerer utgivelser kode for å depotet (og par, vanligvis to ganger om dagen eller mer), at hver eneste en av de programmerer tester må kjøre riktig., Ett hundre prosent, hele tiden! Dette betyr at programmerere få umiddelbar tilbakemelding på hvordan de gjør det. I tillegg, disse testene gir uvurderlig støtte som software design er forbedret.

Design Forbedring (Refactoring)

Extreme Programming fokuserer på å levere forretningsverdi i hver iterasjon. For å oppnå dette i løpet av hele prosjektet, må programmet være godt designet. Alternativet ville være å bremse ned og til syvende og sist blir sittende fast., Slik XP bruker en prosess av kontinuerlig design forbedring kalt Refactoring, fra tittelen Martin Fowler ‘ s bok, «Refactoring: Bedre Utforming av Eksisterende Kode».

refactoring prosessen fokuserer på fjerning av duplisering (et sikkert tegn på dårlig design), og på å øke den «samhold» av koden, mens du senker «kopling». Høy samhold og lav kopling har blitt anerkjent som kjennetegner godt designet kode for minst tretti år. Resultatet er at XP lagene starte med en god, enkel design, og har alltid en god, enkel design for programvaren., Dette gir dem mulighet til å opprettholde sin utvikling hastighet, og faktisk generelt øke hastigheten som prosjektet går fremover.

Refactoring er, selvfølgelig, sterkt støttet av omfattende testing for å være sikker på at som design utvikler seg, og ingenting er ødelagt. Dermed kunden tester og programmerer tester er en kritisk styrkende faktor. XP praksis støtter hverandre: de er sterkere sammen enn hver for seg.

Kontinuerlig Integrasjon

Extreme Programming lagene holder systemet fullt integrert i alle tider. Vi sier at daglig bygger er for pyser: XP lag bygge flere ganger per dag., (En XP team av førti mennesker bygger på minst åtte eller ti ganger per dag!)

fordelen med denne praksisen kan bli sett ved å tenke tilbake på prosjektene du har kanskje hørt om (eller selv blitt en del av) hvor byggeprosessen var ukentlig eller sjeldnere, og vanligvis ledet til «integrering helvete», hvor du har alt brøt, og ingen visste hvorfor.

Sjeldne integrasjon fører til alvorlige problemer på en programvare-prosjekt., Først av alt, selv om integrasjon er avgjørende for å shipping godt å jobbe-koden, laget er ikke øvd på det, og ofte er det delegert til folk som ikke er kjent med hele systemet. Andre, sjelden integrert kode er ofte – jeg vil si vanligvis – buggy kode. Problemer med å krype inn på integrering gang det er ikke oppdaget av noen av testingen som foregår på en unintegrated system. Tredje, svak integrering prosessen fører til lange koden fryser., Koden fryser bety at du har lang tid perioder når programmerere kan jobbe på viktige shippable funksjoner, men at de funksjoner som må holdes tilbake. Dette svekker deres posisjon i markedet, eller med sluttbrukerne.

Kollektiv Kode Eierskap

På en Ekstrem Programmering prosjektet, noen par av programmerere kan forbedre en kode til enhver tid. Dette betyr at all kode som får nytte av mange folks oppmerksomhet, noe som øker kode kvalitet og reduserer feil., Det er en annen viktig fordel også: når koden er eid av enkeltpersoner, nødvendige funksjoner er ofte satt på feil sted, som en programmerer oppdager at han trenger en funksjon et sted i koden som han ikke eier. Eieren er for opptatt til å gjøre det, så programmerer setter funksjonen i sin egen kode, hvor det ikke hører hjemme. Dette fører til stygge, som er vanskelig å vedlikeholde kode, full av duplisering og med lav (dårlig) samhold.

Kollektive eierskap kan være et problem hvis folk jobbet blindt på koden de ikke forstår., XP unngår disse problemene gjennom to viktige teknikker: programmerer tester fange opp eventuelle feil, og par-programmering betyr at den beste måten å arbeide på ukjente koden er å koble sammen med ekspert. I tillegg til å sikre god endringer når det er nødvendig, er denne praksis sprer kunnskap i hele laget.

Koding Standard

XP team følger en felles koding standard, slik at all koden i systemet ser ut som om det var skrevet av en enkelt – svært kompetent – individuell., De nærmere detaljer om standarden er ikke viktig: det som er viktig er at all koden ser kjent ut, støtte for kollektivt eierskap.

Metafor

Extreme Programming lagene utvikle en felles visjon for hvordan programmet fungerer, som vi kaller «metafor». På sitt beste, metaforen er en enkel malende beskrivelse av hvordan programmet fungerer, for eksempel «dette programmet fungerer som en summende bier, gå ut for pollen og bringe den tilbake til flokken» som en beskrivelse for en agent-basert information retrieval system.

noen Ganger en tilstrekkelig poetisk metafor ikke oppstår., I alle fall, med eller uten levende bilder, XP lagene bruk et felles system for navn for å være sikker på at alle forstår hvordan systemet fungerer, og hvor du skal lete for å finne den funksjonalitet du er på jakt etter, eller for å finne riktig sted å sette den funksjonalitet du er i ferd med å legge til.

Bærekraftig Tempo

Extreme Programming lagene er i det for lang sikt. De jobber hardt, og det i et tempo som kan opprettholdes på ubestemt tid. Dette betyr at de jobber overtid når den er effektiv, og at de vanligvis arbeider på en slik måte som å maksimere produktiviteten uke inn og uke ut., Det er ganske godt forstått i disse dager at døden mars prosjekter er verken produktive og heller produsere kvalitet programvare. XP lagene er i det for å vinne, ikke for å dø.

Konklusjon

Extreme Programming er en disiplin av programvare utvikling, basert på verdiene av enkelhet, kommunikasjon, tilbakemelding, og mot. Det fungerer ved å bringe hele laget sammen i nærvær av enkle praksis, med nok tilbakemelding til at teamet å se hvor de er og om å tilpasse praksis til sin unike situasjon.