Kooperation in Softwareprojekten! Lohnt sich das? (Teil 2)

Im ersten Teil dieses Beitrages wurde das Gefangenendilemma vorgestellt. Es zeigt, dass es Situationen gibt, in der die jeweils beste Strategie vom Handeln anderer Personen abhängt. Die Frage, ob ich kooperativ sein oder besser entschlossen meinen eigenen Vorteil suchen soll, lässt sich demnach nicht aus der eigenen subjektiven Sicht allein heraus beantworten.

Wie soll man sich jetzt aber im echten Leben verhalten? Ist das Gefangenendilemma überhaupt in der Praxis anwendbar?

Die letzte Frage kann man eindeutig mit Ja beantworten. Es gibt viele Situationen, die mit dem Gefangenendilemma vergleichbar sind oder waren. So stellte man im ersten Weltkrieg fest, dass in den Schützengräben viele Soldaten auf Kooperation setzten, anstatt sich gegenseitig zu vernichten. So wurden an bestimmten Tageszeiten Feuerpausen eingelegt oder man schoss einfach in die Luft.

Den Soldaten auf beiden Seiten, die täglichem Feuer ausgesetzt waren, wurde nämlich eines sehr schnell klar: Wenn die eigene Seite eine Stellung bombardierte und fünf Feinde tötete, dann antwortete die Gegenseite mit einer Salve und tötete dadurch fünf eigene Kameraden. Spieltheoretisch ist das kein Problem. Im echten Leben dagegen schon.

Verbrüderungen dieser Art waren keine Einzelfälle. Die Generalität begegnete diesem Phänomen mit drastischen Strafen. Wer mit dem Feind kooperierte, wurde erschossen. Doch selbst diese Maßnahme beendete die Kooperation nicht. Erst als man begann, kooperative Truppenteile zu verlegen und an anderen Frontabschnitten einzusetzen, hörten die Verbrüderungen auf. Die Soldaten wurden mit neuen Feinden konfrontiert von denen sie nicht wussten, ob sie kooperieren würden oder nicht. Das Gefangenendilemma begann so zu sagen immer wieder von neuem. Anschauen kann man sich das ganze im Film Joyeux Noël von Christian Carion.

An dieser Stelle sei angemerkt, dass es einen großen Unterschied gibt, wie oft das Gefangenendilemma wiederholt wird. Beim ersten Mal kenne ich meinen Gegner überhaupt nicht. Beim zweiten Mal weiß ich jedoch, wie er sich in der Vergangenheit verhalten hat, und ich kann meine Schlüsse daraus ziehen. Diese Variante nennt sich iteratives Gefangenendilemma.

Zurück zur Frage, wie man sich im echten Leben verhalten sollte. Die geschilderten Verbrüderungen legen ja die Vermutung nahe, dass Kooperation sehr gut funktioniert. Ganz so einfach ist es aber nicht!

Man stelle sich nur einmal vor, wie leicht es wäre, eine auf Kooperation eingestellte Kompanie von Soldaten zu besiegen. Die eigenen Verluste wären nahezu bei null, die des Gegners wären maximal. In der ursprünglichen Geschichte ist dies die Kombination Freispruch und 5 Jahre Gefängnis.

Um herauszufinden, welche Strategie die beste für das iterative Gefangenendilemma ist, veranstaltete Robert Axelrod, ein US-amerikanischer Politikwissenschaftler, ein Computerturnier. Hierzu lud er Im Jahr 1980 die damals bekanntesten Spieltheoretiker ein. Jeder von ihnen entwickelte eine individuelle Strategie für das Gefangenendilemma, die dann jeweils in ein einfaches Computerprogramm umgesetzt wurde. Jedes Programm trat dann in genau 200 Zügen gegen alle anderen und auch gegen sich selbst an.

Die teilnehmenden Programme verfolgten von Beginn an sehr unterschiedliche Strategien. Einige waren sehr einfach, andere basierten auf komplexen statistischen Verfahren. Manche waren kooperativ, also „nett“, andere setzten auf Verrat, waren also „nicht nett“.

Die Siegerstrategie war eine echte Überraschung. Sie stammte von Anatol Rapoport, einem Professor für Psychologie und Mathematik an der University of Toronto, und gehörte zu den einfachsten Programmen im Feld. Sie hieß Tit for tat, auf Deutsch „Wie du mir so ich dir“.

Tit for tat gehörte zu den „netten“ Programmen. Es kooperierte bei jeder ersten Begegnung und richtete sein weiteres Verhalten danach aus, wie sich der andere bei dieser Begegnung benahm. War der Gegner kooperativ, war auch Tit for tat kooperativ. War der Gegner es nicht, sah auch Tit for tat keine Veranlassung „nett“ zu sein. Das vorangegangene Verhalten des Gegners wurde also kopiert. Überrascht von diesem Ergebnis wurde ein zweites, größeres Turnier veranstaltet. Doch auch hier hieß der Sieger Tit for tat.

Insgesamt wurden fünf Turniere gespielt. Bei fast allen gewann Tit for tat. Soweit ich weiß, gab es zum Ende eine bessere Strategie, die jedoch auf der Grundidee von Tit for tat basierte. Nachzulesen ist das ganze übrigens in Axelrods Buch, Die Evolution der Kooperation.

Was aber bedeuten die Ergebnisse dieses Turnier für unser Ausgangsproblem. Führt Kooperation nun automatisch zum Erfolg?

Kooperative Strategien sind meiner Ansicht nach immer dann erfolgreich, wenn wir uns in Situationen befinden, in denen Menschen sich zunächst freundlich begegnen. Leider gilt dies nicht immer für Softwareprojekte. Sehr oft sind Projekte sehr zerfahren und ihre Protagonisten alles andere als freundlich zueinander. Wer nichtsdestotrotz gleich von Beginn an versucht, auf Kosten Anderer zu leben, wird im Einzelfall vielleicht erfolgreich sein. Auf Dauer aber nicht.

Der Erfolg von Tit for tat zeigt auch deutlich, dass unkooperatives Verhalten auf keinen Fall toleriert werden darf. So standen alle rein kooperativen Programme in Axelrods Turnier von Anfang an auf verlorenem Posten. Mit anderen Worten: Wer sich ständig über den Tisch ziehen lässt, ist selber Schuld.

Auf der anderen Seite verdeutlicht Tit for tat aber auch, wie wichtig es ist zu verzeihen. Wer einen Fehler einsieht und wieder kooperativ ist, verdient eine immer eine zweite Chance.

Prima, dann haben wir es ja jetzt: Wie du mir so ich dir und alles ist in Butter!

Nun ja, ganz so einfach ist es nicht. Zugegeben, Tit for tat ist eine gute Wahl aber lange nicht die Beste. Aus meiner Sicht hat diese Strategie einen entscheidenden Fehler.

Welchen? Das erfahrt ihr im dritten und letzten Teil von Kooperation in Softwareprojekten! Lohnt sich das?.

 

Meine Links zum Thema bei del.icio.us:

Blogged with Flock

Tags: