Extrem programmering

Extrem programmering ( XP , till och med extrem programmering ) är en metod som löser en programmeringsuppgift i spetsen för mjukvaruutveckling och den fäster ett formaliserat tillvägagångssätt mindre viktigt. Detta tillvägagångssätt definierar en processmodell för mjukvaruteknik som närmar sig kundens krav i små steg.

Grunderna

XP livscykel

XP är en processmodell som struktureras genom kontinuerliga iterationer och användning av flera individuella metoder. XP skapades genom syntes av olika discipliner inom mjukvaruutveckling och bygger på metoder som har testats och testats i praktiken, även känd som bästa praxis .

XP följer ett strukturerat förfarande och fokuserar på lagarbete, öppenhet och ständig kommunikation mellan alla inblandade. Kommunikation är en grundpelare.

Metoden förutsätter att kunden ännu inte helt känner till kraven för programvaran som ska skapas i början av projektet och inte kan strukturera den på ett adekvat sätt, eller att ett utvecklingsteam som har anförtrotts implementeringen inte har all information för att göra en pålitlig uppskattning av den ansträngning som krävs under den tid som krävs för att ge upp till examen. Under ett projekt förändras ofta prioriteringar och vikter. Programvarufunktioner som krävs i början kan krävas i en annan form eller till och med bli helt föråldrade över tiden.

Med ett konsekvent fokus på XP bör programvaran som ska skapas ges snabbare och en högre programvarukvalitet och kundnöjdhet bör uppnås än med traditionella metoder. Kunden ska få en färdig produkt för tillverkning som han aktivt har deltagit i.

Nya funktioner utvecklas, integreras och testas ständigt. För att funktionerna ska utvecklas utförs stegen för riskanalys, nyttoanalys, tillhandahållande av en första körbar version ( prototyp ) och ett acceptantest.

Använda sig av

Enligt representanter för denna procedurmodell är XP riskhantering . Den bekräftar risken, reagerar aktivt på den och försöker minimera den. Denna implicita hantering av riskfaktorn står i kontrast till mer tydliga förfaranden, såsom att upprätta en risklista . Mjukvaruutvecklingsprojekt utsätts för olika faror för vilka Extreme Programming bör erbjuda lösningar.

Kundperspektiv

Tack vare sina korta utvecklingscykler erbjuder XP kunden möjligheten att när som helst påverka projektet. Detta är avsett att säkerställa att produkten anpassar sig till nuvarande krav, istället för att uppfylla föråldrade krav från en för länge försvunnen analysfas och därmed vara inaktuell när den introduceras. Dessutom kan kunden använda en ofullständig men åtminstone funktionell produkt efter kort tid. I bästa fall är kunden alltid uppdaterad med den senaste informationen om projektet som utvecklingsteam.

Ett vanligt tillvägagångssätt vid traditionell mjukvaruutveckling är: ”Kanske en dag behöver vi en eller annan programfunktion” , även känd som en funktion . XP kontrasterar detta: Lämna det! (se även YAGNI - "Du behöver inte det"). Innan vart och ett av de korta utvecklingsstegen arbetar vi med kunden för att bestämma exakt vad som verkligen är användbart att utveckla. Den så kallade ” featurit ” bör undvikas.

En av de största riskerna med mjukvaruutveckling är att kunden får en produkt som de inte vill ha i den här formen. XP vill förhindra detta genom att kunden kontinuerligt deltar aktivt i utvecklingsprocessen. Han kan titta på mellanversioner och direkt uttrycka ändringsförfrågningar.

För att kunna utnyttja dessa fördelar måste kunden acceptera ett antal begränsningar och krav i utbyte. XP kräver att han arbetar med utvecklingsteamet under hela utvecklingsprocessen. Dessutom måste han göra utan en formell definition av projektinnehållet (specifikation) (se även Den ideala kunden ).

Programmerarens vy

Det finns ingen strikt uppdelning av roller, eftersom uppgifter tilldelas beroende på situation och färdigheter. Den allmänna kunskapsutbyte och konstant kommunikation hindrar ett kunskapsmonopol . Detta är avsett att lindra individen, eftersom trycket annars väger en person om han är den enda som är bekant med en modul .

För att undvika oanvändbarhet på grund av programfel såväl som felaktig integrering av enskilda komponenter , syftar många tester så tidigt som möjligt till i XP. Varje komponent har ett modultest (enhetstest); i Java till exempel med JUnit . Om ett fel upptäcks i en komponent under utvecklingen utvecklas ett test som lokaliserar det. Dagligt engagemang av de enskilda utvecklarna som är involverade i projektet med automatiskt genomförande av testerna ( regressionstest ) bör leda till en avsevärd kvalitetsökning. Fel bör hittas tidigare, eftersom ju senare ett fel hittas desto dyrare är det att korrigera det. Dessutom bör den testdrivna utvecklingen leda till programkod som är lättare att underhålla och har en bättre design.

Eftersom de flesta enskilda metoder är inriktade på programmerarens vardag, betyder XP också en hög grad av utmaning och, om nödvändigt, förändringar för de inblandade. Dessa aspekter diskuteras mer detaljerat i avsnittet The Ideal Programmer .

Projektvy

XP ger projektet möjlighet att minimera risker. Med korrekt användning av XP bör kunden få programvara vars omfattning inte överraskar honom. Teamet borde inte heller vara så mottagligt för misslyckande (sjukdom, olycka, byte av jobb) hos individer. Ärliga kontakter med kunderna bör öka trovärdigheten och tillfredsställelsen och minimera den rädsla som kan uppstå mellan kunden ("Förstod de mig?", "Vad kommer de att leverera?") Och utveckling ("Vad vill han exakt?", "Kommer han är nöjd med vad vi levererar? ") Består.

Är kostnadsförda uppskattningar pålitliga eftersom de träffades som ett team och ständigt genomgår en kritisk granskning ( Review ). Laganda främjas enligt XP. Det bör vara tydligt för alla i teamet att målet bara kan uppnås som en enhet. Om ett projekt avbryts i förtid, till exempel av kostnadsskäl, kommer de regelbundna iterationerna fortfarande att resultera i en mest användbar produkt.

I många projekt är det inte möjligt att slutföra produkten inom önskad tid, i önskad omfattning och med de planerade resurserna. I XP ska endast det som faktiskt har en fördel för kunden realiseras. De funktioner som behöver skapas bör identifieras genom ständigt utbyte med kunden och prioritetsanalyser. Du bör börja med de funktioner som har störst nytta och med störst (teknisk) risk.

Affärssynpunkt

Ur ekonomisk synvinkel representerar extrem programmering en organisationsform som direkt beskriver processerna för värdeskapande . I ekonomi används också resultat från andra samhällsvetenskaper , särskilt sociologi , för att utvärdera extrem programmering .

När det gäller riskhantering används detta alternativ främst för att kontrollera risker . Som med många värdeskapande processer, särskilt inom mjukvaruutveckling, är risker mestadels operativa risker: Värdeskapande är ineffektivt om kundens önskemål inte har uppfyllts och de uppsatta målen därför inte har uppfyllts. Mervärdet är ineffektivt om alltför stora ansträngningar gjordes för att uppnå resultatet. Riskminskning, och därmed effektivitet och effektivitet, bör uppnås med Extreme Programming genom att hantera fel, med anställda och med kunder:

• Ersättning för sjukfrånvaro
• Kundorienterad utveckling
• Mindre fel i resultatet

Den mest exakta möjliga identifieringen av risker genom själva processen bör möjliggöra en bedömning av risken med anpassade kostnadsberäkningar. Extrem programmering kan å andra sidan göra det svårare att flytta risken. Ur ett riskhanteringsperspektiv är extrem programmering bara ett sätt att hantera risker och ett som har både fördelar och nackdelar.

De mänskliga resurserna i företag ansåg extrem programmering, särskilt vad gäller dess inverkan på anställdas nöjdhet. Extrem programmering bör medvetet eller omedvetet bidra till samarbete . För mänskliga resurser är denna procedur särskilt intressant ur utvecklingen av personalresurser . Den totala produktiviteten bör ökas genom högre medarbetarnöjdhet och undvikande av övertid. Ur en rent matematisk synpunkt antyder dock övningen av parprogrammering det motsatta. Att undvika specialisering och individuell kunskap om delar av programvaran tjänar den kollektiva kunskapskonstruktionen och kan förenkla utbytet av utvecklare.

Under de senaste åren har företagsadministrationen som helhet gått från process- och värdeskapningsinriktad till kund- och marknadsinriktad ledning. Även om extrem programmering beskriver mervärdet erbjuder det möjligheter till ett kundorienterat tillvägagångssätt. Extrem programmering bör - som länge har varit vanligt i andra branscher - göra det möjligt för kunden att vara mer engagerad i värdeskapningsprocessen. Detta blir desto viktigare när programvara skapas och säljs mer som en preliminär produkt och mindre som en faktor bra .

Extrem programmering och dess ansträngning måste också beaktas ur informationshanteringens synvinkel , som definierar och ekonomiskt utvärderar ansträngningarna för det absolut nödvändiga informationsutbytet. Resultat från informations- och kommunikationsvetenskap används för detta ändamål . I synnerhet kan mediarikhetsteorin användas: Eftersom de frågor som ska diskuteras och kommuniceras vanligtvis är komplexa väljs också komplexa, rika kommunikationsmedier : direkta, personliga konversationer. Den svåra rumsliga fördelningsförmågan hos utvecklingsprocesserna och kundens engagemang måste ifrågasättas kritiskt, eftersom det kan finnas en rumsskillnad mellan utvecklare och kunder.

Handling

Extrem programmering kallas ibland för en informell (och därför icke-bindande) metod. Det är dock varken tillvägagångssättet eller målet. Faktum är att formaliseringen av Extreme Programming-metoden medvetet hålls platt och mager. Å andra sidan måste ett avtal mellan kunden och programmeraren upprättas med avseende på de skapade dokumentens bindande karaktär, så länge de ännu inte har ersatts med nyare versioner. Dessutom måste processen för att ersätta en version av ett dokument med en nyare version av detta dokument formaliseras så att båda parter är medvetna om denna ersättning och accepterar denna ersättning.

Organisationsstruktur

Förutom utvecklingsteamet finns det i huvudsak kunden och produktägaren . Det ska inte finnas någon rollseparation inom utvecklingsteamet. Ingen skillnad görs mellan vem i laget som har vilken specialitet eller vilka specialkompetenser de har med sig. Varje person i teamet är som utvecklare ( utvecklaren hänvisas). En chef är vanligtvis någon med ledande befogenheter, dvs. en disciplinär handledare. Detta är mindre viktigt i XP. Däremot finns det en "ledare" i teamet, någon som samordnar kommunikationen med kunderna eller med varandra. Användaren av programvaran som ska skapas kan också leda teamet genom projektet. Skillnaden mellan chef och ”ledare” är typisk för smidiga processmodeller. Produktägaren, som bestämmer exakt procedur, är ansvarig. Produktägare i den mening som XP kan till exempel vara en representant för produkthantering, en kund eller en användare av produkten. Rollerna fördelas olika beroende på projekt och miljö, ofta också i personlig förening.

Kravshantering

Den hantering av de krav och deras genomförande är en nyckelkomponent XPS. Programvarans kvalitet och flexibilitet bör ökas med en blandning av olika mått som presenteras i följande avsnitt, så att förhållandet mellan tidpunkten då begäran gjordes och kostnaderna till stor del är linjära.

Ändra kostnadskurvan beroende på tidpunkten för ändringen

När det gäller en till stor del linjär kurs av en avledbar förändringskostnadskurva, undviks en fullständig kartläggning av alla krav i början av projektet. Istället beaktas de krav som bara uppstår under implementeringen. Denna procedur är resultatet av observationerna att å ena sidan kunden ännu inte vet exakt vad han vill ha i början av projektet, å andra sidan förändras dessa krav under projektets gång. Dessutom, ju senare du hittar dem desto dyrare är de. I värsta fall får kunden något levererat efter ett långt projekt som han inte vill ha i den här formen. Ständigt idéutbyte med kunden, öppenhet för förändringar och ständig integration motverkar dessa risker. Krav tillhandahålls ofta först som prototyper . Det här är versioner som ännu inte har den slutliga funktionaliteten.

planera

Släpp, iterationer, användarberättelser och uppgifter

I samband med planeringen görs vanligtvis följande skillnad: en release innehåller de funktioner som kollektivt och individuellt motiverar tillhandahållandet av en ny version av produkten. För att komma till släppet måste en släppplan planeras, som i huvudsak består av iterationer . Bland annat bestäms antalet och varaktigheten av iterationerna beroende på beräknad utvecklingstid för släppet. Iterationer pågår vanligtvis mellan en och fyra veckor. Tidpunkten för färdigställandet diskuteras som ett tidsintervall vars storlek minskar kontinuerligt under släppet på grund av den kunskap som erhållits och de framsteg som gjorts.

Riskvärdejämförelse och fördelning av prioriteringar

Användarberättelser

De individuella innovationer som ska implementeras inom iterationerna beskrivs med kunden genom användarberättelser .

Hela laget är involverat i skapandet. Kraven som ska bearbetas skrivs på enskilda kort ( berättelsekort ) och placeras så att de kan ses av alla. Utöver denna procedur är det också vanligt att skriva Class Responsibility Collaboration Models på CRC-kort . CRC-modeller tar en aktör i systemet och beskriver deras ansvar och interaktioner med andra aktörer.

De användarberättelser tilldelas prioritetsvärden. För att göra detta, laget och kunden måste först få klarhet i om vilka användar berättelser har den största risken när det gäller schema, kostnader eller funktionalitet och vilka användarhistorier erbjuda den produkten den högsta eller lägsta mervärde, varvid ett diagram kan vara hjälpsam. Släppet bör börja med användarberättelserna som kombinerar högsta risk och högsta nytta. Då ska de användarberättelserna förverkligas som har låg risk men hög nytta. Sedan hanterar teamet användarberättelserna som kombinerar låg risk och låg nytta. Att slutföra användarberättelser med liten nytta men hög risk bör undvikas.

Kundnöjdhet

Förutom en bedömning av nytta och risk är en analys av kundkrav viktig för beslutet om vilka användarberättelser som ska implementeras i utgåvan eller i de första iterationerna. Ett XP-projekt använder ofta Kano-modellen . I en systematisk kundundersökning ställs frågor i en funktionell form och i en dysfunktionell form . Det kan sedan bestämmas vilka användarberättelser som måste fyllas i ( måste-ha ), vilka är linjära till sin karaktär ( ju mer, desto bättre; se linjär .) Och vilka är stimulerande (kunden förväntar sig inte dessa funktioner, använder den produkten även utan det. Detta ökar priset.). Den kunskap som erhållits på detta sätt diskuteras.

XP kännetecknas av att hänsynen till storleken på en enhet, såsom frisättning eller iteration, är oberoende av dess varaktighet.

Uppskattning av ansträngning

När det gäller släppplanering är användarberättelser fortfarande ganska korniga. Om ett team behandlar en användarberättelse mer detaljerat beskrivs den mer detaljerat tillsammans med kunden. Användarberättelser uppskattas vanligtvis i berättelsespoäng , även om en uppskattning av idealdagar också är möjlig. Berättelsepoäng är relativa ansträngningar , dvs. utvecklingsinsatsen för en berättelse jämfört med andra. Det är möjligt att initiala uppskattningar ändras under projektets gång. Hela laget uppskattar ett antal poäng för användarberättelserna i flera omgångar i ett planeringsspel .

Efter att användarberättelser har utvärderats, prioriterats och tilldelats en iteration börjar teamet implementeringen. I början av iterationen delas användarberättelser in i finkorniga, tekniska arbetspaket ( uppgifter ), som vanligtvis har en längd på timmar. Teamet utför denna uppdelning och uppskattar varaktigheten för varje uppgift. Det har dock ännu inte fastställts vem som tilldelas uppgiften. I början av arbetet genomför utvecklarna ett arbetspaket, vanligtvis baserat på färdigheter. Denna process diskuteras kort i teamet. Efter den första tilldelningen av arbetspaketen startas en ytterligare uppgift om en teammedlem hittar tid för det, dvs. har slutfört sin tidigare uppgift. Implementeringen av en användarberättelse, dvs. funktionaliteten, är endast klar när alla enskilda uppgifter i denna användarberättelse har bearbetats och testerna har skrivits och alla har klarat.

En tabell med anslag för ansträngningar på ett fiktivt läkarkontor är avsett att demonstrera detta förfarande. Varje läkare har programvara som hjälper dem att hantera sina patienter och deras möten:

Uttrycket hastighet (hastighet) för lagets genomströmning, så antalet nås inom en iteration Story Points. Att bestämma hastigheten hjälper till att uppskatta hur lång tid det tar att utveckla önskad funktionalitet för en release, eller hur många iterationer som är nödvändiga. Det är normalt att lagets hastighet inte alltid är densamma.

Utveckling och examen

Tidsintervall mellan stegen.

Det finns ett kort dagligt möte (stand-up möte) där varje utvecklare rapporterar vad han har gjort dagen innan, där det fanns några problem och vad han skulle vilja göra idag. Dessutom bildas arbetspar beroende på situationen ( parprogrammering ) . Under dagen, medan utvecklarna programmerar funktionaliteten och testerna, sker ytterligare konstant utbyte (parförhandlingar) .

Om en användarberättelse inte kan slutföras i en iteration, till exempel för att testerna misslyckades eller uppskattningen visade sig vara för kort eller omfattningen för att vara för stor, delas den vanligtvis upp i flera mindre eller helt i nästa iteration uppskjuten . Även under en iteration kan något förändras i sammansättningen av iterationen på grund av förändrade prioriteringar hos kunden eller nya upptäckter. När iterationen är klar tar ledningsrepresentanter , kunden ( acceptantest ) eller andra personer som är intresserade av produkten en titt på produkten i det nuvarande expansionsfasen och ger feedback. Så det är tänkbart att kunden kan ställa in nya prioriteringar eller ta med ytterligare idéer under acceptansprovet.

Tekniskt stöd måste ses på ett differentierat sätt. Å ena sidan undviks medvetet tekniska hjälpmedel , till exempel när man skapar användarberättelser. Dessa skapas vanligtvis manuellt. Å andra sidan används tekniken också för mycket, till exempel i automatiserad integration och automatiserat utförande av tester. Dessutom finns det projektledningsverktyg som har fokuserat på de speciella ramvillkoren och kraven för XP.

Differentiering från konventionella förfaranden

Funktionaliteten som ska utvecklas beskrivs kort och informellt i användarberättelser. De flesta av kunskapen om funktionaliteten i deras utveckling ligger hos de involverade. Användarberättelser värderas vanligtvis bara i förhållande till varandra. I början av en iteration bestäms dess innehåll. Sedan delas de valda användarberättelserna in i uppgifter. Det som också är nytt med XP-metoden är att inte bara enskilda människor utan hela teamet uppskattar insatsen. Uppskattningsprocessen är också ny. Tidpunkten när och hur uppgifterna tilldelas de enskilda utvecklarna är också ett avgränsningskriterium. Endast under iterationen tar de enskilda utvecklarna på sig en uppgift, beroende på deras tillgänglighet. Det finns många tester för alla användarberättelser. En användarberättelse är bara helt klar när alla tester har slutförts. Det dagliga korta utbytet är vanligt för den smidiga metoden .

Komponenter

XP består av värderingar, principer och metoder. Även om det också finns andra auktoritativa källor (se webblänkar och litteratur ), är sammanställningen av värderingar, principer och praxis baserad på Kent Beck, vars fortfarande helt nya, evolutionära vidareutveckling XP också beaktas här. Det finns ingen tydlig definition av XP, även om de tre ursprungliga författarnas diskussioner och förklaringar formar XP mest signifikant.

värden

XP definierar fem centrala värden, abstrakta element som är av central betydelse: kommunikation , enkelhet , feedback , mod och respekt , varigenom respekten kom senare. Enligt XP är det inte möjligt att framgångsrikt utveckla programvara utan att ständigt följa dessa centrala värden.

De centrala XP-värdena

Teamet kommunicerar ständigt för att utbyta information. Själva processen kräver en hög nivå av kommunikationsvilja. Det finns ett ständigt utbyte mellan alla inblandade, även mellan utvecklingsteamet och kunden. Människor som inte är experter på en teknisk uppgift som just har diskuterats säger också. På detta sätt ingår de, det finns ytterligare feedback och alla känner sig skyldiga till laget och produkten. Konstant kommunikation med kunden, mottagande av hans feedback och uppfyllande av hans önskemål, inklusive en körbar produkt som helt uppfyller hans önskemål, är viktigare än kontraktsförhandlingar . Kommunikation kännetecknas också av respektfull interaktion, både inom teamet och med kunden. Olika åsikter accepteras.

Utvecklarna ska vara modiga och kommunicera öppet. Om ett krav inte kan genomföras i en iteration påpekas det direkt på ett öppet och ärligt sätt. En atmosfär måste skapas som minimerar konventionella störningar (som onaturlig konkurrens inom laget på produktens bekostnad). För att främja öppenhet och mod och för att möta gruppdynamiska , psykologiska svårigheter, kan en dommeslagare användas medvetet för att öppet och snabbt diskutera dåliga nyheter eller möjliga svårigheter eller en diaboli-förespråkare kan användas.

Den enklaste lösningen på ett problem bör implementeras. I varje iteration fokuserar hela teamet exakt på de krav som för närvarande ska implementeras. De tekniska lösningarna bör alltid hållas så enkla som möjligt.

Principer

Det finns 14 principer som bildar en bro mellan de abstrakta värdena och de konkreta tillämpliga metoderna. Dessa principer bör alltid beaktas. De är mänsklighet , ekonomisk effektivitet , ömsesidig nytta , självjämlikhet , förbättring , mångfald , reflektion , löpning , utnyttjande av möjligheter , undvikande av uppsägningar , acceptans av misslyckanden , kvalitet , små steg och accepterat ansvar .

Programvara är utvecklad av människor. Så människor är den faktor som XP säger förtjänar särskild uppmärksamhet. Genom att skapa en mänsklig atmosfär bör utvecklarnas grundläggande behov (säkerhet, perfektion, identifiering med gruppen, perspektiv och förståelse) tillgodoses.

Programvaran som skapats eller en enda funktion måste vara ekonomisk å ena sidan och ändå ge verkligt värde. Å andra sidan måste det vara till nytta för båda sidor och tillfredsställa alla inblandade (utvecklingsteam och kund).

Principerna för XP

Återanvändning av befintliga lösningar, inklusive till exempel de många olika tester som ständigt körs automatiskt, är viktigt. Det är uppenbart för alla att initiala lösningar vanligtvis inte är optimala. Lösningen förbättras ständigt baserat på feedback och nya insikter. Att erkänna allt bättre lösningar är endast möjligt genom ständig reflektion och kontinuerlig ifrågasättning av respektive tillvägagångssätt i laget. Produktiviteten i denna process ökar proportionellt mot inkonsekvensen hos teamet som består av personer med olika färdigheter och karaktärer . Olika åsikter tolereras inte bara utan även uppmuntras. För detta ändamål måste ett konflikthanteringssystem upprättas.

Programvarans funktionalitet måste alltid garanteras. Även om korta iterationer med ständig feedback hjälper till att hålla projektet igång, måste fel fortfarande beaktas. Det är ganska vanligt och accepterat att genomföra en implementering som kanske inte är optimal eller till och med bristfällig först. Dessa svårigheter måste ses som en möjlighet och möjlighet att ytterligare mogna produkten och teamet. Ett öppet, konstruktivt förhållningssätt till utmaningarna med mjukvaruutveckling lyckas desto bättre, desto mer är alla berörda villiga att ta sitt ansvar. Att tilldela en utvecklare en aktivitet och ett ansvar på ett disciplinärt sätt räcker inte, eftersom han måste aktivt acceptera och leva ansvaret.

En annan viktig punkt är den höga kvaliteten , som enligt XP, till skillnad från andra faktorer som resurser, funktionalitet eller deadline, inte kan diskuteras. Denna grundinställning skiljer sig från många andra metoder för mjukvaruutveckling, där programvara ska slutföras vid en viss tidpunkt och med ett definierat funktionsområde, vilket nästan alltid påverkar mjukvarukvaliteten. Kvaliteten är dock särskilt viktig för att hålla produkten i drift, felfri och expanderbar. På medellång sikt är programvara med bra design och hög kvalitet billigare, mer utbyggbart och mindre benäget för fel än snabbt skapad, så kallad quick-and-dirty-programvara .

God kvalitet inkluderar också att undvika uppsägningar (onödigt upprepade eller upprepade steg eller steg som kan automatiseras manuellt).

Genom att ta snabba, små steg förblir teamet flexibelt och kan snabbt anpassa sig till nya ramvillkor och svara på feedback. De negativa konsekvenserna av ett enda litet, misslyckat steg kan kompenseras med ett nytt steg mycket snabbare än vad som skulle vara fallet med ett enda större steg.

Övningar

Man kan skilja mellan traditionella och evolutionära metoder. De traditionella är utbredda och används i XP-världen. De evolutionära tar på sig olika nya resultat från åren av XP-användning. De förfina eller modifiera de ursprungliga metoderna något, vilket gör användningen tydligare och mer förståelig.

XP förknippas ofta med eller reduceras till traditionella metoder.

Traditionella metoder

Koppla ihop programmering

Vid parprogrammering delar två programmerare en dator - en kodad ( drivrutinen ) och den andra tänker och har den stora bilden i åtanke ( partnerna ). Rollerna byts ut regelbundet. Detta tillvägagångssätt ökar kunskapsöverföringen. Nybörjare bör lära sig snabbare av en specialist. Kunskapen distribueras. Projektet är inte längre så sårbart för en individs misslyckande. Konstant kodgranskning av utveckling och kommunikation förbättrar designen och hittar fel snabbare (se även principen om fyra ögon ).

Kollektivt ägande

Aktiviteter distribueras initialt inte till individer utan till hela teamet. Enligt metoden finns en medvetenhet och skyldighet att bara kunna lyckas som ett team. Enskilda medarbetare inte har en monopol på kunskap . Parprogrammering och ändrade applikationsområden är avsedda att motverka tendensen för enskilda människor att se delar som deras egendom.

Permanent integration

Kontinuerlig integration av de enskilda komponenterna i ett operativt övergripande system med korta tidsintervall. Enligt XP, ju oftare den integreras, desto högre rutin uppstår. Fel upptäcks tidigt. Kostnaderna i samband med integrationen bör minimeras till nästan noll, eftersom integrationen är en del av ett dagligt steg som till stor del måste vara helt automatiserat och stabilt och testat.

Testdriven utveckling eller permanent testning

Med testdriven utveckling , de delprov är (enhet test) första skriftliga innan själva funktionaliteten är programmerad. Som ett resultat hanterar utvecklaren tidigt designen av koden och funderar noga på sitt programmeringsarbete. Testerna utförs efter varje programmeringssteg och ger feedback om utvecklingsläget. Testerna är automatiserade. Integrationstester utförs under en integration. Man gör en åtskillnad mellan ett regressionstest och ett modultest. Medan enhetstester testar enskilda moduler är ett regressionstest det kollektiva utförandet av alla tester för att kontrollera den oförändrade funktionaliteten hos den gamla funktionaliteten som redan fanns före iterationen. Även prestandatester , där effekt- och hastighetsegenskaperna mäts med avseende på de erforderliga värdena, är vanliga. Utvecklaren får feedback om hur många och vilka tester som misslyckades. Ett acceptantest är presentation av produktens status för att bekräfta kundens tillfredsställelse och användbarheten.

XP bästa metoder

Kundengagemang

Kundens nära engagemang, det vill säga kunden specificerar iterationsmålet med ett urval av de användarberättelser som ska implementeras och har kort därefter möjlighet att genomföra acceptattester . Berättelsekort fungerar som ett medium för att spela in korta användningsfall i form av användarberättelser . Kunden måste alltid vara närvarande eller åtminstone tillgänglig. Förutom användarberättelser på berättelsekort finns det också sättet att skriva CRC-modeller på CRC-kort .

Refactoring

Pågående refactoring , konstant arkitektur , design och kod förbättringar även för att kunna identifiera och eliminera anti-mönster omedelbart. XP bekräftar förekomsten av kod som är ofullkomlig i början. Istället granskas alla delar kontinuerligt. Platser som kan optimeras förbättras vanligtvis omedelbart eller definieras som fel ( buggar ) som kommer att fixas i en senare iteration.

Ingen övertid

40-timmarsvecka , dvs. H. Övertid bör undvikas eftersom det påverkar arbetets glädje och på medellång sikt programmerarnas koncentrationsförmåga och därmed produktens kvalitet. Det har bevisats att utvecklarens produktivitet minskar genom övertid. Arbete utanför ordinarie arbetstid tolereras i enskilda fall men belönas inte på något sätt eller förväntas. Övertid är vanligtvis bara ett tecken på dålig planering .

Iterationer

Korta iterationer för att ge kunden en körbar mellanstatus för produkten med jämna mellanrum. En iteration är en kronologiskt och tekniskt fristående enhet. Korta iterationer och tillhörande acceptansprov möjliggör snabba återkopplingsslingor mellan utveckling och kund.

liknelse

Eftersom ett latent missförstånd mellan kunden och utvecklingsteamet är ett vanligt problem vid traditionellt inrättade mjukvaruprojekt - utvecklaren har svårt med kundens tekniska språk och vice versa - kraven i kundens tekniska ordförråd , helst också själv, i form av användar berättelser beskrivits. Alla talar ett språk, vilket kan förstärkas med en ordlista . En metafor väljs, en vardagsberättelse som liknar innehållet och är förståelig för båda sidor.

Kodningsstandarder

Vid programmering följer teamet standarder som gör det möjligt för teamet att ta ansvar för denna uppgift. Enligt XP är det bara möjligt att ändra utvecklaranvändningen inom alla delar av programvaran om det finns gemensamma standarder.

Enkel design

Den enklaste lösningen bör sökas, dvs. den som uppnår exakt vad som önskas (och inte mer). Medvetet allmänna ( generiska ) lösningar eller förberedande åtgärder för potentiella framtida krav undviks. När det gäller enkelhet, den slang förkortningar KISS ( ”Keep it simple, dum”) och YAGNI ( ”Du kommer inte att behöva det”) är vanliga.

Planerar spel

Nya versioner av programvaran specificeras i ett planeringsspel , även känt som planeringspoker , och den insats som krävs för att implementera dem uppskattas. Både utvecklingsteamet och kunden är inblandade i denna iterativa process.

Evolutionära metoder

De evolutionära metoderna publicerades fem år efter originalet och ersatte dem. De kan delas in i huvudmetoder och kompletterande tillhörande metoder . När det gäller innehåll är de nya metoderna jämförbara med de gamla, traditionella metoderna. Namnen på de gamla metoderna har delvis modifierats eller delats upp i enskilda delmetoder. Två metoder har tagits bort: metaforen var för svår att förmedla och enligt litteraturen har den inte tagit fast. Kodningsstandarder tas för givet och nämns inte längre uttryckligen.

Huvudpraxis

De viktigaste metoderna är: Sammanträde , informativ arbetsplats , team , parprogrammering , energiskt arbete , avslappnat arbete , berättelser , veckovis cykel , kvartalscykel , 10-minutersbyggnad , kontinuerlig integration , test-första programmering och inkrementell design .

Kommunikationen ska optimeras genom ett öppet, delat arrangemang av arbetsstationerna. Denna form är att föredra framför en rumsskillnad mellan de inblandade på grund av bättre kommunikationsalternativ. Arbetsplatsen måste också vara "informativ" genom att till exempel aktuella uppgifter, projektets status och annan viktig information alltid syns tydligt från arbetsplatsen. Det rekommenderas till exempel att fästa användarberättelserna centralt på en vägg.

De viktigaste metoderna för evolutionär XP

Enligt XP är laget viktigare än individerna . Gemensamma beslut tas i medvetenheten om att vi bara kan lyckas som en gemenskap. Detta främjas av det faktum att de enskilda tekniska aktiviteterna i planeringen inte tilldelas enskilda personer utan teamet. Teamet löser problem utan en extern chefs ingripande. Uppsatsen Domkyrkan och basaren behandlar också ämnet för det självreglerande teamet . Parprogrammering med alternerande partner bör ytterligare främja denna grundläggande attityd.

Arbetet ska köras med full motivation och samtidigt i en avslappnad, kollegial atmosfär, eftersom utvecklarna arbetar utan övertid och därmed uppnås maximal produktivitet. Säkerhetsbuffertar beaktas. Löften som inte kan hållas undviks.

Funktionaliteten som ska utvecklas beskrivs i form av berättelser, till exempel användarberättelser. I en veckocykel bestäms vilka kundförfrågningar som ska hanteras nästa. Själva projektet planeras i en kvartalscykel. De angivna cyklerna är riktvärden, vars storlekar kan variera i daglig användning.

Programvaran för att skapa och utföra alla tester som krävs för att slutföra på högst tio minuter. Denna 10-minutersbyggnad minimerar kostnaden för att bygga och testa programvaran. Alla ändringar som görs av en utvecklare bör publiceras ungefär varannan timme. Denna kontinuerliga integration är avsedd att förhindra ett potentiellt kaos som kan uppstå om utvecklarna sällan införde sina ändringar och förbättringar av produkten i det centrala datalagringssystemet ( repository ). Alla anställda har ändringarna snabbt tillgängliga. Både de tio minuterna för byggnaden och de två timmarna för integrationen är mål som kan variera i specifika projekt. Speciellt för stora projekt med en stor mängd källkod och utvecklare tar en byggnad betydligt längre tid och integrationsintervallen blir ofta längre. Övningarna betonar bara riktning och ger ett idealiskt värde att sträva efter. Automation kan minimera byggtiden så mycket som möjligt.

Utvecklingen kännetecknas av test-första programmeringsmetoden: testet måste skrivas innan funktionaliteten kan implementeras. En inkrementell design som absorberar ny kunskap och feedback förbättrar kontinuerligt programvarans design.

Tillhörande praxis

Följande metoder är:

• korrekt kundengagemang
• inkrementell distribution
• Lagkonstans
• krympande lag
• kausala analyser
• delad kod
• Kodning och testning
• en central kodbas
• daglig distribution
• förhandlingsbara, avtalsenliga funktioner
• Betala per användning.

Kunden deltar aktivt i utvecklingen. Han deltar i de vanliga mötena och deltar aktivt. Inkluderingen är också tydlig i omfattningen av funktioner som ska utvecklas, som måste förbli förhandlingsbara. Flera mindre kontrakt istället för ett stort kontrakt kan minimera risker och öka flexibiliteten i projekt som drivs på detta sätt. Eftersom nya versioner ständigt görs tillgängliga iterativt måste kundens betalningar vara oberoende av antalet tillgängliga versioner. Kunden betalar inte för varje version av programvaran utan per användning.

De sekundära metoderna för evolutionär XP

Å ena sidan bör laget leva från sin beständighet, men det kan också minskas med avseende på personal. Utvecklingsteamet måste vara detsamma i flera projekt. Som en del av produktutvecklingen förvärvar den kompetensen att arbeta tillsammans som ett team som kan användas för ytterligare projekt. När teamet blir mer produktivt och produktivt bör dess arbetsbelastning förbli konstant trots att resurserna flyttas till andra team.

Koden som det centrala mediet spelar en central roll. Den förvaras i en central, databasliknande struktur ( förvar ). Det finns bara en officiell version (kodbas) av systemet. Denna kod delas bildligt sett mellan utvecklarna. Varje utvecklare i teamet måste kunna ändra "utländsk" kod när som helst (kollektiv kodägande). Förutom koden finns det alltid test som tillsammans med koden är det enda mediet som skapas och görs tillgängligt av utvecklingsarbetet (”artefakter”). Alla andra medier, till exempel dokumentation, genereras enbart från kod och tester.

Inkrementell distribution (överföring av applikationen till målsystemet) utförs för att identifiera svårigheter tidigt. Om gamla system ska ersättas med ny programvara måste en del i taget bytas ut. Denna procedur är avsedd att göra omvandlingen enklare att planera. Driftsättningen måste ske stegvis dagligen. En ny version av programvaran ska tas i produktion varje dag. Detta gör distributionsrutinen, minimerar kostnader och fel och möjliggör kontinuerliga integrations- och godkännandestester. Om ett tekniskt fel uppstår måste en kausal analys utföras.

Grad av flexibilitet kontra styvhet

En av de teoretiska grunderna för Extreme Programming är graden av flexibilitet hos mjukvarusystemet som ska utvecklas. XP antar ett åtminstone proportionellt förhållande mellan motsatsen till flexibilitet, så kallad styvhet , och underhållskostnaderna för felsökning eller utvidgning av systemet. Ju mer flexibelt ett mjukvarusystem är, desto lägre underhållskostnader, desto styvare, desto högre.

Några styvhetskriterier:

• Antalet överflödiga eller oanvända funktioner
• Dålig, saknad, svår att förstå eller för omfattande dokumentation
• En svårförståelig eller oflexibel design
• Saknade regressionstest
• Ett besvärligt övergripande system

Flexibilitetskriterierna är motsatta av styvhetskriterierna, till exempel en lättförståelig och flexibel design.

Enligt XP tjänar några av de mekanismer som definieras som en del av Extreme Programming för att öka flexibiliteten:

• Den testdrivna utvecklingen säkerställer tillräcklig tillgänglighet av regressionstest och förbättrad testbarhet för programvaran
• Den ständiga refactoring leder till eliminering av fel, en lättförståelig och flexibel design samt god dokumentation
• Kontinuerlig integration kräver oundvikligen ett lätt övergripande system
• Användarberättelser används för att avgöra vilken funktionalitet som ska utvecklas och för att utarbeta den mellan kunden och utvecklingsteamet

Ursprung och avgränsning

XP är en representant för agil mjukvaruutveckling. Jämfört med traditionella processmodeller väljer den alternativa metoder för att hantera utmaningar under mjukvaruutveckling.

Traditionella procedurmodeller

I processmodeller som är traditionella ur dagens perspektiv är programvaruutvecklingsprocessen organiserad i på varandra följande faser . Efter flera års användning av traditionella procedurmodeller, som vattenfallsmodellen som användes från 1970, har de ansvariga för projektet , ur XP-representantens synvinkel, inte tillräckligt förstått hur man kan få kontroll över problemen och riskerna med mjukvaruutveckling. Många projekt har aldrig avslutats eller överträffat planeringen när det gäller tid och / eller kostnader. Många projekt som kördes under långa tidsperioder täckte de krav som specificerades i början men tog inte tillräckligt hänsyn till det faktum att kraven kan förändras eller att det bara är under projektets gång som kunden verkligen vet vad slutet är resultatet ska se ut. Framgång och svårigheter med programvaruprojekt som levererar Chaos Report från The Standish Group regelbundet djupforskning, till exempel 1994

Till skillnad från traditionella processmodeller, går utvecklingsprocessen i XP igenom alla discipliner för klassisk mjukvaruutveckling (till exempel kravanalys, design , implementering , test ) iterat i korta cykler . Med detta inkrementella förfarande realiseras (implementeras) bara de funktioner som krävs i det aktuella iterationssteget . Detta gör XP lättare : ingen fullständig teknisk specifikation av lösningen som ska utvecklas krävs (det finns till exempel ingen kravspecifikation ).

XP: s historia

Extrem programmering , och därmed standarder som JUnit, utvecklades av Kent Beck , Ward Cunningham och Ron Jeffries (alla de första undertecknarna av Agile Manifesto ) när de arbetade med Chrysler Comprehensive Compensation System- projektet för att skapa programvara. Arbetet med det så kallade C3-projektet började 1995 och avbröts 2000 efter Daimlers övertagande. Mjukvaran som utvecklades i processen användes inom löneutredningen och baserades huvudsakligen på småprat . C3-projektet implementerades ursprungligen enligt vattenfallsmodellen. Efter nästan ett år gjordes inga betydande framsteg, utvecklingsstrategin ändrades. Projektet karaktäriserades av ofta förändrade krav och hög personalomsättning.

XP är en smidig processmodell. I följande tabell jämförs de centrala discipliner som identifierats av XP med den historiska, utbredda metoden och dess risker för programvaruutveckling. Företag som inte använder XP kan använda procedurmodeller som - medvetet eller omedvetet - hanterar dessa discipliner positivt.

På grund av den växande användningen optimeras XP ytterligare: ju fler projekt som utvecklas enligt XP, desto mer erfarenhet strömmar in i den vidare utvecklingen av XP. Eftersom det också är en summa av bästa praxis kan man alltså säga: "I praktiken är det anpassat för övning".

Andra smidiga processmodeller

Den lägsta gemensamma nämnaren för alla agila processmodeller är "Agile Manifesto":

• Individer och interaktioner har företräde framför processer och verktyg
• Körbar programvara har prioritet framför omfattande dokumentation
• Samarbete med kunden har prioritet framför kontraktsförhandlingar
• Att svara på förändringar har prioritet framför strikt spårning av planer

Förutom XP har Scrum också uppnått en viss nivå av medvetenhet. Förutom många likheter med XP tillhandahåller Scrum specifikationer angående iterationslängd, loggning och procedurer inom vissa områden. Scrum använder sin egen vokabulär.

En annan disciplin som ofta citeras i detta sammanhang är funktionsdriven utveckling , en metod som också fokuserar på den funktionalitet som ska tillhandahållas.

Likheter mellan XP och Kaizen , ett koncept som utvecklats i Japan främst inom bilindustrin ( kontinuerlig förbättringsprocess ) för att säkerställa kvalitet i tillverkningsprocessen och optimera tillverknings- och hanteringskostnader med hjälp av "smalare" metoder ( lean produktion ), kan inte förbises.

En annan smidig processmodell är Crystal , en familj av metoder vars medlemmar vanligtvis är markerade med färger.

Traditionella processmodeller, såsom V-modellen , har också berikats med ny kunskap inom mjukvaruutveckling. Som ett resultat använder efterträdaren, V-Modell XT , smidiga metoder. V-Modell XT anger inte längre en strikt sekvens av faser som ska köras igenom.

XP i projekt

Idag, över tio år efter de första XP-stegen, åtnjuter XP och andra smidiga metoder växande popularitet. Forskning från Forrester Research visade att i Nordamerika och Europa 2005 genomfördes cirka 14% av alla projekt med agila metoder (varav XP är det vanligaste) och många andra överväger en utplacering.

Användare av XP inkluderar både företag som producerar och säljer programvara kommersiellt såväl som företag vars faktiska verksamhet inte är skapande av programvara: Dresdner Kleinwort Wasserstein , Encyclopaedia Britannica , Fidelity , Progressive , Capital One , Royal & Sunalliance , Channel One , Daedalos International , Gemplus , it-agile , Qwest och O&O Services .

Många företag rapporterar offentligt sina erfarenheter med XP. De beskriver hur de använde XP i detalj, vilka svårigheter som uppstod och hur framgången skulle bedömas. Symantec har publicerat sin förändring i processmodellen mot XP. Med XP har Saber Airline Solutions minskat både fel i deras programvara och utvecklingstid:

kritik

Allt-eller-ingenting-principen

Enligt vissa huvudpersoner i XP-metoden arbetar de enskilda metoderna så nära varandra att de bör användas utan undantag. Till och med att inte använda enskilda metoder bör begränsa effektiviteten i den övergripande metoden massivt. Eftersom användningen av metoderna ofta baseras på många krav (se t.ex. avsnitten The Ideal Client och The Ideal Programmer ) är det troligt att enskilda metoder inte kan användas i specifika projekt. Detta ger sedan en enkel förklaring till misslyckandet med XP-projekt: Vanligtvis kan en försummad metod hittas, så att misslyckandet inte kan tillskrivas XP som ett övergripande tillvägagångssätt, utan till försummelsen av denna metod. Under tiden är det kontroversiellt om alla metoder verkligen måste användas för att öka sannolikheten för ett framgångsrikt projekt genom XP.

Rörliga krav

En av de främsta anledningarna till att specificera krav i klassiska processmodeller är att skapa en pålitlig grund för utvecklingsarbete så att ändringar av implementeringen som är nödvändiga senare förblir så små som möjligt. Det implicita antagandet av denna inställning är att ju senare ändringar måste göras, desto dyrare blir det. Även om detta antagande har bekräftats i många projekt, antar XP till viss del att förändringar i allmänhet är "billiga" om de genomförs kontinuerligt. XP förnekar också implicit antagandet att senare ändringar blir dyrare och motiverar detta med att ändringarna inte behöver implementeras i flera artefakter samtidigt (specifikation, dokumentation, källkod) - som i andra tillvägagångssätt.

Antagandena om XP i detta avseende gäller verkligen när kraven oundvikligen kan ändras. I det här fallet kan specificering av kraven ibland innebära mer ansträngningar än att utelämna specifikationen - om bara för att specifikationen alltid måste ändras. Det är dock oklart varför det borde vara skadligt att specificera kraven åtminstone om de är säkra på att hålla till projektets slut. Genom att inte använda en specifikation riskerar du att förbise kraven eller missbedöma deras innebörd. Det kan också tänkas att kunden medvetet kommer att ändra sina krav under projektets gång, men berätta för utvecklingsteamet att hans syn hittills bara har missförstått. När det gäller bedömningen att senare ändringar inte är dyrare än tidiga, är invändningen att sena ändringar kan vara mycket dyra om de påverkar applikationens utformning på ett grundläggande sätt. Att ändra arkitekturen i en applikation kan inte genomföras utan betydande ansträngning, det kan faktiskt vara dyrare än en ny implementering. Det är inte uppenbart och verkar därför vara en trosfråga om XP kan förhindra sådana situationer genom användning av dess metoder.

Den perfekta kunden

Användningen av XP kräver en kund som vill experimentera, som inte bara måste avstå från ett antal vanliga tillvägagångssätt utan också måste spendera betydande resurser själv. Några av de saker som en kund inte vill göra utan inkluderar:

dokumentation

Programvara kan introduceras i komplexa systemlandskap så att ett stort antal berörda parter (t.ex. de som ansvarar för gränssnitt, anställda från externa leverantörer etc.) måste få kunskap om tekniska detaljer. I sådana miljöer förbjuder företagets riktlinjer vanligtvis att avstå från detaljerad dokumentation. Men även om detta inte är fallet återstår att klargöra hur kunskap om tekniska detaljer ska förmedlas till de berörda om det inte finns någon dokumentation, och ännu mer om det måste antas att framtida förändringar kommer att påverka relevanta tekniska detaljer.

Specifikation

Särskilt vid ingående av arbetskontrakt uppstår frågan för kunden om exakt vad handeln egentligen består av som förvärvas till det avtalade priset. Dessutom kan riktlinjer för hela företaget kräva att en specifikation skapas.

evenemang

Eftersom projektledarens representant för kunden ofta måste rapportera projektförloppet själv, är slutförandet av vissa funktioner på fasta datum, dvs. utarbetandet av en projektplan, ofta en oumbärlig del av det gemensamma tillvägagångssättet.

Utöver dessa punkter representerar principen "kund på plats" ett krav som bara sällan kan implementeras i verkligheten. För att kunna utföra sin uppgift måste medarbetaren uppenbarligen ha en betydande mängd kunskap. Om så är fallet kommer dock medarbetaren sannolikt inte att kunna dispenseras på flera månader i sitt eget företag heller. Det är inte ovanligt att IT-projekt läggs ut på externa tjänsteleverantörer för att begränsa sina egna resurser. Principen kund på plats representerar således ett av de svåraste kraven för extrem programmering att uppfylla.

Den perfekta programmeraren

XP ställer många krav på inblandade programmerare.

• Programmerarna måste ha mycket goda färdigheter, eftersom det frekventa förändringsbaserade tillvägagångssättet med refaktorer inte kan genomföras utan omfattande programmeringserfarenhet och utan användning av lämpliga verktyg.
• Programmerare har ofta ett mycket utvecklat ego, som manifesterar sig i en stor övertygelse om "rätta lösningar" och en viss känsla av ägande med avseende på den skrivna koden. Inte alla programmerare klarar det faktum att - enligt XP - har alla rätt att ändra alla andras kod.
• XP har ett antal funktioner som kräver en hög nivå av disciplin (som test-first-tillvägagångssättet, ständigt refactoring, programmering i par osv.) Och några andra som uppmuntrar en viss disciplin (t.ex. B. utelämnar specifikation och dokumentation) . Det finns en risk att de senare metoderna kommer att betonas framför de tidigare. Att följa tillvägagångssätten med hög grad av disciplin kräver skickliga deltagare och en fungerande självreglering av teamet. Eftersom en person som är ansvarig för projektet kanske inte har utsetts är frågan vem som i slutändan kommer att se till att alla aspekter följs konsekvent.

Kraven visar att XP inte kan tillämpas på något team.

Begränsat team och därför projektstorlek

Flera XP-metoder kräver en hög grad av ömsesidig information och därmed en hög grad av kommunikation mellan de inblandade. Kontinuerlig refactoring kan till exempel kräva ändringar av delade komponenter som hela teamet måste informeras om. Bristen på en projektledare kräver ömsesidiga avtal om arbetsfördelning. Eftersom det också saknas exakt specifikation och dokumentation måste all information för implementering vara tillgänglig hos de involverade. Men med teamets storlek ökar kommunikationsinsatsen kvadratiskt, så att XP-projekt har en naturlig gräns vad gäller teamstorlek. Den maximala storleken ställs vanligtvis in på tio lagmedlemmar.

Inte lämpligt för fastprisprojekt

En annan vanlig kritikpunkt är att XP inte är lämpligt för fastprisprojekt . Eftersom kunden betalar ett fast pris måste entreprenören på något sätt se till att han bara behöver tillhandahålla en fast tjänst för detta pris. Tillhandahållandet av tjänster tills kunden är nöjd kan resultera i ständigt nya kundkrav, så att ansträngningarna i implementeringen inte kan förutses. Att definiera den fasta tjänsten som innehållet i kontraktet för arbete skulle motsvara en specifikation och är därför missnöjd i XP. Det finns några sätt att göra XP-kompatibelt med fastprisprojekt:

• Försäkringspremier på uppskattningen
• Användarberättelser (eller berättelsekort) blir föremål för kontraktet
• Särskilda värderingsmodeller självkostnadspris limit , fas fast pris eller begäran enhetspris .

Effektiviteten av dessa tillvägagångssätt är dock oklar. Användarberättelser kan vara för exakta för att skydda affären mot oväntade tekniska krav. De nämnda prismodellerna motsvarar endast delvis ett fast pris och därmed ett kontrakt för arbete, så det är tveksamt om en kund skulle acceptera detta genom att ange ett fast pris. Detsamma gäller försäkringspremier.

Fasta slutföringsdatum

XP: s iterativa tillvägagångssätt och avsaknaden av en projektplan föreslår redan att slutförandet av ett tekniskt önskat funktionsområde inom ett visst datum inte kan garanteras utan vidare. Även om något kommer att vara klart före det inställda datumet (eftersom fokus för varje iteration är på körbar, eventuellt till och med produktionsfärdig programvara), kan man inte förutsäga vilka tekniska aspekter de faktiskt är - desto mindre övertid undviks och i större utsträckning mer nödvändiga refaktorer är svåra att uppskatta på grund av flexibla krav.

Använd i distribuerade miljöer

XP anses vara svårare att använda än konventionella modeller i distribuerade miljöer. Den direkta kontakten mellan utvecklaren och varandra och med kunderna är problematisk om det finns olika kunder eller de parter som arbetar på avlägsna platser, t.ex. vid delvis outsourcad utveckling ( outsourcing ).

Kritik mot individuella metoder

Det upprepade skapandet av testfall och automatiserat, permanent genomförande av testerna kan vara tidskrävande i komplexa eller samtidiga applikationer och distribuerade system . Om roller inte utvecklas måste alla veta allt istället för att ställa in individuella prioriteringar i teamet (klassiskt exempel: GUI-utveckling och databasutveckling), vilket kan minska teamets övergripande prestanda.

Personalpolitik

Eftersom teamet är i förgrunden kanske enskilda utvecklare inte belönas enligt omfattningen av deras utvecklade funktionalitet. I synnerhet är avgiftsavtalet inte en lämplig ersättningsmodell när XP-processmodellen används.

Se även

• Kristall , smidig processmodell
• Scrum , smidig processmodell som harmoniserar väl med XP

litteratur

• Kent Beck : Extrem programmering förklarad, omfamna förändring. Addison-Wesley, 1999, ISBN 0-201-61641-6 (2: a upplagan, 2004, ISBN 0-321-27865-8 ).
• Kent Beck: Extrem programmering, manifestet. Addison-Wesley, 2000, ISBN 3-8273-1709-6 . (Översättning på tyska)
• XP-serien:
  • Kent Beck, Martin Fowler : Planering av extrem programmering. Addison-Wesley, 2000, ISBN 0-201-71091-9 .
  • Ron Jeffries et al.: Extrem programmering installerad. Addison-Wesley, 2000, ISBN 0-201-70842-6 .
  • Giancarlo Succi, Michele Marchesi: Extrem programmering granskad. Addison-Wesley, 2001, ISBN 0-201-71040-4 .
  • James Newkirk, Robert C. Martin : Extrem programmering i praktiken. Addison-Wesley, 2001, ISBN 0-201-70937-6 .
  • William C. Wake: Extrem programmering utforskad. Addison-Wesley, 2001, ISBN 0-201-73397-8 .
  • Ken Auer, Roy Miller: Extreme Programming Applied. Addison-Wesley, 2001, ISBN 0-201-61640-8 .
  • Pete McBreen: Questioning Extreme Programming. Addison-Wesley, 2002, ISBN 0-201-61640-8 .
  • Giancarlo Succi et al.: Extreme Programming Perspectives. Addison-Wesley, 2002, ISBN 0-201-77005-9 .
  • Doug Wallace et al.: Extrem programmering för webbprojekt. Addison-Wesley, 2002, ISBN 0-201-79427-6 .
  • Lisa Crispin, Tip House: Testing Extreme Programming. Addison-Wesley, 2002, ISBN 0-321-11355-1 .
• Scott W. Ambler: Agile Modelling: Effective Practices for eXtreme Programming and the Unified Process. Wiley, John & Sons, 2002, ISBN 0-471-20282-7 .
• Ron Jeffries: Extreme Programming Adventures in C #. Microsoft Press, 2004, ISBN 0-7356-1949-2 .
• Henning Wolf et al.: EXtreme Programming, En introduktion med rekommendationer och praktisk erfarenhet. dpunkt, 2: a upplagan, 2005, ISBN 3-89864-339-5 .

webb-länkar

tysk

• Podcast om extrem programmering från Chaosradio Express
• Artikel från Die Zeit
• Extrem programmering - Tillbaka till grunderna? ( Memento från 8 augusti 2017 i internetarkivet ) (PDF, 110 KiB)
• Vad är extrem programmering? - av Frank Westphal
• OpenSource-utveckling och dess dynamik ( Memento från 18 mars 2013 i Internetarkivet ) (med kapitel om smidiga metoder och XP)

engelsk

• Agile Alliance
• Extrem programmering: En mild introduktion.
• XP (Ron Jeffries)
• XP (Ward Cunningham)
• XP-The New Methodology (Martin Fowler)

Specialkonferenser om ämnet

• XP Days Germany , den årliga XP-konferensen i Tyskland

Individuella bevis

1. ↑ Tom DeMarco, Timothy Lister: Bärentango , Hanser Fachbuch, mars 2003, ISBN 3-446-22333-9 .
2. ↑ Kent Beck: Extreme Programming Explained. Omfamla förändring . 1: a upplagan, Addison-Wesley, 2000, ISBN 0-201-61641-6 .
3. ↑ Kent Beck, Cynthia Andres: Extrem programmering förklaras. Omfamna förändring . 2: a upplagan, Addison-Wesley, december 2004, ISBN 0-321-27865-8 .
4. ^ The Standish Group: CHAOS-rapporten (1994). Åtkomst 12 januari 2020 .  (Engelska), 12 juni 2006.
5. ↑ Chrysler Comprehensive Compensation System: Chrysler Goes To Extremes ( Memento från 13 januari 2015 i Internetarkivet ) (PDF, engelska; 188 kB), 9 juni 2006.
6. ↑ Chrysler Comprehensive Compensation System: Extrem programmering anses vara skadligt för pålitlig programutveckling (PDF), 6 februari 2002.
7. ^ Chrysler Comprehensive Compensation: Projekt för att ersätta befintliga löneapplikationer med en enda applikation. (Engelska), 16 oktober 2013.
8. ^ Ward Cunningham, Kent Beck et al.: Manifest for Agile Software Development (engelska), 2001.
9. ^ Forrester Research: Företags-IT leder den andra vågen av smidig adoption ( Memento av den 16 oktober 2007 i internetarkivet ) (engelska), 30 november 2005.
10. ↑ C2: Företag som gör Xp , 23 juli 2006.
11. ^ Object Mentor, Inc.: Företag som använder XP, kunder ( Memento den 23 april 2006 i Internetarkivet ) (engelska), 23 juli 2006.
12. ↑ Dr. Dobb's: Going to Extremes , 2 januari 2002.
13. ↑ ^{a b} Computerworld: Saber vidtar extrema åtgärder ( Memento av 13 mars 2009 i Internet Archive ) (engelska), 29 mars 2004.
14. ↑ Henrik Kniberg: Scrum och XP från diken (PDF, engelska), 27 juni 2007.

Denna version lades till i listan över artiklar som är värda att läsa den 17 juli 2006 .