Vad är extrem programmering?

Planeringsspel

XP planning tar upp två viktiga frågor i mjukvaruutveckling: förutsäga vad som kommer att uppnås vid förfallodagen och bestämma vad du ska göra härnäst. Tyngdpunkten ligger på att styra projektet – vilket är ganska enkelt – snarare än på exakt förutsägelse av vad som kommer att behövas och hur lång tid det kommer att ta – vilket är ganska svårt., Det finns två viktiga planeringssteg i XP som tar itu med dessa två frågor:

Release Planning är en övning där kunden presenterar de önskade funktionerna för programmerarna, och programmerarna uppskattar deras svårigheter. Med kostnadsberäkningarna i hand, och med kunskap om betydelsen av funktionerna, lägger kunden ut en plan för projektet. Inledande utgivningsplaner är nödvändigtvis otydliga: varken prioriteringarna eller uppskattningarna är verkligen solida, och tills laget börjar fungera vet vi inte hur snabbt de kommer att gå., Även den första utgåvan planen är korrekt nog för beslutsfattande, dock, och XP-Team revidera release plan regelbundet.

Iteration planering är den praxis där laget ges riktning varje par veckor. XP lag bygga programvara i två veckor ”iterationer”, leverera kör användbar programvara i slutet av varje iteration. Under Iterationsplanering presenterar kunden de önskade funktionerna under de närmaste två veckorna. Programmerarna dela upp dem i uppgifter, och uppskatta deras kostnad(på en finare detaljnivå än i Release planering)., Baserat på mängden arbete som utförts i föregående iteration registrerar laget för vad som kommer att genomföras i den nuvarande iterationen.

dessa planeringssteg är mycket enkla, men de ger mycket bra information och utmärkt styrkontroll i händerna på kunden. Varje par veckor är mängden framsteg helt synlig. Det finns ingen ”nittio procent gjort” i XP: en funktionshistoria slutfördes, eller det var det inte., Detta fokus på synlighet resulterar i en trevlig liten paradox: å ena sidan, med så mycket synlighet, är kunden i stånd att avbryta projektet om framsteg inte är tillräckligt. Å andra sidan är framsteg så synliga, och förmågan att bestämma vad som ska göras nästa är så komplett, att XP-projekt tenderar att leverera mer av vad som behövs, med mindre tryck och stress.

Kundtester

som en del av att presentera varje önskad funktion definierar XP-kunden en eller flera automatiska acceptanstester för att visa att funktionen fungerar., Teamet bygger dessa tester och använder dem för att bevisa för sig själva, och för kunden, att funktionen genomförs korrekt. Automatisering är viktigt eftersom manuell test hoppas över i tidspressen. Det är som att släcka ljuset när natten blir mörkaste.

de bästa XP-lagen behandlar sina kundtester på samma sätt som de gör programmeringstester: när testet körs fortsätter laget att fungera korrekt därefter. Det betyder att systemet bara förbättras, alltid går framåt, aldrig backsliding.,

små utgåvor

XP-Team övar små utgåvor på två viktiga sätt:

För det första släpper teamet igång, testat programvara, levererar affärsvärde som kunden valt, varje iteration. Kunden kan använda denna programvara för alla ändamål, vare sig utvärdering eller ens släppa till slutanvändare (rekommenderas). Den viktigaste aspekten är att programvaran är synlig, och ges till kunden, i slutet av varje iteration. Detta håller allt öppet och konkret.

För det andra släpper XP-lag ofta till sina slutanvändare., XP webbprojekt släppa så ofta som dagligen, i hus projekt varje månad eller oftare. Även krymplindade produkter levereras så ofta som kvartalsvis.

det kan tyckas omöjligt att skapa bra versioner detta ofta, men XP-lag överallt gör det hela tiden. Se kontinuerlig Integration för mer om detta, och notera att dessa frekventa utgåvor hålls tillförlitliga av XP: s besatthet med testning, som beskrivs här i Kundtester och testdriven utveckling.

Enkel Design

XP-lag bygger programvara till en enkel men alltid adekvat design., De börjar enkelt, och genom programmerare testning och designförbättring, de håller det så. Ett XP-team håller designen exakt anpassad för systemets nuvarande funktionalitet. Det finns ingen bortkastad rörelse, och programvaran är alltid redo för vad som händer.

Design I XP är inte en engångs sak, eller en up-front sak, det är en all-the-time sak. Det finns konstruktionssteg i frigöringsplanering och iterationsplanering, plus Team engagerar sig i snabba designsessioner och designrevisioner genom refactoring, genom hela projektets gång., I en inkrementell, iterativ process som extrem programmering, är bra design viktigt. Det är därför det finns så mycket fokus på design under hela utvecklingen.

parprogrammering

all produktionsprogramvara i XP är byggd av två programmerare, som sitter sida vid sida, på samma maskin. Denna praxis säkerställer att all produktionskod granskas av minst en annan programmerare, och resulterar i bättre design, bättre testning och bättre kod.

det kan tyckas ineffektivt att ha två programmerare som gör ”en programmerares jobb”, men det omvända är sant., Forskning om parprogrammering visar att parning ger bättre kod på ungefär samma tid som programmerare som arbetar ensamma. Det är rätt: två huvuden är verkligen bättre än en!

vissa programmerare objekt för att para ihop programmering utan att någonsin försöka det. Det tar lite övning att göra bra, och du måste göra det bra i några veckor för att se resultaten. Nittio procent av programmerare som lär sig parprogrammering föredrar det, så vi rekommenderar det starkt till alla lag.

Parning, förutom att ge bättre kod och tester, tjänar också till att kommunicera kunskap i hela laget., Som parbrytare får alla fördelarna med allas specialiserade kunskaper. Programmerare lär sig, deras färdigheter förbättras, de blir mer värdefulla för laget och företaget. Parning, även på egen hand utanför XP, är en stor vinst för alla.

testdriven utveckling

extrem programmering är besatt av feedback, och i mjukvaruutveckling kräver bra feedback bra testning. Top XP-lag övar ”testdriven utveckling”, som arbetar i mycket korta cykler för att lägga till ett test och sedan få det att fungera., Nästan enkelt producerar lag kod med nästan 100 procent testtäckning, vilket är ett bra steg framåt i de flesta butiker. (Om dina programmerare redan gör ännu mer sofistikerade tester, mer makt till dig. Fortsätt, det kan bara hjälpa!)

det räcker inte att skriva tester: du måste köra dem. Även här är extrem programmering extrem. Dessa ”programmerare tester”, eller” enhetstester ” samlas alla tillsammans, och varje gång någon programmerare släpper någon kod till förvaret (och par släpper vanligtvis två gånger om dagen eller mer), måste varenda en av programmeraren tester köras korrekt., Hundra procent, hela tiden! Det innebär att programmerare får omedelbar feedback om hur de gör. Dessutom ger dessa tester ovärderligt stöd eftersom mjukvarudesignen förbättras.

design Improvement (Refactoring)

Extreme Programming fokuserar på att leverera affärsvärde i varje iteration. För att uppnå detta under hela projektet måste programvaran vara väl utformad. Alternativet skulle vara att sakta ner och slutligen fastna., Så XP använder en process av kontinuerlig design förbättring kallas Refactoring, från titeln Martin Fowlers bok, ”Refactoring: förbättra utformningen av befintlig kod”.

refactoringprocessen fokuserar på borttagning av dubbelarbete (ett säkert tecken på dålig design) och på att öka kodens ”sammanhållning”, samtidigt som man sänker ”kopplingen”. Hög sammanhållning och låg koppling har erkänts som kännetecknen för väldesignad kod i minst trettio år. Resultatet är att XP-team börjar med en bra, enkel design och alltid har en bra, enkel design för programvaran., Detta gör det möjligt för dem att upprätthålla sin utvecklingshastighet, och i själva verket ökar i allmänhet hastigheten när projektet går framåt.

Refactoring stöds naturligtvis starkt av omfattande testning för att vara säker på att när designen utvecklas är ingenting brutet. Således kundtester och programmerare tester är en kritisk möjliggörande faktor. XP-metoderna stöder varandra: de är starkare tillsammans än separat.

kontinuerlig Integration

extrema Programmeringsteam håller systemet fullt integrerat hela tiden. Vi säger att dagliga byggnader är för wimps: XP-lag bygger flera gånger per dag., (Ett XP-team med fyrtio personer bygger minst åtta eller tio gånger per dag!)

fördelen med denna praxis kan ses genom att tänka tillbaka på projekt du kanske har hört talas om (eller till och med varit en del av) där byggprocessen var veckovis eller mindre ofta, och ledde vanligtvis till ”integration hell”, där allt bröt och ingen visste varför.

sällan integration leder till allvarliga problem på ett mjukvaruprojekt., Först och främst, även om integrationen är kritisk för att skicka bra arbetskod, övas laget inte på det, och ofta delegeras det till personer som inte är bekanta med hela systemet. För det andra är sällan integrerad kod ofta – jag skulle säga vanligtvis – buggy kod. Problem kryper in vid integrationstid som inte upptäcks av någon av de tester som sker på ett icke-integrerat system. För det tredje leder svag integrationsprocess till lång kod fryser., Kod fryser innebär att du har långa tidsperioder när programmerare kan arbeta på viktiga shippable funktioner, men att dessa funktioner måste hållas tillbaka. Detta försvagar din position på marknaden, eller med dina slutanvändare.

kollektiv kod ägande

på en extrem programmering projekt, kan alla par programmerare förbättra någon kod när som helst. Detta innebär att all kod får nytta av många människors uppmärksamhet, vilket ökar kodkvaliteten och minskar defekter., Det finns också en annan viktig fördel: när koden ägs av individer, krävs funktioner ofta på fel plats, som en programmerare upptäcker att han behöver en funktion någonstans i kod som han inte äger. Ägaren är för upptagen för att göra det, så programmeraren sätter funktionen i sin egen kod, där den inte hör hemma. Detta leder till ful, svår att underhålla kod, full av dubbelarbete och med låg (dålig) sammanhållning.

kollektivt ägande kan vara ett problem om människor arbetade blint på kod som de inte förstod., XP undviker dessa problem genom två viktiga tekniker: programmeraren tester fånga misstag, och par programmering innebär att det bästa sättet att arbeta på obekant kod är att para ihop med experten. Förutom att säkerställa goda modifieringar vid behov sprider denna praxis kunskap i hela laget.

Kodningsstandard

XP – lag följer en gemensam kodningsstandard, så att all kod i systemet ser ut som om den skrevs av en enda väldigt kompetent individ., Standardens särdrag är inte viktiga: det som är viktigt är att all kod ser bekant ut, till stöd för kollektivt ägande.

metafor

extrema Programmeringsteam utvecklar en gemensam vision om hur programmet fungerar, som vi kallar ”metafor”. I bästa fall är metaforen en enkel suggestiv beskrivning av hur programmet fungerar, till exempel ”det här programmet fungerar som en bikupa av bin, går ut för pollen och tar det tillbaka till bikupan” som en beskrivning för ett agentbaserat informationshämtningssystem.

Ibland uppstår inte en tillräckligt poetisk metafor., I vilket fall som helst, med eller utan levande bilder, använder XP-team ett gemensamt namnsystem för att vara säker på att alla förstår hur systemet fungerar och var de ska leta efter den funktionalitet du letar efter, eller för att hitta rätt plats för att sätta den funktionalitet du ska lägga till.

hållbar takt

extrema Programmeringsteam är i det på lång sikt. De arbetar hårt, och i en takt som kan upprätthållas på obestämd tid. Detta innebär att de arbetar övertid när det är effektivt, och att de normalt arbetar på ett sådant sätt att maximera produktiviteten vecka in och vecka ut., Det är ganska väl förstått dessa dagar att death march projekt är varken produktiva eller producera kvalitet programvara. XP lag för att vinna, inte att dö.

slutsats

extrem programmering är en disciplin av mjukvaruutveckling baserad på värden av enkelhet, kommunikation, feedback och mod. Det fungerar genom att föra hela laget tillsammans i närvaro av enkla metoder, med tillräckligt med feedback för att göra det möjligt för laget att se var de är och att anpassa metoderna till sin unika situation.