Collective ownership - aber richtig!
Im Extreme Programming (XP) gibt es bekanntlich den Grundsatz der Collective Ownership. Das ist im Grunde eine tolle Sache, sofern man die damit einhergehenden Fallstricke kennt und vermeidet.
Nehmen wir mal an, daß es in diesem Team nur einen einzígen MA gibt, der sich in sehr spezieller Weise
unkooperativ verhält. Und zwar programmiert dieser MA gelegentlich seine Sachen zwar zuende, "übersieht"
aber immer wieder wichtige Randbedingungen. Oder einzelne Codeteile werden "optimiert", so daß zwar alles
viel schneller geht, aber sich durch die Änderungen bestimmte Seiteneffekte ergeben bzw. grundlegende
Semantiken ändern, was wiederum zu schwer zu findenden Folgefehlern führt.
Zwar werden alle Tests erfolgreich durchgefürt, aber leider decken die Tests nicht die gesamte Funktionalität ab (sowas kommt durchaus vor, zB. bei Legacy-Code).
Der Effekt ist nun der, daß Entwickler A mit einer hinreißenden Performance glänzt und seine Aufgaben wie am Schnürchen erledigt, seine Teammitglieder B und C aber leider die ganzen Fehler ausbügeln müssen, weil sie die ja gefunden haben - und wer den Fehler findet, der darf ihn auch beheben. Entsprechend schlecht ist deren Performance, auch Beschwerden bei A führen zu nichts ... bis sich B und C völllig demotiviert dazu entschließen, ihrerseits eben keine Fehler mehr zu finden.
Der Code wird immer instabiler und das Projekt wird schließlich abgebrochen.
Bei der Ursachenforschung fällt nur auf, daß B und C schlecht gearbeitet haben, jedoch aus irgendeinem unerfindlichen Grund dem fleißigen A, der bis zum Schluß sogar noch Überstunden gemacht hat, die Schuld für den Fehlschlag in die Schuhe schieben wollen.
Bemerkenswert ist, daß sich alle drei Beteiligten bei nüchterner und wertungsfreier Betrachtung der Fakten absolut rational verhalten haben. Schuld am Dilemma ist einfach die fehlerhafte Implementierung des Prozesses: Collective Ownership funktioniert nur dann zuverlässig, wenn ein automatisierter Build- und Testlauf installiert ist und der Code ausreichend mit Unit-Tests abgedeckt wurde, so daß der Großteil der Fehler frühzeitig, zuverlässig und automatisch gefunden werden.