Extrem programmering (XP) ger resultat, men är det rätt för dig?

Om termen extrem programmering får dig att tänka på X-games och actionsport är du inte helt fel ute. Extrem programmering (XP) är faktiskt ett ganska extremt sätt att programmera. I likhet med andra agila metoder för programvaruutveckling använder XP anpassningsbar, testdriven utveckling för programvaruteknik. Men till skillnad från andra metoder har extrem programmering strikta regler och vägledande värderingar som styr hur arbetet utförs. 

Vad är extrem programmering (XP)?

Extrem programmering är en agil projekthanteringsmetod som fokuserar på snabbhet och enkelhet med korta utvecklingscykler och mindre dokumentation. Processstrukturen bestäms av fem vägledande värderingar, fem regler och 12 XP-praxis (som vi kommer att gå igenom närmare i den här artikeln). 

Precis som andra agila metoder är XP en metod för programvaruutveckling som är uppdelad i arbetssprintar. Agila ramverk följer en iterativ process: ramverket slutförs och granskas efter varje sprint, förfinas för maximal effektivitet och anpassas till förändrade krav. I likhet med andra agila metoder gör XP:s design det möjligt för utvecklare att svara på kundberättelser, anpassa sig och ändra i realtid. Men XP är mycket mer disciplinerat och använder frekventa kodgranskningar och enhetstester för att göra ändringar snabbt. Det är också mycket kreativt och samarbetsinriktat, och prioriterar teamarbete under alla utvecklingsstadier.

Extrem programmering vs Scrum

Scrum är en annan vanlig typ av agil metodik som hanteras av en Scrummästare. I likhet med XP kör Scrum sprintar med användarberättelser för att utveckla nya produkt- eller programvarufunktioner. XP är dock mer rigorös än Scrum, med strikta regler och riktlinjer som uppmuntrar till ständig kontakt mellan utvecklare och kunden. Du kan också använda Scrum för alla processer som kräver iteration och kundinmatning, medan du bara skulle använda XP-programmering.

Vem skapade extrem programmering?

XP har sitt ursprung i slutet av 1990-talet, då Kent Beck skapade det för att hantera utvecklingen av ett lönesystem för Chrysler som kallades C3-projektet. Målet med XP var (och är fortfarande) att ta bort motståndet mot att ändra kod i utvecklingsprojekt. I mer traditionella programvaruutvecklingsmetoder lämnar man ofta koden ifred när den väl är skriven (förutom för felsökning). Med XP granskar man koden så noggrant att utvecklare kan bestämma sig för att skriva om den helt efter en enda iteration. 

När ska man använda extrem programmering?

Eftersom extrem programmering fokuserar på programvaruutveckling används den vanligtvis bara av teknikteam. Även i programvaruteam fungerar det bara i vissa inställningar. För att få ut mesta möjliga av extrem programmering är det bäst att använda den när du: 

• Hanterar ett mindre team. På grund av sin samarbetsinriktade karaktär fungerar XP bäst i mindre team på under 10 personer. 

• är i ständig kontakt med dina kunder. XP införlivar kundernas krav i hela utvecklingsprocessen och förlitar sig till och med på dem för testning och godkännanden.

• Har ett anpassningsbart team som kan omfamna förändring (utan att bli upprörda). Extrem programmering kräver ofta att hela teamet kastar bort sitt hårda arbete. Det finns också regler som gör det möjligt för andra teammedlemmar att göra ändringar när som helst, vilket inte fungerar om dina teammedlemmar tar det personligt.

• Är väl insatta i de tekniska aspekterna av kodning. XP är inte för nybörjare. Du måste kunna arbeta och göra ändringar snabbt.

XP:s livscykel

XP-livscykeln uppmuntrar kontinuerlig integrering där teammedlemmarna integrerar nästan konstant, så ofta som varje timme eller dagligen. Men hela livscykeln ser ut så här:

• Hämta oavslutat arbete från användarberättelser 

• Du prioriterar de viktigaste punkterna 

• Påbörja iterativ planering  

• Införliva ärlig planering  

• Håll en ständig kommunikation med alla intressenter och stärk teamet  

• Lansera arbetet.  

• Ta emot feedback. 

• Gå tillbaka till det iterativa planeringsstadiet och upprepa efter behov.

5 värderingar i extrem programmering

Extrem programmering är värderingsdriven. I stället för att använda externa motivatorer gör XP det möjligt för ditt team att arbeta på ett mindre komplicerat sätt (med fokus på enkelhet och samarbete över komplexa designer), allt baserat på de här fem värderingarna.

1. Enkelhet

Innan du påbörjar något extremt programmeringsarbete ska du först fråga dig själv: Vad är det enklaste som också fungerar? Delen "som fungerar" är en viktig skillnad – det enklaste är inte alltid praktiskt eller effektivt. I XP fokuserar du på att få det viktigaste arbetet gjort först. Det innebär att du letar efter ett enkelt projekt som du vet att du kan genomföra.

2. Kommunikation

XP förutsätter snabb reaktionsförmåga och effektiv kommunikation. För att kunna arbeta måste teamet vara öppet och ärligt mot varandra. När problem uppstår förväntas du säga ifrån. Anledningen till det är att andra teammedlemmar ofta redan har en lösning. Och om de inte har det, kommer ni att hitta en snabbare som grupp än vad ni skulle göra ensamma.

3. Feedback

Precis som andra agila metoder införlivar XP användarberättelser och feedback direkt i processen. XP fokuserar på att producera arbete snabbt och enkelt och sedan dela det för att få nästan omedelbar feedback. Därför har utvecklare nästan konstant kontakt med kunderna under hela processen. I XP lanserar man frekventa utgåvor för att få insikter tidigt och ofta. När du får feedback anpassar du processen för att införliva den (i stället för projektet). Om feedbacken till exempel minskar onödig fördröjningstid, justerar du processen så att ett par utvecklare förbättrar fördröjningstiden i stället för att justera projektet som helhet.

4. Mod

XP kräver ett visst mått av mod. Du förväntas alltid ge ärliga uppdateringar om dina framsteg, vilket kan vara ganska sårbart. Om du missar en deadline i XP vill din teamledare förmodligen inte diskutera varför. Istället berättar du att du missade en deadline, tar ansvar och går tillbaka till arbetet. 

Om du är teamledare är det ditt ansvar i början av XP-processen sätta upp förväntningar på framgång och definiera vad som är "klart". Det finns ofta ingen plan för misslyckanden eftersom teamet fokuserar på framgång. Det kan dock vara skrämmande, eftersom saker och ting inte alltid går som planerat. Men om saker och förändras under XP-processen förväntas ditt team anpassa sig och förändras i takt med det. 

5. Respekt

Med tanke på hur högt XP prioriterar kommunikation och ärlighet är det vettigt att respekt är viktigt. För att team ska kunna kommunicera och samarbeta effektivt måste de kunna vara oeniga. Men det finns sätt att göra det på ett vänligt sätt. Respekt är en bra grund som leder till vänlighet och förtroende, även när det finns en hel del ärlighet. För extrem programmering är förväntningarna: 

• Ömsesidig respekt mellan kunder och utvecklingsteam. 

• Ömsesidig respekt mellan teammedlemmar. 

• En insikt om att alla i teamet bidrar med något värdefullt till projektet.

5 regler för extrem programmering

Extreme programming-värderingarna är de mer filosofiska aspekterna. Reglerna är de praktiska tillämpningarna för hur arbetet ska utföras. Du behöver båda för att driva ett effektivt XP-team. 

1. Planering

I planeringsskedet för XP bestämmer du om projektet är genomförbart och om det passar för XP. För att göra det ska du titta på:

• Användarberättelser för att se om de matchar värdet av enkelhet och kontrollera att kunden är tillgänglig för processen. Om användarberättelsen är mer komplex eller om den är gjord av en anonym kund kommer den förmodligen inte att fungera för XP.

• Projektets Business-värde och prioritering för att se till att det är i linje med att "få det viktigaste arbetet gjort först". 

• Vilket utvecklingsstadium du befinner dig i. XP är bäst för tidig utveckling och fungerar inte lika bra för senare iterationer.

När du har bekräftat att projektet är lämpligt för XP kan du skapa ett utgivningsschema, men tänk på att du bör släppa tidigt och ofta för att få feedback. Gör så här:

• Dela upp projektet i iterationer och skapa en plan för varje iteration. 

• Sätt upp realistiska deadliner och en hållbar takt. 

• Dela uppdateringar när de sker, vilket ger ditt team möjlighet att vara ärligt och transparent. 

• Dela uppdateringar i realtid som hjälper teamet att identifiera, anpassa och göra ändringar snabbare. 

• Använd ett projekthanteringsverktyg för att skapa en Kanban-tavla eller tidslinje för att spåra förloppet i realtid. 

2. Hantera

En av de viktigaste delarna i XP är det fysiska utrymmet. XP-purister rekommenderar att man använder en öppen arbetsyta där alla teammedlemmar arbetar i ett öppet rum. Eftersom XP är så samarbetsinriktat är det bra att ha ett utrymme där ni kan träffas fysiskt. Men det är inte alltid praktiskt i dagens samhälle. Om du arbetar i ett distansteam kan du överväga att använda en plattform som uppmuntrar asynkront arbete för samarbete på distans. På så sätt kan alla medlemmar fortsätta att arbeta med projektet tillsammans, även om de inte är fysiskt tillsammans.

Precis som i andra agila metoder kan du använda dagliga standup-möten för att hålla koll på läget och uppmuntra till ständig, öppen kommunikation. Det är bra att använda både en veckocykel och en kvartalscykel. Under kvartalscykeln granskar du och teamet de berättelser som kommer att vägleda ert arbete. Ni kommer också att studera er XP-process och leta efter luckor eller möjligheter att göra ändringar. Därefter arbetar ni i veckocykler som alla börjar med ett kundmöte. Kunden väljer den användarberättelse som programmerarna ska arbeta med den veckan. 

Som chef eller teamledare kommer ditt fokus att vara på att upprätthålla arbetsförloppet, mäta takten, flytta runt teammedlemmar för att åtgärda buggar eller problem när de uppstår, eller ändra XP-processen för att passa ditt nuvarande projekt och iteration. Kom ihåg att målet med XP är att vara flexibel och vidta åtgärder, så ditt arbete kommer att vara mycket fokuserat på teamets nuvarande arbete och reaktivt för eventuella ändringar.

3. Design

När du precis har kommit igång med extrem programmering börjar du med den enklaste möjliga designen, med vetskapen om att senare iterationer kommer att göra dem mer komplexa. Lägg inte till tidig funktionalitet i det här skedet för att hålla det så enkelt som möjligt.

XP-team använder ofta CRC-kort (class-responsibility-collaboration) för att visa hur varje objekt i designen interagerar. Genom att fylla i varje fält i kortet får du en visuell interaktion av alla funktioner och hur de relaterar och interagerar. CRC-kort inkluderar: 

• Klass (samling av liknande objekt)

• Ansvarsområden (relaterade till klassen).

• Medarbetare (klass som interagerar med den här)

CRC-kort är användbara för att stimulera processen och upptäcka potentiella problem. Oavsett hur du utformar processen bör du använda ett system som minskar potentiella flaskhalsar. För att göra det bör du se till att du proaktivt letar efter risker. Så snart ett potentiellt hot dyker upp ska du tilldela en eller två teammedlemmar att hitta en lösning i händelse av att hotet inträffar.

4. Kodning

En av de mer unika aspekterna av XP är att du kommer att hålla konstant kontakt med kunden under hela kodningsprocessen. Det här partnerskapet gör det möjligt att testa och införliva feedback i varje iteration, i stället för att vänta till slutet av en sprint. Men kodningsreglerna är ganska strikta i XP. Några av reglerna är:

• All kod måste uppfylla kodningsstandarder.

• Använda ett enhetstest för att fastställa krav och utveckla alla aspekter av projektet.

• Programmering i par: två utvecklare arbetar tillsammans samtidigt på samma dator. Det tar inte längre tid, utan man använder snarare dubbelt så mycket fokus för att producera resultat av högsta kvalitet. 

• Använd kontinuerliga integreringar för att lägga till ny kod och testa den omedelbart.

• Endast ett par kan uppdatera koden vid en viss tidpunkt för att minska antalet fel.

• Kollektivt kodägande: alla medlemmar i teamet kan ändra koden när som helst.

5. Testning

Du bör testa under hela den extrema programmeringsprocessen. All kod måste klara enhetstester innan den släpps. Om du upptäcker buggar under dessa tester skapar du nya, ytterligare tester för att åtgärda dem. Senare kommer du att konfigurera samma användarberättelse som du har arbetat med i ett acceptanstest. Under det här testet granskar kunden resultaten för att se hur väl du har översatt användarberättelsen till produkten.

Vilka är de 12 extrema programmeringsmetoderna?

För att ytterligare finslipa processen använder XP också en uppsättning av 12 metoder under hela processen. De är baserade på det agila manifestet, men anpassade för att passa XP-behov:

1. Planeringsspelet: XP-planering används för att styra arbetet. Resultaten av planeringen bör vara vad du hoppas uppnå och när, och vad du ska göra härnäst.

2. Kundtester: När du har slutfört en ny funktion kommer kunden att utveckla ett acceptanstest för att avgöra hur nära den är deras ursprungliga användarberättelse.

3. Små lanseringar: XP använder små, rutinmässiga lanseringar för att få insikter under hela processen. Ofta går lanseringarna direkt till kunderna, även om de kan ske internt.

4. Enkel design: XP-systemet är utformat för enkelhet – du producerar bara det som är nödvändigt och inget mer. 

5. Parprogrammering: All programmering görs av ett par utvecklare som sitter sida vid sida. Det finns inget soloarbete i extrem programmering.

6. Testdriven utveckling (TDD): XP:s beroende av feedback kräver omfattande testning. Genom korta cykler släpper programmerare automatiserade tester och reagerar sedan omedelbart.

7. Refactoring: Här uppmärksammar man kodbasens finare detaljer, tar bort dubbletter och ser till att koden är sammanhängande. Det här resulterar i bra, enkla designer.

8. Kollektivt ägarskap: Alla kodningspar kan ändra koden när som helst, oavsett om de utvecklade den eller inte. XP producerar kod som ett team, och allas arbete hålls till de högre kollektiva standarderna.

9. Kontinuerlig integrering: XP-team väntar inte på slutförda iterationer, utan integrerar kontinuerligt. Ofta integrerar ett XP-team flera gånger om dagen.

10. Hållbar takt: Intensiteten i XP-arbetet kräver att du sätter en hållbar takt. Team bör bestämma hur mycket arbete de kan producera på det här sättet per dag och per vecka och använda det för att fastställa deadlines för arbetet.

11. Metafor: Metaforen är bokstavligen en metafor. Den bestäms av teamet och använder språk för att beskriva hur teamet ska fungera. Till exempel: Vi är myror som arbetar tillsammans för att bygga upp myrstacken. 

12. Kodningsstandard: XP-team följer en standard. På samma sätt som författare måste anta ett varumärkes röst för att låta som om samma person alltid skriver, kodar XP-utvecklare på samma enhetliga sätt så att det låter som om en och samma utvecklare har skrivit det.

Intensivt men effektivt

Vid det här laget har du säkert förstått att extrem programmering är, ja, extrem. Processen är rigorös och mycket strukturerad, men resultaten kan vara värda det. XP:s unika utvecklingsprocess som innehåller kundfeedback och intensiv, samarbetsinriktad programmering resulterar i högkvalitativ programvara. 

Effektivisera din XP-planering och -hantering med ett arbetshanteringsverktyg som uppdateras och anpassas i realtid, precis som ditt arbete gör.