Refaktorieren einmal anders: Refaktorieren von Organisationen

Übersicht

Refaktorieren ist ein wesentliches Element in der Programmierung unter Verwendung von XP. Typischerweise wird der Quelltext solange umgearbeitet, bis er im Hinblick auf bestimmte Kriterien wie z.B. Anzahl der Klassen oder Anzahl der Methoden optimiert ist. Funktional bleibt das System dabei unverändert, was wiederum durch Komponententests sichergestellt wird.

Dieser Artikel versucht einen weiteren Anwendungsbereich für das Refaktorieren zu skizzieren, nämlich die Aufbauorganisation in der Softwarentwicklung

Das zweite Projekt

Manchmal beginnen die Probleme, wenn man ein zweites Projekt parallel startet und für dieses zweite Projekt ein weiteres Entwicklungsteam zusammengestellt wird. Es wird dann sehr schnell deutlich, daß es ja Funktionalitäten gibt, die in beiden Projekten benötigt werden. Dann stellt sich die Frage, wie dies organisatorisch gelöst werden soll.

Gemeinsame Nutzung von Quelltext

Eine erste Lösungsmöglichkeit ist die gemeinsame Nutzung von Quelltext. Jedes Team schreibt dann die Komponententests, die es für die eigene Funktionalität benötigt. Dann schreibt das gleiche Programmiererpaar den Quelltext. Die Funktionalität steht dann direkt nach der Integration beiden Teams zur Verfügung.

Dieser Ansatz profitiert von einer unmittelbaren Kommunikation zwischen den Teams. Wenn auf Zuruf klar ist, dass das eine Team jetzt am gemeinsamen Quelltext arbeitet und in welchem Teil, so kann man bereits eine Menge bürokratischen Verwaltungsaufwandes sparen. Durch die Verwendung des Codes in beiden Teams, und weil beide Teams Komponententests beisteuern, wird die Qualität der gemeinsam genutzten Funktionalität in aller Regel besser sein.

Nachteile

Es gibt jedoch auch eine Reihe von Nachteilen. Da stellt sich die Frage, was passiert, wenn ein Team z.B. im Zuge von Refaktorierungen zu der Erkenntnis gelangt, dass eine bestimmte Schnittstelle (oder auch Methode) eine andere Signatur haben sollte? Soll eine Methode zu einer Klasse hinzugefügt werden, auch wenn diese Methode nur von einem Team verwendet wird? Oder soll in diesem Fall dieses eine Team eine abgeleitete Klasse implementieren? Geht das auch so einfach bei Komponenten, die unter Verwendung von Corba bzw. COM implementiert wurden?

Einen Teil der Probleme bekommt man in den Griff, in dem man nur Änderungen erlaubt (natürlich per Konvention, nicht "par ordre du mufti"!), die etwas inkrementell hinzufügen. Darunter fallen dann Änderungen wie zum Beispiel das Hinzufügen von Klassen oder Methoden in der "veröffentlichten" Schnittstelle. Unter veröffentlichter Schnittstelle verstehe ich hier die Menge von Methoden, die von außerhalb einer Klasse oder Komponente aufgerufen werden können. Mindestens für diese existieren also Komponententests. Des weiteren gehe ich davon aus, dass alle Attribute nicht öffentlich zugreifbar sind.

Aber auch mit dieser Konvention sind noch nicht alle Probleme gelöst. Ein weiteres Problem ist: Was passiert mit einer Methode oder Klasse, die von keinem der beiden Teams mehr verwendet wird? Eigentlich sollten diese wieder aus dem Quelltext entfernt werden. Das geht aber nicht, da kein Team für sich allein entscheiden kann, ob das der Fall ist oder nicht. Also bleibt der Code drin mit dem Ergebnis, dass man über die Zeit mehr und mehr "Leichen im Keller" hat. Dies widerspricht auch dem Prinzip des schlichten Designs.

Und noch eine Frage muss bei dieser Lösung geklärt werden. XP sieht eine gemeinsame Verantwortlichkeit für das System und damit auch für den Quelltext vor. Wer ist aber verantworlich, wenn sich wie in diesem Falle, die Verantwortlichkeiten überschneiden?

Refaktorieren der Organization (Organizational Refactoring)

Die gemeinsame Nutzung von Quelltext kann auch auf andere Weise erreicht werden, nämlich durch eine kleine organisatorische Änderung.

Die Funktionalität, die gemeinsam genutzt werden soll, wird einfach in einen separaten Bereich ausgelagert. Dann werden für diesen Bereich mindestens zwei Ingenieure, einer aus jedem Team, abgestellt, die gemeinsam für diesen Bereich verantwortlich sind. Dieses Team, nennen wir es Mini-Team, arbeitet innerhalb der eigenen Verantwortlichkeit nach XP-Prinzipien.

Es sind verschiedene Varianten denkbar. Zum Beispiel könnte es sein, dass das Mini-Team entweder die ganze Zeit tatsächlich existiert; es könnte jedoch ebenso sein, dass es nur ad-hoc zusammengestellt wird. Das Mini-Team kann natürlich aus zwei Mitgliedern desselben Teams bestehen; besser ist es jedoch, aus jedem Team mindestens ein Mitglied zu haben, um den Wissenstransfer über die Teams hinweg zu verbessern.

Vorteile

Dieser Ansatz bringt verschiedene Vorteile:

• Die Kommunikation zwischen den Teams wird intensiviert und nach XP-Prinzipien gestaltet.
• Das Mini-Team hat das Wissen, ob bestimmte Funktionalität überhaupt benutzt wird. Wenn nicht, kann dann auch diese nicht-benutzte Funktionalität wieder entfernt werden. => keine "Leichen im Keller".
• Da aus jedem Team ein Vertreter im Mini-Team sitzt, können bis zu einem gewissen Grad auch Signaturen von Schnittstellen oder Methoden verändert werden, da jeweils auch der Quelltext der anderen Teams modifiziert werden kann.

Einwände

Wie vieles andere hat auch diese Medaille zwei Seiten.

Was passiert, wenn nicht nur zwei sonderen z.B. ein dutzend Teams Quelltext gemeinsam nutzen möchten? In manchen Fällen wäre dann ja das Mini-Team schon größer als alle Einzelteams.

Wenn tatsächlich soviele XP-Teams existieren (gibt es ein Unternehmen, wo das der Fall ist?), dann ist die F&E-Organisation bereits so groß, dass die gemeinsam verwendeten Quelltexte besser wie ein separates Produkt gehandhabt werden. Das Mini-Team wird dann zu einem ganz normalen XP-Team. Die anderen Teams sind dann die Kunden bzw. Anwender und werden jeweils in die Entscheidungen des "Mini-Teams" einbezogen. Das Grundprinzip der vorgestellten Lösung bleibt dabei aber gleich.

Einsatz bei Rahmenwerken

Manchmal werden gemeinsame Funktionalitäten in Rahmenwerken (Frameworks) zusammengefasst. Dies hängt davon ab, welche Software-Architektur verwendet wird. Grundsätzlich funktioniert der hier vorgeschlagene Ansatz auf die gleiche Weise. Das Mini-Team wird permanent oder aber vorübergehend verantwortlich für das Rahmenwerk.

Verwandte Arbeiten

XP in Verbindung mit Organisationsänderungen wurde aus einer anderen Perspektive bereits bei Carsten Jacobi und Bernhard Rumpe auf der XP2000 behandelt. Dieser Beitrag ist auch in "Extreme Programming Examined" enthalten.

Carsten und Bernhard vergleichen verschiedene Reorganisationsansätze mit unterschiedlichen Softwareentwicklungsansätzen, darunter XP. Für die Organisation sehr großer Projekte schlagen sie einen Ansatz vor, den sie als "Hierarchical XP" bezeichnen.

Tipps

• Das Mini-Team besteht aus mindestens zwei Programmierern (damit Paarweises Programmieren funktioniert!)
• Das Mini-Team sollte aus jedem Team mindestens einen Vertreter haben.
• Bei kleinen F&E-Organisationen kann das Team ad-hoc für die Implementierung einer einzelnen Aufgabe oder Benutzergeschichte gebildet und danach wieder aufgelöst werden.