FAGBOK:"Extreme Programming Refactored: The Case Against XP" av Matt Stephens og Doug Rosenberg

XP er utrolig populært for tiden. Alle kule Javaprogrammerere har omfavnet det. Og det er jo ikke så rart - de kjedelige oppgavene som design og dokumentasjon erstattes av det vi liker best: koding. Og metoden skal sikre at kunden får systemet han ønsker og med høy kvalitet.

XP sine kjerneverdier er

• Kommunikasjon
• Enkelhet
• Feedback
• Mot

Hvis jeg skal våge meg på en kort beskrivelse av de viktigste punktene i XP er det:

• Ikke design i forkant. Designet kommer ut av koden.
• Utviklingen skal være testdrevet: testen skal skrives før selve koden.
• Det skal være en kunde tilstede som kan ta avgjørelser.
• Koden skal skrives om hele tiden (refactor mercilessly).
• Ikke lag mer enn det som du vet trengs.
  
• Teamet skal sitte sammen.
• Programmering skal gjøres i par. Og parene skal byttes om hele tiden.
• Koden skal eies kollektivt.
  
• Koden skal releases ofte. Det eneste som skal gjøres i en release er aktiviteter som gir kunden verdi.

I tillegg har XP en ekstremt høy kulhetsfaktor. Når man leser om XP, spesielt på nettet så får man nesten inntrykk av at det er Zen-mestere som snakker.

Også kommer det altså en bok som river alt dette flotte ned. De går systematisk gjennom XP og det som skrives om det og trekker frem problemer. Og de forslår endringer og tilpasninger som kan bøte på noen av problemene.

Noen av hovedpunktene deres er:

• Man trenger endel design før man begynner å kode. Man trenger ihvertfall en domenemodell.
• Man trenger også å lage noen rammeverk. Man kan ikke refactore ting som for eksempel skalering og flerbrukerhåndtering inn i kode. Det tar ihvertfall mye lenger tid enn dersom man har laget et rammeverk på forhånd.
• Noen ganger må man lage mere enn akkurat det som trengs nå. Dermed må man bruke tid på ting som ikke gir direkte verdi for kunden i neste release.
  
• All koding egner seg ikke til parprogrammering. Folk er forskjellige og alle passer ikke til å jobbe så tett med alle. Noen jobber faktisk best alene.
• Databaser er ikke lette å refactore.
• Man trenger en mere formalisert måte å håndtere krav enn storycards. Det er ikke lett å ta det alvorlig når det blir sagt at dersom et kort blir borte uten at kunden merker det så var ikke det kravet så viktig likevel.
  
• Når kunden faktisk har tatt en versjon av systemet i bruk så mister man mye frihet til endringer. Og man bruker mye tid på å ta kundens data videre til neste release og til å hjelpe kunden med å komme rundt feil.
• Mange av XP sine fordeler forsvinner når prosjektet blir stort. Det er ikke lett å la et team på 100 personer sitte sammen. Og kollektivt eierskap til en virkelig stor kodebase er urealistisk. Og vil du da at alle skal ha mot til å refactore alt?
  
• C3-prosjektet som ofte trekkes frem som er et av de store prosjektene hvor XP ble utviklet, ble faktisk stoppet fordi de ikke nådde målene. Slemt å si men sant.

Boken er ganske godt skrevet, men den har mye som irriterer. Frem for alt at de hele tiden skal være morsomme. Spesielt alle sangtekstene som boken er full av virker unødvendige og plagsomme. Samme med de ironiske små historiene. (Unntaket her er historien om The XP Society's Annual Picnic. Særdeles morsom!)
Man kan vel også si at sitater fra bøker og wikier som er løsrevet fra sammenhengen er en litt usportslig måte å argumentere.....

Men uansett svakheter så er dette en bok som alle bør lese! Det er riktig og viktig å sette spørsmål ved populære sannheter.

Synes du denne bokanmeldelsen kunne vært lengre og bedre? Da kan jeg anbefale denne på Slashdot.

Og jeg fant nettopp The XP Society's Annual Picnic på nettet!

Kan kjøpes på play.com.

Amazon sier:
Extreme Programming Refactored: The Case Against XP is meant to provide an independent look at Extreme Programming. It is meant to cut through the marketing hype of Extreme Programming and expose a number of weaknesses with this approach to software development. It tries to draw a distinction between true "agility" in a software process and "fragility" inherent in techniques such as oral documentation. Extreme Programming (XP) is a consummate mix of good goals, some good advice, and lots of bad advice. The goals and the good advice draw people in; the bad advice can potentially cause projects to fail. The XPers' theory is that when applied together, this mixture of rules will somehow magically be safe. XP therefore represents a high-risk process, wrapped in a "feel-good" methodology. The marketing, hype, and earnest self-assurance of its authors will convince many project leaders to try out XP on their next project. In Extreme Programming Refactored: The Case Against XP into a more viable process, Rosenberg and Stephens are not attempting to define a new methodology, as there are plenty of those in the World already. Instead, they will be examining XP in the context of existing methodologies and processes such as RUP, ICONIX, Spiral, RAD, DSDM, etc - and showing how XP goals can be achieved using these existing processes (with a slight emphasis on RUP and ICONIX), using software wisdom that has been tried and proven to work again and again.

Terningkast 5