GemeinsameVerantwortlichkeit bedeutet, dass jeder Programmierer im Team grundsätzlich an jedem Teil eines Projekts arbeiten kann und soll und dass er auch überall Änderungen vornehmen darf. Insbesondere bedeutet es auch, dass jeder verpflichtet ist, zu der Lösung von Problemen aktiv beizutragen, sobald sie ihm bewusst sind - "das ist nicht meine Aufgabe" gibt es nicht als Ausrede.

Wichtig in diesem Zusammenhang ist

• ProgrammierenInPaaren, also ein 4-Augen-Prinzip bei allem, was getan wird.
• KomponentenTests und AkzeptanzTests, welche garantieren, dass die durch sie abgedeckte Funktionalität nicht durch Änderungen gefährdet wird.

Diskussion zum Kommunikationsaufwand

Durch GemeinsameVerantwortlichkeit wird der Kommunikationsaufwand gesteigert.

Wie genau hat sich dieser erhöhte Bedarf an Kommunikation bei Euch ausgewirkt? Was wurde zusätzlich kommuniziert, und wie?

Bei uns war der Kommunikationsaufwand unspezifisch [,?] insgesamt aber wesentlich höher. Wir haben inzwischen einen Modulverantwortlichen - wohlgemerkt kein Besitzer.

Der Verantwortliche weiss über Änderungen in seinem Modul bescheid, geändert wird dabei von jedem bei Bedarf.

Durch diese Konstellation gibt's einen bekannten Ansprechpartner (das rumlaufen und "weisst du noch, was da war?") entfällt somit. Andererseits muss derjenige, der einen Fehler gefunden und Zeit hat, nicht zum Verantw. sagen: "In deinem Modul ist ein Fehler, reparier du in mal". -- MichaelJerger --

Habt Ihr eine OffeneArbeitsumgebung?

Ich nehm mal an, dass man das so nennen kann. Der Grossteil des Teams arbeitet in einem Grossraumbüro.

Wie wird der Modulverantwortliche über Änderungen informiert? Wie ist Eure Erfahrung mit BesprechungenImStehen?

Hört sich an, als hättet Ihr eine gute Lösung für Euer Problem gefunden!

Der Modulverantwortliche wird mündlich informiert oder zur Beratung hinzugezogen. BesprechungenImStehen gab's bei uns schon immer, und wenn unbedingt mal gesessen wird, gibt's den Meet'O'Meter von meiner Homepage ( http://www.jerger.org) -- mj --

Diskussion zum Besitzergefühl

Frage: Entwickler, die neu sind in XP-Projekten, haben doch bestimmt ein ausgeprägtes Besitzergefühl für ihren Code. Sind die nicht beleidigt, wenn einfach ein anderes Paar hergeht und den Code, den der andere Entwickler geschrieben hat, heftig refaktorisiert? Wie ist das bei Euch, wie geht Ihr damit um? MatthiasBohlen

Das habe ich tatsächlich bereits am eigenen Leibe erlebt. Das Problem war meiner Meinung nach, dass sich im Team schnell relativ feste, durch gleichartige Design-Vorlieben geprägte Paare gebildet hatten, zwischen denen zu wenig kommuniziert wurde. Das hat zwischenzeitlich zu einer ziemlich gespannten "wir vs. die"-Atmosphäre und recht heftigen Entladungen selbiger geführt.

Als Lösungsansatz hatten wir nach einer emotionalen, aber durchaus konstruktiven Aussprache beschlossen, bewusst häufiger die Programmierpartner zu wechseln und so auch heterogene Paare zu bilden und tiefgreifende Refactorings teamweit zu kommunizieren. Zeitweise haben sich so sogar kurzzeitig Tri- und Quadrupel-Programming-Episoden ergeben.

Nach meinem Eindruck hat dies sehr schnell zu einem deutlich verbesserten Vertrauensverhältnis zwischen den Teammitgliedern geführt. Leider hat die Geschäftsführung aber sehr bald das Team aufgelöst (ich vermute aus mangelndem Vertrauen, den Konflikt positiv lösen zu können), so dass ich nicht wirklich sagen kann, ob es sich um eine langanhaltende Wirkung gehandelt hätte. -- IljaPreuß

Frage: Ist wirklich die Änderung des Codes durch andere das Problem oder eher die Art, wie das geschieht? Wenn man sehr unterschiedliche Auffassungen darüber hat, was gutes Design hat, kann ich mir solche Konflikte sehr gut vorstellen. In XP ist das beste Design ja das Einfachste. Wir haben mit XP-Neulingen häufig darüber Uneinigkeit, wie einfach etwas werden darf (die Neulinge halten häufig die Lösungen der alten XPler für zu einfach). Das hat sich bisher aber immer von selbst gegeben - dauert aber natürlich auch seine Zeit. -- StefanRoock