Themen
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).
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.
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.
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.
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.
Tabelle 3: XP-Rollen zu RUP-Rollen in einem kleinen Projekt zuordnen
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.
-
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.
|