1. Vad är XP

XP är en lättviktsmetod för programmering av mindre projekt.

• Ett litet projekt är 1-12 pers. XP fungerar även upp till 24 personer, men över denna summa måste en tyngre metod tillämpas, eller att projektet delas i delprojekt.

2. Grunderna i XP

Följande punkter sammanfattar XP:

1. The Planning game: Beställare och utvecklare samarbetar enligt följande princip:
   1. Krav (Användarberättelser): Beställare sammanställer en lista med krav, som formuleras som Användarberättelser.
   2. Estimering: Utvecklarna tidsuppskattar varje Användarberättelse.
   3. Val av Användarberättelser: Beställaren väljer vilka berättelser som ska byggas och i vilken ordning. Beställaren bestämmer hur ofta releaser till produktion ska ske.
2. Små leveranser: Leverans sker med jämna mellanrum, varje vecka, varannan vecka eller var tredje vecka. Leveransdatum skjuts aldrig upp.
3. Gemensamt språk: Skapa en terminologi för projektet, så att alla domänobjekt är namngivna.
4. Enkel design: Lös bara dagens problem, alltså de som beskrivs av User Stories.
5. Konstant testning: Skriv enhetstester för all kod som ska skrivas. Skriv Acceptanstester för User Stories.
6. Refactoring: Utför refactoring så fort det behövs.
7. Konstant kodgranskning (Parprogrammering): En kodar, en granskar.
8. Konstant kundnärvaro: En kund finns alltid till hands i projektet.
9. Kontinuerlig integration (dagligen): Minst en gång om dagen måste projektet integreras.
10. Kollektivt kodägande: Ingen utvecklare äger en modul, alla i projektet kan arbeta var som helst i koden.
11. 40-timmarsvecka: Jobba aldrig över, skala bort UserStories istället inför leveransen.
12. Kodstandard: I idealfallet vet man inte vem som har skrivit koden.

3. Missuppfattningar om XP

Följande missuppfattning är vanlig om XP:

• XPare cowboyhackar utan begränsningar.

4. Beskrivning av ett XP-projekt

Följande text hittade jag på nätet:

1. The first thing you'd notice is that all the programmers are in a room together, usually sitting around a large table in the middle of the room. The programmers may have desks or offices nearby, but you can tell by where the books are piled that the big table is where the action is.
2. XP teams work in a series of fixed iteration cycles. Iterations typically last 1, 2 or 3 weeks each depending on the team. (A given team will almost always use same the iteration size for every iteration.)
3. At the beginning of each iteration, the team gets together with the customer for a planning meeting. In that meeting, they go over the features the customer wants done in that iteration, breaking each feature down into individual engineering tasks. Individual developers then sign up for specific tasks, and estimate those tasks. No developer is allowed to sign up for more work in the coming iteration than he completed in the previous iteration.
4. During the rest of the iteration, the team will implement the features they signed up for, pair programming on all production code. All code is written test-first -- that is, the developers don't write any code until they have a failing test case. The developers write unit tests to test individual classes and subsystems. The customer provides functional or acceptance tests to validate the features that the programmers are developing.
5. At the end of the iteration (usually on a Friday), the programmers deliver a working system to the customer. The system may not be complete, but all functionality that is implemented works completely, without bugs. The customer accepts delivery, and the team goes home early. The next Monday everyone meets again to plan the next iteration, and the cycle repeats itself.
6. Actual product release is almost a non-event. The customer takes the delivered system from some iteration, and distributes it to end users. The system is always very nearly defect-free, so the only question is when the developers have added enough functionality to make it worthwhile for the end users to upgrade.