Konzept: Agile Verfahren und RUP
Diese Richtlinie erläutert, wie einige der Best Practices der agilen Softwareentwicklung auf RUP-basierte Projekte angewendet werden können.
Beziehungen
Hauptbeschreibung

Themen

Einführung

Rational Unified Process (RUP) ist ein Prozessgerüst, das, im Laufe der Jahre von Rational Software verfeinert, für Softwareprojekte aller Größen breite Anwendung findet. Seit einiger Zeit werden immer mehr so genannte agile Prozesse, wie z. B. eXtreme Programming (XP), SCRUM, Feature-Driven Development (FDD) und die Crystal-Clear-Methodik, als effektive Methoden für das Erstellen kleinerer Systeme verwendet. (Weitere Informationen zur Agile Alliance finden Sie auf der Website www.agilealliance.org.)

Die folgenden Abschnitte sollen den Projektteams helfen, die einige der agilen Verfahren in diesen Methoden bewerten möchten, um festzustellen, welchen Nutzen der vollständigere, von RUP entwickelte Entwicklungsprozess ihnen bringt (weitere Informationen zu RUP finden Sie in der Einführung in RUP).

Übersicht

In der agilen Softwareentwicklung wurden verschiedene synthetische Best Practices erstellt, die sich besonders auf kleine, an einem Ort befindliche Projektteams anwenden lassen. RUP ist für Projektteams jeder Größe geeignet und kann auch auf kleine Projekte gut angewendet werden. Allgemein betrachtet haben RUP und die Prozesse der agilen Entwicklung eine ähnliches Konzept der wichtigen Best Practices, die für die Entwicklung von Qualitätssoftware erforderlich sind, z. B. die Anwendung der iterativen Entwicklung und die Konzentration auf die Benutzer.

In den folgenden Abschnitten wird erläutert, wie einige der Best Practices der agilen Softwareentwicklung auf RUP-basierte Projekte angewendet werden können. Hier stehen die von der Methodik eXtreme Programming (XP) verwendeten Verfahren im Vordergrund. (Weitere Informationen zu XP finden Sie auf der Website http://www.extremeprogramming.org.)

XP-Verfahren

XP umfasst vier grundlegende "Aktivitäten" (Codieren, Testen, Zuhören, Design), die eigentlich eher an den RUP-Disziplinen ausgerichtet sind. Diese XP-Aktivitäten werden mit einer Gruppe von Verfahren ausgeführt, die die Leistung weiterer Aktivitäten, die mit einigen der anderen Disziplinen in RUP übereinstimmen, erfordert. Die XP-Verfahren werden in der Veröffentlichung Extreme Programming Explained wie folgt definiert:

  • Planung: Den Umfang des nächsten Release durch Kombination der Geschäftsprioritäten und technischen Berechnungen schnell bestimmen. Wenn der Plan von der Realität eingeholt wird, den Plan aktualisieren.
  • Kleine Releases: Ein einfaches System schnell produzieren und dann in kurzen Zeitabständen neue Versionen herausgeben.
  • Metapher: Die gesamte Entwicklung mit einer einfachen bildhaften Geschichte, die die Funktionsweise des gesamten Systems erläutert, begleiten.
  • Einfaches Design: Das System muss stets so einfach wie möglich gestaltet werden. Nicht erforderliche Komplexität wird, sobald sie erkannt wird, entfernt.
  • Tests: Programmierer schreiben ständig Einheitentests, die fehlerlos absolviert werden müssen, damit die Entwicklung fortgesetzt werden kann. Kunden schreiben Tests, die zeigen, dass Features fertig gestellt sind.
  • Refactoring: Programmierer strukturieren das System um, um es zu vereinfachen oder flexibler zu gestalten, Duplikate zu entfernen oder die Kommunikation zu verbessern, ohne dabei das Systemverhalten zu ändern.
  • Pair-Programming: Der gesamte Produktionscode wird von zwei Programmierern an einem System geschrieben.
  • Kollektives Eigentumsrecht: Jeder kann jederzeit im gesamten System Code ändern.
  • Fortlaufende Integration: Das System mehrmals am Tag integrieren und Builds erstellen, sobald eine Aufgabe abgeschlossen ist.
  • 40-Stunden-Woche: In der Regel nicht mehr als 40 Stunden pro Woche arbeiten. Niemals länger als eine Woche ununterbrochen Überstunden machen.
  • Kunde vor Ort: Einen realen Benutzer, der Vollzeit Fragen beantworten kann, in das Team holen.
  • Codierungsstandards: Programmierer schreiben den gesamten Code in Übereinstimmung mit Regeln, die Gewicht legen auf Kommunikation über den Code.

Beispielsweise werden Aktivitäten, deren Ausführung sich aus dem Verfahren Planung ergibt, hauptsächlich der RUP-Disziplin Projektmanagement zugeordnet. Einige der RUP-Themen jedoch, wie z. B. das Deployment der freigegebenen Software, werden nicht von XP abgedeckt. Anforderungen werden hauptsächlich außerhalb des XP-Bereichs entwickelt, da der Kunde die Anforderungen definiert und bereitstellt. XP kann, auch weil es für einfachere Entwicklungsprojekte verwendet wird, sehr gut für die von RUP behandelten Problemstellungen in den Disziplinen Konfigurationsmanagement, Änderungsmanagement und Umgebung eingesetzt werden.

XP-Verfahren, die mit RUP kompatibel sind

Bei den Disziplinen , in denen es zwischen XP und RUP Überlappungen gibt, können die folgenden, in XP beschriebenen Verfahren in RUP eingesetzt werden bzw. werden sie bereits in einigen Fällen eingesetzt:

  • Planung: Mit der XP-Richtlinie zur Planung können viele der in der RUP-Disziplin dargestellten Ziele für ein sehr kleines Projekt erreicht werden. Dies ist besonders nützlich für Projekte mit wenigen formalen Abläufen, die keine formalen, temporären Artefakte für das Projektmanagement erstellen müssen.
  • Test-First-Design und Refactoring: Das sind gute Techniken, die in der RUP-Disziplin angewendet werden können. Die Textpraxis von XP, die ein Test-First-Design erfordert, ist eine besonders gut geeignete Methode, Voraussetzungen detailliert zu klären. Das Refactoring lässt sich, wie im nächsten Abschnitt beschrieben, bei größeren Systemen möglicherweise nicht gut abstufen.
  • Fortlaufende Integration: RUP unterstützt dieses Verfahren durch Builds auf der Subsystem- und Systemebene (mit einer Iteration). Komponenten, deren Einheiten bereits getestet wurden, werden in den neu entstehenden Systemkontext integriert und dort getestet.
  • Kunde vor Ort: Viele der RUP-Aktivitäten würden von der Anwesenheit eines Kunden im Team vor Ort stark profitieren, wodurch die Anzahl von benötigten temporären Liefergegenständen, insbesondere Dokumenten, reduziert werden kann. XP hebt den kontinuierlichen und vertrauten Dialog als bevorzugtes Mittel der Kommunikation zwischen Kunde und Entwickler hervor. Wenn jedoch ein System, und sei es nur ein kleines, übergeben werden soll, reicht der Dialog allein nicht aus. XP trägt diesem Umstand in Form von Nachträgen, z. B. Designdokumenten am Ende eines Projekts, Rechnung. XP verhindert zwar nicht das Erstellen von Dokumenten oder anderen Artefakten, sagt jedoch, dass Sie nur solche erstellen sollten, die Sie wirklich benötigen. RUP stimmt damit zwar überein, beschreibt allerdings im Detail, was möglicherweise erforderlich ist, wenn Kontinuität und Vertrautheit nicht ausreichend gegeben sind.
  • Codierungsstandards: RUP hat ein Artefakt, Richtlinien für die Programmierung, die in fast immer als obligatorisch betrachtet wird. (Dies wird in den meisten Projektrisikoprofilen so gehandhabt.)
  • 40-Stunden-Woche: Wie XP rät auch RUP, Überstunden nicht zur Regel zu machen. XP akzeptiert Spielräume für die Gestaltung der Arbeitszeit, daher wird kein festes Limit von 40 Stunden vorgegeben. Softwareentwickler sind bekannt dafür, viele unbezahlte Überstunden zu machen, nur um eine gestellte Aufgabe als abgeschlossen betrachten zu können. Manager müssen diese Praxis nicht unbedingt und willkürlich beenden, sie sollten sie jedoch nicht ausnutzen oder gar als Verpflichtung vorgeben. Stattdessen sollten sie die tatsächlich absolvierten Arbeitsstunden festhalten. Wenn ein Mitarbeiter über einen langen Zeitraum viele Überstunden macht, sollte dies unbedingt untersucht werden. Diese Fragen sind zwischen dem Manager und dem betreffenden Mitarbeiter je nach Einzelfall und unter Berücksichtigung der Meinung der anderen Teammitglieder zu klären. Die 40-Stunden-Grenze ist lediglich eine Richtschnur, wenn auch eine wichtige.
  • Pair-Programming: XP vertritt die Auffassung, dass Pair-Programming gut ist für die Codequalität und für das Arbeitsklima im Team. RUP beschreibt den Vorgang der Codeerstellung zwar nicht so detailliert, es wäre jedoch sicherlich möglich, Pair-Programming in einem RUP-basierten Prozess zu praktizieren. Verschiedene Informationen zum Pair-Programming, z. B. zum Test-First-Design und Refactoring, werden jetzt in Form von White Papern mit RUP bereitgestellt. Es ist sicherlich nicht erforderlich, eines dieser Verfahren in RUP zu verwenden. In einer Teamumgebung mit einer offenen Kommunikationskultur wären die Vorzüge des Pair-Programming bezüglich der Auswirkungen auf die Gesamtkosten des Lebenszyklus nur schwer zu erkennen. In einem intakten Team werden die Mitarbeiter ganz von selbst diskutieren und Probleme lösen, ohne dass sie dazu ausdrücklich verpflichtet werden müssten.

Die Annahme, dass ein guter Prozess auf der "Mikroebene" umgesetzt werden muss, ist oft nicht korrekt und mit manchen Unternehmenskulturen nicht vereinbar. Eine strikte Umsetzung wird daher von RUP nicht befürwortet. Unter bestimmten Bedingungen ist paarweises Arbeiten - sowie einige der anderen teambasierten Verfahren, die von XP befürwortet werden - sicherlich vorteilhaft, da das eine Teammitglied das andere unterstützen kann. Beispiele:

  • In einem frühen Stadium der Teamzusammenstellung
  • In Teams, die mit neuer Technologie keine Erfahrungen haben
  • In Teams, die sich aus erfahrenen und weniger erfahrenen Mitgliedern zusammensetzen.

XP-Verfahren, die sich nicht gut abstufen lassen

Die folgenden XP-Verfahren lassen sich bei größeren Systemen nicht gut abstufen und werden daher in RUP nur unter Vorbehalt verwendet.

  • Metapher: Bei größeren, komplexen Systemen reicht eine Metapher für die Architektur nicht aus. RUP bietet ein sehr viel umfangreicheres Gerüst für die Beschreibung der Architektur, das nicht, wie in Extreme Programming Explained beschrieben, das mehr ist als nur "große Boxen und Verbindungen". Selbst in der XP-Community ist die Metapher inzwischen veraltet. Die Metapher ist kein XP-Verfahren mehr.
  • Kollektives Eigentumsrecht: Ist nützlich, wenn die Mitglieder eines Teams, die für ein kleines System oder Subsystem verantwortlich sind, mit dem gesamten Code vertraut sind. Die Entscheidung, ob alle Teammitglieder in gleicher Weise das Recht haben sollten, an beliebiger Stelle Änderungen vorzunehmen, sollte von der Komplexität des Codes abhängig gemacht werden. Oft ist es schneller und auch sicherer, eine Korrektur von einem einzelnen Mitglied bzw. einem Paar, der bzw. das gegenwärtig am relevanten Codesegment arbeitet, vornehmen zu lassen. Die Vertrautheit mit selbst dem klarsten Code nimmt mit der Zeit rapide ab, insbesondere wenn er algorithmisch komplex aufgebaut ist.
  • Refactoring: In einem großen System ist häufiges Refactoring kein Ersatz für einen Mangel an Architektur. In der Veröffentlichung Extreme Programming Explained wird darauf hingewiesen, dass die Designstrategie von XP auf einem sich stets leicht ändernden Algorithmus basiert. Man bekommt ein einfaches Design, dann macht man es ein wenig komplexer, dann ein wenig einfacher, dann wieder ein wenig komplexer. Das Problem mit dieser Art von Algorithmus besteht darin, dass man dort, wo nur eine groß angelegte Änderung eine Situation verbessern kann, mit einer kleinen Änderung kein Optimum erzielen kann. Die RUP-Architektur stellt Anzeige- und Zugriffsmöglichkeiten bereit, um ein großes, komplexes System flexibel zu machen.
  • Kleines Releases: Die Geschwindigkeit, mit der ein Kunde neue Releases akzeptieren und implementieren kann, hängt von vielen Faktoren ab, normalerweise der Systemgröße, die im Allgemeinen mit dem Einfluss auf die Geschäftsabläufe korreliert. Ein zweimonatiger Zyklus ist für einige Systemtypen möglicherweise viel zu kurz oder aufgrund der Deployment-Logistik nicht möglich.

XP-Verfahren, das Vorsicht erfordert

Abschließend ist festzuhalten, dass auch ein XP-Verfahren, das auf den ersten Blick so aussieht, als könne es mit dem einfachen Design von RUP ausgeführt werden, weiter ausgearbeitet und mit Vorsicht gehandhabt werden muss, bevor es allgemein angewendet werden kann.

  • Einfaches Design
    XP ist sehr stark funktionsbasiert: Benutzer-Storys werden ausgewählt, in Aufgaben zerlegt und dann implementiert. Laut der Veröffentlichung Extreme Programming Explained ist das richtige Design für die Software dann erreicht, wenn alle Tests absolviert wurden, keine Logik-Duplikate vorkommen, alle wichtigen Ziele des Programmierers realisiert wurden und die geringstmögliche Anzahl der Klassen und Methoden erreicht ist. Laut XP-Philosophie darf nichts, was keinen geschäftlichen Nutzen für den Kunden hat, zum Produkt hinzugefügt werden.

    Es gibt hier, ähnlich wie bei den lokalen Optimierungen, ein Problem hinsichtlich der von RUP so genannten nicht funktionalen Anforderungen. Diese Anforderungen bringen dem Kunden ebenfalls geschäftlichen Nutzen, sind jedoch schwieriger als Storys darzustellen. Einige der XP-Vorgaben fallen in diese Kategorie. Auch RUP befürwortet kein Design, das über die Erfordernisse hinausgeht, es befürwortet jedoch sehr wohl ein Design mit einem Architekturmodell, das ein Schlüssel zur Erfüllung der nicht funktionalen Anforderungen ist.

    RUP stimmt also mit XP darin überein, dass das so genannte einfache Design die Ausführung aller Tests umfasst, allerdings mit dem Zusatz, dass dies Tests beinhaltet, die zeigen, dass die Software die nicht funktionalen Anforderungen erfüllt. Dies ist nur dann von großer Bedeutung, wenn die Systemgröße und -komplexität zunehmen, die Architektur vollkommen neu ist oder wenn es viele nicht funktionale Anforderungen gibt. Beispielsweise hat es den Anschein, dass die Notwendigkeit, ein Marshaling für Daten (Betrieb in einer heterogenen verteilten Umgebung) auszuführen, den Code übermäßig komplex gestaltet, dennoch ist es weiterhin im gesamten Programm erforderlich.

Zuordnung von Artefakten für ein kleines Projekt

Wenn RUP für ein kleines Projekt angepasst wird und die Anforderungen des Arbeitsergebnisses entsprechend reduziert werden, wie kann man diese Situation mit dem Äquivalent der Artefakte in einem XP-Projekt vergleichen? Tabelle 1 zeigt eine typische Gruppe von RUP-Artefakten in einem kleinen RUP-Projekt.

XP-Artefakte
RUP-Artefakte
(Beispiel für kleine Projekte)
Storys
Weitere Dokumentation aus Dialogen
Vision
Glossar
Anwendungsfallmodell
Einschränkungen Ergänzende Spezifikationen
Abnahmetests und Einheitentests
Testdaten und Testergebnisse

 Testplan,  Testfall, Testsuite (einschließlich  Testscript und  Testdaten)
Testprotokoll
Zusammenfassung der Testbewertung

Software (Code) Implementierungsmodell
Releases  Produkt (Deployment-Einheit)
 Release-Informationen
Metapher Softwarearchitekturdokument
Design (CRC, UML-Skizze)
Technische und andere Aufgaben
Am Ende erstellt Designdokumente
Unterstützende Dokumentation
Designmodell
Codierungsstandards  Projektspezifische Richtlinien
Arbeitsbereich
Testgerüst und Testtools
 Entwicklungsfall
 Konfiguration der Testumgebung
Release-Plan
Iterationsplan
Geschätzter Aufwand für Storys und Aufgaben
Softwareentwicklungsplan
Iterationsplan
Gesamtplan und Budget Kosten-Nutzen-Analyse
Liste der Risiken
Fortschrittsberichte
Zeitaufzeichnungen für Aufgaben
Messdaten (einschließlich Ressourcen, Umfang, Qualität, Zeit)
Ergebnisprotokollierung
Berichte und Anmerkungen zu Besprechungen
Statusbewertung
Iterationsauswertung
Prüfunterlagen
Mängel (und zugeordnete Daten) Änderungsanfragen
Tools für Codemanagement Projekt-Repository
 Arbeitsbereich
Lösung

Prototypen
Prototyp der Benutzerschnittstelle
Prüfung der Erfolgschancen der Architektur

XP selbst (Empfehlungen und Anleitung)

Liste der Testideen
 Projektspezifische Richtlinien

[Nicht in XP enthalten]

Datenmodell
 Unterstützendes Material für Benutzer

Tabelle 1: Zuordnung von Artefakten für ein kleines Projekt von XP zu RUP

Die Unterteilung der Artefakte variiert zwar auf beiden Seiten, normalerweise stimmen aber die RUP-Artefakte für kleine Projekte recht gut mit denen eines XP-Projekts überein.

Beachten Sie, dass die Tabelle auch einige Artefakte beinhaltet, die nicht von XP abgedeckt werden, jedoch in vielen Projekten benötigt werden. Diese beinhalten ein Datenmodell und Artefakte, die sich auf das Deployment beziehen, z. B.  Unterstützendes Material für Benutzer.

Aktivitäten

RUP definiert eine Aufgabe als Arbeit, die von einer Rolle ausgeführt wurde. Dazu wurden entweder Eingabeartefakte verwendet und umgesetzt oder neue und geänderte Ausgabeartefakte erstellt. RUP zählt diese Aktivitäten auf und kategorisiert sie in Übereinstimmung mit den Disziplinen . Diese Disziplinen sind folgende: Voraussetzungen, Analyse und Design, Deployment und Projektmanagement (unter anderem).

Aktivitäten sind aufgrund der Artefakte, die sie erstellen und verwenden, zeitgebunden: Eine Aktivität kann logisch beginnen, wenn ihre Eingaben verfügbar (und entsprechend ausgereift) sind. Das bedeutet, dass die Aktivitäten von Produzenten und Konsumenten sich zeitlich überschneiden können, wenn der Artefaktstatus dies zulässt, sie müssen nicht in nacheinander ablaufen. Aktivitäten sollen eine Anleitung für die Erstellung eines Artefakts geben und können auch dem Projektleiter bei der Planung helfen.

Eng verbunden mit RUP im Kontext des Lebenszyklus, der Artefakte und Aktivitäten sind die so genannten Best Practices: bewährte Prinzipien der Softwareentwicklung zur Fertigung von Qualitätssoftware nach festgelegtem Zeitplan und Budget. RUP unterstützt und realisiert durch seine Aktivitäten (und deren zugeordnete Artefakte) diese Best Practices, die im gesamten Prozess gegenwärtig sind und die wichtigen RUP-Prinzipien hervorheben. Beachten Sie, dass auch XP den Begriff "Verfahren" verwendet, es gibt jedoch, wie nachfolgend erläutert wird, keine genaue Ausrichtung am RUP-Konzept der Best Practices.

XP präsentiert eine ansprechend einfache Sicht auf die Softwareentwicklung in Form von vier grundlegenden Aktivitäten - Codieren, Testen, Zuhören und Design - die gemäß einiger unterstützender Verfahren (wie in der Veröffentlichung "Extreme Programming Explained", Kapitel 9, erläutert) aktiviert und strukturiert werden müssen. Tatsächlich sind die XP-Aktivitäten, wie schon dargelegt, hinsichtlich des Umfangs näher an den RUP-Disziplinen angesiedelt als an den RUP-Aktivitäten, und viele der Abläufe in einem XP-Projekt (zusätzlich zu den vier grundlegenden Aktivitäten) wurden von ihnen abgeleitet, ausgearbeitet und angewendet.

Es gibt also ein XP-Äquivalent zu den RUP-Aktivitäten, die XP-"Aktivitäten" werden nicht formal als solche bezeichnet oder beschrieben. Wenn Sie z. B. im Kapitel 4, "User Stories", der Veröffentlichung Extreme Programming Installed nachschlagen, finden Sie die Überschrift "Define requirements with stories, written on cards". Das gesamte Kapitel enthält eine Mischung aus Prozessbeschreibungen und Anleitungen, die sich damit befassen, was Benutzer-Storys sind, wie (und von wem) sie erstellt werden sollten. So geht es weiter: In den verschiedenen Abschnitten der XP-Handbücher (unter Überschriften, die mal artefakt-, mal aktivitätsbasiert sind), werden die Begriffe "Erstellte Dinge" (Things Produced) und "Getane Dinge" (Things Done) beschrieben, mit unterschiedlich strikten Vorgaben und unterschiedlicher Detailliertheit.

Der hohe Grad an Vorgaben, den RUP offensichtlich aufweist, resultiert aus seiner Vollständigkeit und größeren Formalität in der Art und Weise, wie Aktivitäten und Ein- und Ausgaben gehandhabt werden. XP hat zwar auch Vorgaben, die Formalität und Detailliertheit werden aber, möglicherweise in dem Bemühen, ein "Leichtgewicht" zu sein, einfach übergangen. Der Mangel der Genauigkeit im Detail ist weder eine Stärke noch eine Schwäche an sich, der Mangel an detaillierten Informationen in XP sollte aber nicht mit Einfachheit verwechselt werden. Dieser Mangel kann von erfahrenen Entwicklern gut bewältigt werden, in vielen Fällen jedoch sind mehr Details eine große Hilfe für neue Teammitglieder und solche, die mit dem Teamansatz in der Softwareentwicklung noch nicht viele Erfahrungen gesammelt haben.

Bei Aktivitäten wie bei Artefakten ist es wichtig, sich auf die gesetzten Ziele zu konzentrieren. Eine Aktivität blind auszuführen, ist niemals eine empfehlenswerte Vorgehensweise. Aktivitäten und zugeordnete Richtlinien sind Mittel zum Erreichen des gesetzten Ziels, bieten jedoch keinen Ersatz für eine klare Definition des Ziels. Dieses Einstellung wird in XP gut zum Ausdruck gebracht und sollte von allen RUP-Benutzern beherzigt werden.

Rollen

In RUP werden Aktivitäten von Rollen (oder, genauer gesagt, von Einzelpersonen oder Gruppen, die die Rolle innehaben) ausgeführt. Rollen haben auch die Verantwortung für bestimmte Artefakte. Die verantwortliche Rolle erstellt normalerweise das Artefakt und stellt sicher, dass alle Änderungen, die von anderen Rollen vorgenommen werden (falls diese zulässig sind), das Artefakt nicht beschädigen. Eine Einzelperson oder Gruppe kann eine oder mehrere Rollen übernehmen. Eine Rolle muss nicht einer bestimmten Position in einer Organisation zugeordnet sein.

Die Veröffentlichung Extreme Programming Explained definiert sieben Rollen für die XP-Programmierung - Kunde (Customer), Tester, Überwacher (Tracker), Coach, Berater (Consultant) und Chef (Big Boss) - und beschreibt deren Verantwortlichkeiten und Kompetenzen. Verweise auf einige diese Rollen werden in einigen anderen XP-Büchern vorgenommen. Der Unterschied in der Anzahl der Rollen bei XP und RUP ist einfach zu erklären:

  • XP deckt nicht alle RUP-Disziplinen ab.
  • XP-Rollen sind eher mit Positionen in einer Organisation (möglicherweise mit verschiedenen Verantwortlichkeiten) als mit RUP-Rollen vergleichbar. Beispielsweise übernimmt der XP-Programmierer eigentlich mehrere RUP-Disziplinen, Implementierung, Codeüberprüfung und Integration, die geringfügig andere Kompetenzen erfordern.

XP- und RUP-Rollen in einem kleinen Projekt

Wenn RUP-Rollen einem kleinen Projekt zugeordnet werden, wird die Anzahl der XP-gleichen Rollen, denen sie entsprechen, erheblich reduziert, und zwar auf 5 Positionen oder Jobtitel. Tabelle 3 (abgeleitet aus RUP) zeigt diese Zuordnung zur entsprechenden XP-Rolle.

XP-Rolle Mitglied eines kleinen RUP-Projektteams (Beispiel) RUP-Rolle
Coach
Berater (Consultant)
Chef (Big Boss)
Sally Slalom, leitende Managerin Projekleiter
 Deployment-Manager
Technischer Prüfer
Konfigurationsmanager
Änderungsmanagementleiter
Customer (Kunde) Stakeholder (wie in der Vision beschrieben)
Managementprüfer
Technischer Prüfer (Anforderungen)
Kunde (Customer)
Chef (Big Boss)
Überwacher (Tracker)
Tom Telemark, leitender Softwareentwickler Systemanalytiker
Anforderungsautor
Designer der Benutzerschnittstelle
Softwarearchitekt
Technischer Prüfer
Testleiter
Testanalytiker

Entwicklerrollen (mit weniger Gewicht)

Programmierer
Tester

Susan Snow, Softwareentwicklerin

Henry Halfpipe, Softwareentwickler (Assist.)

Designer
Implementierer
Technischer Prüfer
Integrator
Testdesigner
Tester
 Technischer Autor
Überwacher (Tracker) Patrick Powder, Verwaltungsassistent Zuständig für die Pflege der Projektwebsite, assistiert der Rolle Projektleitung bei der Planung bzw. zeitlichen Planung von Aufgaben, assistiert der Rolle Änderungsmanagement hinsichtlich der Steuerung der an den Artefakten vorzunehmenden Änderungen. Kann bei Bedarf auch anderen Rollen assistieren.

Tabelle 3: XP-Rollen zu RUP-Rollen in einem kleinen Projekt zuordnen

XP-Verfahren mit RUP verwenden

RUP ist ein Prozessgerüst, in dem bestimmte Prozesse konfiguriert und dann instanziert werden können. RUP muss konfiguriert werden, das ist ein erforderlicher, in RUP selbst definierter Schritt. Daher sollte eine angepasste RUP-Version, d. h., eine RUP-Version, die an die von XP explizit genannten (und entsprechend ableitbaren) Projektmerkmale angepasst wurde, mit XP verglichen werden. Ein so angepasster RUP-Prozess könnte viele XP-Verfahren (z. B. Pair-Programming, Test-First-Design und Refactoring) aufnehmen, wäre aber immer noch identisch mit XP, da RUP die Wichtigkeit der Architektur, der Abstrahierung (in der Modellierung), der Risiken und deren unterschiedliche zeitliche Struktur (Phasen und Iterationen) hervorhebt.

XP ist klar auf die Implementierung von Lightweight-Prozessen für kleine Projekte ausgerichtet. Daher beinhaltet es auch Beschreibungen (zumindest in den Büchern), die nicht vollständig ausgearbeitet sind. In einer XP-Implementierung wird es immer Dinge geben, die während des Betriebs entdeckt, ersonnen oder definiert werden müssen. RUP ist sowohl für Projekte, die in Umfang und Art dem XP-Standard entsprechen, als auch für Projekte, auf die dies nicht zutrifft, einsetzbar. Wie die folgende Literaturübersicht zeigt, ist RUP mit den meisten in der XP-Literatur beschriebenen Verfahren kompatibel.

Vergessen Sie nicht, dass das Besondere an XP ist, dass es sich auf das Unternehmen, die Menschen und die Unternehmenskultur konzentriert. Das ist in allen Projekten wichtig und kann sicherlich auch auf die Projekte angewendet werden, die RUP verwenden. Kleine Projekte können stark profitieren, wenn sie diese Verfahren zusammen einsetzen.

Referenzliteratur zum agilen Prozess

  • eXtreme Programming (XP) (Weitere Informationen finden Sie unter http://www.extremeprogramming.org/more.html.):
    • Extreme Programming Explained: Embrace Change. Kent Beck erläutert die Konzepte und die Philosophie, die hinter XP stehen. Das Buch beschreibt das Was und Warum, jedoch nicht das Wie.
    • Refactoring Improving the Design of Existing Code. Martin Fowler schreibt das erste maßgebende Werk zum Refactoring. Wird in Form von Mustern präsentiert. Enthält viele Beispiele in Java. Dieses Buch erläutert, warum und wie Refactoring durchgeführt wird.
    • Extreme Programming Installed. Von Ron Jeffries, Chet Hendrickson und Ann Anderson. Dieses Buch behandelt bestimmte XP-Verfahren detaillierter als die Veröffentlichung "Extreme Programming Explained". Es erläutert die Programmierung für XP.
    • Planning Extreme Programming. Von Kent Beck und Martin Fowler. Dieses Buch stellt die neuesten Ideen zur Planung von Software in einer Umgebung für schnelle Lieferung vor. Es erläutert, wie ein Projekt mit XP durchgeführt wird.
    • Extreme Programming Examined. Von Giancarlo Succi und Michele Marchesi. Eine abgerundete Dokumentsammlung zu XP2000, die die meisten Themen abdeckt.
    • Extreme Programming in Practice. Von Robert C. Martin und James W. Newkirk. Ein reales Projekt, bei dem XP verwendet wurde, wird in allen Details geschildert.
    • Extreme Programming Explored. Von William C. Wake. Basiert auf der beliebten XPlorations-Website. Spezifische Themen werden im Detail erläutert.
    • Extreme Programming Applied: Playing to Win. Von Ken Auer und Roy Miller. Erfahrungen von Wegbereitern der XP-Anwendung.

Informationen zu anderen Mitgliedern der Agile Alliance finden Sie unter http://www.agilealliance.org.