mirror of
https://gitlab.com/harald.mueller/aktuelle.kurse.git
synced 2024-10-19 09:55:03 +02:00
954 lines
171 KiB
Plaintext
954 lines
171 KiB
Plaintext
<!DOCTYPE html>
|
||
<html class="client-nojs" lang="de" dir="ltr">
|
||
<head>
|
||
<meta charset="UTF-8"/>
|
||
<title>Extreme Programming – Wikipedia</title>
|
||
<script>document.documentElement.className="client-js";RLCONF={"wgBreakFrames":!1,"wgSeparatorTransformTable":[",\t.",".\t,"],"wgDigitTransformTable":["",""],"wgDefaultDateFormat":"dmy","wgMonthNames":["","Januar","Februar","März","April","Mai","Juni","Juli","August","September","Oktober","November","Dezember"],"wgRequestId":"189edab9-212b-4b99-baf9-bea518b4ee00","wgCSPNonce":!1,"wgCanonicalNamespace":"","wgCanonicalSpecialPageName":!1,"wgNamespaceNumber":0,"wgPageName":"Extreme_Programming","wgTitle":"Extreme Programming","wgCurRevisionId":207672512,"wgRevisionId":207672512,"wgArticleId":52075,"wgIsArticle":!0,"wgIsRedirect":!1,"wgAction":"view","wgUserName":null,"wgUserGroups":["*"],"wgCategories":["Wikipedia:Vorlagenfehler/Vorlage:Zitat/Übersetzung gewünscht","Wikipedia:Belege fehlen","Wikipedia:Lesenswert","Vorgehensmodell (Software)","Agile Softwareentwicklung","Englische Phrase"],"wgPageContentLanguage":"de","wgPageContentModel":"wikitext","wgRelevantPageName":
|
||
"Extreme_Programming","wgRelevantArticleId":52075,"wgIsProbablyEditable":!0,"wgRelevantPageIsProbablyEditable":!0,"wgRestrictionEdit":[],"wgRestrictionMove":[],"wgFlaggedRevsParams":{"tags":{"accuracy":{"levels":1}}},"wgStableRevisionId":207672512,"wgMediaViewerOnClick":!0,"wgMediaViewerEnabledByDefault":!0,"wgPopupsFlags":4,"wgVisualEditor":{"pageLanguageCode":"de","pageLanguageDir":"ltr","pageVariantFallbacks":"de"},"wgMFDisplayWikibaseDescriptions":{"search":!0,"nearby":!0,"watchlist":!0,"tagline":!0},"wgWMESchemaEditAttemptStepOversample":!1,"wgULSCurrentAutonym":"Deutsch","wgNoticeProject":"wikipedia","wgEditSubmitButtonLabelPublish":!0,"wgULSPosition":"interlanguage","wgULSisCompactLinksEnabled":!0,"wgGENewcomerTasksGuidanceEnabled":!0,"wgGEAskQuestionEnabled":!0,"wgGELinkRecommendationsFrontendEnabled":!0,"wgCentralAuthMobileDomain":!1,"wgWikibaseItemId":"Q209711"};RLSTATE={"ext.globalCssJs.user.styles":"ready","site.styles":"ready","user.styles":
|
||
"ready","ext.globalCssJs.user":"ready","user":"ready","user.options":"loading","ext.flaggedRevs.icons":"ready","oojs-ui-core.styles":"ready","oojs-ui.styles.indicators":"ready","mediawiki.widgets.styles":"ready","oojs-ui-core.icons":"ready","ext.cite.styles":"ready","skins.vector.styles.legacy":"ready","ext.flaggedRevs.basic":"ready","ext.visualEditor.desktopArticleTarget.noscript":"ready","ext.uls.interlanguage":"ready","ext.wikimediaBadges":"ready","wikibase.client.init":"ready"};RLPAGEMODULES=["ext.cite.ux-enhancements","site","mediawiki.page.ready","mediawiki.toc","skins.vector.legacy.js","ext.flaggedRevs.advanced","ext.gadget.editMenus","ext.gadget.WikiMiniAtlas","ext.gadget.OpenStreetMap","ext.gadget.CommonsDirekt","mmv.head","mmv.bootstrap.autostart","ext.popups","ext.visualEditor.desktopArticleTarget.init","ext.visualEditor.targetLoader","ext.eventLogging","ext.wikimediaEvents","ext.navigationTiming","ext.uls.compactlinks","ext.uls.interface","ext.cx.eventlogging.campaigns",
|
||
"ext.centralNotice.geoIP","ext.centralNotice.startUp","ext.centralauth.centralautologin","ext.growthExperiments.SuggestedEditSession"];</script>
|
||
<script>(RLQ=window.RLQ||[]).push(function(){mw.loader.implement("user.options@1hzgi",function($,jQuery,require,module){/*@nomin*/mw.user.tokens.set({"patrolToken":"+\\","watchToken":"+\\","csrfToken":"+\\"});mw.user.options.set({"variant":"de"});
|
||
});});</script>
|
||
<link rel="stylesheet" href="/w/load.php?lang=de&modules=ext.cite.styles%7Cext.flaggedRevs.basic%2Cicons%7Cext.uls.interlanguage%7Cext.visualEditor.desktopArticleTarget.noscript%7Cext.wikimediaBadges%7Cmediawiki.widgets.styles%7Coojs-ui-core.icons%2Cstyles%7Coojs-ui.styles.indicators%7Cskins.vector.styles.legacy%7Cwikibase.client.init&only=styles&skin=vector"/>
|
||
<script async="" src="/w/load.php?lang=de&modules=startup&only=scripts&raw=1&skin=vector"></script>
|
||
<meta name="ResourceLoaderDynamicStyles" content=""/>
|
||
<link rel="stylesheet" href="/w/load.php?lang=de&modules=site.styles&only=styles&skin=vector"/>
|
||
<meta name="generator" content="MediaWiki 1.38.0-wmf.5"/>
|
||
<meta name="referrer" content="origin"/>
|
||
<meta name="referrer" content="origin-when-crossorigin"/>
|
||
<meta name="referrer" content="origin-when-cross-origin"/>
|
||
<meta name="format-detection" content="telephone=no"/>
|
||
<meta property="og:title" content="Extreme Programming – Wikipedia"/>
|
||
<meta property="og:type" content="website"/>
|
||
<link rel="preconnect" href="//upload.wikimedia.org"/>
|
||
<link rel="alternate" media="only screen and (max-width: 720px)" href="//de.m.wikipedia.org/wiki/Extreme_Programming"/>
|
||
<link rel="alternate" type="application/x-wiki" title="Seite bearbeiten" href="/w/index.php?title=Extreme_Programming&action=edit"/>
|
||
<link rel="apple-touch-icon" href="/static/apple-touch/wikipedia.png"/>
|
||
<link rel="shortcut icon" href="/static/favicon/wikipedia.ico"/>
|
||
<link rel="search" type="application/opensearchdescription+xml" href="/w/opensearch_desc.php" title="Wikipedia (de)"/>
|
||
<link rel="EditURI" type="application/rsd+xml" href="//de.wikipedia.org/w/api.php?action=rsd"/>
|
||
<link rel="license" href="https://creativecommons.org/licenses/by-sa/3.0/"/>
|
||
<link rel="canonical" href="https://de.wikipedia.org/wiki/Extreme_Programming"/>
|
||
<link rel="dns-prefetch" href="//meta.wikimedia.org" />
|
||
<link rel="dns-prefetch" href="//login.wikimedia.org"/>
|
||
</head>
|
||
<body class="mediawiki ltr sitedir-ltr mw-hide-empty-elt ns-0 ns-subject mw-editable page-Extreme_Programming rootpage-Extreme_Programming skin-vector action-view skin-vector-legacy"><div id="mw-page-base" class="noprint"></div>
|
||
<div id="mw-head-base" class="noprint"></div>
|
||
<div id="content" class="mw-body" role="main">
|
||
<a id="top"></a>
|
||
<div id="siteNotice"><!-- CentralNotice --></div>
|
||
<div class="mw-indicators">
|
||
<div id="mw-indicator-topicon-Vorlage_Lesenswert" class="mw-indicator"><div class="noprint"><a href="#Vorlage_Lesenswert" title="Dies ist ein als lesenswert ausgezeichneter Artikel."><img alt="Dies ist ein als lesenswert ausgezeichneter Artikel." src="//upload.wikimedia.org/wikipedia/commons/thumb/4/43/Qsicon_lesenswert.svg/15px-Qsicon_lesenswert.svg.png" decoding="async" width="15" height="15" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/4/43/Qsicon_lesenswert.svg/23px-Qsicon_lesenswert.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/4/43/Qsicon_lesenswert.svg/30px-Qsicon_lesenswert.svg.png 2x" data-file-width="24" data-file-height="24" /></a></div></div>
|
||
</div>
|
||
<h1 id="firstHeading" class="firstHeading" >Extreme Programming</h1>
|
||
<div id="bodyContent" class="vector-body">
|
||
<div id="siteSub" class="noprint">aus Wikipedia, der freien Enzyklopädie</div>
|
||
<div id="contentSub"></div>
|
||
<div id="contentSub2"></div>
|
||
|
||
<div id="jump-to-nav"></div>
|
||
<a class="mw-jump-link" href="#mw-head">Zur Navigation springen</a>
|
||
<a class="mw-jump-link" href="#searchInput">Zur Suche springen</a>
|
||
<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-parser-output"><p><b>Extreme Programming</b> (<b>XP</b>, auch <b>Extremprogrammierung</b>) ist eine <a href="/wiki/Agile_Methode" class="mw-redirect" title="Agile Methode">Methode</a>, die das Lösen einer Programmieraufgabe in den Vordergrund der Softwareentwicklung stellt und dabei einem formalisierten Vorgehen geringere Bedeutung zumisst.
|
||
Diese Vorgehensweise definiert ein <a href="/wiki/Vorgehensmodell_zur_Softwareentwicklung" title="Vorgehensmodell zur Softwareentwicklung">Vorgehensmodell</a> der <a href="/wiki/Softwaretechnik" title="Softwaretechnik">Softwaretechnik</a>, das sich den Anforderungen des Kunden in kleinen Schritten annähert.
|
||
</p>
|
||
<div id="toc" class="toc" role="navigation" aria-labelledby="mw-toc-heading"><input type="checkbox" role="button" id="toctogglecheckbox" class="toctogglecheckbox" style="display:none" /><div class="toctitle" lang="de" dir="ltr"><h2 id="mw-toc-heading">Inhaltsverzeichnis</h2><span class="toctogglespan"><label class="toctogglelabel" for="toctogglecheckbox"></label></span></div>
|
||
<ul>
|
||
<li class="toclevel-1 tocsection-1"><a href="#Grundlagen"><span class="tocnumber">1</span> <span class="toctext">Grundlagen</span></a></li>
|
||
<li class="toclevel-1 tocsection-2"><a href="#Nutzen"><span class="tocnumber">2</span> <span class="toctext">Nutzen</span></a>
|
||
<ul>
|
||
<li class="toclevel-2 tocsection-3"><a href="#Kundensicht"><span class="tocnumber">2.1</span> <span class="toctext">Kundensicht</span></a></li>
|
||
<li class="toclevel-2 tocsection-4"><a href="#Programmierersicht"><span class="tocnumber">2.2</span> <span class="toctext">Programmierersicht</span></a></li>
|
||
<li class="toclevel-2 tocsection-5"><a href="#Projektsicht"><span class="tocnumber">2.3</span> <span class="toctext">Projektsicht</span></a></li>
|
||
<li class="toclevel-2 tocsection-6"><a href="#Betriebswirtschaftliche_Sicht"><span class="tocnumber">2.4</span> <span class="toctext">Betriebswirtschaftliche Sicht</span></a></li>
|
||
</ul>
|
||
</li>
|
||
<li class="toclevel-1 tocsection-7"><a href="#Vorgehen"><span class="tocnumber">3</span> <span class="toctext">Vorgehen</span></a>
|
||
<ul>
|
||
<li class="toclevel-2 tocsection-8"><a href="#Aufbauorganisation"><span class="tocnumber">3.1</span> <span class="toctext">Aufbauorganisation</span></a></li>
|
||
<li class="toclevel-2 tocsection-9"><a href="#Anforderungsmanagement"><span class="tocnumber">3.2</span> <span class="toctext">Anforderungsmanagement</span></a></li>
|
||
<li class="toclevel-2 tocsection-10"><a href="#Planung"><span class="tocnumber">3.3</span> <span class="toctext">Planung</span></a>
|
||
<ul>
|
||
<li class="toclevel-3 tocsection-11"><a href="#User-Storys"><span class="tocnumber">3.3.1</span> <span class="toctext">User-Storys</span></a></li>
|
||
<li class="toclevel-3 tocsection-12"><a href="#Aufwandsabschätzung"><span class="tocnumber">3.3.2</span> <span class="toctext">Aufwandsabschätzung</span></a></li>
|
||
</ul>
|
||
</li>
|
||
<li class="toclevel-2 tocsection-13"><a href="#Entwicklung_und_Abschluss"><span class="tocnumber">3.4</span> <span class="toctext">Entwicklung und Abschluss</span></a></li>
|
||
<li class="toclevel-2 tocsection-14"><a href="#Abgrenzung_von_herkömmlichem_Vorgehen"><span class="tocnumber">3.5</span> <span class="toctext">Abgrenzung von herkömmlichem Vorgehen</span></a></li>
|
||
</ul>
|
||
</li>
|
||
<li class="toclevel-1 tocsection-15"><a href="#Bestandteile"><span class="tocnumber">4</span> <span class="toctext">Bestandteile</span></a>
|
||
<ul>
|
||
<li class="toclevel-2 tocsection-16"><a href="#Werte"><span class="tocnumber">4.1</span> <span class="toctext">Werte</span></a></li>
|
||
<li class="toclevel-2 tocsection-17"><a href="#Prinzipien"><span class="tocnumber">4.2</span> <span class="toctext">Prinzipien</span></a></li>
|
||
<li class="toclevel-2 tocsection-18"><a href="#Praktiken"><span class="tocnumber">4.3</span> <span class="toctext">Praktiken</span></a>
|
||
<ul>
|
||
<li class="toclevel-3 tocsection-19"><a href="#Traditionelle_Praktiken"><span class="tocnumber">4.3.1</span> <span class="toctext">Traditionelle Praktiken</span></a></li>
|
||
<li class="toclevel-3 tocsection-20"><a href="#Evolutionäre_Praktiken"><span class="tocnumber">4.3.2</span> <span class="toctext">Evolutionäre Praktiken</span></a>
|
||
<ul>
|
||
<li class="toclevel-4 tocsection-21"><a href="#Hauptpraktiken"><span class="tocnumber">4.3.2.1</span> <span class="toctext">Hauptpraktiken</span></a></li>
|
||
<li class="toclevel-4 tocsection-22"><a href="#Begleitpraktiken"><span class="tocnumber">4.3.2.2</span> <span class="toctext">Begleitpraktiken</span></a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</li>
|
||
<li class="toclevel-2 tocsection-23"><a href="#Flexibilitätsgrad_vs._Steifheit"><span class="tocnumber">4.4</span> <span class="toctext">Flexibilitätsgrad vs. Steifheit</span></a></li>
|
||
</ul>
|
||
</li>
|
||
<li class="toclevel-1 tocsection-24"><a href="#Ursprung_und_Abgrenzung"><span class="tocnumber">5</span> <span class="toctext">Ursprung und Abgrenzung</span></a>
|
||
<ul>
|
||
<li class="toclevel-2 tocsection-25"><a href="#Traditionelle_Vorgehensmodelle"><span class="tocnumber">5.1</span> <span class="toctext">Traditionelle Vorgehensmodelle</span></a></li>
|
||
<li class="toclevel-2 tocsection-26"><a href="#Geschichte_von_XP"><span class="tocnumber">5.2</span> <span class="toctext">Geschichte von XP</span></a></li>
|
||
<li class="toclevel-2 tocsection-27"><a href="#Andere_agile_Vorgehensmodelle"><span class="tocnumber">5.3</span> <span class="toctext">Andere agile Vorgehensmodelle</span></a></li>
|
||
</ul>
|
||
</li>
|
||
<li class="toclevel-1 tocsection-28"><a href="#XP_in_Projekten"><span class="tocnumber">6</span> <span class="toctext">XP in Projekten</span></a></li>
|
||
<li class="toclevel-1 tocsection-29"><a href="#Kritik"><span class="tocnumber">7</span> <span class="toctext">Kritik</span></a>
|
||
<ul>
|
||
<li class="toclevel-2 tocsection-30"><a href="#Das_Alles-oder-Nichts-Prinzip"><span class="tocnumber">7.1</span> <span class="toctext">Das Alles-oder-Nichts-Prinzip</span></a></li>
|
||
<li class="toclevel-2 tocsection-31"><a href="#Bewegliche_Anforderungen"><span class="tocnumber">7.2</span> <span class="toctext">Bewegliche Anforderungen</span></a></li>
|
||
<li class="toclevel-2 tocsection-32"><a href="#Der_ideale_Kunde"><span class="tocnumber">7.3</span> <span class="toctext">Der ideale Kunde</span></a></li>
|
||
<li class="toclevel-2 tocsection-33"><a href="#Der_ideale_Programmierer"><span class="tocnumber">7.4</span> <span class="toctext">Der ideale Programmierer</span></a></li>
|
||
<li class="toclevel-2 tocsection-34"><a href="#Beschränkte_Team-_und_damit_Projektgröße"><span class="tocnumber">7.5</span> <span class="toctext">Beschränkte Team- und damit Projektgröße</span></a></li>
|
||
<li class="toclevel-2 tocsection-35"><a href="#Fehlende_Eignung_für_Festpreisprojekte"><span class="tocnumber">7.6</span> <span class="toctext">Fehlende Eignung für Festpreisprojekte</span></a></li>
|
||
<li class="toclevel-2 tocsection-36"><a href="#Feste_Fertigstellungstermine"><span class="tocnumber">7.7</span> <span class="toctext">Feste Fertigstellungstermine</span></a></li>
|
||
<li class="toclevel-2 tocsection-37"><a href="#Einsatz_in_verteilten_Umgebungen"><span class="tocnumber">7.8</span> <span class="toctext">Einsatz in verteilten Umgebungen</span></a></li>
|
||
<li class="toclevel-2 tocsection-38"><a href="#Kritik_an_einzelnen_Praktiken"><span class="tocnumber">7.9</span> <span class="toctext">Kritik an einzelnen Praktiken</span></a></li>
|
||
<li class="toclevel-2 tocsection-39"><a href="#Personalpolitik"><span class="tocnumber">7.10</span> <span class="toctext">Personalpolitik</span></a></li>
|
||
</ul>
|
||
</li>
|
||
<li class="toclevel-1 tocsection-40"><a href="#Siehe_auch"><span class="tocnumber">8</span> <span class="toctext">Siehe auch</span></a></li>
|
||
<li class="toclevel-1 tocsection-41"><a href="#Literatur"><span class="tocnumber">9</span> <span class="toctext">Literatur</span></a></li>
|
||
<li class="toclevel-1 tocsection-42"><a href="#Weblinks"><span class="tocnumber">10</span> <span class="toctext">Weblinks</span></a></li>
|
||
<li class="toclevel-1 tocsection-43"><a href="#Einzelnachweise"><span class="tocnumber">11</span> <span class="toctext">Einzelnachweise</span></a></li>
|
||
</ul>
|
||
</div>
|
||
|
||
<h2><span class="mw-headline" id="Grundlagen">Grundlagen</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=1" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Grundlagen">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=1" title="Abschnitt bearbeiten: Grundlagen">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h2>
|
||
<div class="thumb tright"><div class="thumbinner" style="width:402px;"><a href="/wiki/Datei:XP-Life.png" class="image"><img alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/1/19/XP-Life.png/400px-XP-Life.png" decoding="async" width="400" height="395" class="thumbimage" srcset="//upload.wikimedia.org/wikipedia/commons/1/19/XP-Life.png 1.5x" data-file-width="415" data-file-height="410" /></a> <div class="thumbcaption"><div class="magnify"><a href="/wiki/Datei:XP-Life.png" class="internal" title="vergrößern und Informationen zum Bild anzeigen"></a></div>XP-Lebenszyklus</div></div></div>
|
||
<p>XP ist ein durch fortlaufende <a href="/wiki/Iteration#Softwaretechnik" title="Iteration">Iterationen</a> und den Einsatz mehrerer Einzelmethoden strukturierendes Vorgehensmodell. XP entstand durch die <a href="/wiki/Synthese" title="Synthese">Synthese</a> verschiedener Disziplinen der <a href="/wiki/Softwareentwicklung" class="mw-redirect" title="Softwareentwicklung">Softwareentwicklung</a> und basiert auf in der Praxis bewährten Methoden, auch <a href="/wiki/Best_practice" class="mw-redirect" title="Best practice">Best practices</a> genannt.
|
||
</p><p>XP folgt einem strukturierten Vorgehen und stellt die Teamarbeit, Offenheit und stete Kommunikation zwischen allen Beteiligten in den Vordergrund. Kommunikation ist dabei eine Grundsäule.
|
||
</p><p>Die Methode geht davon aus, dass der Kunde die <a href="/wiki/Anforderung" title="Anforderung">Anforderungen</a> an die zu erstellende <a href="/wiki/Software" title="Software">Software</a> zu Projektbeginn noch nicht komplett kennt und nicht hinreichend strukturieren kann, beziehungsweise dass ein mit der Realisierung betrautes Entwicklerteam nicht über alle Informationen verfügt, um eine verlässliche <a href="/wiki/Aufwandssch%C3%A4tzung_(Softwaretechnik)" title="Aufwandsschätzung (Softwaretechnik)">Aufwandsschätzung</a> über die notwendige Dauer bis zum Abschluss zu geben. Im Laufe eines Projektes ändern sich nicht selten Prioritäten und Gewichte. Zu Beginn geforderte Funktionen der Software werden möglicherweise in einer anderen Form benötigt oder im Laufe der Zeit sogar komplett hinfällig.
|
||
</p><p>Bei einer konsequenten Ausrichtung an XP soll die zu erstellende Software schneller bereitgestellt werden sowie eine höhere Softwarequalität und Zufriedenheit des Kunden als mit traditionellen Ansätzen zu erreichen sein. Der Kunde soll ein einsatzbereites Produkt erhalten, an dessen Herstellung er aktiv teilgenommen hat.
|
||
</p><p>Neue Funktionalitäten werden permanent entwickelt, integriert und getestet. Für die zu entwickelnden Funktionalitäten werden jeweils die Schritte Risikoanalyse, Nutzenanalyse, die Bereitstellung einer ersten ausführbaren Version (<a href="/wiki/Prototyping_(Softwareentwicklung)" title="Prototyping (Softwareentwicklung)">Prototyping</a>) und ein Akzeptanztest durchgeführt.
|
||
</p>
|
||
<h2><span class="mw-headline" id="Nutzen">Nutzen</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=2" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Nutzen">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=2" title="Abschnitt bearbeiten: Nutzen">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h2>
|
||
<p>Nach Vertretern dieses Vorgehensmodells ist XP <a href="/wiki/Risikomanagement" title="Risikomanagement">Risikomanagement</a>. Es bejaht das Risiko, geht aktiv darauf ein und versucht, es zu minimieren. Dieser implizite Umgang mit dem Faktor <i>Risiko</i> steht im Gegensatz zu eher expliziten Vorgehensweisen, wie der Aufstellung einer <i>Risikoliste</i>.<sup id="cite_ref-MARC_1-0" class="reference"><a href="#cite_note-MARC-1">[1]</a></sup> Softwareentwicklungsprojekte sind unterschiedlichen Gefahren ausgesetzt, für die Extreme Programming Lösungen anbieten soll.
|
||
</p>
|
||
<h3><span class="mw-headline" id="Kundensicht">Kundensicht</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=3" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Kundensicht">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=3" title="Abschnitt bearbeiten: Kundensicht">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Dem Kunden bietet XP, gerade durch seine kurzen Entwicklungszyklen, jederzeit die Möglichkeit, steuernd auf das Projekt einzuwirken. Dadurch soll erreicht werden, dass sich das Produkt aktuellen Anforderungen anpasst, statt überholten Anforderungen aus einer längst vergangenen Analysephase zu genügen und damit bereits bei Einführung veraltet zu sein. Zudem kann der Kunde bereits nach kurzer Zeit ein unvollständiges aber zumindest funktionstüchtiges Produkt einsetzen. Der Kunde ist im besten Fall jederzeit auf demselben aktuellen Informationsstand bezüglich des Projektes wie das Entwicklerteam.
|
||
</p><p>Ein häufiger Ansatz traditioneller Softwareerstellung ist: <i>„Vielleicht brauchen wir irgendwann einmal diese oder jene Programmfunktionen“</i>, auch <a href="/wiki/Feature-Request" title="Feature-Request">Feature</a> genannt. XP stellt dem gegenüber: <i>Lass es!</i> (vgl. auch <a href="/wiki/YAGNI" title="YAGNI">YAGNI</a> – „You Ain’t Gonna Need It“). Vor jedem der kurzen Entwicklungsschritte wird zusammen mit dem Kunden genau festgelegt, was wirklich sinnvoll ist, entwickelt zu werden. Die sogenannte „<a href="/wiki/Featuritis" class="mw-redirect" title="Featuritis">Featuritis</a>“ soll damit vermieden werden.
|
||
</p><p>Eines der größten Risiken der Softwareentwicklung ist, dass dem Kunden ein Produkt bereitgestellt wird, das er in dieser Form nicht möchte. XP möchte dem durch ständige, aktive Einbeziehung des Kunden in den Entwicklungsprozess vorbeugen. Er kann sich Zwischenversionen ansehen und direkt Änderungswünsche äußern.
|
||
</p><p>Um diese Vorteile nutzen zu können, muss der Kunde im Gegenzug auch eine Reihe von Einschränkungen und Forderungen hinnehmen. So fordert XP von ihm, dass er während der gesamten Entwicklungszeit mit dem Entwicklungsteam zusammenarbeitet. Des Weiteren muss er auf eine formale Festlegung der Projektinhalte (Spezifikation) verzichten (siehe auch <i><a href="#Der_ideale_Kunde">Der ideale Kunde</a></i>).
|
||
</p>
|
||
<h3><span class="mw-headline" id="Programmierersicht">Programmierersicht</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=4" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Programmierersicht">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=4" title="Abschnitt bearbeiten: Programmierersicht">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Es existiert keine strikte Rollentrennung, da die Aufgabenverteilung abhängig von Situation und Fähigkeiten geschieht. Der allgemeine Wissensaustausch und die stetige Kommunikation beugen einem Wissens<a href="/wiki/Monopol" title="Monopol">monopol</a> vor. Dies soll den Einzelnen entlasten, da ansonsten der Druck auf einer Person lastet, wenn diese sich als Einzige in einem <a href="/wiki/Modul_(Software)" title="Modul (Software)">Modul</a> auskennt.
|
||
</p><p>Um Unbenutzbarkeit aufgrund von Programmfehlern sowie fehlerhafte Integration einzelner <a href="/wiki/Komponente_(Software)" title="Komponente (Software)">Komponenten</a> zu vermeiden, werden bei XP viele und möglichst frühe Tests angestrebt. Jede Komponente besitzt einen <a href="/wiki/Modultest" title="Modultest">Modultest</a> (Unit-Test); in <a href="/wiki/Java_(Programmiersprache)" title="Java (Programmiersprache)">Java</a> beispielsweise mit <a href="/wiki/JUnit" title="JUnit">JUnit</a>. Bei Feststellung eines Fehlers in einer Komponente während der Entwicklung wird ein Test entwickelt, der diesen lokalisiert. Eine tägliche Einbeziehung der einzelnen am Projekt beteiligten Entwickler mit automatischer Ausführung der Tests (<a href="/wiki/Regressionstest" title="Regressionstest">Regressionstest</a>) soll zu einer erheblichen Qualitätssteigerung führen. Fehler sollen so früher gefunden werden, denn je später ein Fehler gefunden wird, desto teurer ist meist dessen Korrektur. Außerdem soll die <a href="/wiki/Testgetriebene_Entwicklung" title="Testgetriebene Entwicklung">testgetriebene Entwicklung</a> zu einem leichter wartbaren Programmcode mit besserem Design führen.
|
||
</p><p>Da die meisten Einzelmethoden gerade auf den Alltag der Programmierer ausgerichtet sind, bedeutet XP zugleich auch ein hohes Maß an Herausforderung und ggf. Umstellung der Beteiligten. Auf diese Aspekte wird ausführlicher im Abschnitt <i><a href="#Der_ideale_Programmierer">Der ideale Programmierer</a></i> eingegangen.
|
||
</p>
|
||
<h3><span class="mw-headline" id="Projektsicht">Projektsicht</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=5" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Projektsicht">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=5" title="Abschnitt bearbeiten: Projektsicht">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Dem Projekt bietet XP die Möglichkeit, Risiken zu minimieren. Unter richtiger Anwendung von XP soll der Kunde Software erhalten, deren Umfang ihn nicht überrascht. Das Team soll ferner gegen Ausfall (Krankheit, Unfall, Stellenwechsel) Einzelner nicht mehr so anfällig sein. Ein ehrlicher Umgang mit dem Kunden soll die Glaubwürdigkeit und Zufriedenheit steigern und die <a href="/wiki/Angst" title="Angst">Angst</a> minimieren, die unter Umständen zwischen Kunde („Haben die mich verstanden?“, „Was werden sie wohl liefern?“) und Entwicklung („Was will er eigentlich genau?“, „Ob er zufrieden sein wird mit dem, was wir liefern?“) vorherrscht.
|
||
</p><p>Aufwandsabschätzungen werden verlässlicher, da sie im Team getroffen und ständig einer kritischen Überprüfung (<a href="/wiki/Review_(Softwaretest)" title="Review (Softwaretest)">Review</a>) unterzogen werden. <a href="/wiki/Teamgeist" class="mw-redirect" title="Teamgeist">Teamgeist</a> wird laut XP gefördert. Jedem im Team sollte klar sein, dass das Ziel nur als Einheit erreichbar ist. Sollte ein Projekt, zum Beispiel aus Kostengründen, vorzeitig eingestellt werden, besteht durch die regelmäßigen Iterationen dennoch ein zumeist einsatzfähiges Produkt.
|
||
</p><p>In vielen Projekten gelingt es nicht, das Produkt in der gewünschten Zeit im gewünschten Umfang und mit den geplanten Ressourcen fertigzustellen. In XP soll nur das verwirklicht werden, was tatsächlich einen Nutzen für den Kunden hat. Durch ständigen Austausch mit dem Kunden sowie Prioritätsanalysen sollen die unbedingt zu erstellenden Funktionen identifiziert werden. Dabei sollte mit den Funktionen begonnen werden, die den größten Nutzen haben und das größte (technische) Risiko beinhalten.
|
||
</p>
|
||
<h3><span class="mw-headline" id="Betriebswirtschaftliche_Sicht">Betriebswirtschaftliche Sicht</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=6" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Betriebswirtschaftliche Sicht">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=6" title="Abschnitt bearbeiten: Betriebswirtschaftliche Sicht">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Extreme Programming stellt aus wirtschaftswissenschaftlicher Sicht eine Form der <a href="/wiki/Organisation" title="Organisation">Organisation</a> dar, die direkt die Prozesse der <a href="/wiki/Wertsch%C3%B6pfung_(Wirtschaft)" title="Wertschöpfung (Wirtschaft)">Wertschöpfung</a> beschreibt. In den Wirtschaftswissenschaften werden zur Bewertung von Extreme Programming auch Erkenntnisse anderer <a href="/wiki/Sozialwissenschaften" title="Sozialwissenschaften">Sozialwissenschaften</a>, insbesondere der <a href="/wiki/Soziologie" title="Soziologie">Soziologie</a>, genutzt.
|
||
</p><p>Dem <a href="/wiki/Risikomanagement" title="Risikomanagement">Risikomanagement</a> dient diese Alternative vor allem zur Steuerung von <a href="/wiki/Risiko" title="Risiko">Risiken</a>. Wie bei vielen Prozessen der Wertschöpfung sind besonders in der Softwareentwicklung Risiken meist operative Risiken: Die Wertschöpfung ist <a href="/wiki/Effektivit%C3%A4t" title="Effektivität">ineffektiv</a>, wenn die Kundenwünsche nicht getroffen und gesteckte Ziele somit verfehlt wurden. Die Wertschöpfung ist ineffizient, wenn zum Erreichen des Ergebnisses ein zu hoher Aufwand entstand. Risikoverminderung, und dadurch Effektivität und Effizienz, soll bei Extreme Programming durch die Art des Umgangs mit Fehlern, mit Mitarbeitern und mit Kunden erreicht werden:
|
||
</p>
|
||
<ul><li>Kompensation von Krankheitsausfällen</li>
|
||
<li>Kundennahe Entwicklung</li>
|
||
<li>Weniger Fehler im Ergebnis</li></ul>
|
||
<p>Ein möglichst genaues Erkennen von Risiken durch das Verfahren selbst soll über angepasste Aufwandsschätzungen eine Bewertung des zu akzeptierenden Risikos ermöglichen. Extreme Programming kann dagegen eine Risikoverlagerung erschweren. Aus der Sicht des Risikomanagements ist Extreme Programming also <i>nur</i> eine Möglichkeit, mit Risiken umzugehen, und zwar eine Möglichkeit, die Vor- und Nachteile besitzt.
|
||
</p><p>Das <a href="/wiki/Personalwesen" title="Personalwesen">Personalwesen</a> in Unternehmen betrachtet Extreme Programming insbesondere im Hinblick auf seine Auswirkungen auf die Mitarbeiterzufriedenheit. Extreme Programming soll dabei bewusst oder unbewusst zum <a href="/wiki/Kooperatives_Lernen" title="Kooperatives Lernen">kooperativen Lernen</a> beitragen. Für das Personalwesen ist dieses Verfahren also besonders aus Sicht der <a href="/wiki/Personalentwicklung" title="Personalentwicklung">Personalentwicklung</a> interessant. Durch höhere Mitarbeiterzufriedenheit und durch die Vermeidung von Überstunden soll die gesamte Produktivität erhöht werden. Die Praktik des Pair-Programming lässt allerdings – rein mathematisch betrachtet – Gegenteiliges vermuten. Die Vermeidung von Spezialistentum und individuellem Besitz von Wissen über Teile der Software dient der <a href="/wiki/Kollektive_Wissenskonstruktion" class="mw-redirect" title="Kollektive Wissenskonstruktion">kollektiven Wissenskonstruktion</a> und kann die Ersetzung von Entwicklern vereinfachen.
|
||
</p><p>Die gesamte Betriebswirtschaftslehre ist in den letzten Jahren von der prozess- bzw. wertschöpfungsorientierten zur kunden- bzw. marktorientierten Unternehmensführung übergegangen. Auch wenn Extreme Programming die Wertschöpfung beschreibt, bietet es Möglichkeiten zu kundennaher Vorgehensweise. Über Extreme Programming soll – wie in anderen Branchen schon länger üblich – eine größere Einbindung des Kunden in den Wertschöpfungsprozess möglich sein. Wichtig wird dies umso mehr, wenn Software weniger als <a href="/wiki/Faktormarkt" title="Faktormarkt">Faktorgut</a>, sondern mehr als <a href="/wiki/Halbfabrikat" title="Halbfabrikat">Vorprodukt</a> erstellt und vertrieben wird.
|
||
</p><p>Ebenfalls betrachtet werden muss Extreme Programming und dessen Aufwand aus Sicht des <a href="/wiki/Informationsmanagement" title="Informationsmanagement">Informationsmanagements</a>, das den Aufwand für den unbedingt notwendigen Informationsaustausch festlegt und ökonomisch bewertet. Genutzt werden dazu Erkenntnisse der <a href="/wiki/Informationswissenschaft" title="Informationswissenschaft">Informations-</a> und <a href="/wiki/Kommunikationswissenschaft" title="Kommunikationswissenschaft">Kommunikationswissenschaft</a>. Dabei kann insbesondere die <a href="/wiki/Medienreichhaltigkeitstheorie" title="Medienreichhaltigkeitstheorie">Medienreichhaltigkeitstheorie</a> eingesetzt werden: Weil die zu diskutierenden und kommunizierenden Sachverhalte in der Regel komplex sind, werden auch komplexe, reichhaltige <a href="/wiki/Massenmedien" title="Massenmedien">Kommunikationsmedien</a> gewählt: direkte, persönliche Gespräche. Kritisch zu hinterfragen ist hierbei die schwierige räumliche Verteilbarkeit der Entwicklungsprozesse sowie die Einbindung des Kunden, da unter Umständen eine räumliche Trennung zwischen Entwicklern und Kunden besteht.
|
||
</p>
|
||
<h2><span class="mw-headline" id="Vorgehen">Vorgehen</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=7" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Vorgehen">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=7" title="Abschnitt bearbeiten: Vorgehen">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h2>
|
||
<p>Vereinzelt wird Extreme Programming als informelle (und damit unverbindliche) Methode bezeichnet. Das trifft jedoch weder den Ansatz noch das Ziel. Tatsächlich ist die Formalisierung der Methode des Extreme Programming bewusst flach und schlank gehalten. Hingegen muss ein Einvernehmen zwischen Kunden und Programmierern hinsichtlich der Verbindlichkeit der erstellten Unterlagen hergestellt werden, solange diese noch nicht durch neuere Fassungen ersetzt wurden. Weiter muss der Vorgang des Ersetzens einer Fassung einer Unterlage durch eine neuere Fassung dieser Unterlage soweit formalisiert sein, dass beide Parteien Kenntnis von dieser Ersetzung haben und diese Ersetzung annehmen.
|
||
</p>
|
||
<h3><span class="mw-headline" id="Aufbauorganisation">Aufbauorganisation</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=8" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Aufbauorganisation">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=8" title="Abschnitt bearbeiten: Aufbauorganisation">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Neben dem Entwicklungsteam gibt es im Wesentlichen den Kunden und den <i>Product-Owner</i>. Innerhalb des Entwicklerteams soll es keine Rollentrennung geben. So wird nicht unterschieden, wer im Team welches Spezialgebiet hat, beziehungsweise welche besonderen Fähigkeiten er mitbringt. Jede Person im Team wird als <a href="/wiki/Softwareentwickler" title="Softwareentwickler">Entwickler</a> (<i>Developer</i>) bezeichnet. Ein <a href="/wiki/Manager_(Wirtschaft)" title="Manager (Wirtschaft)">Manager</a> ist gewöhnlich eine Person mit Führungsbefugnis, also ein disziplinarischer Vorgesetzter. Dieser hat in XP weniger Wichtigkeit. Dagegen gibt es einen „Leiter“ des Teams, also jemand, der die Kommunikation mit Kunden oder untereinander koordiniert. Auch der Nutzer der zu erstellenden Software kann das Team durch das Projekt führen. Die Unterscheidung zwischen Manager und „Leiter“ ist für agile Vorgehensmodelle typisch. Der Product-Owner, der über die genaue Vorgehensweise entscheidet, trägt die Verantwortung. Product-Owner im Sinne von XP kann beispielsweise ein Vertreter des Produktmanagements, ein Kunde oder ein Nutzer des Produktes sein. Die Rollen sind je nach Projekt und Umgebung unterschiedlich, häufig auch in Personalunion, verteilt.
|
||
</p>
|
||
<table class="wikitable zebra" style="background:#F0F0FF;">
|
||
<caption>Die Rollen bei XP
|
||
</caption>
|
||
<tbody><tr class="hintergrundfarbe8">
|
||
<th>Rolle
|
||
</th>
|
||
<th>Beispiel
|
||
</th>
|
||
<th>Aufgaben
|
||
</th></tr>
|
||
<tr>
|
||
<td>Produktbesitzer
|
||
</td>
|
||
<td>Produktmanagement, Marketing, ein Benutzer, Kunde, Manager des Benutzers, Analyst, Sponsor
|
||
</td>
|
||
<td>Hat Verantwortung, setzt Prioritäten, Entscheider für bestes <a href="/wiki/Return_on_Investment" title="Return on Investment">ROI</a>
|
||
</td></tr>
|
||
<tr>
|
||
<td>Kunde
|
||
</td>
|
||
<td>Auftraggeber, kann auch der Produktbesitzer sein, kann, muss aber nicht der Benutzer sein
|
||
</td>
|
||
<td>Entscheidet, was gemacht wird, gibt regelmäßig Rückmeldung, Auftraggeber
|
||
</td></tr>
|
||
<tr>
|
||
<td>Entwickler
|
||
</td>
|
||
<td>Bestandteil des Teams, das ganze Entwicklungsteam besteht aus Entwicklern: Programmierer, Tester, DB-Experten, Architekt, Designer
|
||
</td>
|
||
<td>Entwickelt das Produkt
|
||
</td></tr>
|
||
<tr>
|
||
<td>Projektmanager
|
||
</td>
|
||
<td>Ist gewöhnlich der Produktbesitzer. Kann auch Entwickler aber nicht Manager des Teams sein
|
||
</td>
|
||
<td>Führung des Teams
|
||
</td></tr>
|
||
<tr>
|
||
<td>Benutzer
|
||
</td>
|
||
<td>Der Nutzer des zu erstellenden Produktes
|
||
</td>
|
||
<td>Wird das zu erstellende Produkt nutzen
|
||
</td></tr></tbody></table>
|
||
<h3><span class="mw-headline" id="Anforderungsmanagement">Anforderungsmanagement</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=9" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Anforderungsmanagement">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=9" title="Abschnitt bearbeiten: Anforderungsmanagement">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Der <a href="/wiki/Anforderungserhebung" class="mw-redirect" title="Anforderungserhebung">Umgang mit den Anforderungen und deren Verwirklichung</a> ist eine zentrale Komponente XPs. Durch eine Mischung verschiedener, in den folgenden Abschnitten dargestellter Maßnahmen soll die Qualität und Flexibilität der Software gesteigert werden, so dass sich der Zusammenhang zwischen dem Zeitpunkt der Anforderungsstellung und den damit entstehenden Kosten weitgehend linear darstellt.
|
||
</p>
|
||
<div class="thumb tright"><div class="thumbinner" style="width:402px;"><a href="/wiki/Datei:Xpkurve.png" class="image"><img alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/6/60/Xpkurve.png/400px-Xpkurve.png" decoding="async" width="400" height="270" class="thumbimage" srcset="//upload.wikimedia.org/wikipedia/commons/6/60/Xpkurve.png 1.5x" data-file-width="444" data-file-height="300" /></a> <div class="thumbcaption"><div class="magnify"><a href="/wiki/Datei:Xpkurve.png" class="internal" title="vergrößern und Informationen zum Bild anzeigen"></a></div>Änderungskostenkurve in Abhängigkeit vom Zeitpunkt der Änderung</div></div></div>
|
||
<p>Bei einem weitgehend linearen Verlauf einer ableitbaren <a href="/wiki/Kostenaufl%C3%B6sung" title="Kostenauflösung">Änderungskostenkurve</a> wird auf eine vollständige Erhebung aller Anforderungen zu Beginn des Projektes verzichtet. Stattdessen werden die sich erst im Laufe der Umsetzung ergebenden Anforderungen berücksichtigt. Dieses Vorgehen resultiert aus den Beobachtungen, dass einerseits der Kunde zu Beginn des Projektes noch gar nicht genau weiß, was er möchte, andererseits sich diese Anforderungen im Laufe eines Projektes ändern. Darüber hinaus sind Fehler umso teurer, je später man sie findet. Im schlimmsten Fall erhält der Kunde nach einem langen Projekt etwas geliefert, was er in dieser Form gar nicht haben möchte. Ständiger Gedankenaustausch mit dem Kunden, Offenheit für Änderungen und stetige Integration wirken diesen Risiken entgegen. Anforderungen werden nicht selten zunächst als <a href="/wiki/Prototyping_(Softwareentwicklung)" title="Prototyping (Softwareentwicklung)">Prototypen</a> bereitgestellt. Dabei handelt es sich um Versionen, die noch nicht die volle, endgültige Funktionalität besitzen.
|
||
</p>
|
||
<h3><span class="mw-headline" id="Planung">Planung</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=10" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Planung">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=10" title="Abschnitt bearbeiten: Planung">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<div class="thumb tright"><div class="thumbinner" style="width:402px;"><a href="/wiki/Datei:Release3.png" class="image"><img alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/c/ca/Release3.png/400px-Release3.png" decoding="async" width="400" height="324" class="thumbimage" srcset="//upload.wikimedia.org/wikipedia/commons/c/ca/Release3.png 1.5x" data-file-width="503" data-file-height="407" /></a> <div class="thumbcaption"><div class="magnify"><a href="/wiki/Datei:Release3.png" class="internal" title="vergrößern und Informationen zum Bild anzeigen"></a></div>Release, Iterationen, User-Storys und Tasks</div></div></div>
|
||
<p>Im Rahmen der Planung wird gewöhnlich folgende Unterscheidung vorgenommen: ein <a href="/wiki/Versionierung" class="mw-redirect" title="Versionierung">Release</a> beinhaltet die Funktionen, die insgesamt und für sich geschlossen die Bereitstellung einer neuen Version des Produktes rechtfertigen. Um zu dem Release zu kommen, ist ein Release-Plan aufzustellen, der im Wesentlichen aus <a href="/wiki/Iteration" title="Iteration">Iterationen</a> besteht. Unter anderem abhängig von der geschätzten Entwicklungsdauer des Release werden die Iterationen in Anzahl und Dauer festgelegt. Iterationen dauern üblicherweise zwischen einer und vier Wochen. Der Zeitpunkt der Fertigstellung wird als Zeitintervall diskutiert, dessen Größe im Laufe des Release aufgrund gewonnener Erkenntnisse und des durchgeführten Fortschritts ständig abnimmt.
|
||
</p>
|
||
<div class="thumb tright"><div class="thumbinner" style="width:304px;"><a href="/wiki/Datei:Risk-value-priorisierung.png" class="image"><img alt="" src="//upload.wikimedia.org/wikipedia/commons/b/bc/Risk-value-priorisierung.png" decoding="async" width="302" height="255" class="thumbimage" data-file-width="302" data-file-height="255" /></a> <div class="thumbcaption"><div class="magnify"><a href="/wiki/Datei:Risk-value-priorisierung.png" class="internal" title="vergrößern und Informationen zum Bild anzeigen"></a></div>Risiko-Wert Gegenüberstellung und Verteilung der Prioritäten</div></div></div>
|
||
<h4><span class="mw-headline" id="User-Storys">User-Storys</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=11" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: User-Storys">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=11" title="Abschnitt bearbeiten: User-Storys">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h4>
|
||
<p>Die innerhalb der Iterationen umzusetzenden einzelnen Neuerungen werden mit dem Kunden durch <i><a href="/wiki/User-Story" class="mw-redirect" title="User-Story">User-Storys</a></i> beschrieben.
|
||
</p><p>Das ganze Team ist bei der Erstellung beteiligt. Die abzuarbeitenden Anforderungen werden auf einzelnen Karten (<i>Story Cards</i>) geschrieben und für alle sichtbar platziert. Neben diesem Vorgehen ist es auch üblich <i>Class Responsibility Collaboration Models</i> auf <i>CRC Cards</i> zu verfassen. <i>CRC Models</i> nehmen sich dabei einen Akteur im System vor und beschreiben dessen Verantwortlichkeiten und Interaktionen mit anderen Akteuren.
|
||
</p><p>Den <i>User-Storys</i> werden Prioritätswerte zugeordnet. Dazu muss das Team zusammen mit dem Kunden zunächst Klarheit gewinnen, welche <i>User-Storys</i> das höchste Risiko bezüglich Zeitplan, Kosten oder Funktionalität besitzen und welche <i>User-Storys</i> dem <a href="/wiki/Produkt_(Wirtschaft)" title="Produkt (Wirtschaft)">Produkt</a> den höchsten, respektive den niedrigsten Mehrwert bieten, wobei ein Diagramm hilfreich sein kann. Das Release sollte mit den <i>User-Storys</i> begonnen werden, die das höchste Risiko und den höchsten Nutzen auf sich vereinen. Danach sind diejenige <i>User-Storys</i> zu verwirklichen, die geringes Risiko aber hohen Nutzen haben. Anschließend geht das Team die <i>User-Storys</i> an, die geringes Risiko und geringen Nutzen auf sich vereinen. Die Fertigstellung von User-Storys mit geringem Nutzen aber hohem Risiko ist zu vermeiden.
|
||
</p>
|
||
<div class="thumb tleft"><div class="thumbinner" style="width:318px;"><a href="/wiki/Datei:Kano-modell.png" class="image"><img alt="" src="//upload.wikimedia.org/wikipedia/commons/8/87/Kano-modell.png" decoding="async" width="316" height="260" class="thumbimage" data-file-width="316" data-file-height="260" /></a> <div class="thumbcaption"><div class="magnify"><a href="/wiki/Datei:Kano-modell.png" class="internal" title="vergrößern und Informationen zum Bild anzeigen"></a></div>Kundenzufriedenheit</div></div></div>
|
||
<p>Neben einer Abschätzung nach Nutzen und Risiko ist für die Entscheidung, welche <i>User-Storys</i> in dem Release beziehungsweise in den ersten Iterationen umgesetzt werden sollen, noch eine Analyse der Kundenwünsche von Bedeutung. Dabei bedient sich ein XP-Projekt häufig des <a href="/wiki/Kano-Modell" title="Kano-Modell">Kano-Modells</a>. Dabei werden in einer systematischen Kundenbefragung Fragen in <i>funktionaler Form</i> und in <i>dysfunktionaler Form</i> gestellt. Es lässt sich anschließend bestimmen, welche <i>User-Storys</i> unbedingt fertiggestellt werden müssen (<i>Must-haves</i>), welche linearer Natur sind (je mehr, desto besser; siehe <i><a href="/wiki/Linearit%C3%A4t" title="Linearität">linear</a></i>.) und welche <i>Exciters</i> sind (Der Kunde rechnet nicht mit diesen Merkmalen, nutzt das Produkt auch ohne. Es lässt sich dadurch der Preis erhöhen.). Die so gewonnenen Erkenntnisse werden diskutiert.
|
||
</p><p>XP zeichnet sich dadurch aus, dass die Betrachtung der Größe einer Einheit, wie Release oder Iteration, unabhängig von ihrer Dauer ist.
|
||
</p>
|
||
<h4><span id="Aufwandsabsch.C3.A4tzung"></span><span class="mw-headline" id="Aufwandsabschätzung">Aufwandsabschätzung</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=12" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Aufwandsabschätzung">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=12" title="Abschnitt bearbeiten: Aufwandsabschätzung">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h4>
|
||
<p>Bei der Release-Planung sind User-Storys noch recht grobkörnig. Beschäftigt sich ein Team mit einer User-Story genauer, so wird sie, zusammen mit dem Kunden, detaillierter beschrieben. User-Storys werden gewöhnlich in <i>Story-Points</i> abgeschätzt, wobei auch eine Abschätzung in <i>idealen Tagen</i> möglich ist. Story-Points sind relative <a href="/wiki/Aufwandssch%C3%A4tzung_(Softwaretechnik)" title="Aufwandsschätzung (Softwaretechnik)">Aufwandsabschätzungen</a>, also der Entwicklungsaufwand für eine Story im Vergleich zu anderen. Dabei kann es sein, dass erste Abschätzungen im Verlaufe des Projektes geändert werden. Es wird vom ganzen Team, in mehreren Runden, in einem <i>Planning-Game</i> eine Punkteanzahl für die User-Storys geschätzt.
|
||
</p><p>Nachdem User-Storys abgeschätzt, priorisiert und einer Iteration zugewiesen wurden, beginnt das Team mit der Umsetzung. User-Storys werden zu Beginn der Iteration in feinkörnige, technische Arbeitspakete (<a href="/wiki/Aufgabe_(Pflicht)" title="Aufgabe (Pflicht)">Tasks</a>) zerlegt, die gewöhnlich einen Umfang von Stunden besitzen. Das Team führt diese Zerlegung durch und schätzt die Dauer eines jeden Tasks. Es wird allerdings noch nicht festgelegt wer den Task zugeteilt bekommt. Zu Beginn der Arbeiten nehmen sich die Entwickler jeweils ein Arbeitspaket vor, gewöhnlich nach Fähigkeiten. Dieser Vorgang wird im Team kurz diskutiert. Nach der anfänglichen Zuweisung der Arbeitspakete wird ein weiterer Task begonnen, wenn ein Teammitglied Zeit dafür findet, also seinen vorangegangenen Task abgeschlossen hat. Die Implementierung einer User-Story, also der Funktionalität, ist erst abgeschlossen, wenn alle einzelnen Tasks dieser User-Story abgearbeitet und die Tests geschrieben und alle erfolgreich durchlaufen sind.
|
||
</p><p>Der Demonstration dieser Vorgehensweise soll eine Tabelle mit Aufwandsabschätzungen in einer fiktiven Arztpraxis dienen. Jeder Arzt hat eine Software, die ihm hilft, seine Patienten und die Termine zu verwalten:
|
||
</p>
|
||
<table class="wikitable zebra" style="background:#F0F0FF; text-align:center;">
|
||
<caption>User-Storys mit Aufwandsabschätzung in Story-Points
|
||
</caption>
|
||
<tbody><tr class="hintergrundfarbe8">
|
||
<th>Story No.
|
||
</th>
|
||
<th>Story
|
||
</th>
|
||
<th>Abschätzung<br />(Story Points)
|
||
</th></tr>
|
||
<tr>
|
||
<td>1
|
||
</td>
|
||
<td style="text-align:left;">Als Arzt kann ich alle Patienten sehen, die ich am Tage habe.
|
||
</td>
|
||
<td>3
|
||
</td></tr>
|
||
<tr>
|
||
<td>2
|
||
</td>
|
||
<td style="text-align:left;">Als Arzt kann ich über die Gesundheitsgeschichte meiner Patienten Auskunft geben.
|
||
</td>
|
||
<td>5
|
||
</td></tr>
|
||
<tr>
|
||
<td>3
|
||
</td>
|
||
<td style="text-align:left;">Als Assistentin kann ich einem Patienten einen Termin geben.
|
||
</td>
|
||
<td>2
|
||
</td></tr>
|
||
<tr>
|
||
<td>4
|
||
</td>
|
||
<td style="text-align:left;">Als Assistentin kann ich einem Patienten eine Verschreibung ausdrucken.
|
||
</td>
|
||
<td>1
|
||
</td></tr></tbody></table>
|
||
<p>Der Begriff <i>Velocity</i> (Geschwindigkeit) beschreibt den Durchsatz des Teams, also die Anzahl der innerhalb einer Iteration erreichten Story-Points. Die Bestimmung der Velocity hilft abzuschätzen, wie lange die Entwicklung der gewünschten Funktionalität für ein Release dauert, beziehungsweise wie viele Iterationen notwendig sind. Es ist normal, dass die Geschwindigkeit des Teams nicht immer die gleiche ist.
|
||
</p>
|
||
<h3><span class="mw-headline" id="Entwicklung_und_Abschluss">Entwicklung und Abschluss</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=13" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Entwicklung und Abschluss">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=13" title="Abschnitt bearbeiten: Entwicklung und Abschluss">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<div class="thumb tright"><div class="thumbinner" style="width:402px;"><a href="/wiki/Datei:Extreme_Programming_Planungs-_und_Feedback-Schleifen.svg" class="image"><img alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/2/28/Extreme_Programming_Planungs-_und_Feedback-Schleifen.svg/400px-Extreme_Programming_Planungs-_und_Feedback-Schleifen.svg.png" decoding="async" width="400" height="367" class="thumbimage" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/2/28/Extreme_Programming_Planungs-_und_Feedback-Schleifen.svg/600px-Extreme_Programming_Planungs-_und_Feedback-Schleifen.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/2/28/Extreme_Programming_Planungs-_und_Feedback-Schleifen.svg/800px-Extreme_Programming_Planungs-_und_Feedback-Schleifen.svg.png 2x" data-file-width="367" data-file-height="337" /></a> <div class="thumbcaption"><div class="magnify"><a href="/wiki/Datei:Extreme_Programming_Planungs-_und_Feedback-Schleifen.svg" class="internal" title="vergrößern und Informationen zum Bild anzeigen"></a></div>Zeitlicher Abstand der Schritte.</div></div></div>
|
||
<p>Es gibt eine tägliche kurze Besprechung <i>(Stand-up Meeting)</i>, bei der jeder Entwickler berichtet, was er am Vortag geleistet hat, wo es gegebenenfalls Probleme gab und was er heute leisten möchte. Ferner werden situationsabhängig Arbeitspaare gebildet <i>(<a href="/wiki/Pair-Programming" class="mw-redirect" title="Pair-Programming">Pair-Programming</a>)</i>. Im Laufe des Tages findet, während die Entwickler die Funktionalität und die Tests programmieren, weiterer stetiger Austausch <i>(Pair-Negotiations)</i> statt.
|
||
</p><p>Kann eine User-Story in einer Iteration nicht abgeschlossen werden, zum Beispiel weil die Tests nicht erfolgreich waren oder sich die Abschätzung als zu knapp beziehungsweise der Umfang als zu groß herausgestellt hat, so wird sie gewöhnlich in mehrere kleinere aufgeteilt oder komplett in die nächste Iteration verschoben. Auch während einer Iteration kann sich, durch sich ändernde Prioritäten des Kunden oder durch neue Erkenntnisse, an der Zusammenstellung der Iteration etwas ändern. Ist die Iteration abgeschlossen, schauen sich Vertreter des <a href="/wiki/Unternehmensf%C3%BChrung" title="Unternehmensführung">Managements</a>, der Kunde (<a href="/wiki/Akzeptanztest_(Softwaretechnik)" title="Akzeptanztest (Softwaretechnik)">Akzeptanztest</a>) oder andere Personen, die an dem Produkt Interesse haben, das Produkt in der aktuellen Ausbaustufe an und geben Rückmeldungen. So ist es denkbar, dass der Kunde während des Akzeptanztests neue Prioritäten setzt oder weitere Ideen einbringt.
|
||
</p><p>Technische Unterstützung muss differenziert betrachtet werden. Einerseits wird bewusst auf technische <a href="/wiki/Arbeitsmittel" title="Arbeitsmittel">Hilfsmittel</a> verzichtet, so etwa bei der Erstellung von User-Storys. Diese werden gewöhnlich manuell erstellt. Andererseits wird die Technik aber auch exzessiv genutzt, so etwa bei der automatisierten Integration und der automatisierten Durchführung von Tests. Darüber hinaus existieren Projektmanagement-Werkzeuge, die sich auf die speziellen Rahmenbedingungen und Anforderungen XPs konzentriert haben.
|
||
</p>
|
||
<h3><span id="Abgrenzung_von_herk.C3.B6mmlichem_Vorgehen"></span><span class="mw-headline" id="Abgrenzung_von_herkömmlichem_Vorgehen">Abgrenzung von herkömmlichem Vorgehen</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=14" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Abgrenzung von herkömmlichem Vorgehen">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=14" title="Abschnitt bearbeiten: Abgrenzung von herkömmlichem Vorgehen">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Die zu entwickelnde Funktionalität wird kurz und formlos in User-Storys beschrieben. Das meiste Wissen über die Funktionalität ihrer Entwicklung befindet sich in den Köpfen der Beteiligten. User-Storys werden gewöhnlich nur relativ zueinander geschätzt. Zu Beginn einer Iteration wird deren Inhalt festgelegt. Anschließend kommt erst die Aufteilung der gewählten User-Storys in Tasks. Neuartig an dem XP-Ansatz ist ebenfalls, dass nicht nur einzelne Personen, sondern das ganze Team den jeweiligen Aufwand schätzt. Auch das Verfahren der Schätzung ist neu. Der Zeitpunkt, wann und wie die Tasks den einzelnen Entwicklern zugeteilt werden, ist ebenfalls ein Abgrenzungskriterium. Erst im Laufe der Iteration nehmen sich die einzelnen Entwickler, je nach ihrer Verfügbarkeit, eines Tasks an. Zu allen User-Storys gibt es zahlreiche Tests. Eine User-Story ist erst komplett abgeschlossen, wenn alle Tests erfolgreich abgelaufen sind. Der tägliche kurze Austausch ist für die <a href="/wiki/Agile_Softwareentwicklung" title="Agile Softwareentwicklung">agile Methodik</a> üblich.
|
||
</p>
|
||
<h2><span class="mw-headline" id="Bestandteile">Bestandteile</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=15" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Bestandteile">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=15" title="Abschnitt bearbeiten: Bestandteile">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h2>
|
||
<p>XP besteht aus Werten, Prinzipien und Praktiken. Obwohl es auch andere maßgebliche Quellen gibt (siehe <a href="#Weblinks">Weblinks</a> und <a href="#Literatur">Literatur</a>), orientiert sich die Zusammenstellung der Werte, Prinzipien und Praktiken an Kent Beck,<sup id="cite_ref-BECK1_2-0" class="reference"><a href="#cite_note-BECK1-2">[2]</a></sup> dessen noch recht neue, evolutionäre Weiterentwicklungen XPs hier ebenfalls Berücksichtigung finden.<sup id="cite_ref-BECK2_3-0" class="reference"><a href="#cite_note-BECK2-3">[3]</a></sup> Es existiert keine eindeutige Definition von XP, wobei allerdings die Diskussionen und Ausführungen der drei Originalverfasser XP am signifikantesten prägen.
|
||
</p>
|
||
<h3><span class="mw-headline" id="Werte">Werte</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=16" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Werte">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=16" title="Abschnitt bearbeiten: Werte">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>XP definiert fünf zentrale Werte, abstrakte Elemente, die von zentraler Bedeutung sind: <i>Kommunikation</i>, <i>Einfachheit</i>, <i>Rückmeldung</i>, <i>Mut</i> und <i>Respekt</i>, wobei Respekt erst später dazukam. Ohne stetige Beachtung dieser zentralen Werte ist es laut XP nicht möglich, erfolgreich Software zu entwickeln.
|
||
</p>
|
||
<div class="thumb tright"><div class="thumbinner" style="width:363px;"><a href="/wiki/Datei:XP-Werte.png" class="image"><img alt="" src="//upload.wikimedia.org/wikipedia/commons/c/c9/XP-Werte.png" decoding="async" width="361" height="271" class="thumbimage" data-file-width="361" data-file-height="271" /></a> <div class="thumbcaption"><div class="magnify"><a href="/wiki/Datei:XP-Werte.png" class="internal" title="vergrößern und Informationen zum Bild anzeigen"></a></div>Die zentralen XP-Werte</div></div></div>
|
||
<p>Das Team kommuniziert stetig, um Informationen auszutauschen. Der Prozess selbst erfordert hohe Kommunikationsbereitschaft. Es gibt einen stetigen Austausch aller Beteiligten, also auch zwischen dem Entwicklungsteam und dem Kunden. Es kommen auch Personen zu Wort, die in einer gerade diskutierten technischen Aufgabenstellung keine Experten sind. So werden sie miteinbezogen, es gibt zusätzliche Rückmeldungen und jeder fühlt sich dem Team und dem Produkt verpflichtet. Stetige Kommunikation mit dem Kunden, Aufnahme seines Feedbacks und Erfüllung seiner Wünsche, also auch eines lauffähigen Produktes, das seinen Wünschen voll entspricht, ist wichtiger als <a href="/wiki/Vertrag" title="Vertrag">Vertragsverhandlungen</a>. Die Kommunikation zeichnet sich ferner durch einen respektvollen Umgang aus, sowohl im Team untereinander als auch mit dem Kunden. Unterschiedliche Meinungen werden akzeptiert.
|
||
</p><p>Die Entwickler sollen mutig sein und die Kommunikation offen gestalten. Falls eine Anforderung nicht in einer Iteration umgesetzt werden kann, wird in offener und ehrlicher Art und Weise direkt darauf hingewiesen. Es muss eine Atmosphäre geschaffen werden, die herkömmliche Störungen (wie unnatürlichen Konkurrenzkampf innerhalb des Teams zu Lasten des Produktes) minimiert. Um die Offenheit und den Mut zu fördern und <a href="/wiki/Gruppendynamik" title="Gruppendynamik">gruppendynamischen</a>, <a href="/wiki/Psychologie" title="Psychologie">psychologischen</a> Schwierigkeiten entgegenzutreten, kann bewusst ein <i>Doomsayer</i> zur offenen, zeitnahen Aussprache von schlechten Nachrichten oder möglichen Schwierigkeiten oder auch ein <a href="/wiki/Advocatus_Diaboli" title="Advocatus Diaboli">Advocatus Diaboli</a> eingesetzt werden.
|
||
</p><p>Es soll die einfachste Lösung für eine Problemstellung umgesetzt werden. In jeder Iteration konzentriert sich das komplette Team genau auf die momentan umzusetzenden Anforderungen. Die Lösungen sind technisch immer möglichst einfach zu halten.
|
||
</p>
|
||
<h3><span class="mw-headline" id="Prinzipien">Prinzipien</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=17" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Prinzipien">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=17" title="Abschnitt bearbeiten: Prinzipien">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Es gibt 14 Prinzipien, die eine Brücke bilden zwischen den abstrakten Werten und den konkret anwendbaren Praktiken. Diese Prinzipien sollten immer Berücksichtigung finden. Sie sind <i>Menschlichkeit</i>, <i>Wirtschaftlichkeit</i>, <i>Beidseitiger Vorteil</i>, <i>Selbstgleichheit</i>, <i>Verbesserungen</i>, <i>Vielfältigkeit</i>, <i>Reflexion</i>, <i>Lauf</i>, <i>Gelegenheiten wahrnehmen</i>, <i>Redundanzen vermeiden</i>, <i>Fehlschläge hinnehmen</i>, <i>Qualität</i>, <i>Kleine Schritte</i> sowie <i>Akzeptierte Verantwortung</i>.
|
||
</p><p>Software wird von Menschen entwickelt. Menschen bilden also den Faktor, dem laut XP besondere Aufmerksamkeit gilt. Durch Schaffung einer menschlichen Atmosphäre soll den Grundbedürfnissen der Entwickler (Sicherheit, Vollendung, Identifikation mit der Gruppe, Perspektive und Verständnis) entsprochen werden.
|
||
</p><p>Die erstellte Software beziehungsweise eine einzelne Funktionalität muss einerseits wirtschaftlich sein und dennoch einen echten Wert bringen. Andererseits muss sie für beide Seiten von Vorteil sein und alle Beteiligten (Entwicklungsteam und Kunde) zufriedenstellen.
|
||
</p>
|
||
<div class="thumb tright"><div class="thumbinner" style="width:355px;"><a href="/wiki/Datei:XP-Evolution-Prinzipien.png" class="image"><img alt="" src="//upload.wikimedia.org/wikipedia/commons/2/22/XP-Evolution-Prinzipien.png" decoding="async" width="353" height="289" class="thumbimage" data-file-width="353" data-file-height="289" /></a> <div class="thumbcaption"><div class="magnify"><a href="/wiki/Datei:XP-Evolution-Prinzipien.png" class="internal" title="vergrößern und Informationen zum Bild anzeigen"></a></div>Die Prinzipien XPs</div></div></div>
|
||
<p>Die Wiederverwendung bestehender Lösungen, wozu beispielsweise die zahlreichen unterschiedlichen Tests gehören, die stetig automatisiert durchlaufen werden, ist wichtig. Es ist jedem klar, dass erste Lösungen meist nicht optimal sind. Aus Feedback und selbst gewonnenen, neuen Erkenntnissen wird die Lösung stetig verbessert. Immer bessere Lösungen zu erkennen, gelingt nur durch stetige Reflexion und ein kontinuierliches Hinterfragen der jeweiligen Vorgehensweisen im Team. Die Produktivität dieses Verfahrens steigt proportional zur Uneinheitlichkeit des aus Personen mit unterschiedlichen Fähigkeiten und <a href="/wiki/Pers%C3%B6nlichkeit" title="Persönlichkeit">Charakteren</a> bestehenden Teams. Verschiedene Meinungen werden nicht nur geduldet, sondern sogar gefördert. Dazu muss ein <a href="/wiki/Konfliktmanagement" title="Konfliktmanagement">Konfliktmanagement</a> etabliert werden.
|
||
</p><p>Die Lauffähigkeit der Software muss zu jedem Zeitpunkt garantiert sein. Obwohl kurze Iterationen mit permanentem Feedback dabei helfen, das Projekt in einem Lauf zu halten, müssen Fehlschläge dennoch miteinkalkuliert werden. Es ist durchaus üblich und wird akzeptiert, eine Umsetzung durchzuführen, die zunächst nicht optimal oder sogar fehlerhaft sein kann. Diese Schwierigkeiten müssen als Gelegenheit und Chance begriffen werden, das Produkt und das Team noch weiter reifen zu lassen. Ein offener, konstruktiver Umgang mit den Herausforderungen der Softwareentwicklung gelingt umso besser, je mehr alle Beteiligten bereit sind, ihre Verantwortung zu akzeptieren. Einem Entwickler eine Aktivität und Verantwortung nur disziplinarisch aufzutragen, reicht nicht aus, da er die Verantwortung aktiv annehmen und leben muss.
|
||
</p><p>Ein weiterer wichtiger Punkt ist die hohe <a href="/wiki/Qualit%C3%A4t" title="Qualität">Qualität</a>, die gemäß XP im Gegensatz zu anderen Faktoren wie Ressourcen, Funktionsumfang oder Endtermin nicht zur Diskussion steht. Diese Grundeinstellung unterscheidet sich von vielen anderen Methoden der Softwareerstellung, bei denen Software zu einem bestimmten Zeitpunkt und in einem definierten Funktionsumfang fertiggestellt werden soll, worunter fast immer die Softwarequalität leidet. Gerade die Qualität ist allerdings wichtig, um das Produkt einsatzfähig, fehlerfrei und erweiterbar zu halten. Software mit gutem Design und hoher Qualität ist mittelfristig kostengünstiger, erweiterbarer und weniger fehlerbehaftet als schnell erstellte, sogenannte <i>Quick-and-dirty-Software</i>.
|
||
</p><p>Zu guter Qualität gehört auch die Vermeidung von Redundanzen (unnötig mehrfach oder wiederholt ausgeführte oder auch manuell ausgeführte automatisierbare Schritte).
|
||
</p><p>Durch schnelle, kleine Schritte bleibt das Team flexibel und kann sich schnell neuen Rahmenbedingungen anpassen und auf Feedback eingehen. Die negativen Folgen eines einzelnen kleinen, nicht erfolgreichen Schrittes können wesentlich schneller durch einen neuen Schritt kompensiert werden, als dies bei einem einzelnen größeren Schritt der Fall wäre.
|
||
</p>
|
||
<h3><span class="mw-headline" id="Praktiken">Praktiken</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=18" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Praktiken">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=18" title="Abschnitt bearbeiten: Praktiken">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Es lassen sich traditionelle und evolutionäre Praktiken unterscheiden. Die traditionellen sind in der XP-Welt weit verbreitet und genutzt. Die evolutionären nehmen verschiedene neue Erkenntnisse aus der jahrelangen Anwendung XPs auf. Sie verfeinern oder modifizieren die ursprünglichen Praktiken geringfügig und machen damit die Nutzung klarer und verständlicher.
|
||
</p><p>XP wird häufig mit den traditionellen Praktiken verbunden, beziehungsweise darauf reduziert.
|
||
</p>
|
||
<h4><span class="mw-headline" id="Traditionelle_Praktiken">Traditionelle Praktiken</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=19" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Traditionelle Praktiken">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=19" title="Abschnitt bearbeiten: Traditionelle Praktiken">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h4>
|
||
<dl><dt>Pair-Programming</dt>
|
||
<dd>Bei der <a href="/wiki/Paarprogrammierung" title="Paarprogrammierung">Paarprogrammierung</a> teilen sich zwei <a href="/wiki/Programmierer" class="mw-redirect" title="Programmierer">Programmierer</a> einen Computer – einer codiert (der <i>Driver</i>) und der andere denkt mit und hat das Gesamtbild im Kopf (der <i>Partner</i>). Die Rollen werden regelmäßig getauscht. Dieses Vorgehen steigert den Wissenstransfer. Anfänger sollen schneller von der Arbeit eines Spezialisten lernen. Das Wissen wird verteilt. Das Projekt ist nicht mehr so anfällig gegen den Ausfall eines Einzelnen. Durch ständigen <a href="/wiki/Codereview" class="mw-redirect" title="Codereview">Codereview</a> der Entwicklung und Kommunikation wird das <a href="/wiki/Design" title="Design">Design</a> verbessert und Fehler schneller gefunden (siehe auch <a href="/wiki/Vier-Augen-Prinzip" title="Vier-Augen-Prinzip">Vier-Augen-Prinzip</a>).</dd>
|
||
<dt>Kollektives Eigentum</dt>
|
||
<dd>Aktivitäten werden zunächst nicht an einzelne Personen verteilt, sondern an das ganze Team. Es existiert laut Methodik das Bewusstsein und die Verpflichtung nur als Team erfolgreich sein zu können. Einzelne Teammitglieder besitzen kein Wissens<a href="/wiki/Monopol" title="Monopol">monopol</a>. Pair-Programming und wechselhafte Einsatzgebiete sollen der Strömung entgegenwirken, dass einzelne Personen Teile als ihren Besitz betrachten.</dd>
|
||
<dt><span id="Permanente_Integration"></span>Permanente Integration</dt>
|
||
<dd><a href="/wiki/Kontinuierliche_Integration" title="Kontinuierliche Integration">Kontinuierliche Integration</a> der einzelnen <a href="/wiki/Komponente_(Software)" title="Komponente (Software)">Komponenten</a> zu einem lauffähigen Gesamtsystem in kurzen Zeitabständen. Je häufiger integriert wird, desto höher wird laut XP die eintretende Routine. Fehler werden damit früh aufgedeckt. Die mit der Integration verbundenen Kosten sollen fast auf Null minimiert werden, da die Integration zu einem täglichen Schritt gehört, der weitestgehend vollautomatisiert und selbst stabil und durchgetestet sein muss.</dd>
|
||
<dt><span id="Permanentes_Testen"></span>Testgetriebene Entwicklung bzw. Permanentes Testen</dt>
|
||
<dd>Bei der <a href="/wiki/Testgetriebene_Entwicklung" title="Testgetriebene Entwicklung">testgetriebenen Entwicklung</a> werden erst die <a href="/wiki/Modultest" title="Modultest">Modultests</a> (Unit-Test) geschrieben, bevor die eigentliche Funktionalität programmiert wird. Der Entwickler befasst sich dadurch früh mit dem Design des Codes und überdenkt seine Programmierarbeit genau. Die Tests werden nach jedem Programmierschritt ausgeführt und liefern Rückmeldung über den Entwicklungsstand. Die Tests sind automatisiert. Im Laufe einer Integration werden Integrationstests durchgeführt. Es wird zwischen <a href="/wiki/Regressionstest" title="Regressionstest">Regressionstest</a> und Modultest unterschieden. Während Modultests (Unit-Tests) einzelne Module testen, ist ein Regressionstest die kollektive Ausführung aller Tests, um die unveränderte Lauffähigkeit der <i>alten</i>, bereits vor der Iteration existenten Funktionalität zu überprüfen. Auch <a href="/wiki/Rechenleistung" title="Rechenleistung">Performancetests</a>, bei denen die Leistungs- und Geschwindigkeitsmerkmale in Bezug auf die geforderten Werte gemessen werden, sind üblich. Der Entwickler bekommt Rückmeldung (Feedback), wie viele und welche Tests nicht erfolgreich waren. Ein <a href="/wiki/Akzeptanztest_(Softwaretechnik)" title="Akzeptanztest (Softwaretechnik)">Akzeptanztest</a> ist die Präsentation des Standes des Produktes, um die Zufriedenheit des Kunden und die Nutzbarkeit zu validieren.</dd></dl>
|
||
<div class="thumb tright"><div class="thumbinner" style="width:402px;"><a href="/wiki/Datei:Xp-kreis.png" class="image"><img alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/7/7e/Xp-kreis.png/400px-Xp-kreis.png" decoding="async" width="400" height="280" class="thumbimage" srcset="//upload.wikimedia.org/wikipedia/commons/7/7e/Xp-kreis.png 1.5x" data-file-width="425" data-file-height="297" /></a> <div class="thumbcaption"><div class="magnify"><a href="/wiki/Datei:Xp-kreis.png" class="internal" title="vergrößern und Informationen zum Bild anzeigen"></a></div>XP Best Practices</div></div></div>
|
||
<dl><dt>Kundeneinbeziehung</dt>
|
||
<dd>Enge Einbeziehung des Kunden, das heißt, der Kunde gibt das <a href="/wiki/Iteration" title="Iteration">Iterationsziel</a> mit einer Auswahl der zu realisierenden <i>User-Storys</i> vor und hat kurz danach die Möglichkeit, <a href="/wiki/Akzeptanztest_(Softwaretechnik)" title="Akzeptanztest (Softwaretechnik)">Akzeptanztests</a> durchzuführen. <i><a href="/wiki/Story-Card" class="mw-redirect" title="Story-Card">Story-Cards</a></i> dienen als Medium, um die kurzen Anwendungsfälle in Form von <i>User-Storys</i> aufzunehmen. Der Kunde muss immer anwesend oder zumindest erreichbar sein. Neben User-Storys auf Story-Cards existiert noch der Ansatz, <i>CRC-Modelle</i> auf <a href="/wiki/Class-Responsibility-Collaboration-Karten" title="Class-Responsibility-Collaboration-Karten">CRC-Karten</a> zu verfassen.</dd>
|
||
<dt>Refactoring</dt>
|
||
<dd>Laufendes <a href="/wiki/Refactoring" title="Refactoring">Refactoring</a>, ständige <a href="/wiki/Softwarearchitektur" title="Softwarearchitektur">Architektur</a>-, <a href="/wiki/Design" title="Design">Design</a>- und <a href="/wiki/Code" title="Code">Code</a>-Verbesserungen, auch um <a href="/wiki/Anti-Pattern" title="Anti-Pattern">Anti-Patterns</a> umgehend erkennen und beseitigen zu können. XP bejaht die Existenz von Code, der am Beginn nicht perfekt ist. Stattdessen sind sämtliche Teile einem stetigen Review unterworfen. Gefundene, optimierungsfähige Stellen werden gewöhnlich sofort verbessert oder als Fehler (<a href="/wiki/Programmfehler" title="Programmfehler">Bugs</a>) definiert, die in einer späteren Iteration behoben werden.</dd>
|
||
<dt>Keine Überstunden</dt>
|
||
<dd><i>40-Stunden-Woche</i>, d. h. Überstunden sind zu vermeiden, weil darunter die Freude an der Arbeit, mittelfristig die Konzentrationsfähigkeit der Programmierer und somit auch die Qualität des Produktes leidet. Nachweislich sinkt die <a href="/wiki/Produktivit%C3%A4t" title="Produktivität">Produktivität</a> eines Entwicklers durch Überstunden. Arbeit außerhalb der regulären Arbeitszeit wird im Einzelfall zwar geduldet, aber auf keinen Fall besonders entlohnt oder erwartet. Überstunden zeugen gewöhnlich einfach nur von falscher <a href="/wiki/Planung" title="Planung">Planung</a>.</dd>
|
||
<dt>Iterationen</dt>
|
||
<dd>Kurze <a href="/wiki/Iteration" title="Iteration">Iterationen</a>, um dem Kunden in regelmäßigen Zeitabständen einen lauffähigen Zwischenstand des Produkts zu liefern. Eine Iteration ist eine zeitlich und fachlich in sich abgeschlossene Einheit. Kurze Iterationen und damit verbundene Akzeptanztests erlauben schnelle Feedbackschleifen zwischen Entwicklung und Kunde.</dd>
|
||
<dt>Metapher</dt>
|
||
<dd>Da in traditionell aufgesetzten Softwareprojekten ein latentes Missverständnis zwischen Kunde und Entwicklungsteam ein häufiges Problem darstellt – der Entwickler hat Schwierigkeiten mit der Fachsprache des Kunden und umgekehrt –, werden die Anforderungen im fachlichen <a href="/wiki/Vokabular" class="mw-redirect" title="Vokabular">Vokabular</a> des Kunden, idealerweise auch von ihm selbst, in Form von <i>User-Storys</i> beschrieben. Alle sprechen eine Sprache, was durch ein <a href="/wiki/Glossar" title="Glossar">Glossar</a> noch verstärkt werden kann. Es wird eine <i>Metapher</i> gewählt, eine inhaltlich ähnliche, für beide Seiten verständliche Alltagsgeschichte.</dd>
|
||
<dt>Coding-Standards</dt>
|
||
<dd>Das Team hält sich bei der Programmierarbeit an <a href="/wiki/Coding_standards" class="mw-redirect" title="Coding standards">Standards</a>, welche erst die gemeinschaftliche Verantwortung des Teams bei dieser Aufgabe ermöglichen. Wechselnder Einsatz der Entwickler in allen Bereichen der Software ist laut XP nur durch gemeinsame Standards sinnvoll möglich.</dd>
|
||
<dt>Einfaches Design</dt>
|
||
<dd>Es soll die einfachste Lösung angestrebt werden, also diejenige, die genau das Gewünschte erreicht (und nicht mehr). Bewusst allgemein (<a href="/wiki/Generisch" title="Generisch">generisch</a>) gehaltene Lösungen oder vorbereitende Maßnahmen für potentiell zukünftige Anforderungen werden vermieden. Zum Thema Einfachheit sind die <a href="/wiki/Umgangssprache" title="Umgangssprache">umgangssprachlichen</a> <a href="/wiki/Akronym" title="Akronym">Akronyme</a> <a href="/wiki/KISS-Prinzip" title="KISS-Prinzip">KISS</a> („Keep it simple, stupid“) und <a href="/wiki/YAGNI" title="YAGNI">YAGNI</a> („You Ain’t Gonna Need It“) verbreitet.</dd>
|
||
<dt>Planning-Game</dt>
|
||
<dd>Neue Versionen der Software werden in einem <i>Planning-Game</i>, auch als <i>Planning-Poker</i> bekannt, spezifiziert und der Aufwand zu deren Umsetzung abgeschätzt. An diesem iterativen Prozess sind sowohl Entwicklungsmannschaft als auch Kunde beteiligt.</dd></dl>
|
||
<h4><span id="Evolution.C3.A4re_Praktiken"></span><span class="mw-headline" id="Evolutionäre_Praktiken">Evolutionäre Praktiken</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=20" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Evolutionäre Praktiken">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=20" title="Abschnitt bearbeiten: Evolutionäre Praktiken">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h4>
|
||
<p>Die evolutionären Praktiken wurden fünf Jahre nach den ursprünglichen publiziert und ersetzen diese. Sie lassen sich unterteilen in <i>Hauptpraktiken</i> und ergänzende <i>Begleitpraktiken</i>. Inhaltlich sind die neuen Praktiken mit den alten, traditionellen Praktiken vergleichbar. Die Bezeichnungen der alten Praktiken wurden teilweise modifiziert oder in einzelne Unterpraktiken aufgeteilt. Zwei Praktiken sind weggefallen: die Praktik <i>Metapher</i> war zu schwer zu vermitteln und hat sich laut Literatur nicht durchgesetzt. <i>Coding-Standards</i> werden als selbstverständlich vorausgesetzt und nicht mehr explizit erwähnt.
|
||
</p>
|
||
<h5><span class="mw-headline" id="Hauptpraktiken">Hauptpraktiken</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=21" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Hauptpraktiken">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=21" title="Abschnitt bearbeiten: Hauptpraktiken">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h5>
|
||
<p>Die Hauptpraktiken sind: <i>Räumlich zusammen sitzen</i>, <i>Informativer Arbeitsplatz</i>, <i>Team</i>, <i>Pair-Programming</i>, <i>Energievolle Arbeit</i>, <i>Entspannte Arbeit</i>, <i>Storys</i>, <i>Wöchentlicher Zyklus</i>, <i>Quartalsweiser Zyklus</i>, <i>10-Minuten-Build</i>, <i><a href="/wiki/Kontinuierliche_Integration" title="Kontinuierliche Integration">Kontinuierliche Integration</a></i>, <i>Test-First-Programmierung</i> und <i>Inkrementelles Design</i>.
|
||
</p><p>Durch offene, gemeinsame Anordnung der Arbeitsplätze soll die Kommunikation optimiert werden. Diese Form ist aufgrund der besseren Kommunikationsmöglichkeiten einer räumlichen Trennung der Beteiligten vorzuziehen. Der Arbeitsplatz muss ferner „informativ“ sein, indem zum Beispiel aktuelle Tasks, der Stand des Projektes und andere wichtige Informationen vom Arbeitsplatz aus immer gut sichtbar sind. Empfehlenswert ist es hier zum Beispiel, die User-Storys zentral an einer Wand anzubringen.
|
||
</p>
|
||
<div class="thumb tright"><div class="thumbinner" style="width:402px;"><a href="/wiki/Datei:XP-Evolution-Hauptpraktiken.png" class="image"><img alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/1/14/XP-Evolution-Hauptpraktiken.png/400px-XP-Evolution-Hauptpraktiken.png" decoding="async" width="400" height="223" class="thumbimage" srcset="//upload.wikimedia.org/wikipedia/commons/1/14/XP-Evolution-Hauptpraktiken.png 1.5x" data-file-width="415" data-file-height="231" /></a> <div class="thumbcaption"><div class="magnify"><a href="/wiki/Datei:XP-Evolution-Hauptpraktiken.png" class="internal" title="vergrößern und Informationen zum Bild anzeigen"></a></div>Die Hauptpraktiken des evolutionären XPs</div></div></div>
|
||
<p>Das Team ist laut XP wichtiger als die <a href="/wiki/Individuum" title="Individuum">Individuen</a>. Es fällt, im Bewusstsein, nur als Gemeinschaft erfolgreich zu sein, gemeinsame Entscheidungen. Dies wird dadurch gefördert, dass die einzelnen technischen Aktivitäten in der Planung nicht einzelnen Personen, sondern dem Team zugeordnet werden. Probleme löst das Team ohne den Eingriff eines Managers von außen. Mit dem Thema <i>selbstregulierendes Team</i> befasst sich auch der Essay <i><a href="/wiki/Die_Kathedrale_und_der_Basar" title="Die Kathedrale und der Basar">Die Kathedrale und der Basar</a></i>. <i>Pair-Programming</i> mit abwechselnden Partnern soll diese Grundeinstellung weiter fördern.
|
||
</p><p>Die Arbeit soll mit voller Motivation und gleichzeitig in einer entspannten, kollegialen Atmosphäre ablaufen, da die Entwickler ohne Überstunden arbeiten und somit maximale Produktivität erreicht wird. Es werden Sicherheitspuffer einkalkuliert. Nicht einhaltbare Versprechen werden vermieden.
|
||
</p><p>Die zu entwickelnde Funktionalität wird in Form von Storys beschrieben, beispielsweise User-Storys. In wöchentlichem Zyklus wird entschieden, welche Kundenwünsche als Nächstes in Angriff genommen werden. Das Projekt selbst wird in einem quartalsweisen Zyklus geplant. Die vorgegebenen Zyklen sind Richtwerte, deren Größen im täglichen Einsatz variieren können.
|
||
</p><p>Die Software zu <a href="/wiki/Erstellungsprozess" title="Erstellungsprozess">erstellen</a> und alle Testläufe durchzuführen soll in maximal zehn Minuten abgeschlossen sein. Durch diesen <i>10-Minuten-Build</i> werden die Kosten für Erstellung und das Testen der Software minimiert. Alle von einem Entwickler gemachten Änderungen sollten circa alle zwei Stunden bereitgestellt werden. Diese kontinuierliche Integration soll einem potentiellen Chaos vorbeugen, das entstehen könnte, wenn die Entwickler ihre Änderungen und Erweiterungen am Produkt selten in das zentrale Datenhaltungssystem (<a href="/wiki/Repository" title="Repository">Repository</a>) einstellen würden. Alle Mitarbeiter haben so die Änderungen rasch zur Verfügung. Sowohl die zehn Minuten beim Build als auch die zwei Stunden bei der Integration sind Zielvorgaben, die in konkreten Projekten variieren können. Gerade bei großen Projekten mit einer großen Menge an <a href="/wiki/Quelltext" title="Quelltext">Quelltext</a> und Entwicklern wird ein Build deutlich länger dauern, und die Integrationsintervalle werden oft größer sein. Die Praktiken betonen nur die Richtung und geben einen Idealwert vor, der angestrebt werden sollte. Durch Automatisierung lässt sich die Build-Zeit weitestgehend minimieren.
|
||
</p><p>Die Entwicklung ist gekennzeichnet durch den Test-First-Programmieransatz: vor der Realisierung der Funktionalität muss der Test geschrieben werden. Ein inkrementelles Design, das neue Erkenntnisse und Feedback aufnimmt, verbessert das Design der Software stetig.
|
||
</p>
|
||
<h5><span class="mw-headline" id="Begleitpraktiken">Begleitpraktiken</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=22" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Begleitpraktiken">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=22" title="Abschnitt bearbeiten: Begleitpraktiken">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h5>
|
||
<p>Die Begleitpraktiken sind:
|
||
</p>
|
||
<ul><li>richtige Kundeneinbeziehung</li>
|
||
<li>inkrementelles Deployment</li>
|
||
<li>Team-Konstanz</li>
|
||
<li>schrumpfende Teams</li>
|
||
<li>ursachliche Analysen</li>
|
||
<li>geteilter Code</li>
|
||
<li>Codierung und Testen</li>
|
||
<li>eine zentrale <a href="/wiki/Codebasis" title="Codebasis">Codebasis</a></li>
|
||
<li>tägliches Deployment</li>
|
||
<li>verhandelbarer, vertraglicher Funktionsumfang</li>
|
||
<li>Zahlen-pro-Nutzung.</li></ul>
|
||
<p>Der Kunde nimmt aktiv an der Entwicklung teil. Er ist Teilnehmer an den regelmäßigen Treffen und wird aktiv miteinbezogen. Die Einbeziehung zeigt sich auch beim zu entwickelnden Funktionsumfang, der verhandelbar bleiben muss. Mehrere kleinere Verträge anstatt eines großen Vertrags können in derartig betriebenen Projekten Risiken minimieren und die Flexibilität erhöhen. Da iterativ stetig neue Versionen bereitgestellt werden, müssen die <a href="/wiki/Zahlung" title="Zahlung">Zahlungen</a> des Kunden unabhängig von der Anzahl der bereitgestellten Versionen sein. Der Kunde zahlt nicht für jede Version der Software, sondern pro Nutzung.
|
||
</p>
|
||
<div class="thumb tright"><div class="thumbinner" style="width:402px;"><a href="/wiki/Datei:XP-Evolution-Nebenpraktiken.png" class="image"><img alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/8/85/XP-Evolution-Nebenpraktiken.png/400px-XP-Evolution-Nebenpraktiken.png" decoding="async" width="400" height="205" class="thumbimage" srcset="//upload.wikimedia.org/wikipedia/commons/8/85/XP-Evolution-Nebenpraktiken.png 1.5x" data-file-width="408" data-file-height="209" /></a> <div class="thumbcaption"><div class="magnify"><a href="/wiki/Datei:XP-Evolution-Nebenpraktiken.png" class="internal" title="vergrößern und Informationen zum Bild anzeigen"></a></div>Die Nebenpraktiken des evolutionären XPs</div></div></div>
|
||
<p>Das Team soll einerseits von seiner Konstanz leben, kann aber auch personell verkleinert werden. Das Entwicklerteam muss über mehrere Projekte hinweg das gleiche sein. Es erwirbt im Rahmen der Produktentwicklung die Fähigkeiten, als Team zusammenzuarbeiten, welche für weitere Projekte genutzt werden kann. Sobald das Team leistungsstärker und produktiver wird, sollte seine Arbeitslast, trotz einer Verlagerung von Ressourcen zu anderen Teams, konstant bleiben.
|
||
</p><p>Dem Code als dem im Zentrum stehenden Medium kommt eine zentrale Rolle zu. Er wird in einer zentralen, datenbankähnlichen Struktur (<a href="/wiki/Repository" title="Repository">Repository</a>) gehalten. Es existiert nur eine offizielle Version (Codebasis) des Systems. Dieser Code wird, bildlich gesprochen, zwischen den Entwicklern geteilt. Jeder Entwickler im Team muss in der Lage sein, auch „fremden“ Code jederzeit ändern zu können (Collective-Code-Ownership). Neben dem Code existieren immer die Tests, die zusammen mit dem Code die einzigen zu erstellenden, durch die Entwicklungsarbeit bereitgestellten Medien („Artefakte“) sind. Alle anderen Medien, zum Beispiel die Dokumentation, werden allein aus Code und Tests generiert.
|
||
</p><p>Um Schwierigkeiten früh zu identifizieren, wird inkrementelles Deployment (die Überführung der Anwendung auf das Zielsystem) durchgeführt. Wenn <a href="/wiki/Legacy-System" class="mw-redirect" title="Legacy-System">Altsysteme</a> durch neue Software ersetzt werden sollen, muss ein Teil nach dem anderen ersetzt werden. Dieses Vorgehen soll die Umstellung planbarer machen. Das Deployment ist täglich inkrementell durchzuführen. Jeden Tag soll eine neue Version der Software produktiv gestellt werden. Dies macht das Deployment zur Routine, minimiert dessen Kosten und Fehler und ermöglicht stetige Integrations- und Akzeptanztests. Falls einmal ein technisches Fehlverhalten eintritt, muss eine ursächliche Analyse durchgeführt werden.
|
||
</p>
|
||
<h3><span id="Flexibilit.C3.A4tsgrad_vs._Steifheit"></span><span class="mw-headline" id="Flexibilitätsgrad_vs._Steifheit">Flexibilitätsgrad vs. Steifheit</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=23" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Flexibilitätsgrad vs. Steifheit">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=23" title="Abschnitt bearbeiten: Flexibilitätsgrad vs. Steifheit">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Eine der theoretischen Grundlagen des Extreme Programming ist der Flexibilitätsgrad des zu entwickelnden Softwaresystems. XP geht von einem mindestens proportionalen Zusammenhang zwischen dem Gegenteil der Flexibilität, der sogenannten <i>Steifheit</i>, und den Pflegekosten zur Fehlerbehebung oder Erweiterung des Systems aus. Je flexibler ein Softwaresystem, desto geringer sind die Pflegekosten, je steifer, desto höher.
|
||
</p><p>Einige Steifheitskriterien:
|
||
</p>
|
||
<ul><li>Die Anzahl überflüssiger bzw. ungenutzter Merkmale</li>
|
||
<li>Eine schlechte, fehlende, schwer verständliche oder zu umfangreiche Dokumentation</li>
|
||
<li>Ein schwer verständlicher oder unflexibler Entwurf</li>
|
||
<li>Fehlende Regressionstests</li>
|
||
<li>Ein schwerfälliges Gesamtsystem</li></ul>
|
||
<p>Die Flexibilitätskriterien sind das Gegenteil der Steifheitskriterien, zum Beispiel ein leicht verständlicher und flexibler Entwurf.
|
||
</p><p>Einige der als Bestandteil des Extreme Programming definierten Mechanismen dienen laut XP der Erhöhung der Flexibilität:
|
||
</p>
|
||
<ul><li>Die testgetriebene Entwicklung sorgt für ein ausreichendes Vorhandensein von Regressionstests und eine verbesserte <a href="/wiki/Testbarkeit" title="Testbarkeit">Testbarkeit</a> der Software</li>
|
||
<li>Das ständige Refactoring führt zur Fehlerbeseitigung, einem leicht verständlichen und flexiblen Entwurf sowie guter Dokumentation</li>
|
||
<li>Die kontinuierliche Integration erfordert zwangsläufig ein leichtgewichtiges Gesamtsystem</li>
|
||
<li>Um die zu entwickelnde Funktionalität zu bestimmen, und zwischen Kunde und Entwicklungsteam auszuarbeiten, werden User-Storys eingesetzt</li></ul>
|
||
<h2><span class="mw-headline" id="Ursprung_und_Abgrenzung">Ursprung und Abgrenzung</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=24" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Ursprung und Abgrenzung">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=24" title="Abschnitt bearbeiten: Ursprung und Abgrenzung">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h2>
|
||
<p>XP ist ein Vertreter der agilen Softwareentwicklung. Im Vergleich zu traditionellen <a href="/wiki/Vorgehensmodell_zur_Softwareentwicklung" title="Vorgehensmodell zur Softwareentwicklung">Vorgehensmodellen</a> wählt es alternative Ansätze, um Herausforderungen während der Softwareentwicklung zu adressieren.
|
||
</p>
|
||
<h3><span class="mw-headline" id="Traditionelle_Vorgehensmodelle">Traditionelle Vorgehensmodelle</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=25" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Traditionelle Vorgehensmodelle">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=25" title="Abschnitt bearbeiten: Traditionelle Vorgehensmodelle">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>In aus heutiger Sicht <i>traditionellen</i> Vorgehensmodellen ist der Softwareentwicklungsprozess in aufeinanderfolgenden <a href="/wiki/Projektphase" title="Projektphase">Phasen</a> organisiert. Nach Jahren der Anwendung von traditionellen Vorgehensmodellen, wie dem ab 1970 genutzten <a href="/wiki/Wasserfallmodell" title="Wasserfallmodell">Wasserfallmodell</a>, haben es, aus Sicht der XP-Vertreter, Projektverantwortliche nur unzureichend verstanden, die Probleme und Risiken der Softwareentwicklung in den Griff zu bekommen. Viele Projekte kamen nie zu einem Abschluss oder überstiegen zeitlich und/oder kostenmäßig die Planung. Viele, gerade über lange Zeiträume laufende Projekte deckten mit Abschluss zwar die zu Beginn spezifizierten Anforderungen ab, berücksichtigten allerdings unzureichend, dass Anforderungen sich ändern können oder erst im Laufe eines Projektes dem Kunden wirklich klar ist, wie das Endergebnis aussehen soll. Über Erfolg und Schwierigkeiten von Softwareprojekten liefert der <i><a href="/wiki/Chaos-Studie" title="Chaos-Studie">Chaos-Report</a></i> von <i>The Standish Group</i> regelmäßig fundierte Untersuchungen, wie beispielsweise 1994.<sup id="cite_ref-CHAOS_4-0" class="reference"><a href="#cite_note-CHAOS-4">[4]</a></sup>
|
||
</p><p>In Abgrenzung zu traditionellen Vorgehensmodellen durchläuft der Entwicklungsprozess in XP immer wieder iterativ in kurzen Zyklen sämtliche Disziplinen der klassischen Softwareentwicklung (zum Beispiel Anforderungsanalyse, <a href="/wiki/Design" title="Design">Design</a>, <a href="/wiki/Implementierung" title="Implementierung">Implementierung</a>, <a href="/wiki/Test" title="Test">Test</a>). Durch diese inkrementelle Vorgehensweise werden nur die im aktuellen Iterationsschritt benötigten <a href="/wiki/Merkmal" title="Merkmal">Merkmale</a> verwirklicht (implementiert). XP ist dadurch <i>leichtgewichtiger</i>: Es wird keine komplette technische <a href="/wiki/Spezifikation" title="Spezifikation">Spezifikation</a> der zu entwickelnden Lösung vorausgesetzt (so gibt es beispielsweise kein <a href="/wiki/Pflichtenheft" title="Pflichtenheft">Pflichtenheft</a>).
|
||
</p>
|
||
<h3><span class="mw-headline" id="Geschichte_von_XP">Geschichte von XP</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=26" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Geschichte von XP">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=26" title="Abschnitt bearbeiten: Geschichte von XP">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p><i>Extreme Programming</i>, und damit einher <a href="/wiki/Industriestandard" title="Industriestandard">Standards</a> wie JUnit, wurden von <a href="/wiki/Kent_Beck" title="Kent Beck">Kent Beck</a>, <a href="/wiki/Ward_Cunningham" title="Ward Cunningham">Ward Cunningham</a> und <a href="/wiki/Ron_Jeffries" title="Ron Jeffries">Ron Jeffries</a> (allesamt Erstunterzeichner des <a href="/wiki/Agile_Manifesto" class="mw-redirect" title="Agile Manifesto">Agile Manifesto</a>) während ihrer Arbeit im <a href="/wiki/Projekt" title="Projekt">Projekt</a> Comprehensive Compensation System bei <a href="/wiki/Chrysler_Corporation" class="mw-redirect" title="Chrysler Corporation">Chrysler</a> zur Erstellung von Software entwickelt. Die Arbeiten am sogenannten C3-Projekt begannen 1995 und wurden 2000 nach der Übernahme durch Daimler eingestellt. Die dabei entwickelte Software wurde im Bereich der <a href="/wiki/Lohnabrechnung" class="mw-redirect" title="Lohnabrechnung">Lohnabrechnung</a> eingesetzt und basierte hauptsächlich auf <a href="/wiki/Smalltalk_(Programmiersprache)" title="Smalltalk (Programmiersprache)">Smalltalk</a>. Das C3-Projekt wurde ursprünglich nach dem Wasserfallmodell umgesetzt. Nachdem nach knapp einem Jahr kein wesentlicher Fortschritt zu verzeichnen war, wurde der Entwicklungsansatz geändert. Das Projekt zeichnete sich aus durch häufig wechselnde Anforderungen und einer hohen Mitarbeiterfluktuation.<sup id="cite_ref-C3_5-0" class="reference"><a href="#cite_note-C3-5">[5]</a></sup><sup id="cite_ref-C3-XP_6-0" class="reference"><a href="#cite_note-C3-XP-6">[6]</a></sup><sup id="cite_ref-C3-Wiki_7-0" class="reference"><a href="#cite_note-C3-Wiki-7">[7]</a></sup>
|
||
</p><p>XP ist ein agiles Vorgehensmodell. Die folgende Tabelle stellt den von XP identifizierten Kerndisziplinen den historischen, weitverbreiteten Ansatz mitsamt seinen Risiken der Softwareentwicklung gegenüber. Unternehmen, die XP nicht einsetzen, können Vorgehensmodelle verwenden, die sich – bewusst oder unbewusst – mit diesen Disziplinen positiv auseinandersetzen.
|
||
</p>
|
||
<table class="wikitable zebra" style="background:#F0F0FF;">
|
||
<caption>Verbreitete XP-Kerndisziplinen und Risiken bei herkömmlicher Herangehensweise
|
||
</caption>
|
||
<tbody><tr class="hintergrundfarbe8">
|
||
<th>Praktik
|
||
</th>
|
||
<th>Richtiges Vorgehen nach XP
|
||
</th>
|
||
<th>Traditionelles oder falsches Vorgehen/Risiko nach XP
|
||
</th></tr>
|
||
<tr>
|
||
<td>Kommunikation
|
||
</td>
|
||
<td>Stetiger Austausch wird gefördert und erwartet.
|
||
</td>
|
||
<td>Jeder muss zunächst mal seine Aufgaben lösen.
|
||
</td></tr>
|
||
<tr>
|
||
<td>Mut
|
||
</td>
|
||
<td>Offene Atmosphäre.
|
||
</td>
|
||
<td>Angst vor versäumten Terminen und Missverständnissen mit Kunden.
|
||
</td></tr>
|
||
<tr>
|
||
<td>Kollektives Eigentum
|
||
</td>
|
||
<td>Programmcode, Dokumente etc. gehören dem Team.
|
||
</td>
|
||
<td>Jeder fühlt sich nur für seine Artefakte verantwortlich.
|
||
</td></tr>
|
||
<tr>
|
||
<td>Pair-Programming
|
||
</td>
|
||
<td>Zu zweit am Rechner.
|
||
</td>
|
||
<td>Jeder will und muss zunächst auf seine ihm zugewiesenen Aufgaben schauen.
|
||
</td></tr>
|
||
<tr>
|
||
<td>Integration
|
||
</td>
|
||
<td>Stetige Integrationen erlauben Feedback und erhöhen Qualität.
|
||
</td>
|
||
<td>Selten Integrationen, da vermeintlich unnütz und Zeitverschwendung.
|
||
</td></tr>
|
||
<tr>
|
||
<td>Testgetriebene Entwicklung
|
||
</td>
|
||
<td>Testen hat einen hohen Stellenwert.
|
||
</td>
|
||
<td>Testen kostet nur Zeit. Wenige manuelle Tests.
|
||
</td></tr>
|
||
<tr>
|
||
<td>Kundeneinbeziehung
|
||
</td>
|
||
<td>Der Kunde wird zur aktiven Mitarbeit aufgerufen.
|
||
</td>
|
||
<td>Der Kunde ist selten wirklicher Partner, sondern nur die „andere Seite des Vertrages“.
|
||
</td></tr>
|
||
<tr>
|
||
<td>Refactoring
|
||
</td>
|
||
<td>Suboptimales Design und Fehler werden akzeptiert.
|
||
</td>
|
||
<td>Fehler sind verpönt. Erstellte Artefakte laufen angeblich immer direkt perfekt.
|
||
</td></tr>
|
||
<tr>
|
||
<td>Keine Überstunden
|
||
</td>
|
||
<td>Einhaltung der regulären Arbeitszeit.
|
||
</td>
|
||
<td>Stetige, regelmäßige Überschreitung der regulären Arbeitszeit.
|
||
</td></tr>
|
||
<tr>
|
||
<td>Iterationen
|
||
</td>
|
||
<td>Ein Release wird in viele handliche Iterationen unterteilt.
|
||
</td>
|
||
<td>Iterationen sind nicht nötig, es wird an einem Release gearbeitet.
|
||
</td></tr>
|
||
<tr>
|
||
<td>Stand-up-Meeting
|
||
</td>
|
||
<td>Täglicher, strukturierter Austausch.
|
||
</td>
|
||
<td>Große, lange, seltenere Projektmeetings. Die Personenanzahl und der Inhalt sind häufig zu aufgebläht.
|
||
</td></tr>
|
||
<tr>
|
||
<td>Dokumentation
|
||
</td>
|
||
<td>Wo es sinnvoll ist.
|
||
</td>
|
||
<td>Wichtiges Artefakt. Alles muss standardisiert dokumentiert sein. Dokumentation wird aber nicht genutzt.
|
||
</td></tr>
|
||
<tr>
|
||
<td>Metapher
|
||
</td>
|
||
<td>Ein gemeinsames Vokabular.
|
||
</td>
|
||
<td>Kunde und Entwicklung sprechen in zwei Sprachen, häufig aneinander vorbei.
|
||
</td></tr>
|
||
<tr>
|
||
<td>Team
|
||
</td>
|
||
<td>Das Team ist wichtig. Es existieren keine Rollen. Feedback wird von jedem erwartet.
|
||
</td>
|
||
<td>Spezialistentum. Abschottung. Wissensmonopole.
|
||
</td></tr>
|
||
<tr>
|
||
<td>Standards
|
||
</td>
|
||
<td>Standards, wo es sinnvoll erscheint.
|
||
</td>
|
||
<td>Überregulierung. Starrer Prozess.
|
||
</td></tr>
|
||
<tr>
|
||
<td>Qualität
|
||
</td>
|
||
<td>Inhärenter Bestandteil.
|
||
</td>
|
||
<td>Der Faktor, der als erster vernachlässigt wird, wenn Zeit oder Geld knapp werden.
|
||
</td></tr></tbody></table>
|
||
<p>Aufgrund der wachsenden Nutzung wird XP weiter optimiert: je mehr Projekte gemäß XP entwickelt werden, desto mehr Erfahrungen fließen in die Weiterentwicklung von XP ein. Da es auch eine Summe von <a href="/wiki/Best_practice" class="mw-redirect" title="Best practice">Best practices</a> ist, lässt sich somit sagen: „Es wird in der Praxis für die Praxis angepasst“.
|
||
</p>
|
||
<h3><span class="mw-headline" id="Andere_agile_Vorgehensmodelle">Andere agile Vorgehensmodelle</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=27" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Andere agile Vorgehensmodelle">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=27" title="Abschnitt bearbeiten: Andere agile Vorgehensmodelle">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<div class="hauptartikel" role="navigation"><span class="hauptartikel-pfeil" title="siehe" aria-hidden="true" role="presentation">→ </span><i><span class="hauptartikel-text">Hauptartikel</span>: <a href="/wiki/Agile_Softwareentwicklung" title="Agile Softwareentwicklung">Agile Softwareentwicklung</a></i></div>
|
||
<p>Der kleinste gemeinsame Nenner aller agilen Vorgehensmodelle ist das „Agile Manifest“:<sup id="cite_ref-AM_8-0" class="reference"><a href="#cite_note-AM-8">[8]</a></sup>
|
||
</p>
|
||
<ul><li><i>Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen</i></li>
|
||
<li><i>Lauffähige Software hat Vorrang vor ausgedehnter Dokumentation</i></li>
|
||
<li><i>Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen</i></li>
|
||
<li><i>Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung</i></li></ul>
|
||
<p>Neben XP hat auch <a href="/wiki/Scrum" title="Scrum">Scrum</a> einen gewissen Bekanntheitsgrad erlangt. Neben vielen Ähnlichkeiten mit XP gibt Scrum in bestimmten Bereichen Vorgaben bezüglich Iterationslänge, Protokollierung und Verfahren. Scrum nutzt ein eigenes Vokabular.
|
||
</p><p>Eine weitere gerne in diesem Zusammenhang angeführte Disziplin ist das <a href="/wiki/Feature_Driven_Development" title="Feature Driven Development">Feature Driven Development</a>, eine Methodik, die den Schwerpunkt ebenfalls auf die bereitzustellende Funktionalität legt.
|
||
</p><p>Ähnlichkeiten zwischen XP und <a href="/wiki/Kaizen" title="Kaizen">Kaizen</a>, einem in Japan vor allem in der Autoindustrie entwickelten Konzept (<a href="/wiki/Kontinuierlicher_Verbesserungsprozess" title="Kontinuierlicher Verbesserungsprozess">Kontinuierlicher Verbesserungsprozess</a>) zur Sicherung der Qualität im Fertigungsprozess und einer Optimierung der Fertigungs- und Managementkosten mittels „schlankerer“ Ansätze (<a href="/wiki/Schlanke_Produktion" title="Schlanke Produktion">Schlanke Produktion</a>), sind nicht zu übersehen.
|
||
</p><p>Ein weiteres agiles Vorgehensmodell ist <a href="/wiki/Crystal_Family" title="Crystal Family">Crystal</a>, eine Familie von Methoden, deren Mitglieder meist mit Farben gekennzeichnet werden.
|
||
</p><p>Auch traditionelle Vorgehensmodelle, wie das <a href="/wiki/V-Modell_(Entwicklungsstandard)" title="V-Modell (Entwicklungsstandard)">V-Modell</a>, wurden zwischenzeitlich um neue Erkenntnisse in der Softwareentwicklung angereichert. Als Ergebnis bedient sich der Nachfolger, das <i>V-Modell XT</i>, agiler Ansätze. So gibt das V-Modell XT keine strikte Sequenz an zu durchlaufenden Phasen mehr vor.
|
||
</p>
|
||
<h2><span class="mw-headline" id="XP_in_Projekten">XP in Projekten</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=28" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: XP in Projekten">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=28" title="Abschnitt bearbeiten: XP in Projekten">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h2>
|
||
<p>Heute, über zehn Jahre nach den ersten XP-Schritten, erfreuen sich XP und andere agile Methoden wachsender Beliebtheit. Untersuchungen von „Forrester Research“ ergaben, dass in Nordamerika und Europa 2005 circa 14 % aller Projekte mit agilen Methoden durchgeführt wurden<sup id="cite_ref-FOR_9-0" class="reference"><a href="#cite_note-FOR-9">[9]</a></sup> (von denen XP die verbreitetste ist) und viele andere einen Einsatz prüfen.
|
||
</p><p>Zu den Nutzern XPs zählen sowohl Unternehmen, die kommerziell Software herstellen und vertreiben, als auch Unternehmen, deren eigentliches Geschäft nicht die Erstellung von Software ist: <i>Dresdner Kleinwort Wasserstein</i>, <i><a href="/wiki/Encyclopaedia_Britannica" class="mw-redirect" title="Encyclopaedia Britannica">Encyclopaedia Britannica</a></i>, <i>Fidelity</i>, <i>Progressive</i>, <i>Capital One</i>, <i>Royal & Sunalliance</i>, <i>Channel One</i>, <i>Daedalos International</i>, <i>Gemplus</i>, <i>it-agile</i>, <i>Qwest</i> und <i>O&O Services</i>.<sup id="cite_ref-C2COMPDOINGXP_10-0" class="reference"><a href="#cite_note-C2COMPDOINGXP-10">[10]</a></sup><sup id="cite_ref-OMCOMPDOINGXP_11-0" class="reference"><a href="#cite_note-OMCOMPDOINGXP-11">[11]</a></sup>
|
||
</p><p>Viele Unternehmen berichten öffentlich von ihren Erfahrungen mit XP. Sie schildern, wie sie XP im Detail eingesetzt haben, welche Schwierigkeiten dabei auftraten und wie der Erfolg einzuschätzen war. <i><a href="/wiki/NortonLifeLock" title="NortonLifeLock">Symantec</a></i> hat seine Änderung des Vorgehensmodells hin zu XP publiziert.<sup id="cite_ref-SYMANTEC_12-0" class="reference"><a href="#cite_note-SYMANTEC-12">[12]</a></sup> <i>Sabre Airline Solutions</i> hat mit XP sowohl die Fehler in ihrer Software als auch die Entwicklungszeit reduziert:<sup id="cite_ref-SABRE_13-0" class="reference"><a href="#cite_note-SABRE-13">[13]</a></sup>
|
||
</p>
|
||
<div class="Vorlage_Zitat" style="margin:1em 40px;">
|
||
<div style="margin:1em 0;"><blockquote lang="en" style="margin:0;">
|
||
<p>“It was XP […] that produced the dramatic quality improvements […] You have the weaker people paired with the stronger people, and business knowledge and coding knowledge are transferred very quickly.”
|
||
</p>
|
||
</blockquote>
|
||
</div><div class="cite" style="margin:-1em 0 1em 1em;">– <span class="Person">Gary Anthes</span><sup id="cite_ref-SABRE_13-1" class="reference"><a href="#cite_note-SABRE-13">[13]</a></sup></div></div>
|
||
<h2><span class="mw-headline" id="Kritik">Kritik</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=29" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Kritik">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=29" title="Abschnitt bearbeiten: Kritik">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h2>
|
||
<div class="hintergrundfarbe1 rahmenfarbe1 navigation-not-searchable noprint Vorlage_Belege_fehlen hatnote" style="border-style: solid; border-width: 1px; clear: left; margin-bottom:1em; margin-top:1em; padding: 0.25em; overflow: hidden; word-break: break-word; word-wrap: break-word;"><div class="noviewer nomobile" style="display: table-cell; padding-bottom: 0.2em; padding-left: 0.25em; padding-right: 1em; padding-top: 0.2em; vertical-align: middle;" aria-hidden="true" role="presentation"><a href="/wiki/Wikipedia:Belege" title="Belege"><img alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/b/b7/Qsicon_Quelle.svg/24px-Qsicon_Quelle.svg.png" decoding="async" width="24" height="24" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/b/b7/Qsicon_Quelle.svg/36px-Qsicon_Quelle.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/b/b7/Qsicon_Quelle.svg/48px-Qsicon_Quelle.svg.png 2x" data-file-width="24" data-file-height="24" /></a></div>
|
||
<div style="display: table-cell; vertical-align: middle; width: 100%;">
|
||
<div>
|
||
Dieser Artikel oder nachfolgende Abschnitt ist nicht hinreichend mit <a href="/wiki/Wikipedia:Belege" title="Wikipedia:Belege">Belegen</a> (beispielsweise <a href="/wiki/Hilfe:Einzelnachweise" title="Hilfe:Einzelnachweise">Einzelnachweisen</a>) ausgestattet. Angaben ohne ausreichenden Beleg könnten demnächst entfernt werden. Bitte hilf Wikipedia, indem du die Angaben recherchierst und <span style="white-space:nowrap">gute Belege einfügst.</span><br /><span class="editoronly" style="display:none;"></span></div>
|
||
</div></div>
|
||
<h3><span class="mw-headline" id="Das_Alles-oder-Nichts-Prinzip">Das Alles-oder-Nichts-Prinzip</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=30" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Das Alles-oder-Nichts-Prinzip">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=30" title="Abschnitt bearbeiten: Das Alles-oder-Nichts-Prinzip">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Gemäß einigen Protagonisten des XP-Ansatzes wirken die einzelnen Methoden so eng zusammen, dass diese ohne Ausnahme eingesetzt werden sollen. Bereits der Verzicht auf einzelne Methoden soll die Wirksamkeit des Gesamtansatzes massiv einschränken. Da jedoch der Einsatz der Methoden oftmals auf zahlreichen Voraussetzungen basiert (siehe z. B. die Abschnitte <a href="#Der_ideale_Kunde">Der ideale Kunde</a> und <a href="#Der_ideale_Programmierer">Der ideale Programmierer</a>), ist es wahrscheinlich, dass in konkreten Projekten einzelne Methoden eben gerade nicht angewandt werden können. Das liefert dann auch auf einfache Weise eine Erklärung für das Scheitern von XP-Projekten: Meist dürfte sich eine vernachlässigte Methode finden lassen, so dass das Scheitern nicht auf XP als Gesamtansatz, sondern auf die Vernachlässigung dieser Methode zurückgeführt werden kann. Mittlerweile ist es umstritten, ob tatsächlich alle Methoden angewendet werden müssen, um durch XP die Wahrscheinlichkeit auf einen erfolgreichen Projektverlauf zu erhöhen.
|
||
</p>
|
||
<h3><span class="mw-headline" id="Bewegliche_Anforderungen">Bewegliche Anforderungen</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=31" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Bewegliche Anforderungen">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=31" title="Abschnitt bearbeiten: Bewegliche Anforderungen">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Ein Hauptgrund für die Spezifikation von Anforderungen besteht bei klassischen Vorgehensmodellen in der Schaffung einer verlässlichen Basis für die Entwicklungsarbeit, so dass später notwendige Änderungen an der Realisierung möglichst gering bleiben. Die implizite Annahme dieser Haltung ist, dass Änderungen umso teurer werden, je später sie durchgeführt werden müssen. Obwohl sich diese Annahme in vielen Projekten bestätigt hat, geht XP gewissermaßen davon aus, dass Änderungen grundsätzlich „billig“ sind, wenn man sie kontinuierlich durchführt. Auch verneint XP implizit die Annahme, dass spätere Änderungen teurer werden, und begründet dies damit, dass die Änderungen dann nicht – wie in anderen Ansätzen – in mehreren Artefakten zugleich (Spezifikation, Dokumentation, Quellcode) umgesetzt werden müssen.
|
||
</p><p>Die diesbezüglichen Annahmen von XP treffen sicher dann zu, wenn die Anforderungen <i>unvermeidlich</i> Änderungen unterworfen sein werden. In diesem Fall kann eine Spezifikation der Anforderungen unter Umständen größeren Aufwand nach sich ziehen als das Auslassen der Spezifikation – schon allein deswegen, weil die Spezifikation immer mitgeändert werden muss. Es ist jedoch unklar, warum es schädlich sein sollte, Anforderungen zumindest dann zu spezifizieren, wenn sie mit einiger Sicherheit bis zum Projektende Bestand haben werden. Durch den Verzicht auf eine Spezifikation läuft man Gefahr, Anforderungen zu übersehen oder hinsichtlich ihrer Bedeutung falsch einzuschätzen. Auch ist denkbar, dass der Kunde im Projektverlauf seine Anforderungen bewusst ändert, jedoch gegenüber dem Entwicklungsteam bekundet, seine Auffassung sei bislang nur falsch verstanden worden. Hinsichtlich der Einschätzung, dass spätere Änderungen nicht teurer sind als frühe, ist einzuwenden, dass späte Änderungen dann sehr teuer sein können, wenn sie das Design der Anwendung in grundlegender Weise betreffen. So ist die Änderung der Architektur einer Anwendung nicht ohne erheblichen Aufwand durchzuführen, ja sie kann ggf. teurer sein als eine Neuimplementierung. Es ist nicht ersichtlich und erscheint daher als eine Glaubensfrage, ob XP durch den Einsatz seiner Methoden derartige Situationen verhindern kann.
|
||
</p>
|
||
<h3><span class="mw-headline" id="Der_ideale_Kunde">Der ideale Kunde</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=32" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Der ideale Kunde">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=32" title="Abschnitt bearbeiten: Der ideale Kunde">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Der Einsatz von XP verlangt einen experimentierfreudigen Kunden, der nicht nur auf eine Reihe von üblichen Vorgehensweisen verzichten, sondern zudem selbst erhebliche Ressourcen aufwenden muss. Zu den Aspekten, auf die ein Kunde ungern verzichtet, gehören:
|
||
</p>
|
||
<dl><dt>Dokumentation</dt>
|
||
<dd>Software kann in komplexen <a href="/wiki/Systemlandschaft" title="Systemlandschaft">Systemlandschaften</a> eingeführt werden, so dass unterschiedlichste Beteiligte (z. B. Schnittstellenverantwortliche, Mitarbeiter von externen Providern usw.) Kenntnis von technischen Details erlangen müssen. In solchen Umgebungen verbieten meist schon die Firmenrichtlinien den Verzicht auf eine ausführliche Dokumentation. Aber selbst wenn dies nicht der Fall ist, bleibt zu klären, wie die Kenntnisse über technische Details an die Betroffenen vermittelt werden sollen, wenn keine Dokumentation existiert, und mehr noch, wenn davon ausgegangen werden muss, dass künftige Änderungen die relevanten technischen Einzelheiten betreffen.</dd>
|
||
<dt>Spezifikation</dt>
|
||
<dd>Insbesondere beim Abschluss von Werkverträgen stellt sich für den Kunden die Frage, worin präzise eigentlich das Gewerk besteht, das durch den vereinbarten Preis erworben wird. Des Weiteren können firmenweite Richtlinien die Erstellung einer Spezifikation verlangen.</dd>
|
||
<dt>Termine</dt>
|
||
<dd>Da der projektleitende Vertreter des Kunden oftmals selbst den Projektfortschritt berichten muss, stellt die Fertigstellung bestimmter Funktionen zu festgelegten Terminen, somit also die Aufstellung eines Projektplans, oftmals einen unverzichtbaren Bestandteil der gemeinsamen Vorgehensweise dar.</dd></dl>
|
||
<p>Über diese Punkte hinaus stellt das „Kunde vor Ort“-Prinzip eine Anforderung dar, die in der Realität nur äußerst selten umsetzbar ist. Um seine Aufgabe erfüllen zu können, muss der Mitarbeiter offensichtlich über einen erheblichen Wissensumfang verfügen. Ist dies aber der Fall, so ist der Mitarbeiter sehr wahrscheinlich auch in seinem eigenen Unternehmen nicht für mehrere Monate entbehrlich. Nicht selten werden IT-Projekte zudem gerade deshalb an externe Dienstleister vergeben, um den eigenen Ressourcenaufwand zu beschränken. Das Kunde-vor-Ort-Prinzip stellt somit eine der am schwierigsten erfüllbaren Anforderungen des Extreme Programming dar.
|
||
</p>
|
||
<h3><span class="mw-headline" id="Der_ideale_Programmierer">Der ideale Programmierer</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=33" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Der ideale Programmierer">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=33" title="Abschnitt bearbeiten: Der ideale Programmierer">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>XP stellt zahlreiche Anforderungen an die beteiligten Programmierer.
|
||
</p>
|
||
<ul><li>Die Programmierer müssen über sehr gute Fähigkeiten verfügen, da der auf häufigen Änderungen basierende Ansatz unter Verwendung von Refactorings nicht ohne umfangreiche Programmiererfahrung und ohne den Einsatz von dafür geeigneten Werkzeugen realisiert werden kann.</li>
|
||
<li>Programmierer weisen oftmals ein recht ausgeprägtes Ego auf, das sich in großer Überzeugung von „richtigen Lösungen“ und einem gewissen Besitzdenken hinsichtlich des geschriebenen Codes äußert. Nicht alle Programmierer können damit umgehen, dass – gemäß XP – jeder den Code aller anderen modifizieren darf.</li>
|
||
<li>XP weist eine Reihe von Merkmalen auf, die hohe Disziplin erfordern (wie z. B. der Test-first-Ansatz, das permanente Durchführen von Refactorings, Programmieren in Paaren usw.), und einige andere, die eine gewisse Disziplinlosigkeit fördern (z. B. das Auslassen von Spezifikation und Dokumentation). Es besteht die Gefahr, dass die letzteren Ansätze gegenüber den Ersteren betont werden. Die Einhaltung der Ansätze mit hoher Disziplin erfordert fähige Beteiligte und eine funktionierende Selbstregulierung des Teams. Da aber unter Umständen kein Projektverantwortlicher benannt wurde, fragt sich, wer letztlich für die konsequente Einhaltung aller Aspekte sorgt.</li></ul>
|
||
<p>Die Anforderungen zeigen, dass XP nicht auf beliebige Teams angewandt werden kann.
|
||
</p>
|
||
<h3><span id="Beschr.C3.A4nkte_Team-_und_damit_Projektgr.C3.B6.C3.9Fe"></span><span class="mw-headline" id="Beschränkte_Team-_und_damit_Projektgröße">Beschränkte Team- und damit Projektgröße</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=34" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Beschränkte Team- und damit Projektgröße">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=34" title="Abschnitt bearbeiten: Beschränkte Team- und damit Projektgröße">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Mehrere XP-Methoden erfordern einen hohen Grad an gegenseitiger Informiertheit und somit ein hohes Maß an Kommunikation zwischen den Beteiligten. So bedingt das kontinuierliche Refactoring unter Umständen Änderungen gemeinsam genutzter Komponenten, über die möglichst das gesamte Team unterrichtet sein muss. Das Fehlen eines Projektmanagers erfordert gemeinsame Absprachen zur Arbeitsteilung. Da zudem eine präzise Spezifikation und Dokumentation fehlt, müssen alle Informationen zur Umsetzung in den Köpfen der Beteiligten verfügbar sein. Mit der Größe des Teams steigt jedoch der Kommunikationsaufwand quadratisch an, so dass XP-Projekten eine natürliche Grenze hinsichtlich der Teamgröße gesetzt ist. Die maximale Größe wird gemeinhin bei zehn Teammitgliedern angesetzt.
|
||
</p>
|
||
<h3><span id="Fehlende_Eignung_f.C3.BCr_Festpreisprojekte"></span><span class="mw-headline" id="Fehlende_Eignung_für_Festpreisprojekte">Fehlende Eignung für Festpreisprojekte</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=35" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Fehlende Eignung für Festpreisprojekte">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=35" title="Abschnitt bearbeiten: Fehlende Eignung für Festpreisprojekte">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Ein weiterer häufiger Kritikpunkt ist, dass XP für <a href="/wiki/Festpreis" title="Festpreis">Festpreisprojekte</a> nicht geeignet sei. Da der Kunde einen festen Preis zahlt, muss der Auftragnehmer in irgendeiner Form sicherstellen, dass er für diesen Preis auch nur eine festgelegte Leistung erbringen muss. Die Leistungserbringung so lange bis der Kunde zufrieden ist, kann in immer neuen Kundenanforderungen münden, so dass die Aufwände für die Realisierung nicht abzusehen sind. Die Festlegung der Festleistung als Inhalt des Werkvertrages entspräche jedoch einer Spezifikation und ist somit in XP verpönt. Es gibt einige Ansätze, XP dennoch mit Festpreisprojekten kompatibel zu machen:
|
||
</p>
|
||
<ul><li>Versicherungsprämien auf die Schätzung</li>
|
||
<li>User-Storys (bzw. die Story-Cards) werden zum Vertragsgegenstand</li>
|
||
<li>besondere Preismodelle wie <i>Aufwandspreis mit Obergrenze</i>, <i>Phasenfestpreis</i> oder <i>Anforderungseinheitspreis</i>.</li></ul>
|
||
<p>Die Wirksamkeit dieser Ansätze ist jedoch unklar. User-Storys können zu unpräzise sein, um das Gewerk gegen unerwartete technische Anforderungen abzusichern. Die angesprochenen Preismodelle entsprechen nur noch bedingt einem Festpreis und damit Werkvertrag, so dass fraglich ist, ob ein Kunde mit der Vorgabe eines Festpreises darauf eingehen würde. Selbiges gilt auch für Versicherungsprämien.
|
||
</p>
|
||
<h3><span class="mw-headline" id="Feste_Fertigstellungstermine">Feste Fertigstellungstermine</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=36" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Feste Fertigstellungstermine">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=36" title="Abschnitt bearbeiten: Feste Fertigstellungstermine">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Die iterative Vorgehensweise von XP und der fehlende Projektplan legen bereits nahe, dass die Fertigstellung eines fachlich gewünschten Funktionsumfangs zu einem gesetzten Termin nicht ohne weiteres garantiert werden kann. Zwar wird zu dem gesetzten Termin <i>etwas</i> fertig sein (da der Fokus jeder Iteration auf einer ausführbaren, ggf. sogar produktionsfähigen Software liegt), welche fachlichen Aspekte dies jedoch tatsächlich sind, kann nicht vorherbestimmt werden – umso weniger als Überstunden verpönt sind und das Ausmaß nötiger Refactorings auf Grund beweglicher Anforderungen nur schwer abgeschätzt werden kann.
|
||
</p>
|
||
<h3><span class="mw-headline" id="Einsatz_in_verteilten_Umgebungen">Einsatz in verteilten Umgebungen</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=37" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Einsatz in verteilten Umgebungen">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=37" title="Abschnitt bearbeiten: Einsatz in verteilten Umgebungen">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>XP gilt in verteilten Umgebungen als schwerer einsetzbar als herkömmliche Modelle. Der direkte Kontakt der Entwickler untereinander und zum Kunden ist problematisch, falls verschiedene Kunden existieren oder die Beteiligten räumlich getrennt arbeiten, so zum Beispiel bei teilweise ausgelagerten Entwicklungen (<a href="/wiki/Outsourcing" title="Outsourcing">Outsourcing</a>).
|
||
</p>
|
||
<h3><span class="mw-headline" id="Kritik_an_einzelnen_Praktiken">Kritik an einzelnen Praktiken</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=38" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Kritik an einzelnen Praktiken">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=38" title="Abschnitt bearbeiten: Kritik an einzelnen Praktiken">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Die stets erneute Erstellung von Testfällen und die automatisierte, permanente Ausführung der Tests kann in komplexen oder <a href="/wiki/Nebenl%C3%A4ufigkeit" title="Nebenläufigkeit">nebenläufigen</a> Anwendungen und <a href="/wiki/Verteiltes_System" title="Verteiltes System">verteilten Systemen</a> aufwändig sein. Wenn sich keine Rollen ausbilden, muss jeder alles wissen, statt einzelne Schwerpunkte im Team zu setzen (klassisches Beispiel: GUI-Entwicklung und Datenbank-Entwicklung), was die Gesamtleistung des Teams vermindern kann.
|
||
</p>
|
||
<h3><span class="mw-headline" id="Personalpolitik">Personalpolitik</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=39" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Personalpolitik">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=39" title="Abschnitt bearbeiten: Personalpolitik">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h3>
|
||
<p>Da das Team im Vordergrund steht, dürfen einzelne Entwickler nicht nach dem Umfang ihrer entwickelten Funktionalität honoriert werden. Insbesondere der Honorarvertrag ist kein geeignetes Vergütungsmodell bei Anwendung des Vorgehensmodells der XP.
|
||
</p>
|
||
<h2><span class="mw-headline" id="Siehe_auch">Siehe auch</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=40" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Siehe auch">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=40" title="Abschnitt bearbeiten: Siehe auch">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h2>
|
||
<ul><li><a href="/wiki/Crystal_Family" title="Crystal Family">Crystal</a>, agiles Vorgehensmodell</li>
|
||
<li><a href="/wiki/Scrum" title="Scrum">Scrum</a>, agiles Vorgehensmodell, das gut mit XP harmoniert<sup id="cite_ref-Scrum_and_XP_14-0" class="reference"><a href="#cite_note-Scrum_and_XP-14">[14]</a></sup></li></ul>
|
||
<h2><span class="mw-headline" id="Literatur">Literatur</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=41" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Literatur">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=41" title="Abschnitt bearbeiten: Literatur">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h2>
|
||
<ul><li><a href="/wiki/Kent_Beck" title="Kent Beck">Kent Beck</a>: <i>Extreme Programming Explained, Embrace Change.</i> Addison-Wesley, 1999, <a href="/wiki/Spezial:ISBN-Suche/0201616416" class="internal mw-magiclink-isbn">ISBN 0-201-61641-6</a> (2. Auflage, 2004, <a href="/wiki/Spezial:ISBN-Suche/0321278658" class="internal mw-magiclink-isbn">ISBN 0-321-27865-8</a>).</li>
|
||
<li>Kent Beck: <i>Extreme Programming, Das Manifest.</i> Addison-Wesley, 2000, <a href="/wiki/Spezial:ISBN-Suche/3827317096" class="internal mw-magiclink-isbn">ISBN 3-8273-1709-6</a>. (deutsche Übersetzung)</li>
|
||
<li>The XP Series:
|
||
<ul><li>Kent Beck, <a href="/wiki/Martin_Fowler" title="Martin Fowler">Martin Fowler</a>: <i>Planning Extreme Programming.</i> Addison-Wesley, 2000, <a href="/wiki/Spezial:ISBN-Suche/0201710919" class="internal mw-magiclink-isbn">ISBN 0-201-71091-9</a>.</li>
|
||
<li><a href="/wiki/Ron_Jeffries" title="Ron Jeffries">Ron Jeffries</a> et al.: <i>Extreme Programming Installed.</i> Addison-Wesley, 2000, <a href="/wiki/Spezial:ISBN-Suche/0201708426" class="internal mw-magiclink-isbn">ISBN 0-201-70842-6</a>.</li>
|
||
<li>Giancarlo Succi, Michele Marchesi: <i>Extreme Programming Examined.</i> Addison-Wesley, 2001, <a href="/wiki/Spezial:ISBN-Suche/0201710404" class="internal mw-magiclink-isbn">ISBN 0-201-71040-4</a>.</li>
|
||
<li>James Newkirk, <a href="/wiki/Robert_C._Martin" class="mw-redirect" title="Robert C. Martin">Robert C. Martin</a>: <i>Extreme Programming in Practice.</i> Addison-Wesley, 2001, <a href="/wiki/Spezial:ISBN-Suche/0201709376" class="internal mw-magiclink-isbn">ISBN 0-201-70937-6</a>.</li>
|
||
<li>William C. Wake: <i>Extreme Programming Explored.</i> Addison-Wesley, 2001, <a href="/wiki/Spezial:ISBN-Suche/0201733978" class="internal mw-magiclink-isbn">ISBN 0-201-73397-8</a>.</li>
|
||
<li>Ken Auer, Roy Miller: <i>Extreme Programming Applied.</i> Addison-Wesley, 2001, <a href="/wiki/Spezial:ISBN-Suche/0201616408" class="internal mw-magiclink-isbn">ISBN 0-201-61640-8</a>.</li>
|
||
<li>Pete McBreen: <i>Questioning Extreme Programming.</i> Addison-Wesley, 2002, <a href="/wiki/Spezial:ISBN-Suche/0201616408" class="internal mw-magiclink-isbn">ISBN 0-201-61640-8</a>.</li>
|
||
<li>Giancarlo Succi et al.: <i>Extreme Programming Perspectives.</i> Addison-Wesley, 2002, <a href="/wiki/Spezial:ISBN-Suche/0201770059" class="internal mw-magiclink-isbn">ISBN 0-201-77005-9</a>.</li>
|
||
<li>Doug Wallace et al.: <i>Extreme Programming for Web Projects.</i> Addison-Wesley, 2002, <a href="/wiki/Spezial:ISBN-Suche/0201794276" class="internal mw-magiclink-isbn">ISBN 0-201-79427-6</a>.</li>
|
||
<li>Lisa Crispin, Tip House: <i>Testing Extreme Programming.</i> Addison-Wesley, 2002, <a href="/wiki/Spezial:ISBN-Suche/0321113551" class="internal mw-magiclink-isbn">ISBN 0-321-11355-1</a>.</li></ul></li>
|
||
<li>Scott W. Ambler: <i>Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process.</i> Wiley, John & Sons, 2002, <a href="/wiki/Spezial:ISBN-Suche/0471202827" class="internal mw-magiclink-isbn">ISBN 0-471-20282-7</a>.</li>
|
||
<li>Ron Jeffries: <i>Extreme Programming Adventures in C#.</i> Microsoft Press, 2004, <a href="/wiki/Spezial:ISBN-Suche/0735619492" class="internal mw-magiclink-isbn">ISBN 0-7356-1949-2</a>.</li>
|
||
<li>Henning Wolf et al.: <i>eXtreme Programming, Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis.</i> dpunkt, 2. Auflage, 2005, <a href="/wiki/Spezial:ISBN-Suche/3898643395" class="internal mw-magiclink-isbn">ISBN 3-89864-339-5</a>.</li></ul>
|
||
<h2><span class="mw-headline" id="Weblinks">Weblinks</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=42" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Weblinks">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=42" title="Abschnitt bearbeiten: Weblinks">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h2>
|
||
<p>Deutsch
|
||
</p>
|
||
<ul><li><a rel="nofollow" class="external text" href="http://chaosradio.ccc.de/cre028.html">Podcast zum Thema Extreme Programming</a> vom <a href="/wiki/Chaosradio" title="Chaosradio">Chaosradio Express</a></li>
|
||
<li><a rel="nofollow" class="external text" href="http://www.zeit.de/2004/01/T-Extremprogrammierer?page=all">Artikel</a> aus <a href="/wiki/Die_Zeit" title="Die Zeit">Die Zeit</a></li>
|
||
<li><a rel="nofollow" class="external text" href="https://web.archive.org/web/20170808203625/http://www4.in.tum.de/publ/papers/Rum01.pdf">Extreme Programming – Back to Basics?</a> (<a href="/wiki/Web-Archivierung#Begrifflichkeiten" title="Web-Archivierung"><span style="color:#303030!important">Memento</span></a> vom 8. August 2017 im <i><a href="/wiki/Internet_Archive" title="Internet Archive">Internet Archive</a></i>) (PDF, 110 KiB)</li>
|
||
<li><a rel="nofollow" class="external text" href="http://www.frankwestphal.de/ExtremeProgramming.html">Was ist Extreme Programming?</a> – von Frank Westphal</li>
|
||
<li><a rel="nofollow" class="external text" href="https://web.archive.org/web/20130318232214/http://www.little-idiot.de/his/t1.htm">OpenSource Entwicklung und ihre Dynamiken</a> (<a href="/wiki/Web-Archivierung#Begrifflichkeiten" title="Web-Archivierung"><span style="color:#303030!important">Memento</span></a> vom 18. März 2013 im <i><a href="/wiki/Internet_Archive" title="Internet Archive">Internet Archive</a></i>) (mit Kapiteln über Agile Methoden und XP)</li></ul>
|
||
<p>Englisch
|
||
</p>
|
||
<ul><li><a rel="nofollow" class="external text" href="https://www.agilealliance.org/">Agile Alliance</a></li>
|
||
<li><a rel="nofollow" class="external text" href="http://www.extremeprogramming.org/">Extreme Programming: A gentle introduction.</a></li>
|
||
<li><a rel="nofollow" class="external text" href="http://www.xprogramming.com/">XP</a> (Ron Jeffries)</li>
|
||
<li><a rel="nofollow" class="external text" href="http://www.c2.com/cgi/wiki?ExtremeProgramming">XP</a> (Ward Cunningham)</li>
|
||
<li><a rel="nofollow" class="external text" href="http://www.martinfowler.com/articles/newMethodology.html">XP-The New Methodology</a> (Martin Fowler)</li></ul>
|
||
<p>Fachkonferenzen zum Thema
|
||
</p>
|
||
<ul><li><a rel="nofollow" class="external text" href="http://www.xpdays.de/">XP Days Deutschland</a>, die jährliche XP-Konferenz in Deutschland</li></ul>
|
||
<h2><span class="mw-headline" id="Einzelnachweise">Einzelnachweise</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/w/index.php?title=Extreme_Programming&veaction=edit&section=43" class="mw-editsection-visualeditor" title="Abschnitt bearbeiten: Einzelnachweise">Bearbeiten</a><span class="mw-editsection-divider"> | </span><a href="/w/index.php?title=Extreme_Programming&action=edit&section=43" title="Abschnitt bearbeiten: Einzelnachweise">Quelltext bearbeiten</a><span class="mw-editsection-bracket">]</span></span></h2>
|
||
<ol class="references">
|
||
<li id="cite_note-MARC-1"><span class="mw-cite-backlink"><a href="#cite_ref-MARC_1-0">↑</a></span> <span class="reference-text">Tom DeMarco, Timothy Lister: <i>Bärentango</i>, Hanser Fachbuch, März 2003, <a href="/wiki/Spezial:ISBN-Suche/3446223339" class="internal mw-magiclink-isbn">ISBN 3-446-22333-9</a>.</span>
|
||
</li>
|
||
<li id="cite_note-BECK1-2"><span class="mw-cite-backlink"><a href="#cite_ref-BECK1_2-0">↑</a></span> <span class="reference-text">Kent Beck: <i>Extreme Programming Explained. Embrace Change</i>. 1st Edition, Addison-Wesley, 2000, <a href="/wiki/Spezial:ISBN-Suche/0201616416" class="internal mw-magiclink-isbn">ISBN 0-201-61641-6</a>.</span>
|
||
</li>
|
||
<li id="cite_note-BECK2-3"><span class="mw-cite-backlink"><a href="#cite_ref-BECK2_3-0">↑</a></span> <span class="reference-text">Kent Beck, Cynthia Andres: <i>Extreme Programming Explained. Embrace Change</i>. 2nd Edition, Addison-Wesley, Dezember 2004, <a href="/wiki/Spezial:ISBN-Suche/0321278658" class="internal mw-magiclink-isbn">ISBN 0-321-27865-8</a>.</span>
|
||
</li>
|
||
<li id="cite_note-CHAOS-4"><span class="mw-cite-backlink"><a href="#cite_ref-CHAOS_4-0">↑</a></span> <span class="reference-text">The Standish Group: <i><span class="cite"><a rel="nofollow" class="external text" href="https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf"><i>The CHAOS Report (1994).</i></a><span class="Abrufdatum"> Abgerufen am 12. Januar 2020</span>.</span><span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3AExtreme+Programming&rft.title=The+CHAOS+Report+%281994%29&rft.description=The+CHAOS+Report+%281994%29&rft.identifier=https%3A%2F%2Fwww.standishgroup.com%2Fsample_research_files%2Fchaos_report_1994.pdf"> </span></i> (englisch), 12. Juni 2006.</span>
|
||
</li>
|
||
<li id="cite_note-C3-5"><span class="mw-cite-backlink"><a href="#cite_ref-C3_5-0">↑</a></span> <span class="reference-text">Chrysler Comprehensive Compensation System: <a rel="nofollow" class="external text" href="https://web.archive.org/web/20150113174308/http://www.xprogramming.com/publications/dc9810cs.pdf"><i>Chrysler Goes To Extremes</i></a> (<a href="/wiki/Web-Archivierung#Begrifflichkeiten" title="Web-Archivierung"><span style="color:#303030!important">Memento</span></a> vom 13. Januar 2015 im <i><a href="/wiki/Internet_Archive" title="Internet Archive">Internet Archive</a></i>) (PDF, englisch; 188 kB), 9. Juni 2006.</span>
|
||
</li>
|
||
<li id="cite_note-C3-XP-6"><span class="mw-cite-backlink"><a href="#cite_ref-C3-XP_6-0">↑</a></span> <span class="reference-text">Chrysler Comprehensive Compensation System: <i><a rel="nofollow" class="external text" href="http://www.agileconnection.com/sites/default/files/article/file/2012/XDD3248filelistfilename1_0.pdf">Extreme Programming Considered Harmful for Reliable Software Development</a></i> (PDF, englisch), 6. Februar 2002.</span>
|
||
</li>
|
||
<li id="cite_note-C3-Wiki-7"><span class="mw-cite-backlink"><a href="#cite_ref-C3-Wiki_7-0">↑</a></span> <span class="reference-text">Chrysler Comprehensive Compensation: <i><a rel="nofollow" class="external text" href="http://c2.com/cgi/wiki?ChryslerComprehensiveCompensation">Project to replace existing payroll applications with a single application.</a></i> (englisch), 16. Oktober 2013.</span>
|
||
</li>
|
||
<li id="cite_note-AM-8"><span class="mw-cite-backlink"><a href="#cite_ref-AM_8-0">↑</a></span> <span class="reference-text">Ward Cunningham, Kent Beck et al.: <i><a rel="nofollow" class="external text" href="http://www.agilemanifesto.org/">Manifesto for Agile Software Development</a></i> (englisch), 2001.</span>
|
||
</li>
|
||
<li id="cite_note-FOR-9"><span class="mw-cite-backlink"><a href="#cite_ref-FOR_9-0">↑</a></span> <span class="reference-text">Forrester Research: <i> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20071016155709/http://www.forrester.com/Research/Document/Excerpt/0,7211,38334,00.html">Corporate IT Leads The Second Wave Of Agile Adoption</a> (<a href="/wiki/Web-Archivierung#Begrifflichkeiten" title="Web-Archivierung"><span style="color:#303030!important">Memento</span></a> vom 16. Oktober 2007 im </i><a href="/wiki/Internet_Archive" title="Internet Archive">Internet Archive</a><i>)</i> (englisch), 30. November 2005.</span>
|
||
</li>
|
||
<li id="cite_note-C2COMPDOINGXP-10"><span class="mw-cite-backlink"><a href="#cite_ref-C2COMPDOINGXP_10-0">↑</a></span> <span class="reference-text">C2: <i><a rel="nofollow" class="external text" href="http://www.c2.com/cgi/wiki?CompaniesDoingXp">Companies Doing Xp</a></i> (englisch), 23. Juli 2006.</span>
|
||
</li>
|
||
<li id="cite_note-OMCOMPDOINGXP-11"><span class="mw-cite-backlink"><a href="#cite_ref-OMCOMPDOINGXP_11-0">↑</a></span> <span class="reference-text">Object Mentor, Inc.: <i><a rel="nofollow" class="external text" href="https://web.archive.org/web/20060423092645/http://www.objectmentor.com/ourCustomers/index">Companies using XP, Customers</a> (<a href="/wiki/Web-Archivierung#Begrifflichkeiten" title="Web-Archivierung"><span style="color:#303030!important">Memento</span></a> vom 23. April 2006 im </i><a href="/wiki/Internet_Archive" title="Internet Archive">Internet Archive</a><i>)</i> (englisch), 23. Juli 2006.</span>
|
||
</li>
|
||
<li id="cite_note-SYMANTEC-12"><span class="mw-cite-backlink"><a href="#cite_ref-SYMANTEC_12-0">↑</a></span> <span class="reference-text">Dr. Dobb’s: <i><a rel="nofollow" class="external text" href="http://www.ddj.com/dept/architect/184414801">Going to Extremes</a></i> (englisch), 2. Januar 2002.</span>
|
||
</li>
|
||
<li id="cite_note-SABRE-13"><span class="mw-cite-backlink">↑ <sup><a href="#cite_ref-SABRE_13-0">a</a></sup> <sup><a href="#cite_ref-SABRE_13-1">b</a></sup></span> <span class="reference-text">Computerworld: <i><a rel="nofollow" class="external text" href="https://web.archive.org/web/20090313033625/http://www.computerworld.com/developmenttopics/development/story/0,10801,91646,00.html">Sabre takes extreme measures</a> (<a href="/wiki/Web-Archivierung#Begrifflichkeiten" title="Web-Archivierung"><span style="color:#303030!important">Memento</span></a> vom 13. März 2009 im </i><a href="/wiki/Internet_Archive" title="Internet Archive">Internet Archive</a><i>)</i> (englisch), 29. März 2004.</span>
|
||
</li>
|
||
<li id="cite_note-Scrum_and_XP-14"><span class="mw-cite-backlink"><a href="#cite_ref-Scrum_and_XP_14-0">↑</a></span> <span class="reference-text">Henrik Kniberg: <a rel="nofollow" class="external text" href="http://www.infoq.com/minibooks/scrum-xp-from-the-trenches">Scrum and XP from the Trenches</a> (PDF, englisch), 27. Juni 2007.</span>
|
||
</li>
|
||
</ol>
|
||
<div class="hintergrundfarbe1 rahmenfarbe1 navigation-not-searchable noprint" style="border-top-style: solid; border-top-width: 1px; clear: both; margin-top:1em; padding: 0.25em; overflow: hidden; word-break: break-word; word-wrap: break-word;" id="Vorlage_Lesenswert"><div class="noviewer" style="display: table-cell; padding-bottom: 0.2em; padding-left: 0.25em; padding-right: 1em; padding-top: 0.2em; vertical-align: middle;" aria-hidden="true" role="presentation"><a href="/wiki/Datei:Qsicon_lesenswert.svg" class="image"><img alt="Qsicon lesenswert.svg" src="//upload.wikimedia.org/wikipedia/commons/thumb/4/43/Qsicon_lesenswert.svg/24px-Qsicon_lesenswert.svg.png" decoding="async" width="24" height="24" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/4/43/Qsicon_lesenswert.svg/36px-Qsicon_lesenswert.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/4/43/Qsicon_lesenswert.svg/48px-Qsicon_lesenswert.svg.png 2x" data-file-width="24" data-file-height="24" /></a></div>
|
||
<div style="display: table-cell; vertical-align: middle; width: 100%;">
|
||
<div role="contentinfo">
|
||
Dieser Artikel wurde am 17. Juli 2006 in <a href="/wiki/Spezial:Permanenter_Link/19063920" title="Spezial:Permanenter Link/19063920">dieser Version</a> in die Liste der <a href="/wiki/Wikipedia:Lesenswerte_Artikel" title="Wikipedia:Lesenswerte Artikel">lesenswerten Artikel</a> aufgenommen.</div>
|
||
</div></div>
|
||
<!--
|
||
NewPP limit report
|
||
Parsed by mw1324
|
||
Cached time: 20211020195559
|
||
Cache expiry: 1814400
|
||
Reduced expiry: false
|
||
Complications: []
|
||
CPU time usage: 0.306 seconds
|
||
Real time usage: 0.381 seconds
|
||
Preprocessor visited node count: 1639/1000000
|
||
Post‐expand include size: 22390/2097152 bytes
|
||
Template argument size: 5378/2097152 bytes
|
||
Highest expansion depth: 12/40
|
||
Expensive parser function count: 1/500
|
||
Unstrip recursion depth: 0/20
|
||
Unstrip post‐expand size: 7551/5000000 bytes
|
||
Lua time usage: 0.040/10.000 seconds
|
||
Lua memory usage: 2404182/52428800 bytes
|
||
Number of Wikibase entities loaded: 0/400
|
||
-->
|
||
<!--
|
||
Transclusion expansion time report (%,ms,calls,template)
|
||
100.00% 220.247 1 -total
|
||
26.91% 59.267 1 Vorlage:Internetquelle
|
||
19.06% 41.985 6 Vorlage:Webarchiv
|
||
13.58% 29.919 1 Vorlage:Str_len
|
||
11.66% 25.687 1 Vorlage:Zitat-en
|
||
11.44% 25.190 2 Vorlage:Anker
|
||
10.39% 22.893 1 Vorlage:Belege_fehlen
|
||
9.99% 22.007 2 Vorlage:Hinweisbaustein
|
||
9.91% 21.823 1 Vorlage:Zitat
|
||
8.59% 18.927 6 Vorlage:Webarchiv/Wayback
|
||
-->
|
||
|
||
<!-- Saved in parser cache with key dewiki:stable-pcache:idhash:52075-0!canonical and timestamp 20211020195559 and revision id 207672512. Serialized with JSON.
|
||
-->
|
||
</div><noscript><img src="//de.wikipedia.org/wiki/Special:CentralAutoLogin/start?type=1x1" alt="" title="" width="1" height="1" style="border: none; position: absolute;" /></noscript>
|
||
<div class="printfooter">Abgerufen von „<a dir="ltr" href="https://de.wikipedia.org/w/index.php?title=Extreme_Programming&oldid=207672512">https://de.wikipedia.org/w/index.php?title=Extreme_Programming&oldid=207672512</a>“</div></div>
|
||
<div id="catlinks" class="catlinks" data-mw="interface"><div id="mw-normal-catlinks" class="mw-normal-catlinks"><a href="/wiki/Wikipedia:Kategorien" title="Wikipedia:Kategorien">Kategorien</a>: <ul><li><a href="/wiki/Kategorie:Wikipedia:Lesenswert" title="Kategorie:Wikipedia:Lesenswert">Wikipedia:Lesenswert</a></li><li><a href="/wiki/Kategorie:Vorgehensmodell_(Software)" title="Kategorie:Vorgehensmodell (Software)">Vorgehensmodell (Software)</a></li><li><a href="/wiki/Kategorie:Agile_Softwareentwicklung" title="Kategorie:Agile Softwareentwicklung">Agile Softwareentwicklung</a></li><li><a href="/wiki/Kategorie:Englische_Phrase" title="Kategorie:Englische Phrase">Englische Phrase</a></li></ul></div><div id="mw-hidden-catlinks" class="mw-hidden-catlinks mw-hidden-cats-hidden">Versteckte Kategorien: <ul><li><a href="/wiki/Kategorie:Wikipedia:Vorlagenfehler/Vorlage:Zitat/%C3%9Cbersetzung_gew%C3%BCnscht" title="Kategorie:Wikipedia:Vorlagenfehler/Vorlage:Zitat/Übersetzung gewünscht">Wikipedia:Vorlagenfehler/Vorlage:Zitat/Übersetzung gewünscht</a></li><li><a href="/wiki/Kategorie:Wikipedia:Belege_fehlen" title="Kategorie:Wikipedia:Belege fehlen">Wikipedia:Belege fehlen</a></li></ul></div></div>
|
||
</div>
|
||
</div>
|
||
<div id='mw-data-after-content'>
|
||
<div class="read-more-container"></div>
|
||
</div>
|
||
|
||
<div id="mw-navigation">
|
||
<h2>Navigationsmenü</h2>
|
||
<div id="mw-head">
|
||
<nav id="p-personal" class="mw-portlet mw-portlet-personal vector-user-menu-legacy vector-menu" aria-labelledby="p-personal-label" role="navigation"
|
||
>
|
||
<h3 id="p-personal-label" aria-label="" class="vector-menu-heading">
|
||
|
||
<span>Meine Werkzeuge</span>
|
||
</h3>
|
||
<div class="vector-menu-content">
|
||
|
||
<ul class="vector-menu-content-list"><li id="pt-anonuserpage" class="mw-list-item"><span>Nicht angemeldet</span></li><li id="pt-anontalk" class="mw-list-item"><a href="/wiki/Spezial:Meine_Diskussionsseite" title="Diskussion über Änderungen von dieser IP-Adresse [n]" accesskey="n"><span>Diskussionsseite</span></a></li><li id="pt-anoncontribs" class="mw-list-item"><a href="/wiki/Spezial:Meine_Beitr%C3%A4ge" title="Eine Liste der Bearbeitungen, die von dieser IP-Adresse gemacht wurden [y]" accesskey="y"><span>Beiträge</span></a></li><li id="pt-createaccount" class="mw-list-item"><a href="/w/index.php?title=Spezial:Benutzerkonto_anlegen&returnto=Extreme+Programming" title="Wir ermutigen dich dazu, ein Benutzerkonto zu erstellen und dich anzumelden. Es ist jedoch nicht zwingend erforderlich."><span>Benutzerkonto erstellen</span></a></li><li id="pt-login" class="mw-list-item"><a href="/w/index.php?title=Spezial:Anmelden&returnto=Extreme+Programming" title="Anmelden ist zwar keine Pflicht, wird aber gerne gesehen. [o]" accesskey="o"><span>Anmelden</span></a></li></ul>
|
||
|
||
</div>
|
||
</nav>
|
||
|
||
<div id="left-navigation">
|
||
<nav id="p-namespaces" class="mw-portlet mw-portlet-namespaces vector-menu vector-menu-tabs" aria-labelledby="p-namespaces-label" role="navigation"
|
||
>
|
||
<h3 id="p-namespaces-label" aria-label="" class="vector-menu-heading">
|
||
|
||
<span>Namensräume</span>
|
||
</h3>
|
||
<div class="vector-menu-content">
|
||
|
||
<ul class="vector-menu-content-list"><li id="ca-nstab-main" class="selected mw-list-item"><a href="/wiki/Extreme_Programming" title="Seiteninhalt anzeigen [c]" accesskey="c"><span>Artikel</span></a></li><li id="ca-talk" class="mw-list-item"><a href="/wiki/Diskussion:Extreme_Programming" rel="discussion" title="Diskussion zum Seiteninhalt [t]" accesskey="t"><span>Diskussion</span></a></li></ul>
|
||
|
||
</div>
|
||
</nav>
|
||
|
||
<nav id="p-variants" class="mw-portlet mw-portlet-variants emptyPortlet vector-menu-dropdown-noicon vector-menu vector-menu-dropdown" aria-labelledby="p-variants-label" role="navigation"
|
||
>
|
||
<input type="checkbox"
|
||
id="p-variants-checkbox"
|
||
role="button"
|
||
aria-haspopup="true"
|
||
data-event-name="ui.dropdown-p-variants"
|
||
class="vector-menu-checkbox" aria-labelledby="p-variants-label" />
|
||
<h3 id="p-variants-label" aria-label="Sprachvariante ändern" class="vector-menu-heading">
|
||
|
||
<span>Varianten</span>
|
||
<span class="vector-menu-checkbox-expanded">ausgeklappt</span>
|
||
<span class="vector-menu-checkbox-collapsed">eingeklappt</span>
|
||
</h3>
|
||
<div class="vector-menu-content">
|
||
|
||
<ul class="vector-menu-content-list"></ul>
|
||
|
||
</div>
|
||
</nav>
|
||
|
||
</div>
|
||
<div id="right-navigation">
|
||
<nav id="p-views" class="mw-portlet mw-portlet-views vector-menu vector-menu-tabs" aria-labelledby="p-views-label" role="navigation"
|
||
>
|
||
<h3 id="p-views-label" aria-label="" class="vector-menu-heading">
|
||
|
||
<span>Ansichten</span>
|
||
</h3>
|
||
<div class="vector-menu-content">
|
||
|
||
<ul class="vector-menu-content-list"><li id="ca-view" class="selected mw-list-item"><a href="/wiki/Extreme_Programming"><span>Lesen</span></a></li><li id="ca-ve-edit" class="mw-list-item"><a href="/w/index.php?title=Extreme_Programming&veaction=edit" title="Diese Seite mit dem VisualEditor bearbeiten [v]" accesskey="v"><span>Bearbeiten</span></a></li><li id="ca-edit" class="collapsible mw-list-item"><a href="/w/index.php?title=Extreme_Programming&action=edit" title="Diese Seite bearbeiten [e]" accesskey="e"><span>Quelltext bearbeiten</span></a></li><li id="ca-history" class="mw-list-item"><a href="/w/index.php?title=Extreme_Programming&action=history" title="Frühere Versionen dieser Seite [h]" accesskey="h"><span>Versionsgeschichte</span></a></li></ul>
|
||
|
||
</div>
|
||
</nav>
|
||
|
||
<nav id="p-cactions" class="mw-portlet mw-portlet-cactions emptyPortlet vector-menu-dropdown-noicon vector-menu vector-menu-dropdown" aria-labelledby="p-cactions-label" role="navigation" title="Weitere Optionen"
|
||
>
|
||
<input type="checkbox"
|
||
id="p-cactions-checkbox"
|
||
role="button"
|
||
aria-haspopup="true"
|
||
data-event-name="ui.dropdown-p-cactions"
|
||
class="vector-menu-checkbox" aria-labelledby="p-cactions-label" />
|
||
<h3 id="p-cactions-label" aria-label="" class="vector-menu-heading">
|
||
|
||
<span>Weitere</span>
|
||
<span class="vector-menu-checkbox-expanded">ausgeklappt</span>
|
||
<span class="vector-menu-checkbox-collapsed">eingeklappt</span>
|
||
</h3>
|
||
<div class="vector-menu-content">
|
||
|
||
<ul class="vector-menu-content-list"></ul>
|
||
|
||
</div>
|
||
</nav>
|
||
|
||
<div id="p-search" role="search" class=" vector-search-box">
|
||
<div>
|
||
<h3 >
|
||
<label for="searchInput">Suche</label>
|
||
</h3>
|
||
<form action="/w/index.php" id="searchform"
|
||
class="vector-search-box-form">
|
||
<div id="simpleSearch"
|
||
class="vector-search-box-inner"
|
||
data-search-loc="header-navigation">
|
||
<input class="vector-search-box-input"
|
||
type="search" name="search" placeholder="Wikipedia durchsuchen" aria-label="Wikipedia durchsuchen" autocapitalize="sentences" title="Durchsuche die Wikipedia [f]" accesskey="f" id="searchInput"
|
||
/>
|
||
<input type="hidden" name="title" value="Spezial:Suche"/>
|
||
<input id="mw-searchButton"
|
||
class="searchButton mw-fallbackSearchButton" type="submit" name="fulltext" title="Suche nach Seiten, die diesen Text enthalten" value="Suchen" />
|
||
<input id="searchButton"
|
||
class="searchButton" type="submit" name="go" title="Gehe direkt zu der Seite mit genau diesem Namen, falls sie vorhanden ist." value="Artikel" />
|
||
</div>
|
||
</form>
|
||
</div>
|
||
</div>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div id="mw-panel">
|
||
<div id="p-logo" role="banner">
|
||
<a class="mw-wiki-logo" href="/wiki/Wikipedia:Hauptseite"
|
||
title="Hauptseite"></a>
|
||
</div>
|
||
<nav id="p-navigation" class="mw-portlet mw-portlet-navigation vector-menu vector-menu-portal portal" aria-labelledby="p-navigation-label" role="navigation"
|
||
>
|
||
<h3 id="p-navigation-label" aria-label="" class="vector-menu-heading">
|
||
|
||
<span>Navigation</span>
|
||
</h3>
|
||
<div class="vector-menu-content">
|
||
|
||
<ul class="vector-menu-content-list"><li id="n-mainpage-description" class="mw-list-item"><a href="/wiki/Wikipedia:Hauptseite" title="Hauptseite besuchen [z]" accesskey="z"><span>Hauptseite</span></a></li><li id="n-topics" class="mw-list-item"><a href="/wiki/Portal:Wikipedia_nach_Themen"><span>Themenportale</span></a></li><li id="n-randompage" class="mw-list-item"><a href="/wiki/Spezial:Zuf%C3%A4llige_Seite" title="Zufällige Seite aufrufen [x]" accesskey="x"><span>Zufälliger Artikel</span></a></li></ul>
|
||
|
||
</div>
|
||
</nav>
|
||
|
||
<nav id="p-Mitmachen" class="mw-portlet mw-portlet-Mitmachen vector-menu vector-menu-portal portal" aria-labelledby="p-Mitmachen-label" role="navigation"
|
||
>
|
||
<h3 id="p-Mitmachen-label" aria-label="" class="vector-menu-heading">
|
||
|
||
<span>Mitmachen</span>
|
||
</h3>
|
||
<div class="vector-menu-content">
|
||
|
||
<ul class="vector-menu-content-list"><li id="n-Artikel-verbessern" class="mw-list-item"><a href="/wiki/Wikipedia:Beteiligen"><span>Artikel verbessern</span></a></li><li id="n-Neuerartikel" class="mw-list-item"><a href="/wiki/Hilfe:Neuen_Artikel_anlegen"><span>Neuen Artikel anlegen</span></a></li><li id="n-portal" class="mw-list-item"><a href="/wiki/Wikipedia:Autorenportal" title="Info-Zentrum über Beteiligungsmöglichkeiten"><span>Autorenportal</span></a></li><li id="n-help" class="mw-list-item"><a href="/wiki/Hilfe:%C3%9Cbersicht" title="Übersicht über Hilfeseiten"><span>Hilfe</span></a></li><li id="n-recentchanges" class="mw-list-item"><a href="/wiki/Spezial:Letzte_%C3%84nderungen" title="Liste der letzten Änderungen in Wikipedia [r]" accesskey="r"><span>Letzte Änderungen</span></a></li><li id="n-contact" class="mw-list-item"><a href="/wiki/Wikipedia:Kontakt" title="Kontaktmöglichkeiten"><span>Kontakt</span></a></li><li id="n-sitesupport" class="mw-list-item"><a href="//donate.wikimedia.org/wiki/Special:FundraiserRedirector?utm_source=donate&utm_medium=sidebar&utm_campaign=C13_de.wikipedia.org&uselang=de" title="Unterstütze uns"><span>Spenden</span></a></li></ul>
|
||
|
||
</div>
|
||
</nav>
|
||
<nav id="p-tb" class="mw-portlet mw-portlet-tb vector-menu vector-menu-portal portal" aria-labelledby="p-tb-label" role="navigation"
|
||
>
|
||
<h3 id="p-tb-label" aria-label="" class="vector-menu-heading">
|
||
|
||
<span>Werkzeuge</span>
|
||
</h3>
|
||
<div class="vector-menu-content">
|
||
|
||
<ul class="vector-menu-content-list"><li id="t-whatlinkshere" class="mw-list-item"><a href="/wiki/Spezial:Linkliste/Extreme_Programming" title="Liste aller Seiten, die hierher verlinken [j]" accesskey="j"><span>Links auf diese Seite</span></a></li><li id="t-recentchangeslinked" class="mw-list-item"><a href="/wiki/Spezial:%C3%84nderungen_an_verlinkten_Seiten/Extreme_Programming" rel="nofollow" title="Letzte Änderungen an Seiten, die von hier verlinkt sind [k]" accesskey="k"><span>Änderungen an verlinkten Seiten</span></a></li><li id="t-specialpages" class="mw-list-item"><a href="/wiki/Spezial:Spezialseiten" title="Liste aller Spezialseiten [q]" accesskey="q"><span>Spezialseiten</span></a></li><li id="t-permalink" class="mw-list-item"><a href="/w/index.php?title=Extreme_Programming&oldid=207672512" title="Dauerhafter Link zu dieser Seitenversion"><span>Permanenter Link</span></a></li><li id="t-info" class="mw-list-item"><a href="/w/index.php?title=Extreme_Programming&action=info" title="Weitere Informationen über diese Seite"><span>Seiteninformationen</span></a></li><li id="t-cite" class="mw-list-item"><a href="/w/index.php?title=Spezial:Zitierhilfe&page=Extreme_Programming&id=207672512&wpFormIdentifier=titleform" title="Hinweise, wie diese Seite zitiert werden kann"><span>Artikel zitieren</span></a></li><li id="t-wikibase" class="mw-list-item"><a href="https://www.wikidata.org/wiki/Special:EntityPage/Q209711" title="Link zum verbundenen Objekt im Datenrepositorium [g]" accesskey="g"><span>Wikidata-Datenobjekt</span></a></li></ul>
|
||
|
||
</div>
|
||
</nav>
|
||
<nav id="p-coll-print_export" class="mw-portlet mw-portlet-coll-print_export vector-menu vector-menu-portal portal" aria-labelledby="p-coll-print_export-label" role="navigation"
|
||
>
|
||
<h3 id="p-coll-print_export-label" aria-label="" class="vector-menu-heading">
|
||
|
||
<span>Drucken/exportieren</span>
|
||
</h3>
|
||
<div class="vector-menu-content">
|
||
|
||
<ul class="vector-menu-content-list"><li id="coll-create_a_book" class="mw-list-item"><a href="/w/index.php?title=Spezial:Buch&bookcmd=book_creator&referer=Extreme+Programming"><span>Buch erstellen</span></a></li><li id="coll-download-as-rl" class="mw-list-item"><a href="/w/index.php?title=Spezial:DownloadAsPdf&page=Extreme_Programming&action=show-download-screen"><span>Als PDF herunterladen</span></a></li><li id="t-print" class="mw-list-item"><a href="/w/index.php?title=Extreme_Programming&printable=yes" title="Druckansicht dieser Seite [p]" accesskey="p"><span>Druckversion</span></a></li></ul>
|
||
|
||
</div>
|
||
</nav>
|
||
<nav id="p-wikibase-otherprojects" class="mw-portlet mw-portlet-wikibase-otherprojects vector-menu vector-menu-portal portal" aria-labelledby="p-wikibase-otherprojects-label" role="navigation"
|
||
>
|
||
<h3 id="p-wikibase-otherprojects-label" aria-label="" class="vector-menu-heading">
|
||
|
||
<span>In anderen Projekten</span>
|
||
</h3>
|
||
<div class="vector-menu-content">
|
||
|
||
<ul class="vector-menu-content-list"><li class="wb-otherproject-link wb-otherproject-commons mw-list-item"><a href="https://commons.wikimedia.org/wiki/Category:Extreme_programming" hreflang="en"><span>Commons</span></a></li></ul>
|
||
|
||
</div>
|
||
</nav>
|
||
|
||
<nav id="p-lang" class="mw-portlet mw-portlet-lang vector-menu vector-menu-portal portal" aria-labelledby="p-lang-label" role="navigation"
|
||
>
|
||
<h3 id="p-lang-label" aria-label="" class="vector-menu-heading">
|
||
|
||
<span>In anderen Sprachen</span>
|
||
</h3>
|
||
<div class="vector-menu-content">
|
||
|
||
<ul class="vector-menu-content-list"><li class="interlanguage-link interwiki-ar mw-list-item"><a href="https://ar.wikipedia.org/wiki/%D8%A8%D8%B1%D9%85%D8%AC%D8%A9_%D9%82%D8%B5%D9%88%D9%89" title="برمجة قصوى – Arabisch" lang="ar" hreflang="ar" class="interlanguage-link-target"><span>العربية</span></a></li><li class="interlanguage-link interwiki-az mw-list-item"><a href="https://az.wikipedia.org/wiki/Ekstremal_proqramla%C5%9Fd%C4%B1rma" title="Ekstremal proqramlaşdırma – Aserbaidschanisch" lang="az" hreflang="az" class="interlanguage-link-target"><span>Azərbaycanca</span></a></li><li class="interlanguage-link interwiki-be-x-old mw-list-item"><a href="https://be-tarask.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D1%82%D1%80%D1%8D%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D0%B5_%D0%BF%D1%80%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%B0%D0%B2%D0%B0%D0%BD%D1%8C%D0%BD%D0%B5" title="Экстрэмальнае праграмаваньне – Weißrussisch (Taraschkewiza)" lang="be-tarask" hreflang="be-tarask" class="interlanguage-link-target"><span>Беларуская (тарашкевіца)</span></a></li><li class="interlanguage-link interwiki-bg mw-list-item"><a href="https://bg.wikipedia.org/wiki/%D0%95%D0%BA%D1%81%D1%82%D1%80%D0%B5%D0%BC%D0%BD%D0%BE_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%B8%D1%80%D0%B0%D0%BD%D0%B5" title="Екстремно програмиране – Bulgarisch" lang="bg" hreflang="bg" class="interlanguage-link-target"><span>Български</span></a></li><li class="interlanguage-link interwiki-ca mw-list-item"><a href="https://ca.wikipedia.org/wiki/Programaci%C3%B3_extrema" title="Programació extrema – Katalanisch" lang="ca" hreflang="ca" class="interlanguage-link-target"><span>Català</span></a></li><li class="interlanguage-link interwiki-cs mw-list-item"><a href="https://cs.wikipedia.org/wiki/Extr%C3%A9mn%C3%AD_programov%C3%A1n%C3%AD" title="Extrémní programování – Tschechisch" lang="cs" hreflang="cs" class="interlanguage-link-target"><span>Čeština</span></a></li><li class="interlanguage-link interwiki-da mw-list-item"><a href="https://da.wikipedia.org/wiki/Extreme_Programming" title="Extreme Programming – Dänisch" lang="da" hreflang="da" class="interlanguage-link-target"><span>Dansk</span></a></li><li class="interlanguage-link interwiki-en mw-list-item"><a href="https://en.wikipedia.org/wiki/Extreme_programming" title="Extreme programming – Englisch" lang="en" hreflang="en" class="interlanguage-link-target"><span>English</span></a></li><li class="interlanguage-link interwiki-es mw-list-item"><a href="https://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema" title="Programación extrema – Spanisch" lang="es" hreflang="es" class="interlanguage-link-target"><span>Español</span></a></li><li class="interlanguage-link interwiki-et mw-list-item"><a href="https://et.wikipedia.org/wiki/Ekstreemprogrammeerimine" title="Ekstreemprogrammeerimine – Estnisch" lang="et" hreflang="et" class="interlanguage-link-target"><span>Eesti</span></a></li><li class="interlanguage-link interwiki-fa mw-list-item"><a href="https://fa.wikipedia.org/wiki/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87%E2%80%8C%D9%86%D9%88%DB%8C%D8%B3%DB%8C_%D9%85%D9%81%D8%B1%D8%B7" title="برنامهنویسی مفرط – Persisch" lang="fa" hreflang="fa" class="interlanguage-link-target"><span>فارسی</span></a></li><li class="interlanguage-link interwiki-fi mw-list-item"><a href="https://fi.wikipedia.org/wiki/Extreme_Programming" title="Extreme Programming – Finnisch" lang="fi" hreflang="fi" class="interlanguage-link-target"><span>Suomi</span></a></li><li class="interlanguage-link interwiki-fr mw-list-item"><a href="https://fr.wikipedia.org/wiki/Extreme_programming" title="Extreme programming – Französisch" lang="fr" hreflang="fr" class="interlanguage-link-target"><span>Français</span></a></li><li class="interlanguage-link interwiki-gl mw-list-item"><a href="https://gl.wikipedia.org/wiki/Programaci%C3%B3n_extrema" title="Programación extrema – Galicisch" lang="gl" hreflang="gl" class="interlanguage-link-target"><span>Galego</span></a></li><li class="interlanguage-link interwiki-he mw-list-item"><a href="https://he.wikipedia.org/wiki/Extreme_Programming" title="Extreme Programming – Hebräisch" lang="he" hreflang="he" class="interlanguage-link-target"><span>עברית</span></a></li><li class="interlanguage-link interwiki-hi mw-list-item"><a href="https://hi.wikipedia.org/wiki/%E0%A4%8F%E0%A4%95%E0%A5%8D%E0%A4%B8%E0%A4%9F%E0%A5%8D%E0%A4%B0%E0%A5%80%E0%A4%AE_%E0%A4%AA%E0%A5%8D%E0%A4%B0%E0%A5%8B%E0%A4%97%E0%A5%8D%E0%A4%B0%E0%A4%BE%E0%A4%AE%E0%A4%BF%E0%A4%82%E0%A4%97" title="एक्सट्रीम प्रोग्रामिंग – Hindi" lang="hi" hreflang="hi" class="interlanguage-link-target"><span>हिन्दी</span></a></li><li class="interlanguage-link interwiki-hu mw-list-item"><a href="https://hu.wikipedia.org/wiki/Extr%C3%A9m_programoz%C3%A1s" title="Extrém programozás – Ungarisch" lang="hu" hreflang="hu" class="interlanguage-link-target"><span>Magyar</span></a></li><li class="interlanguage-link interwiki-ia mw-list-item"><a href="https://ia.wikipedia.org/wiki/Programmation_extreme" title="Programmation extreme – Interlingua" lang="ia" hreflang="ia" class="interlanguage-link-target"><span>Interlingua</span></a></li><li class="interlanguage-link interwiki-id mw-list-item"><a href="https://id.wikipedia.org/wiki/Extreme_programming" title="Extreme programming – Indonesisch" lang="id" hreflang="id" class="interlanguage-link-target"><span>Bahasa Indonesia</span></a></li><li class="interlanguage-link interwiki-it mw-list-item"><a href="https://it.wikipedia.org/wiki/Extreme_programming" title="Extreme programming – Italienisch" lang="it" hreflang="it" class="interlanguage-link-target"><span>Italiano</span></a></li><li class="interlanguage-link interwiki-ja mw-list-item"><a href="https://ja.wikipedia.org/wiki/%E3%82%A8%E3%82%AF%E3%82%B9%E3%83%88%E3%83%AA%E3%83%BC%E3%83%A0%E3%83%BB%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0" title="エクストリーム・プログラミング – Japanisch" lang="ja" hreflang="ja" class="interlanguage-link-target"><span>日本語</span></a></li><li class="interlanguage-link interwiki-ko mw-list-item"><a href="https://ko.wikipedia.org/wiki/%EC%9D%B5%EC%8A%A4%ED%8A%B8%EB%A6%BC_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D" title="익스트림 프로그래밍 – Koreanisch" lang="ko" hreflang="ko" class="interlanguage-link-target"><span>한국어</span></a></li><li class="interlanguage-link interwiki-lt mw-list-item"><a href="https://lt.wikipedia.org/wiki/Ribinis_programavimas" title="Ribinis programavimas – Litauisch" lang="lt" hreflang="lt" class="interlanguage-link-target"><span>Lietuvių</span></a></li><li class="interlanguage-link interwiki-nl mw-list-item"><a href="https://nl.wikipedia.org/wiki/Extreme_programming" title="Extreme programming – Niederländisch" lang="nl" hreflang="nl" class="interlanguage-link-target"><span>Nederlands</span></a></li><li class="interlanguage-link interwiki-no mw-list-item"><a href="https://no.wikipedia.org/wiki/Extreme_programming" title="Extreme programming – Norwegisch (Bokmål)" lang="nb" hreflang="nb" class="interlanguage-link-target"><span>Norsk bokmål</span></a></li><li class="interlanguage-link interwiki-pl mw-list-item"><a href="https://pl.wikipedia.org/wiki/Programowanie_ekstremalne" title="Programowanie ekstremalne – Polnisch" lang="pl" hreflang="pl" class="interlanguage-link-target"><span>Polski</span></a></li><li class="interlanguage-link interwiki-pt mw-list-item"><a href="https://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_extrema" title="Programação extrema – Portugiesisch" lang="pt" hreflang="pt" class="interlanguage-link-target"><span>Português</span></a></li><li class="interlanguage-link interwiki-ru mw-list-item"><a href="https://ru.wikipedia.org/wiki/%D0%AD%D0%BA%D1%81%D1%82%D1%80%D0%B5%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5" title="Экстремальное программирование – Russisch" lang="ru" hreflang="ru" class="interlanguage-link-target"><span>Русский</span></a></li><li class="interlanguage-link interwiki-sh mw-list-item"><a href="https://sh.wikipedia.org/wiki/Ekstremno_programiranje" title="Ekstremno programiranje – Serbokroatisch" lang="sh" hreflang="sh" class="interlanguage-link-target"><span>Srpskohrvatski / српскохрватски</span></a></li><li class="interlanguage-link interwiki-sq mw-list-item"><a href="https://sq.wikipedia.org/wiki/Programimi_ekstrem" title="Programimi ekstrem – Albanisch" lang="sq" hreflang="sq" class="interlanguage-link-target"><span>Shqip</span></a></li><li class="interlanguage-link interwiki-sr mw-list-item"><a href="https://sr.wikipedia.org/wiki/Ekstremno_programiranje" title="Ekstremno programiranje – Serbisch" lang="sr" hreflang="sr" class="interlanguage-link-target"><span>Српски / srpski</span></a></li><li class="interlanguage-link interwiki-sv mw-list-item"><a href="https://sv.wikipedia.org/wiki/Extrem_programmering" title="Extrem programmering – Schwedisch" lang="sv" hreflang="sv" class="interlanguage-link-target"><span>Svenska</span></a></li><li class="interlanguage-link interwiki-te mw-list-item"><a href="https://te.wikipedia.org/wiki/%E0%B0%8E%E0%B0%95%E0%B1%8D%E0%B0%B8%E0%B1%8D%E2%80%8C%E0%B0%9F%E0%B1%8D%E0%B0%B0%E0%B1%80%E0%B0%AE%E0%B1%8D_%E0%B0%AA%E0%B1%8D%E0%B0%B0%E0%B1%8B%E0%B0%97%E0%B1%8D%E0%B0%B0%E0%B0%BE%E0%B0%AE%E0%B0%BF%E0%B0%82%E0%B0%97%E0%B1%8D" title="ఎక్స్ట్రీమ్ ప్రోగ్రామింగ్ – Telugu" lang="te" hreflang="te" class="interlanguage-link-target"><span>తెలుగు</span></a></li><li class="interlanguage-link interwiki-th mw-list-item"><a href="https://th.wikipedia.org/wiki/Extreme_programming" title="Extreme programming – Thailändisch" lang="th" hreflang="th" class="interlanguage-link-target"><span>ไทย</span></a></li><li class="interlanguage-link interwiki-tr mw-list-item"><a href="https://tr.wikipedia.org/wiki/Ekstrem_programlama" title="Ekstrem programlama – Türkisch" lang="tr" hreflang="tr" class="interlanguage-link-target"><span>Türkçe</span></a></li><li class="interlanguage-link interwiki-uk mw-list-item"><a href="https://uk.wikipedia.org/wiki/%D0%95%D0%BA%D1%81%D1%82%D1%80%D0%B5%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F" title="Екстремальне програмування – Ukrainisch" lang="uk" hreflang="uk" class="interlanguage-link-target"><span>Українська</span></a></li><li class="interlanguage-link interwiki-vi mw-list-item"><a href="https://vi.wikipedia.org/wiki/L%E1%BA%ADp_tr%C3%ACnh_c%E1%BB%B1c_h%E1%BA%A1n" title="Lập trình cực hạn – Vietnamesisch" lang="vi" hreflang="vi" class="interlanguage-link-target"><span>Tiếng Việt</span></a></li><li class="interlanguage-link interwiki-zh mw-list-item"><a href="https://zh.wikipedia.org/wiki/%E6%9E%81%E9%99%90%E7%BC%96%E7%A8%8B" title="极限编程 – Chinesisch" lang="zh" hreflang="zh" class="interlanguage-link-target"><span>中文</span></a></li></ul>
|
||
<div class="after-portlet after-portlet-lang"><span class="wb-langlinks-edit wb-langlinks-link"><a href="https://www.wikidata.org/wiki/Special:EntityPage/Q209711#sitelinks-wikipedia" title="Links auf Artikel in anderen Sprachen bearbeiten" class="wbc-editpage">Links bearbeiten</a></span></div>
|
||
</div>
|
||
</nav>
|
||
|
||
</div>
|
||
|
||
</div>
|
||
<footer id="footer" class="mw-footer" role="contentinfo" >
|
||
<ul id="footer-info">
|
||
<li id="footer-info-lastmod"> Diese Seite wurde zuletzt am 15. Januar 2021 um 16:55 Uhr bearbeitet.</li>
|
||
<li id="footer-info-copyright"><div id="footer-info-copyright-stats" class="noprint"><a class="external" href="https://pageviews.toolforge.org/?pages=Extreme_Programming&project=de.wikipedia.org" rel="nofollow">Abrufstatistik</a> · <a class="external" href=" https://xtools.wmflabs.org/articleinfo-authorship/de.wikipedia.org/Extreme_Programming?uselang=de" rel="nofollow">Autoren</a> </div><div id="footer-info-copyright-separator"><br /></div><div id="footer-info-copyright-info">
|
||
Der Text ist unter der Lizenz <a class="internal" href="https://de.wikipedia.org/wiki/Wikipedia:Lizenzbestimmungen_Commons_Attribution-ShareAlike_3.0_Unported">„Creative Commons Attribution/Share Alike“</a> verfügbar; Informationen zu den Urhebern und zum Lizenzstatus eingebundener Mediendateien (etwa Bilder oder Videos) können im Regelfall durch Anklicken dieser abgerufen werden. Möglicherweise unterliegen die Inhalte jeweils zusätzlichen Bedingungen. Durch die Nutzung dieser Website erklären Sie sich mit den <a class="internal" href="https://foundation.wikimedia.org/wiki/Terms_of_Use/de">Nutzungsbedingungen</a> und der <a class="internal" href="https://meta.wikimedia.org/wiki/Privacy_policy/de">Datenschutzrichtlinie</a> einverstanden.<br />
|
||
Wikipedia® ist eine eingetragene Marke der Wikimedia Foundation Inc.</div></li>
|
||
</ul>
|
||
|
||
<ul id="footer-places">
|
||
<li id="footer-places-privacy"><a href="https://meta.wikimedia.org/wiki/Privacy_policy/de" class="extiw" title="m:Privacy policy/de">Datenschutz</a></li>
|
||
<li id="footer-places-about"><a href="/wiki/Wikipedia:%C3%9Cber_Wikipedia" title="Wikipedia:Über Wikipedia">Über Wikipedia</a></li>
|
||
<li id="footer-places-disclaimer"><a href="/wiki/Wikipedia:Impressum" title="Wikipedia:Impressum">Impressum</a></li>
|
||
<li id="footer-places-mobileview"><a href="//de.m.wikipedia.org/w/index.php?title=Extreme_Programming&mobileaction=toggle_view_mobile" class="noprint stopMobileRedirectToggle">Mobile Ansicht</a></li>
|
||
<li id="footer-places-developers"><a href="https://www.mediawiki.org/wiki/Special:MyLanguage/How_to_contribute">Entwickler</a></li>
|
||
<li id="footer-places-statslink"><a href="https://stats.wikimedia.org/#/de.wikipedia.org">Statistiken</a></li>
|
||
<li id="footer-places-cookiestatement"><a href="https://foundation.wikimedia.org/wiki/Cookie_statement">Stellungnahme zu Cookies</a></li>
|
||
</ul>
|
||
|
||
<ul id="footer-icons" class="noprint">
|
||
<li id="footer-copyrightico"><a href="https://wikimediafoundation.org/"><img src="/static/images/footer/wikimedia-button.png" srcset="/static/images/footer/wikimedia-button-1.5x.png 1.5x, /static/images/footer/wikimedia-button-2x.png 2x" width="88" height="31" alt="Wikimedia Foundation" loading="lazy" /></a></li>
|
||
<li id="footer-poweredbyico"><a href="https://www.mediawiki.org/"><img src="/static/images/footer/poweredby_mediawiki_88x31.png" alt="Powered by MediaWiki" srcset="/static/images/footer/poweredby_mediawiki_132x47.png 1.5x, /static/images/footer/poweredby_mediawiki_176x62.png 2x" width="88" height="31" loading="lazy"/></a></li>
|
||
</ul>
|
||
|
||
</footer>
|
||
|
||
|
||
<script>(RLQ=window.RLQ||[]).push(function(){mw.config.set({"wgPageParseReport":{"limitreport":{"cputime":"0.306","walltime":"0.381","ppvisitednodes":{"value":1639,"limit":1000000},"postexpandincludesize":{"value":22390,"limit":2097152},"templateargumentsize":{"value":5378,"limit":2097152},"expansiondepth":{"value":12,"limit":40},"expensivefunctioncount":{"value":1,"limit":500},"unstrip-depth":{"value":0,"limit":20},"unstrip-size":{"value":7551,"limit":5000000},"entityaccesscount":{"value":0,"limit":400},"timingprofile":["100.00% 220.247 1 -total"," 26.91% 59.267 1 Vorlage:Internetquelle"," 19.06% 41.985 6 Vorlage:Webarchiv"," 13.58% 29.919 1 Vorlage:Str_len"," 11.66% 25.687 1 Vorlage:Zitat-en"," 11.44% 25.190 2 Vorlage:Anker"," 10.39% 22.893 1 Vorlage:Belege_fehlen"," 9.99% 22.007 2 Vorlage:Hinweisbaustein"," 9.91% 21.823 1 Vorlage:Zitat"," 8.59% 18.927 6 Vorlage:Webarchiv/Wayback"]},"scribunto":{"limitreport-timeusage":{"value":"0.040","limit":"10.000"},"limitreport-memusage":{"value":2404182,"limit":52428800}},"cachereport":{"origin":"mw1324","timestamp":"20211020195559","ttl":1814400,"transientcontent":false}}});});</script>
|
||
<script type="application/ld+json">{"@context":"https:\/\/schema.org","@type":"Article","name":"Extreme Programming","url":"https:\/\/de.wikipedia.org\/wiki\/Extreme_Programming","sameAs":"http:\/\/www.wikidata.org\/entity\/Q209711","mainEntity":"http:\/\/www.wikidata.org\/entity\/Q209711","author":{"@type":"Organization","name":"Autoren der Wikimedia-Projekte"},"publisher":{"@type":"Organization","name":"Wikimedia Foundation, Inc.","logo":{"@type":"ImageObject","url":"https:\/\/www.wikimedia.org\/static\/images\/wmf-hor-googpub.png"}},"datePublished":"2003-08-17T09:23:50Z"}</script>
|
||
<script>(RLQ=window.RLQ||[]).push(function(){mw.config.set({"wgBackendResponseTime":167,"wgHostname":"mw1370"});});</script>
|
||
</body></html> |