MÜNCHEN(kul/hh) - Produktivitätssteigerungen im Bereich der Softwareentwicklung sind nicht unbedingt mit größeren Investitionen verknüpft. Ruhe, so fanden Tom De Marco und Tim Lister von The Atlantic Systems Guild, New York, bei einer Untersuchung heraus, ist das oberste Gebot: Zeitersparnisse bis zu 40 Prozent ließen sich bei der Aufgabenbewältigung unter "Clean Room"-Bedingungen feststellen.

Die beiden Forscher berichteten auf der 8th International Conference on Software Engineering in London über eine Untersuchung, bei der 166 Programmierer aus 35 Unternehmen verschiedener Branchen an der eintägigen Implementierung eines Benchmarktests teilnahmen.

Hintergrund zu dieser Untersuchung bot die Hypothese, daß Leistungsmerkmale auf veränderbare Faktoren wie Umgebung, Störungen oder unternehmensspezifische Strukturen zurückzuführen sind. 1984 fanden deshalb zur Verifizierung der Hypothese die "Coding War Games" statt. Ziel des als Benchmarking-Übung angelegten Experiments war es, Programmierern die Möglichkeit zu geben, ihre Leistung mit der von Kollegen zu vergleichen.

Das Projekt gliederte sich in zwei Abschnitte (siehe Kasten: Versuchsaufbau): Der erste Part endete mit einem "sauberen" Kompilierungslauf, Teil zwei schloß mit kompletter Fertigstellung der Arbeit ab.

Die Versuchspersonen, so berichteten Lister und De Marco, wurden zu Beginn des Experiments in zwei Gruppen mit gleichen Aufgaben, aber unterschiedlichen Testabläufen eingeteilt. So überprüften die Programmierer der ersten Gruppe ihren eigenen Code nicht selbst, sondern führten lediglich einen Schreibtisch-Test durch. In Gruppe zwei konnten die Programmierer - wie gewohnt - ihren eigenen Code auch selbst testen.

Über ihre Arbeitszeiten mußten die Teilnehmer sorgfältig Buch führen. Aufgelistet wurden Arbeitsperioden, Arbeitstyp, Unterbrechungen sowie Gründe von Störungen. Ferner beantwortete jeder Teilnehmer einen ausführlichen Fragebogen, in dem meßbare Werte bezüglich Arbeitsplatz und Umgebung sowie die subjektive Einstellung es Teilnehmers zu diesen Faktoren bestimmt werden sollten. Interessant sind die zeitmäßigen Unterschiede, die bis zum Ende des ersten Abschnitts festzustellen waren. So erledigte die beste Gruppe die gestellte Aufgabe zweimal schneller als der Durchschnitt.

Die Grafik verdeutlicht, wieviel Zeit die Programmierer bis zum Ende des ersten Abschnitts benötigten. Aus der Abbildung geht hervor, daß fast 40 Prozent der Probanden die gestellte Aufgabe in einer Zeit zwischen drei und fünf Stunden lösten. Davon wandten etwa die Hälfte Cobol an. Die längste gemessene Arbeitsdauer unter Cobol belief sich auf fast 15 Stunden, die kürzeste auf gut eineinhalb Stunden.

Was die Teamzusammensetzung angeht, so kommen die Forscher auch hier auf bemerkenswerte Ergebnisse. So bildete innerhalb der Gruppe jeweils der insgesamt schnellste Programmierer mit dem zweitschnellsten ein Team, der, langsamste arbeitete mit dem zweitlangsamsten zusammen und auch die aufgebenden Probanden gehörten mit Ausnahme von drei Programmierern einem Team an, in dem beide Partner ihre Arbeit nicht zu Ende führten.

Es zeigte sich im Rahmen dieser Untersuchung, daß die Arbeitseffizienz einer Testperson relativ sichere Rückschlüsse auf die Leistung des Teamkollegen zuließ. Der Korrelationskoeffizient der Paarleistung betrug 0,79, zeigt also eine hohe Übereinstimmung. Dieser statistisch signifikante Wert zwischen den Teampartnern läßt vermuten, daß die Leistungsfähigkeit auch durch Gegebenheiten des Arbeitsplatzes und -klimas beeinflußt wird.

So scheint die Differenz zwischen den Leistungsergebnissen der beiden Teampartner ein Indikator für die tatsächliche individuelle Leistungsfähigkeit zu sein. Bei 80 Prozent der Paare differierte die Leistung der einzelnen Partner um lediglich 30 Prozent.

Lister und De Marco vermuteten aufgrund ihrer Zwischenergebnisse, daß Leistung in einer direkten Beziehung zur Gestaltung des Arbeitsplatzes steht. Sie baten deshalb die Probanden, einen Fragebogen zur Arbeitsumgebung auszufüllen. Darin wurden objektive Daten bezüglich des Arbeitsplatzes erfragt, gleichzeitig aber auch subjektive Äußerungen der Testteilnehmer verlangt.

Die in freier Form geschriebenen Kommentare der Teilnehmer über ihre Umgebung klingen nicht gerade erfreulich. Viele Programmierer scheinen an ihrer Arbeitsstelle durch ständige Unterbrechungen und Lärm gestört zu werden (siehe Kasten: Zeitablauf) - an eine Verbesserung der Situation glauben sie nicht.

Um nun die Zusammenhänge zwischen Leistung und Umgebung herauszufinden, wurden alle Teilnehmer, die die Übung beendet hatten ergebnisgerecht in vier Gruppen eingeteilt. Auch hierbei ergaben sich interessante Erkenntnisse (siehe Kasten: Umgebungsfaktoren).

So lag die durchschnittliche Leistung der Top-Gruppe mehr als zweimal so hoch als die des schlechtesten Teams. Aus diesen Angaben läßt sich schließen, daß die miteinander verglichenen Gruppen in grundlegend verschiedenen Umgebungen arbeiten.

Programmierer, die Spitzenleistungen erbringen, haben meist einen großzügig angelegten Arbeitsplatz; Störungen werden wenigstens teilweise abgehalten. Dem Unruhefaktor "Telefon" läßt sich in den meisten Fällen dadurch beikommen, daß eine Bürokraft den Anruf entgegennimmt, wenn der Programmierer das Klingeln ignoriert. Außerdem entwickeln die anderen Mitarbeiter ein Bewußtsein dafür, nicht unnötig zu stören. So kommt es zu verhältnismäßig intensiven Arbeitsperioden ohne Unterbrechungen.

Teilnehmer der leistungsmäßig schwächsten Gruppe arbeiten normalerweise in beengten Raumverhältnissen - acht Probanden müssen mit weniger als vier Quadratmetern auskommen. Auf den Störfaktor "Telefon" kann kein Einfluß genommen werden: Die eine Möglichkeit der Rufumleitung besteht nicht. Auf unterbrechungsfreies Arbeiten wird in diesen Fällen keine Rücksicht genommen.

Manager haben in dieser Hinsicht einen besonders schlechten Ruf, So schrieb ein Teilnehmer des Experiments: "Mein Chef stellt das Telefon seiner Sekretärin auf meinen Apparat um, wenn sie nicht da ist." Zwischen den einzelnen Unterbrechungen stehen den Programmierern nur kurze störungsfreie Zeitabschnitte zur Verfügung.

Vorsicht scheint jedoch geboten, um bei solchen Beobachtungen nicht Ursache und Wirkung zu vermischen: Die Annahme, ein besserer und ruhigerer Arbeitsplatz führe zu

___________________________________________________________________________________

Zeitablauf:

Arbeitsperiode Arbeitstyp Wodurch wurde die Periode

beendet?

2:13 - 2:17 Codieren Anruf

2:20 - 2:23 Codieren Chef kam zum Plaudern vorbei

2:26 - 2:29 Codieren Frage des Kollegen

2:31 - 2:39 Codieren Anruf

2:41 - 2:44 Codieren Anruf

___________________________________________________________________________________

höherer Produktivität, ist nicht die einzigmögliche Lösung. Es erscheint auch Plausibel, daß die hohe Produktivität durch großzügigere Raumzuweisung belohnt wurde. Der Theorie zufolge hätten sich nämlich die besten Programmierer aus eigener Kraft zu bequemeren und ruhigeren Bedingungen hochgearbeitet.

Um diese Möglichkeit zu überprüfen, wurden drei Unternehmen analysiert, die neun oder mehr Teams entsandt hatten. Innerhalb dieser einzelnen Betriebe ließen sich keine oder doch nur wenig Unterschiede in den wichtigsten Umgebungsfaktoren feststellen. Die besten Programmierer arbeiteten mehr oder weniger unter gleichen Raum- und Geräuschbedingungen wie die schlechtesten. Umgebungsfaktoren wie Lärm, Privatsphäre und Unterbrechungshäufigkeit können also durchaus der Schlüssel zu grundlegender Steigerung der Produktivität sein.

Versuchsaufbau

Die Übung wurde nach dem Schema von De Marco als offener Wettbewerb durchgeführt. Jedes Unternehmen entsandte zwei freiwilliger Teilnehmer. Die beiden Partner führten die gleiche eintägige Implementierungsaufgabe unter denselben Bedigungen aus. Dabei sollten sie sich sowohl gegenseitig Konkurrenz machen als auch versuchen, den anderen Teilnehmern Paroli zu bieten.

Die Testpersonen arbeiteten während der üblicken Dienstzeiten an ihrem eigenen Platz. Dabei standen ihnen die unternehmenseigenen Maschinen sowie die im Betrieb verwendeten Entwicklungshilfen und Programmiersprachen zur Verfügung. Beide Teampartner verwendeten dieselbe Programmiersprache und die gleiche Unterstützungsumgebung.

Als Aufgabe sollte ein Programm gemäß einer genau festgelegten Spezifikation implementiert werden. Die vorgegebene Software beinhaltete syntaktische und semantische Aufbereitung von Kalenderdaten sowie die Berechnung von Tagesintervallen zwischen spezifizierten Daten, die bis zu acht Jahrhunderte auseinanderliegen konnten.

Die durchschnittliche Läge eines Programms, das diesen Spezifikationen entsprach, betrug 220 Zeilen. Zwei Drittel der Programme waren zwischen 133 und 297 Zeilen lang. Das durchschnittliche Cobolprogramm bestand aus 237 Zeilen.