Für eine Person machen offensichtlich einige der Praktiken (ProgrammierenInPaaren, GemeinsameVerantwortlichkeit, BesprechungenImStehen) gar keinen Sinn. Von den restlichen Praktiken kann man aber sicher immer noch profitieren. Siehe auch WardsWiki:ExtremeProgrammingForOne

Für zwei und drei Programmierer mögen noch immer einige Praktiken überflüssig erscheinen (z.B. BesprechungenImStehen).

Ab vier Entwicklern würde ich volles XP erwarten. Je nach Team scheint XP bis zu einer Größe von etwa 20 Entwicklern recht problemlos zu skalieren. RonJeffries berichtet in einem Thread auf comp.software.extreme-programming von einem XP-Projekt bei Tumbleweed mit über 30 Entwicklern in einem Team.

Es gibt auch einige wenige Projekte der Größenordnung von 50 bis 100 Entwicklern, die eine Art XP betreiben. Hauptstrategie scheint dabei zu sein, das Projekt klein zu beginnen, mit wachsender Codebasis das Team zu vergrößern, es schließlich an einem angemessenen Punkt zu teilen und eine Art Kunden-Entwickler-Beziehung zwischen den Subteams herzustellen.

Ja, eine Bekannte PM hat XP mit einer Projektgroesse von 150 Mann bereits erfolgreich praktiziert. Es ging dabei um Änderungen an einem bestehendem Produkt. Zur Kommunikationsreduktion wurde bis zur Modulgroesse von ca. 20-30 Mann hierarchisch modularisiert. -- mj

Kann man das irgendwo nachlesen? -- VolkerGlave

Nein, nachlesen kann man das nirgends, sie hat kein Buch darüber geschrieben :-). Es handelt sich hierbei um ein abgeschlossenes Projekt in München. Die genauen Firmendaten hab ich damals nicht nachgefragt. Es ist auch die Frage berechtigt (ich hab mir diese Frage auch schon gestellt), wieviel XP tatsächlich in diesem Projekt realisiert wurde. Auf jeden Fall gab's (wohl) Pairprogramming, Rotation und FortlaufendeIntegration. -- mj

Das scheint mir kein Muss zu sein. Man kann sich mit Kunden-Lieferanten-Beziehungen zwischen Teams auch jede Menge Probleme einhandeln. So kann ich z.B. eine vorliegende Story nur realisieren, wenn vorher Team B etwas tut. Also muss ich denen eine entsprechende Story schreiben und meine solange ruhen lassen, bis Team B mit der Story fertig ist. Wir haben daher in einem Projekt das Projekt nach Anforderungskanälen geteilt (das Projekt ist aber deutlich kleiner als 150 Personen). Das funktioniert natürlich nur dann, wenn man verschiedene Anforderungskanäle hat - wie z.B. bei Multi-Channeling-Anwendungen. -- StefanRoock

Hört sich interessant an - wie gut funktioniert das mit der gemeinsamen Codebasis? Was für Kommunikation gibt es zwischen den Teams? Wieviel kleiner als 150 Personen ist das Projekt? -- ip

Das Gesamtprojekt hat vielleicht 1.000 bis 1.500 Klassen inkl. Tests. Im Projekt sind so an die 25 Mitarbeiter - Tendenz steigend. Das jeder alles ändern darf, ist kein Problem. Es gibt aber eine sogenannte Architekturgruppe (einfach die 4 besten Entwickler), welche meist die heiklen Änderungen an der gemeinsamen Codebasis durchführen. Es gibt als eine Einschränkung bezüglich GemeinsameVerantwortlichkeit per Konvention. An Kommunikation gibt es jeden morgen in jedem Team eine 15 minütige Lagebesprechung und Aufteilung der Stories. Vor dem Mittagessen findet ein StandupMeeting des Gesamtprojektes statt. Nach jeder Iteration gibt es einen TuningWorkshop für des Gesamtprojekt und anschließend je Team ein PlanungsSpiel. Bei Bedarf gibt es Vorträge oder Workshops über bestimmte Systemteile und Lösungen. -- StefanRoock

Wie groß sind die einzelnen Teams?

4 bis 12 Entwickler. Die Teamteilung ist auch nicht statisch, sondern wird immer mal wieder geändert, wenn das sinnvoll erscheint -- StefanRoock

• WardsWiki:PairProgrammingWithSmallTeams
• WardsWiki:LargeExtremeProgramming
• Upcoming Book: Agile in the Large