| Der er ingen mangel på eksempler - både i litteraturen og i det virkelige liv - på hvor galt det kan gå med edb projekter. I den nye ende er det måske
nærliggende at nynne om Amanda, mens en klassisk bog som "The Mythical Man-Month" fra 1975 også er uhyggeligt aktuel i dag. Specielt husker jeg udtrykket: 'Flere programmerings
projekter er gået galt af mangel på kalendertid end af alle andre grunde kombineret'. eXtreme Programming (XP) er ikke en metode, der påstår at løse disse problemer. XP er en række
fremgangsmåder, der i fællesskab giver et bud på, hvordan man kan handle i en vanskelig og omskiftelig verden, sådan at resultatet er kvalitetssoftware.
Der er ikke nogle nye teknikker i XP. Alle fremgangsmåderne er gammelkendte og har været forsøgt før. Og alle er de havnet på den metodiske losseplads i tidens løb. Det nye i XP er
sammenstillingen af teknikkerne på en måde, der tillader dem at holde hverandres svagheder i skak.
Så målet med XP er klart:
- En proces, der tillader frembringelse af software, som kan leveres til tiden, opfylde kundens behov, fungere, vedligeholdes og udvides.
Det første skridt i XP er, at et software projekt kan ses som et kontrolleret system med fire indbyrdes afhængige variable: Pris[cost], kvalitet, tid og indhold[scope]. At de variable er
afhængige betyder, at når de tre af dem holdes fast, vil systemet give den fjerde. Så hvis man siger "vi vil lave disse features[indhold], med disse mennesker og maskiner[pris], i
højeste kvalitet," så svarer systemet med den tid, det tager (ofte en der er højere end man ønsker). Hvis man bilder sig ind, at man sætter alle fire variable, er det i første
omgang kvalitet og dernæst tid, der må holde for. Vores proces må altså forstå at håndtere kompromisser mellem disse fire variable. XP er baseret på fire værdier. Fire elementer,
vi gerne vil se komme til deres ret:
- Kommunikation
- Enkelthed
- Feedback
- Mod
(fortsættes i næste spalte) |
Hvis nogen laver noget forkert, er det fordi de ikke ved bedre. Altså manglede der noget kommunikation. Hvis vi skal kommunikere en masse til alle, bliver det
nemmere, hvis vi laver tingene så enkelt som muligt. Hvis vi skal blive bedre til det vi gør, må vi vide, hvordan det vi gør virker. Derfor skal vi sikre direkte feedback fra vores
aktiviteter. Hvis alt dette skal virke, må vi have mod til at sige sandheden; estimater der er baseret på den viden, vi har, inklusive den feedback vi har fået på vores tidligere estimater. I
lyset af disse værdier udvælger XP fire aktiviteter, som er de ting, vi vil gøre: Kode, teste, lytte og designe. Hvis der ikke er kode, er der intet program. Hvis vi ikke har testet, at den
er der, er der i realiteten ingen kode. Hvis vi ikke har lyttet, er det ikke de rigtige ting vi tester. Hvis vi ikke har designet, kan vi ikke blive ved med at viderudvikle vores kode. Den
endelige form XP antager er de 12 fremgangsmåder, vi vil benytte til at sikre, at vi kommer til at lave så meget af de fire aktiviteter som muligt, og så lidt andet: The Planning Game, Small
Releases, Metaphore, Simple Design, Testing, Refactoring, Pair programming, Collective ownership, 40-hour week, On-Site customer og Coding standard. Det ekstreme i XP er, at man har taget disse
12 fremgangsmåder til deres extremum. Vi skruer simpelt hen alle knapperne op på max. På dette sted er det, at der normalt kommer indvendiger [Det kan man da ikke, det kan aldrig virke,
...]. XP har et svar på disse indvendinger. Og XP har fungeret i virkeligheden. Ikke dermed sagt, at det er nemt. Men XP er et bud på en opførsel, der kan bringe os igennem.
Af andre ting, der karakteriser XP godt, er følgende citat for noget af XP dokumentationen: Extreme Programming seems compatible with observations of programmers in the wild - eller med
andre ord: XP er et bud på, hvordan vi kan bruge de ting, vi er gode til, så vores software projekt bliver en succes. |
