Von Agilisten für Agilisten:das Jazz-Projekt Warum durften sich Entwickler im Züricher IBM-Entwicklungslabor ihre eigene Entwicklungsumgebung schaffen und dabei sorichtig aus dem Vollen schöpfen? Eclipse – etabliert als eine der beiden großen Entwicklungsumgebungen – zeigte von Anfang angroße Akzeptanz unter den Entwicklern, da es dem Entwickler die Arbeit erleichtert und diesen produktiver machte. Etwa zeit-gleich entstanden agile Entwicklungsmethoden, die großes Augenmerk auf die Interaktion der Entwickler setzten und eine engeZusammenarbeit der einzelnen Individuen und Disziplinen notwendig machten. Das bereits im Jahr 2005 ins Leben gerufeneinterne „The Jazz Project“ fand keine den Anforderungen genügende Lösung, die die Produktivität steigernde Methoden durcheine integrierte Lösung für Teams unterstützen könnte. Entstanden ist so die Jazz-Plattform und basierend auf ihr im Jahre 2008als erste eigenständige Lösung für teambasierte Softwareentwicklung Rational Team Concert, welche in den folgenden 3 Jahrenallein IBM intern von ca. 70.000 Entwicklern erfolgreich eingesetzt wurde.

wurde, an dem sich viele Gründungs -mitglieder des IBM-Eclipse-Teams, des IBM-Forschungsbereiches und der neuen IBMRational®-Brand beteiligten. Man suchtenach einer Lösung, die die Zusam menarbeitaller Teammitglieder – insbesondere bei grö-ßeren Projekten mit Projekt mitarbeitern anunterschiedlichen Stand orten – erleichtert.Jedem Projektmitarbeiter sollte ein einfacherZugriff auf die der Rolle entsprechend benö-tigten Informationen ermöglicht werden.

Einfache Bedienbarkeit der neuen Lö -sung wurde gefordert, damit die Werkzeugeals Unterstützung und nicht als Last emp-funden würden. Sie sollten bei der Ein -haltung von Prozessen anleiten und derenDurchführung unterstützen, ohne Zwangauszuüben. Entsprechend des Mottos„Team first“ sollte die neue Lösung auf dieBelange sowie die Prozesse unterschied-licher Teams einstellbar sein.

Bereits nach einem Jahr stellte man dieLösungsansätze auf zwei Konferenzen der

dass skalierbares agiles Vorgehen nur durchunterstützende Werkzeuge erfolgreich wer-den kann [Amb09].

Das Team war jedoch der Ansicht, dassdie seinerzeit auf dem Markt etabliertenWerkzeuge ein Team von solch extremerGröße nur unzureichend unterstützenkonnten. Insbesondere bei der verteiltenZusammenarbeit, gar über unterschiedlicheLänder und Zeitzonen hinweg, wurde dieEffektivität des Teams durch Reibungs -verluste „ausgebremst“. Die unterschied-lichen Werkzeuge waren nur mit erhebli-chem Aufwand zu integrieren. Auch dieNachverfolgbarkeit der Informationenüber unterschiedliche Rollen ließ sich meistnur mit zusätzlichem manuellen Aufwanddarstellen. Der exakte Projektstatus, derfür die Zielorientierung des Teams wichtigist, ließ sich nur schwer ermitteln.

Diese Unzufriedenheit führte schließlichim Jahr 2005 dazu, dass ein IBM-internes„Startup“ – das „Jazz Project“ – geboren

Wie alles begannSeit mehr als 10 Jahren ist IBM® mit einergroßen Zahl von Entwicklern an der Er -stellung und Weiterentwicklung der quell of fe -nen integrierten Entwicklungsumge bungEclipse beteiligt. Das Entwicklerteam ent-schloss sich hier bereits recht früh, nach denim „Agile Manifesto“ [Agi01] beschrie be nenund zu jener Zeit noch wenig verbreiteten agi-len Entwicklungs me tho den vorzugehen.

Als dann im Jahre 2003 Rational Softwarezu IBM stieß, wuchs das Team beträchtlichund der Schwerpunkt der Innovation, derbisher bei der integrierten Entwicklungs -umgebung (IDE) lag, erwei terte sich aufumfassendere Lösungen, die den gesamtenZyklus der Softwareent wicklung unterstüt-zen sollten. Eine engere Abstimmung undZusammenarbeit sowie Koordinierung dereinzelnen Projekte wurden unabdingbar.Obwohl das Agile Mani fest das Individuumund die Zusam men ar beit höher bewertet alsProzesse und Werk zeuge wurde schnell klar,

der au tor

Dr. Hans-Joachim Pross

(hajo.pross@de.ibm.com)ist Client Technical Professional bei der IBM in Köln. Darüber hinaus ist erCommunity of Practice Lead für Change- und Configuration-Management.Nach seinem Studium der Physik arbeitete er zunächst beim Bank-Verlag alsDV-Koordinator, war dann lange Jahre als Berater bei Softlab tätig, ehe er vormehr als 9 Jahren zu IBM Rational wechselte. Dort ist er seither vertriebs-unterstützend für Rational Produkte tätig. Seine aktuellen Schwerpunkte bil-den die Beratung für Lösungen im Bereich Änderungs- und Konfigurations -management, Asset-Management sowie Cloud Computing. Seit 2012 ist erScrum.Org Certified Professional Scrum Master.

Werner Schoepe

(werner.schoepe@de.ibm.com)ist Client Technical Professional bei der IBM in Düsseldorf. Mit seiner 8-jähri-gen Erfahrung bei IBM Rational ist er vertriebsunterstützend für RationalProdukte tätig. Einen Schwerpunkt seiner Tätigkeit bildet die Beratung bei derEinführung von Jazz-basierten Produkten wie Rational Team Concert beiKunden.

1 www.objektspektrum.de

advertorial

Öffentlichkeit vor. Die begeisterten Reak -tionen des Publikums bestätigten, dass mansich auf dem richtigen Weg befand. Manhatte eine Lösung geschaffen, die dieIntegration der unterschiedlichen an derSoftwareentwicklung beteiligten Diszipli nennicht erst im Nachgang als Punkt-zu-Punkt-Integration der genutzten Produkte abbildet,sondern diese gleich bei der Architektur derJazz-Plattform berücksichtigt.

Die grundlegende Idee hierfür wurde ausdem Internet abgeleitet: Alle Artefakte sindüber eine eindeutige URI anzusprechen.Informationen werden nicht dupliziert,sondern lediglich miteinander verbunden.Ferner hatte man in Anlehnung an diePraktiken in der Open Source-Entwicklungvor, jedermann jederzeit Einblick in denStand der Entwicklung zu ermöglichen, ummit den späteren Anwendern frühzeitig inDialog treten zu können. Diese „OpenCommercial Development“ genanntenPraktiken (s. u.) führten dann im Jahre2007 zur Live-Schaltung der Jazz.net-Internetplattform [Jazz™].

Da bereits ab diesem Zeitpunkt die neuentwickelte Plattform auch für derenEntwicklung genutzt wurde, war die imJahr 2008 freigegebene Version 1.0 vonIBM Rational Team Concert™ bereits einausgereiftes Produkt. Bis zum heutigenZeitpunkt wurde Team Concert weiterent-wickelt sowie diverse weitere Produkte aufBasis der Jazz-Plattform erschaffen.

Was kam dabei heraus?Im ersten Wertepaar des Agilen Manifestswird der Fokus auf die Menschen undderen Zusammenarbeit gelegt und bewusstvon den Werkzeugen weggerückt. Zu häu-fig wurden Entwickler in der Vergangenheitdurch komplizierte Werkzeuge, oft einher-gehend mit zähen Prozessen, in ihrerFlexibilität und Kreativität beschnitten.Mit zunehmender Größe und Verteilungvon agilen Projekten bekommen unterstüt-zende Werkzeuge jedoch wieder eine wich-tige Schlüsselstellung.

Die agilen Entwickler von Jazz habengenau hier angesetzt: Eine Lösung, dieMenschen bei ihrer Arbeit unterstützt.Behindert wurden Entwickler oftmalsdurch instabile oder mangelnde Integrationihres „Sammelsuriums der Best of Breed“-Werkzeuge. Medienbrüche sind in solchenWerkzeugketten die Regel.

Um diese Medienbrüche zu verhindern,wurde die Bedienung der auf der Jazz-Plattform basierenden Komponenten in die

Arbeitsumgebung des Entwicklers inte-griert. Neben den IDEs Eclipse oderMicrosoft Visual-Studio© existieren webba-sierte User-Interfaces sowie eine Win dows-Explorer©-Integration. Bestehende Lösun -gen wurden um eine Integration in dieJazz-Plattform erweitert.

Zentraler Bestandteil der komplett neuentwickelten Lösung ist eine Integra tions -plattform – der Jazz Team Server. Dieserstellt Grundfunktionalitäten wie Sicherheit,Benutzerverwaltung, Datenspeicherungsowie Abfragen und Dashboard usw. fürviele Softwareentwicklungswerkzeuge zurVerfügung und bildet damit die Basis fürviele Rational Produkte.

Der Charme der Integrationsplattformbesteht darin, dass nun nicht mehr wie bis-her, jedes einzelne Produkt mit jedem ande-ren an der Lösung beteiligten eine Inte -gration aufweisen muss, sondern jedesProdukt nur noch mit der Integrations -plattform kommuniziert, wodurch dieAnzahl der Integrationen drastisch verrin-gert wird: Z. B. ergeben sich bei sechs zu

integrierenden Produkten sechs statt 15Verbindungen (vgl. Abbildung 2). DieTatsache, dass Integrationen mituntersogar von den Versionen der beteiligtenProdukte abhängen, verstärkt diesen Effektzusätzlich.

Die universelle Integrationsarchitekturwird durch Trennung der Implementierungder Werkzeuge von der Definition und demZugriff der Daten ermöglicht. DieDatenstrukturen folgen offenen Standards(Open Services for Lifecycle Collaboration,kurz OSLC) und sind nicht im Code derProdukte verborgen.

Auch werden grundsätzlich nur loseKopplungen verwendet, sodass die Nicht -verfügbarkeit eines Lösungsbestandteilesnicht gleich die ganze Lösung blockiert,sondern lediglich die gespeichertenVerweise vorübergehend ins Leere führen.

Die Lösung setzt nicht voraus, dass sichalle Daten in einer allumfassenden und zen-tral verwalteten Datenbank befinden müs-sen. Es werden keine Redundanzen durchImport und Export erzeugt. Vielmehr wird

2Online Themenspecial Agility 2012

Online Themenspecial Agility 2012 advertorial

Abb. 1: Schematische Darstellung der Jazz-Architektur

Abb. 2: Vergleich der Anzahl notwendiger Integrationen

den Änderungen zu selektieren – so ist esbeispielsweise leicht möglich, eineFehlerbehebung auszutauschen, aber eineebenfalls erstellte Weiterentwicklung nochnicht abzuliefern.

Das Konzept der verteilten Repositoriesbringt aber auch Nachteile mit sich: DieTatsache, dass alle Anwender das gesamteRepository – also alle Versionen von allenArtefakten – auf dem lokalen Arbeitsplatzvorhalten müssen, wird von Anwendernund Firmen gleichermaßen kritisiert. Vielebemängeln auch die Bedienbarkeit, die oft-mals nur über eine Kommandozeile mög-lich ist. Auch fehlende oder unzureichendeSicherheitskonzepte erschweren den Ein -satz im Unternehmenskontext.

RTC hat die Vorteile der verteiltenSysteme mit denen der zentralen Repo -sitories vereint [Lem11]. Die Entwicklerkönnen unabhängig von einander in ihrem„lokalen Workspace“ arbeiten und beiVorhandensein einer Verbindung zumServer ihre Arbeit mit einem „Check In“ inihrem dazu synchronen „RepositoryWorkspace“ auf dem Server sichern (siehe(a) in Abbildung 4). Erst wenn derEntwickler seine Arbeit fertiggestellt hat,wird er die Ergebnisse in den von allengenutzten „Stream“ liefern (siehe (b) inAbbildung 4). Diese Prozesse sind üblicher-weise durch den Entwickler kontrolliertund werden aus seiner Arbeitsumgebung,der IDE, angestoßen.

wirtschaftlich leben zu können. Deswegenwurde basierend auf der Jazz-Plattform alserstes Produkt Rational Team Concert(RTC) geschaffen – von Agilisten fürAgilisten.

Die wichtigsten Komponenten von RTCsind ein leistungsfähiges Konfigurations-,Änderungs- und Build-Management sowieeine Planungskomponente [WS09], dieneben der agilen Planung für das Teamauch eine persönliche Planung der eigenenArbeitspakete für jeden Entwickler ermög-licht (vgl. Abbildung 3).

Agiles Konfigurations-managementDas Konfigurationsmanagement von RTCwurde zu einer Zeit konzipiert, als dieersten verteilten Konfigurationsmanage-mentsysteme am Markt erschienen. Siesollten dem Benutzer eine möglichst hoheUnabhängigkeit und Flexibilität geben,damit dieser autark, d. h. ohne ständigeVerbindung zu einem Server, in seiner loka-len Umgebung arbeiten kann. Änderungenan Artefakten, die in diesen verteiltenRepositories lokal durchgeführt werden,werden zum Abgleich mit den anderen ver-teilten Repositories oft in „Change Sets“zusammengefasst.

Sofern dieses Zusammenfassen derÄnderungen in Change Sets nach inhalt-lichen Gesichtspunkten erfolgt, ist derAnwender in der Lage, die auszutauschen-

ein offenes, flexibles und verteiltesDatenmodell verwendet, sodass nicht jederBestandteil der Lösung die Datenmodelleder anderen Bestandteile kennen muss. Die„fremden“ Daten zusammen mit derenDarstellung (Rendering) sind durch Nut -zung des Internetprotokolls über eine URLerreichbar und somit leicht in eigene An -wendungen integrierbar.

Die Jazz-Architektur setzt kein Imple -men tierungs-Framework, keine Program -miersprache oder Plattform voraus. Jededas Internet unterstützende Sprache oderPlattform kann verwendet werden, um miteiner Jazz-basierenden Anwendung (überREST-Services) zusammenzuarbeiten.

Open Services for LifecycleCollaboration –herstellerübergreifendeZusammenarbeitDamit auch ALM-Lösungen herstellerüber-greifend integrierbar sind, war es notwen-dig, dass sich die Hersteller in einem offe-nen Standardisierungsgremium einigten[OSLC]. IBM hatte dies initiiert und eineganze Reihe von bedeutenden Herstellernund Anwendern sind dem Gremium beige-treten. Den Autoren ist kein anderer offe-ner Standard bekannt, der das Inte -grationsdilemma für ALM-Lösungenderma ßen umfassend adressiert.

Der gesamte Software-Entwicklungs -zyklus wurde in 15 Domänen unterteilt, diejede für sich einen Mindeststandard vonInformationen definiert, die ein ALM-Werkzeug für die Integration zur Ver -fügung stellen muss. Jedem Anbieter stehtes darüber hinaus frei, diesen Mindest -standard in seinem Werkzeug zu erweitern.

Der OSLC-Ansatz ist stark vonWebtechnologien geprägt. Da alle Datendurch eine URL über das Internetprotokollund REST-Services abrufbar sind, ist esmöglich, aus den Objekten der einzelnenKomponenten der ALM-Lösung ein umfas-sendes Informationsnetzwerk zu erstellen. Ferner ermöglichen die Standards demAnwender, die seiner Ansicht nach jeweilsbeste Komponente in seine Lösung zu inte-grieren oder gar eine bereits genutzteKomponente gegen eine andere auszutau-schen.

Rational Team ConcertDie Jazz-Plattform stellt Grundfunk tio -nalitäten zur Verfügung. Ein agiles Teambenötigt jedoch eine Lösung, um die agilenPraktiken wie z. B. Continuous Integration

advertorial

3 www.objektspektrum.de

Abb. 3: Rational Team Concert

Sobald nun von anderen Teammit -gliedern Änderungen an den Stream gelie-fert wurden, informiert das System in einerspeziellen „Anstehende Änderungen“-Sichtdarüber, dass „mein“ Repository-Work -space im Vergleich zum Stream desProjektes nicht mehr synchron ist. Ob undwann nun ein Entwickler die eingehendenÄnderungen in seine Arbeitsumgebungübernimmt (siehe (c) in Abbildung 4), ent-scheidet dieser selbstbestimmt.

Möchte ein Entwickler noch nicht gelie-ferte Änderungen eines Kollegen, die bishernur in dessen „privaten“ Repository-Work -space verfügbar sind, verwenden, verbindetdieser (vorübergehend) seinen Repository-Workspace mit dem des Kollegen. TeamConcert vergleicht nun den eigenen Repo -sitory-Workspace mit dem des Kollegenund stellt die Änderungen wieder in der„Anstehende Änderungen“-Sicht dar,sodass hier nun ausgewählt werden kann,welche Änderung (Change Sets) manbereits übernehmen möchte und welchenicht (siehe (d) in Abbildung 4).

Das oben bereits erläuterte Konzept derChange Sets bietet eine ganze Reihe vonweiteren Vorteilen für den Anwender:

■ Da Änderungen in Change Sets gesam-melt werden, kann man angefangeneArbeiten jederzeit unterbrechen. Wenneine dringende Tätigkeit eingeschobenwerden muss, obwohl die begonneneArbeit noch nicht fertiggestellt ist undsomit auch nicht an den Stream geliefert

werden kann, besteht die Mög lichkeit,durch ein einziges Kommando alle Ände-rungen eines Change Sets zu suspendie-ren. Nachdem die eingeschobene Arbeitfertiggestellt und an den Stream geliefertist, wird ebenfalls durch ein einzigesKommando der Stand zum Zeitpunktder Unter brechung wiederhergestellt.

■ Change Sets lassen sich mit Arbeits -aufträgen – in Team Concert abgebildetdurch Workitems – verbinden. So isteine Nachverfolgbarkeit von der Storyzum Code möglich. Die „umgekehr-ten“ Fragen wie „Für welches Featurewurde diese Zeile programmiert?“ oder„Wer hat dies geändert?“ sind ebenfallsmit einem Klick zu beantworten.

■ Change Sets lassen sich „rückgängig“machen. So lassen sich leicht noch feh-lerhafte Workitems aus dem Code her-ausnehmen.

■ Der Austausch von Änderungen ist sehreinfach, da diese nahezu beliebig zwi-schen den Workspaces oder Streams„fließen“ können. Dies ist z. B., wieoben bereits beschrieben, für die engeZusammenarbeit an Teilaufgaben hilf-reich. Auch Bugfixes kann man leichtsowohl in den Maintenance- als auch inden Entwicklungs-Stream liefern.

Agile Teams schätzen diese Funktio -nalitäten, weil sie damit in ihrer Zu sam -menarbeit unterstützt werden. Auch geogra-fisch verteilte Teams können profitieren, daRTC nur das Inter net-Protokoll voraussetzt.

Agiles Build-ManagementBuild-Managementsysteme werden in kom-plexen Umgebungen immer wichtiger undhelfen den Agilisten bei der Umsetzung vonContinuous Integration-Konzepten. Bevordie Entwickler ihre Arbeitspakete in denStream liefern, sollten sie auf ihrem priva-ten Workspace einen Build durchführen.Da der Buildserver von RTC eng mit demKonfigurationsmanagement zusammenar-beitet, kann auch dieser private Build aufeinem Server durchgeführt werden unddazu die Konfiguration des privaten Ent -wickler-Workspaces verwenden.

Der Build bekommt bei RTC einenbesonderen Stellenwert, indem er durch eineigenständiges Objekt repräsentiert wird,welches alle Informationen des Build-Kontextes enthält und auf das einfach ausder IDE zugegriffen werden kann. In die-sem Kontext werden Links auf alle ChangeSets (Codeänderungen), die seit dem letz-ten Build hinzugekommen sind, gespei-chert.

Change Sets geben hier wertvolleHinweise auf die neuen Funktionalitätenund somit darauf, was entsprechend zutesten ist. Schlägt ein Build fehl, kann mandurch sukzessives Entfernen der enthalte-nen Change Sets die Ursache für dasFehlschlagen des Build eingrenzen.

Vor jedem Build wird die Konfigurationdes Repositories in einem Snapshot gespei-chert. Damit lässt sich bei fehlgeschlage-nem Build der Zustand des Workspacesjederzeit wiederherstellen. Auch wenn seitdiesem fehlgeschlagenen Build bereits zahl-reiche weitere Änderungen an den Streamgeliefert wurden, kann so die Fehler -behebung auf dem ursächlichen Stand desWorkspace erfolgen.

Zudem werden die Log-Dateien ebenfallsmit dem Build-Objekt verbunden und sindso auch im Nachgang jederzeit leichtzugreifbar. Schlägt ein Build fehl, kann manaus diesem Kontext heraus leicht einenFehler übermitteln, der ebenfalls automa-tisch mit dem Build-Objekt verbundenwird.

KontextbasierteZusammenarbeitEiner der wichtigsten Aspekte bei der agi-len Softwareentwicklung ist die Zusam -menarbeit, die durch kleine Teams und eingemeinsames Büro gewährleistet werdensoll. Aufgrund der Projektgröße konntediese Forderung bei der Entwicklung vonRTC nicht erfüllt werden. Dass Team hat

4Online Themenspecial Agility 2012

Online Themenspecial Agility 2012 advertorial

Abb. 4: Workspace-Konzept in Rational Team Concert

Software in Form eines herunterladbarenMeilensteins zur Verfügung gestellt, sodassauch hier lange vor der Freigabe einer neu-en Version Feedback eingeholt wird.

Integration: Das Ganze istmehr wert, als die Summe derKomponentenRational Team Concert bietet mit seinerumfassenden Lösung für agile Teams einePlanungskomponente, ein Workitem-Management, eine Quellcode-Verwaltung,Unterstützung für fortlaufende Buildssowie anpassbare Prozesse und hilft verteil-ten Teams bei der Zusammenarbeit.

Jede Komponente für sich hat eine inno-vative, an agilen Team-Bedürfnissen ausge-richtete Realisierung bekommen. Derbesondere Mehrwert entsteht jedoch durchdie Verknüpfung der Bereiche miteinander.

Zum einen zeigt er sich schon bei der ein-fachen Installation und Inbetrieb nahme. Dadie Integrationen „out-of-the-box“ mitgelie-fert werden, entsteht hierfür kein zusätzlicherAufwand. Durch die Unterstützung vonOSLC wurde eine offene Lösung geschaffen,die es bei Be darf sogar ermöglicht, einzelneKompo nenten durch bereits imUnternehmen etablierte Werkzeuge zu erset-zen, um bestehende Investitionen zu schüt-zen.

Zum anderen liefern die Integrationen ansich und deren Einbettung in die IDE desAnwenders eine erhebliche Arbeits erleic h -terung, da die Mitarbeiter einfacher undschneller an die benötigten Informationengelangen. ■

Team Concert ermöglicht auch einelösungsübergreifende Verlinkung inRational Quality Manager bzw. RationalRequirements Composer. So kann man sichz. B. zu allen Stories die zugehörigenTestfälle anzeigen lassen.

Kundeneinbindung: „OpenCommercial Development“macht‘s möglichEin ganz wichtiger Aspekt der agilenSoftwareentwicklung ist die Zusammen -arbeit mit dem Kunden. Dies ist beiProdukt entwicklung traditionell seltenmöglich, denn viele Hersteller wollen sichnicht in die Karten schauen lassen.

Für das Jazz-Entwicklungsteam wardurch ihre Beteiligung an Open-Source-Projekten (Eclipse) ein viel offenerer Um -gang mit ihren Kunden und derenAnforderungen selbstverständlich. Konse -quen terweise haben sie auch hier ganz neueWege beschritten, indem sie ihre Ent -wicklung offengelegt haben. Aufwww.jazz.net wird alles veröffentlicht, isteinsehbar und kann kommentiert werden.Kunden haben so immer Einsicht in alleStories und deren Realisierungsstatus.

Als Infrastruktur wurde hierfür schonsehr früh die eigene agile Workitem-Komponente von Rational Team Concertverwendet. Damit wurde das Team selbstsein wichtigster Kunde und merkte sehrfrüh, wenn etwas nicht so funktionierte,wie es sollte. Nach kurzer Zeit war dieQualität auf einem stabilen Niveau, sodassseither jeder zweite Meilenstein für denBetrieb von jazz.net genutzt wird. Kundenwird regelmäßig nach jedem Sprint die

aber erfolgreich eine elektronische Lösunggeschaffen, die hier unterstützen konnte.Weil diese Funktionalität einzigartig amMarkt ist, soll sie hier etwas ausführlicherbeschrieben werden:

■ Artefakte können Links zu beliebigenanderen Artefakten speichern, wodurchdiese zueinander in Kontext gesetztwerden. Beispielsweise kann einWorkitem Links zu anderen Work -items, Change Sets, Builds oder Team -mitgliedern, die sich für dieses Work -item interessieren, aufweisen.

■ Im Kontext der Workitems kann eineDiskussion gestartet werden, sodassalle Teilnehmer die relevanten Infor -mationen immer vor Augen haben.Auch kann aus diesem Kontext gleichein Chat mit einem Teammitglied be -gonnen werden. Der andere bekommtim Chatfenster den Kontext in Formeines Links auf das Workitem mitgelie-fert und kann dieses durch Klicken öff-nen, sodass die weiterführende Infor -mation leicht verfügbar ist. Objektekönnen ins Chatfenster gezogen wer-den, sodass der Chatpartner auch aufdiesen Kontext leicht zugreifen kann.

■ In einem Fenster der IDE werden allerelevanten Ereignisse des Projektesangezeigt. Dies können Zustandsän -derungen von Workitems, erfolgreichewie fehlgeschlagene Builds oder dieBehebung eines Fehlers sein, auf dieman dringend wartet. Auch hier bein-halten alle angezeigten Ereignisse einenLink auf weiterführende Details.

■ Verlinkungen werden automatisierterstellt: Es ist z. B. ausreichend, einWorkitem oder ein Teammitglied ineinem Freitextfeld zu erwähnen, umeinen Querverweis herzustellen. BeiVerweisen auf Teammitglieder erkenntman zusätzlich noch den Online-Statusder betreffenden Person.

Die Technik des Verlinkens ist bei RTCbesonders ausgefeilt: Implizit werden auchRücklinks angelegt, wodurch die Navi -gierbarkeit in beide Richtungen sicherge-stellt ist. Weiterhin sind die Links typisiertund damit für den Nutzer leicht unter-scheidbar. Die Vernetzung der Informa -tionen kann leicht für Auswertungen(Traceability) verwendet werden.

advertorial

5 www.objektspektrum.de

Literatur

[Agi01] Manifesto for Agile Software Development – http://agilemanifesto.org

[Amb09] Scott Ambler – The Agile Scaling Model (ASM): Adapting Agile Methods for Complex

Environments – ftp://ftp.software.ibm.com/common/ssi/sa/wh/n/raw14204usen/RAW14204USEN.PDF

[Jazz] Jazz Community Site – https://www.jazz.net

[Lem11] Jean-Michel Lemieux – Jazz Source Control: Design Objectives –

https://jazz.net/library/article/525

[OSLC] Open Services for Lifcycle Collaboration – http://open-services.net

[Sch09] Werner Schoepe – Der Werkzeugeinsatz bei der Planung von agilen Scrum Projekten –

http://www.sigs-datacom.de/fileadmin/user_upload/zeitschriften/os/2009/Agility/schoepe_OS_agility_09.pdf