Extreme Programming - Versionsgeschichte

Schotterebene: Revert - verzichtbar

Schotterebene — Wed, 16 Apr 2025 03:15:29 GMT

Revert - verzichtbar

← Nächstältere Version		Version vom 16. April 2025, 05:15 Uhr
Zeile 133:		Zeile 133:
	\|-		\|-
	\| 1		\| 1
	\|style="text-align:left;"\| Als Arzt~~/Ärztin~~ kann ich alle Patienten sehen, die ich am Tage habe.		\|style="text-align:left;"\| Als Arzt kann ich alle Patienten sehen, die ich am Tage habe.
	\| 3		\| 3
	\|-		\|-
	\| 2		\| 2
	\|style="text-align:left;"\| Als Arzt~~/Ärztin~~ kann ich über die Gesundheitsgeschichte meiner Patienten Auskunft geben.		\|style="text-align:left;"\| Als Arzt kann ich über die Gesundheitsgeschichte meiner Patienten Auskunft geben.
	\| 5		\| 5
	\|-		\|-
	\| 3		\| 3
	\|style="text-align:left;"\| Als ~~Assistenz~~ kann ich einem Patienten einen Termin geben.		\|style="text-align:left;"\| Als Assistentin kann ich einem Patienten einen Termin geben.
	\| 2		\| 2
	\|-		\|-
	\| 4		\| 4
	\|style="text-align:left;"\| Als ~~Assistenz~~ kann ich einem Patienten eine Verschreibung ausdrucken.		\|style="text-align:left;"\| Als Assistentin kann ich einem Patienten eine Verschreibung ausdrucken.
	\| 1		\| 1
	\|}		\|}

2A02:8109:9A27:BB00:D1A8:2553:436E:3EF9: Geschlechtsneutrale Sprache um die klischeehafte Aufteilung von Fachtätigkeiten für männliche Personen und Hilfstätigkeiten für weibliche Personen zu vermeiden.

2A02:8109:9A27:BB00:D1A8:2553:436E:3EF9 — Tue, 15 Apr 2025 20:39:27 GMT

Geschlechtsneutrale Sprache um die klischeehafte Aufteilung von Fachtätigkeiten für männliche Personen und Hilfstätigkeiten für weibliche Personen zu vermeiden.

← Nächstältere Version		Version vom 15. April 2025, 22:39 Uhr
Zeile 133:		Zeile 133:
	\|-		\|-
	\| 1		\| 1
	\|style="text-align:left;"\| Als Arzt kann ich alle Patienten sehen, die ich am Tage habe.		\|style="text-align:left;"\| Als Arzt/Ärztin kann ich alle Patienten sehen, die ich am Tage habe.
	\| 3		\| 3
	\|-		\|-
	\| 2		\| 2
	\|style="text-align:left;"\| Als Arzt kann ich über die Gesundheitsgeschichte meiner Patienten Auskunft geben.		\|style="text-align:left;"\| Als Arzt/Ärztin kann ich über die Gesundheitsgeschichte meiner Patienten Auskunft geben.
	\| 5		\| 5
	\|-		\|-
	\| 3		\| 3
	\|style="text-align:left;"\| Als ~~Assistentin~~ kann ich einem Patienten einen Termin geben.		\|style="text-align:left;"\| Als Assistenz kann ich einem Patienten einen Termin geben.
	\| 2		\| 2
	\|-		\|-
	\| 4		\| 4
	\|style="text-align:left;"\| Als ~~Assistentin~~ kann ich einem Patienten eine Verschreibung ausdrucken.		\|style="text-align:left;"\| Als Assistenz kann ich einem Patienten eine Verschreibung ausdrucken.
	\| 1		\| 1
	\|}		\|}

Gunnar.Kaestle: spezifischere Wikilink-Auswahl

Gunnar.Kaestle — Sun, 22 Dec 2024 17:19:32 GMT

spezifischere Wikilink-Auswahl

← Nächstältere Version		Version vom 22. Dezember 2024, 19:19 Uhr
Zeile 114:		Zeile 114:
	[[Datei:Kano-modell.png\|mini\|400px\|links\|Kundenzufriedenheit]]		[[Datei:Kano-modell.png\|mini\|400px\|links\|Kundenzufriedenheit]]

	Neben einer Abschätzung nach Nutzen und Risiko ist für die Entscheidung, welche ''User-Storys'' 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 [[Kano-Modell]]s. Dabei werden in einer systematischen Kundenbefragung Fragen in ''funktionaler Form'' und in ''dysfunktionaler Form'' gestellt. Es lässt sich anschließend bestimmen, welche ''User-Storys'' unbedingt fertiggestellt werden müssen ''(Must-haves)'', welche linearer Natur sind (je mehr, desto besser; siehe ''[[~~Linearität (Physik)~~\|~~linear~~]]''.) und welche ''Exciters'' 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.		Neben einer Abschätzung nach Nutzen und Risiko ist für die Entscheidung, welche ''User-Storys'' 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 [[Kano-Modell]]s. Dabei werden in einer systematischen Kundenbefragung Fragen in ''funktionaler Form'' und in ''dysfunktionaler Form'' gestellt. Es lässt sich anschließend bestimmen, welche ''User-Storys'' unbedingt fertiggestellt werden müssen ''(Must-haves)'', welche linearer Natur sind (je mehr, desto besser; siehe auch ''[[Proportionalität\|proportional]]''.) und welche ''Exciters'' 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.

	XP zeichnet sich dadurch aus, dass die Betrachtung der Größe einer Einheit, wie Release oder Iteration, unabhängig von ihrer Dauer ist.		XP zeichnet sich dadurch aus, dass die Betrachtung der Größe einer Einheit, wie Release oder Iteration, unabhängig von ihrer Dauer ist.

Gunnar.Kaestle: spezifischere Wikilink-Auswahl

Gunnar.Kaestle — Sun, 22 Dec 2024 17:17:00 GMT

spezifischere Wikilink-Auswahl

← Nächstältere Version		Version vom 22. Dezember 2024, 19:17 Uhr
Zeile 114:		Zeile 114:
	[[Datei:Kano-modell.png\|mini\|400px\|links\|Kundenzufriedenheit]]		[[Datei:Kano-modell.png\|mini\|400px\|links\|Kundenzufriedenheit]]

	Neben einer Abschätzung nach Nutzen und Risiko ist für die Entscheidung, welche ''User-Storys'' 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 [[Kano-Modell]]s. Dabei werden in einer systematischen Kundenbefragung Fragen in ''funktionaler Form'' und in ''dysfunktionaler Form'' gestellt. Es lässt sich anschließend bestimmen, welche ''User-Storys'' unbedingt fertiggestellt werden müssen ''(Must-haves)'', welche linearer Natur sind (je mehr, desto besser; siehe ''[[Linearität\|linear]]''.) und welche ''Exciters'' 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.		Neben einer Abschätzung nach Nutzen und Risiko ist für die Entscheidung, welche ''User-Storys'' 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 [[Kano-Modell]]s. Dabei werden in einer systematischen Kundenbefragung Fragen in ''funktionaler Form'' und in ''dysfunktionaler Form'' gestellt. Es lässt sich anschließend bestimmen, welche ''User-Storys'' unbedingt fertiggestellt werden müssen ''(Must-haves)'', welche linearer Natur sind (je mehr, desto besser; siehe ''[[Linearität (Physik)\|linear]]''.) und welche ''Exciters'' 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.

	XP zeichnet sich dadurch aus, dass die Betrachtung der Größe einer Einheit, wie Release oder Iteration, unabhängig von ihrer Dauer ist.		XP zeichnet sich dadurch aus, dass die Betrachtung der Größe einer Einheit, wie Release oder Iteration, unabhängig von ihrer Dauer ist.

Thzht: Wiederwahl Lesenswert gescheitert

Thzht — Wed, 13 Nov 2024 14:35:00 GMT

Wiederwahl Lesenswert gescheitert

← Nächstältere Version		Version vom 13. November 2024, 16:35 Uhr
Zeile 491:		Zeile 491:
	== Einzelnachweise ==		== Einzelnachweise ==
	<references />		<references />

	{{Lesenswert\|17. Juli 2006\|19063920}}
	{{Lesenswert-Abwahl}}

	[[Kategorie:Vorgehensmodell (Software)]]		[[Kategorie:Vorgehensmodell (Software)]]

Wiegels: Typografie

Wiegels — Sun, 10 Nov 2024 18:32:51 GMT

Typografie

← Nächstältere Version		Version vom 10. November 2024, 20:32 Uhr
Zeile 61:		Zeile 61:

	=== Aufbauorganisation ===		=== Aufbauorganisation ===
	Neben dem Entwicklungsteam gibt es im Wesentlichen den Kunden und den ''Product-Owner''. 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 [[Softwareentwickler\|Entwickler]] (''Developer'') bezeichnet. Ein [[Manager (Wirtschaft)\|Manager]] 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.		Neben dem Entwicklungsteam gibt es im Wesentlichen den Kunden und den ''Product-Owner''. 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 [[Softwareentwickler\|Entwickler]] ''(Developer)'' bezeichnet. Ein [[Manager (Wirtschaft)\|Manager]] 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.

	{\| class="wikitable zebra" style="background:#F0F0FF;"		{\| class="wikitable zebra" style="background:#F0F0FF;"
Zeile 108:		Zeile 108:
	Die innerhalb der Iterationen umzusetzenden einzelnen Neuerungen werden mit dem Kunden durch ''[[User-Story]]s'' beschrieben.		Die innerhalb der Iterationen umzusetzenden einzelnen Neuerungen werden mit dem Kunden durch ''[[User-Story]]s'' beschrieben.

	Das ganze Team ist bei der Erstellung beteiligt. Die abzuarbeitenden Anforderungen werden auf einzelnen Karten (''Story Cards'') geschrieben und für alle sichtbar platziert. Neben diesem Vorgehen ist es auch üblich ''Class Responsibility Collaboration Models'' auf ''CRC Cards'' zu verfassen. ''CRC Models'' nehmen sich dabei einen Akteur im System vor und beschreiben dessen Verantwortlichkeiten und Interaktionen mit anderen Akteuren.		Das ganze Team ist bei der Erstellung beteiligt. Die abzuarbeitenden Anforderungen werden auf einzelnen Karten ''(Story Cards)'' geschrieben und für alle sichtbar platziert. Neben diesem Vorgehen ist es auch üblich ''Class Responsibility Collaboration Models'' auf ''CRC Cards'' zu verfassen. ''CRC Models'' nehmen sich dabei einen Akteur im System vor und beschreiben dessen Verantwortlichkeiten und Interaktionen mit anderen Akteuren.

	Den ''User-Storys'' werden Prioritätswerte zugeordnet. Dazu muss das Team zusammen mit dem Kunden zunächst Klarheit gewinnen, welche ''User-Storys'' das höchste Risiko bezüglich Zeitplan, Kosten oder Funktionalität besitzen und welche ''User-Storys'' dem [[Produkt (Wirtschaft)\|Produkt]] den höchsten, respektive den niedrigsten Mehrwert bieten, wobei ein Diagramm hilfreich sein kann. Das Release sollte mit den ''User-Storys'' begonnen werden, die das höchste Risiko und den höchsten Nutzen auf sich vereinen. Danach sind diejenige ''User-Storys'' zu verwirklichen, die geringes Risiko aber hohen Nutzen haben. Anschließend geht das Team die ''User-Storys'' an, die geringes Risiko und geringen Nutzen auf sich vereinen. Die Fertigstellung von User-Storys mit geringem Nutzen aber hohem Risiko ist zu vermeiden.		Den ''User-Storys'' werden Prioritätswerte zugeordnet. Dazu muss das Team zusammen mit dem Kunden zunächst Klarheit gewinnen, welche ''User-Storys'' das höchste Risiko bezüglich Zeitplan, Kosten oder Funktionalität besitzen und welche ''User-Storys'' dem [[Produkt (Wirtschaft)\|Produkt]] den höchsten, respektive den niedrigsten Mehrwert bieten, wobei ein Diagramm hilfreich sein kann. Das Release sollte mit den ''User-Storys'' begonnen werden, die das höchste Risiko und den höchsten Nutzen auf sich vereinen. Danach sind diejenige ''User-Storys'' zu verwirklichen, die geringes Risiko aber hohen Nutzen haben. Anschließend geht das Team die ''User-Storys'' an, die geringes Risiko und geringen Nutzen auf sich vereinen. Die Fertigstellung von User-Storys mit geringem Nutzen aber hohem Risiko ist zu vermeiden.
Zeile 114:		Zeile 114:
	[[Datei:Kano-modell.png\|mini\|400px\|links\|Kundenzufriedenheit]]		[[Datei:Kano-modell.png\|mini\|400px\|links\|Kundenzufriedenheit]]

	Neben einer Abschätzung nach Nutzen und Risiko ist für die Entscheidung, welche ''User-Storys'' 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 [[Kano-Modell]]s. Dabei werden in einer systematischen Kundenbefragung Fragen in ''funktionaler Form'' und in ''dysfunktionaler Form'' gestellt. Es lässt sich anschließend bestimmen, welche ''User-Storys'' unbedingt fertiggestellt werden müssen (''Must-haves''), welche linearer Natur sind (je mehr, desto besser; siehe ''[[Linearität\|linear]]''.) und welche ''Exciters'' 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.		Neben einer Abschätzung nach Nutzen und Risiko ist für die Entscheidung, welche ''User-Storys'' 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 [[Kano-Modell]]s. Dabei werden in einer systematischen Kundenbefragung Fragen in ''funktionaler Form'' und in ''dysfunktionaler Form'' gestellt. Es lässt sich anschließend bestimmen, welche ''User-Storys'' unbedingt fertiggestellt werden müssen ''(Must-haves)'', welche linearer Natur sind (je mehr, desto besser; siehe ''[[Linearität\|linear]]''.) und welche ''Exciters'' 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.

	XP zeichnet sich dadurch aus, dass die Betrachtung der Größe einer Einheit, wie Release oder Iteration, unabhängig von ihrer Dauer ist.		XP zeichnet sich dadurch aus, dass die Betrachtung der Größe einer Einheit, wie Release oder Iteration, unabhängig von ihrer Dauer ist.
Zeile 182:		Zeile 182:
	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.		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.

	Die Wiederverwendung bestehender Lösungen, wozu beispielsweise die zahlreichen unterschiedlichen Tests gehören, die stetig automatisiert durchlaufen werden, ist wichtig. <!-- Was ~~soll'n~~ das sein: Selbstgleichheit? Selbstgleichheit zeichnet sich auch dadurch aus, dass Tests immer zusammen mit der Funktionalität entwickelt werden. Wo allerdings ''Verbesserung''spotential identifiziert wird ist die Lösung anzupassen. --> 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 [[Persönlichkeit\|Charakteren]] bestehenden Teams. Verschiedene Meinungen werden nicht nur geduldet, sondern sogar gefördert. Dazu muss ein [[Konfliktmanagement]] etabliert werden.		Die Wiederverwendung bestehender Lösungen, wozu beispielsweise die zahlreichen unterschiedlichen Tests gehören, die stetig automatisiert durchlaufen werden, ist wichtig. <!-- Was soll’n das sein: Selbstgleichheit? Selbstgleichheit zeichnet sich auch dadurch aus, dass Tests immer zusammen mit der Funktionalität entwickelt werden. Wo allerdings ''Verbesserung''spotential identifiziert wird ist die Lösung anzupassen. --> 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 [[Persönlichkeit\|Charakteren]] bestehenden Teams. Verschiedene Meinungen werden nicht nur geduldet, sondern sogar gefördert. Dazu muss ein [[Konfliktmanagement]] etabliert werden.

	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.		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.
Zeile 404:		Zeile 404:
	== Kritik ==		== Kritik ==
	{{Belege fehlen}}		{{Belege fehlen}}

	=== Das Alles-oder-Nichts-Prinzip ===		=== Das Alles-oder-Nichts-Prinzip ===
	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 [[#Der ideale Kunde\|Der ideale Kunde]] und [[#Der ideale Programmierer\|Der ideale Programmierer]]), 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.		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 [[#Der ideale Kunde\|Der ideale Kunde]] und [[#Der ideale Programmierer\|Der ideale Programmierer]]), 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.

Arabsalam: /* XP in Projekten */Bald 20 Jahre her

Arabsalam — Wed, 30 Oct 2024 18:22:48 GMT

XP in Projekten: Bald 20 Jahre her

← Nächstältere Version		Version vom 30. Oktober 2024, 20:22 Uhr
Zeile 388:		Zeile 388:

	== XP in Projekten ==		== XP in Projekten ==
	~~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<ref name="FOR">Forrester Research: '' {{Webarchiv \| url=http://www.forrester.com/Research/Document/Excerpt/0,7211,38334,00.html \| wayback=20071016155709 \| text=Corporate IT Leads The Second Wave Of Agile Adoption}}'' (englisch), 30. November 2005.</ref> (von denen XP die verbreitetste ist) und viele andere einen Einsatz prüfen.		Im Jahr 2005, über zehn Jahre nach den ersten XP-Schritten, erfreuten 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<ref name="FOR">Forrester Research: '' {{Webarchiv \| url=http://www.forrester.com/Research/Document/Excerpt/0,7211,38334,00.html \| wayback=20071016155709 \| text=Corporate IT Leads The Second Wave Of Agile Adoption}}'' (englisch), 30. November 2005.</ref> (von denen XP die verbreitetste ist) und viele andere einen Einsatz prüfen.

	Zu den Nutzern XPs zählten im Juli 2006 sowohl Unternehmen, die kommerziell Software herstellen und vertreiben, als auch Unternehmen, deren eigentliches Geschäft nicht die Erstellung von Software ist: ''Dresdner Kleinwort Wasserstein'', ''[[Encyclopaedia Britannica]]'', ''Fidelity'', ''Progressive'', ''Capital One'', ''Royal & Sunalliance'', ''Channel One'', ''Daedalos International'', ''Gemplus'', ''it-agile'', ''Qwest'' und ''O&O Services''.<ref name="C2COMPDOINGXP">C2: ''[http://www.c2.com/cgi/wiki?CompaniesDoingXp Companies Doing Xp]'' (englisch), 23. Juli 2006.</ref><ref name="OMCOMPDOINGXP">Object Mentor, Inc.: ''{{Webarchiv \| url=http://www.objectmentor.com/ourCustomers/index \| wayback=20060423092645 \| text=Companies using XP, Customers}}'' (englisch), 23. Juli 2006.</ref>		Zu den Nutzern XPs zählten im Juli 2006 sowohl Unternehmen, die kommerziell Software herstellen und vertreiben, als auch Unternehmen, deren eigentliches Geschäft nicht die Erstellung von Software ist: ''Dresdner Kleinwort Wasserstein'', ''[[Encyclopaedia Britannica]]'', ''Fidelity'', ''Progressive'', ''Capital One'', ''Royal & Sunalliance'', ''Channel One'', ''Daedalos International'', ''Gemplus'', ''it-agile'', ''Qwest'' und ''O&O Services''.<ref name="C2COMPDOINGXP">C2: ''[http://www.c2.com/cgi/wiki?CompaniesDoingXp Companies Doing Xp]'' (englisch), 23. Juli 2006.</ref><ref name="OMCOMPDOINGXP">Object Mentor, Inc.: ''{{Webarchiv \| url=http://www.objectmentor.com/ourCustomers/index \| wayback=20060423092645 \| text=Companies using XP, Customers}}'' (englisch), 23. Juli 2006.</ref>

Arabsalam: /* XP in Projekten */Schon lange kein Präsens mehr, laut dem Nachweis [Stand 2013] nutzen einige der genannten Firmen XP nicht mehr

Arabsalam — Wed, 30 Oct 2024 18:19:28 GMT

XP in Projekten: Schon lange kein Präsens mehr, laut dem Nachweis [Stand 2013] nutzen einige der genannten Firmen XP nicht mehr

← Nächstältere Version		Version vom 30. Oktober 2024, 20:19 Uhr
Zeile 390:		Zeile 390:
	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<ref name="FOR">Forrester Research: '' {{Webarchiv \| url=http://www.forrester.com/Research/Document/Excerpt/0,7211,38334,00.html \| wayback=20071016155709 \| text=Corporate IT Leads The Second Wave Of Agile Adoption}}'' (englisch), 30. November 2005.</ref> (von denen XP die verbreitetste ist) und viele andere einen Einsatz prüfen.		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<ref name="FOR">Forrester Research: '' {{Webarchiv \| url=http://www.forrester.com/Research/Document/Excerpt/0,7211,38334,00.html \| wayback=20071016155709 \| text=Corporate IT Leads The Second Wave Of Agile Adoption}}'' (englisch), 30. November 2005.</ref> (von denen XP die verbreitetste ist) und viele andere einen Einsatz prüfen.

	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: ''Dresdner Kleinwort Wasserstein'', ''[[Encyclopaedia Britannica]]'', ''Fidelity'', ''Progressive'', ''Capital One'', ''Royal & Sunalliance'', ''Channel One'', ''Daedalos International'', ''Gemplus'', ''it-agile'', ''Qwest'' und ''O&O Services''.<ref name="C2COMPDOINGXP">C2: ''[http://www.c2.com/cgi/wiki?CompaniesDoingXp Companies Doing Xp]'' (englisch), 23. Juli 2006.</ref><ref name="OMCOMPDOINGXP">Object Mentor, Inc.: ''{{Webarchiv \| url=http://www.objectmentor.com/ourCustomers/index \| wayback=20060423092645 \| text=Companies using XP, Customers}}'' (englisch), 23. Juli 2006.</ref>		Zu den Nutzern XPs zählten im Juli 2006 sowohl Unternehmen, die kommerziell Software herstellen und vertreiben, als auch Unternehmen, deren eigentliches Geschäft nicht die Erstellung von Software ist: ''Dresdner Kleinwort Wasserstein'', ''[[Encyclopaedia Britannica]]'', ''Fidelity'', ''Progressive'', ''Capital One'', ''Royal & Sunalliance'', ''Channel One'', ''Daedalos International'', ''Gemplus'', ''it-agile'', ''Qwest'' und ''O&O Services''.<ref name="C2COMPDOINGXP">C2: ''[http://www.c2.com/cgi/wiki?CompaniesDoingXp Companies Doing Xp]'' (englisch), 23. Juli 2006.</ref><ref name="OMCOMPDOINGXP">Object Mentor, Inc.: ''{{Webarchiv \| url=http://www.objectmentor.com/ourCustomers/index \| wayback=20060423092645 \| text=Companies using XP, Customers}}'' (englisch), 23. Juli 2006.</ref>

	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. ''[[NortonLifeLock\|Symantec]]'' hat seine Änderung des Vorgehensmodells hin zu XP publiziert.<ref name="SYMANTEC">Dr. Dobb’s: ''[http://www.ddj.com/dept/architect/184414801 Going to Extremes]'' (englisch), 2. Januar 2002.</ref> ''Sabre Airline Solutions'' hat mit XP sowohl die Fehler in ihrer Software als auch die Entwicklungszeit reduziert:<ref name="SABRE">Computerworld: ''{{Webarchiv \| url=http://www.computerworld.com/developmenttopics/development/story/0,10801,91646,00.html \| wayback=20090313033625 \| text=Sabre takes extreme measures}}'' (englisch), 29. März 2004.</ref>		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. ''[[NortonLifeLock\|Symantec]]'' hat seine Änderung des Vorgehensmodells hin zu XP publiziert.<ref name="SYMANTEC">Dr. Dobb’s: ''[http://www.ddj.com/dept/architect/184414801 Going to Extremes]'' (englisch), 2. Januar 2002.</ref> ''Sabre Airline Solutions'' hat mit XP sowohl die Fehler in ihrer Software als auch die Entwicklungszeit reduziert:<ref name="SABRE">Computerworld: ''{{Webarchiv \| url=http://www.computerworld.com/developmenttopics/development/story/0,10801,91646,00.html \| wayback=20090313033625 \| text=Sabre takes extreme measures}}'' (englisch), 29. März 2004.</ref>

Alabasterstein: /* Einzelnachweise */ + {{Lesenswert-Abwahl}}

Alabasterstein — Tue, 29 Oct 2024 08:41:19 GMT

Einzelnachweise: + {{Lesenswert-Abwahl}}

← Nächstältere Version		Version vom 29. Oktober 2024, 10:41 Uhr
Zeile 492:		Zeile 492:

	{{Lesenswert\|17. Juli 2006\|19063920}}		{{Lesenswert\|17. Juli 2006\|19063920}}
			{{Lesenswert-Abwahl}}

	[[Kategorie:Vorgehensmodell (Software)]]		[[Kategorie:Vorgehensmodell (Software)]]

Invisigoth67: form

Invisigoth67 — Mon, 10 Jun 2024 09:50:17 GMT

form

← Nächstältere Version		Version vom 10. Juni 2024, 11:50 Uhr
Zeile 152:		Zeile 152:

	=== Entwicklung und Abschluss ===		=== Entwicklung und Abschluss ===
	[[Datei:Extreme Programming Planungs- und Feedback-Schleifen.svg\|mini\|400px\|Zeitlicher Abstand der Schritte.]]		[[Datei:Extreme Programming Planungs- und Feedback-Schleifen.svg\|mini\|400px\|Zeitlicher Abstand der Schritte]]

	Es gibt eine tägliche kurze Besprechung ''(Stand-up Meeting)'', 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 ''([[Pair-Programming]])''. Im Laufe des Tages findet, während die Entwickler die Funktionalität und die Tests programmieren, weiterer stetiger Austausch ''(Pair-Negotiations)'' statt.		Es gibt eine tägliche kurze Besprechung ''(Stand-up Meeting)'', 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 ''([[Pair-Programming]])''. Im Laufe des Tages findet, während die Entwickler die Funktionalität und die Tests programmieren, weiterer stetiger Austausch ''(Pair-Negotiations)'' statt.

← Nächstältere Version		Version vom 30. Oktober 2024, 20:19 Uhr
Zeile 390:		Zeile 390:
	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<ref name="FOR">Forrester Research: '' {{Webarchiv \| url=http://www.forrester.com/Research/Document/Excerpt/0,7211,38334,00.html \| wayback=20071016155709 \| text=Corporate IT Leads The Second Wave Of Agile Adoption}}'' (englisch), 30. November 2005.</ref> (von denen XP die verbreitetste ist) und viele andere einen Einsatz prüfen.		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<ref name="FOR">Forrester Research: '' {{Webarchiv \| url=http://www.forrester.com/Research/Document/Excerpt/0,7211,38334,00.html \| wayback=20071016155709 \| text=Corporate IT Leads The Second Wave Of Agile Adoption}}'' (englisch), 30. November 2005.</ref> (von denen XP die verbreitetste ist) und viele andere einen Einsatz prüfen.

	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: ''Dresdner Kleinwort Wasserstein'', ''[[Encyclopaedia Britannica]]'', ''Fidelity'', ''Progressive'', ''Capital One'', ''Royal & Sunalliance'', ''Channel One'', ''Daedalos International'', ''Gemplus'', ''it-agile'', ''Qwest'' und ''O&O Services''.<ref name="C2COMPDOINGXP">C2: ''[http://www.c2.com/cgi/wiki?CompaniesDoingXp Companies Doing Xp]'' (englisch), 23. Juli 2006.</ref><ref name="OMCOMPDOINGXP">Object Mentor, Inc.: ''{{Webarchiv \| url=http://www.objectmentor.com/ourCustomers/index \| wayback=20060423092645 \| text=Companies using XP, Customers}}'' (englisch), 23. Juli 2006.</ref>		Zu den Nutzern XPs zählten im Juli 2006 sowohl Unternehmen, die kommerziell Software herstellen und vertreiben, als auch Unternehmen, deren eigentliches Geschäft nicht die Erstellung von Software ist: ''Dresdner Kleinwort Wasserstein'', ''[[Encyclopaedia Britannica]]'', ''Fidelity'', ''Progressive'', ''Capital One'', ''Royal & Sunalliance'', ''Channel One'', ''Daedalos International'', ''Gemplus'', ''it-agile'', ''Qwest'' und ''O&O Services''.<ref name="C2COMPDOINGXP">C2: ''[http://www.c2.com/cgi/wiki?CompaniesDoingXp Companies Doing Xp]'' (englisch), 23. Juli 2006.</ref><ref name="OMCOMPDOINGXP">Object Mentor, Inc.: ''{{Webarchiv \| url=http://www.objectmentor.com/ourCustomers/index \| wayback=20060423092645 \| text=Companies using XP, Customers}}'' (englisch), 23. Juli 2006.</ref>

	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. ''[[NortonLifeLock\|Symantec]]'' hat seine Änderung des Vorgehensmodells hin zu XP publiziert.<ref name="SYMANTEC">Dr. Dobb’s: ''[http://www.ddj.com/dept/architect/184414801 Going to Extremes]'' (englisch), 2. Januar 2002.</ref> ''Sabre Airline Solutions'' hat mit XP sowohl die Fehler in ihrer Software als auch die Entwicklungszeit reduziert:<ref name="SABRE">Computerworld: ''{{Webarchiv \| url=http://www.computerworld.com/developmenttopics/development/story/0,10801,91646,00.html \| wayback=20090313033625 \| text=Sabre takes extreme measures}}'' (englisch), 29. März 2004.</ref>		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. ''[[NortonLifeLock\|Symantec]]'' hat seine Änderung des Vorgehensmodells hin zu XP publiziert.<ref name="SYMANTEC">Dr. Dobb’s: ''[http://www.ddj.com/dept/architect/184414801 Going to Extremes]'' (englisch), 2. Januar 2002.</ref> ''Sabre Airline Solutions'' hat mit XP sowohl die Fehler in ihrer Software als auch die Entwicklungszeit reduziert:<ref name="SABRE">Computerworld: ''{{Webarchiv \| url=http://www.computerworld.com/developmenttopics/development/story/0,10801,91646,00.html \| wayback=20090313033625 \| text=Sabre takes extreme measures}}'' (englisch), 29. März 2004.</ref>