Child pages
  • ClearQuest-Jira-Migration - Pilotprojektplanung und -ablaeufe
Skip to end of metadata
Go to start of metadata

Welche Jira-Version im Pilotprojekt?

Atlassian bietet zwei Auslieferungsformen für Jira an. Einerseits kann die Anwendung lokal hinter der eigenen Firewall installiert werden. Andererseits bietet Atlassian die SaaS-Version Atlassian Cloud. Hier stellen wir dar, welche Jira-Variante welche Ziele des Pilotprojekts unterstützt.

Cloud

Das Aufsetzen einer Cloud-Instanz ist so einfach wie bei jeder anderen SaaS-Software. Die schnelle Initiierung eines Pilotprojekts ist möglich, ohne sich um Software- und Hardware-Anforderungen kümmern zu müssen. Auch die eigene IT-Abteilung muss nicht ins Pilotprojekt eingebunden werden. Allerdings unterliegt die Cloud-Lösung einigen Beschränkungen, siehe unsere Aufstellung.

Download

Die lokale Installation bietet die volle Flexibilität, extreme Anpassbarkeit und Erweiterbarkeit ohne Einschränkungen. Dank der Installation hinter der Firewall ist die volle Integration mit anderen Systemen z.B. via LDAP gegeben.

Ziele der Evaluation und Wahl der Jira-Plattform

Evaluationsziel /
Motivation der Migration

Vorteil

Details der Vorteile

Empfohlene Plattform
 für das Pilotprojekt

Empfohlene
Deployment-Szenarien

Produktivität erhöhen und Kollaboration verbessern

Einfache und mächtigere Suche

Quicksearch, Simple Search, Smart Search, Advanced Search (JQL)

Cloud

ClearQuest für alte Projekte oder kompletter Ersatz

 

Kollaboration verbessern

Kommentare, Aktivity Streams, Filter teilen, Zeitzonensensitive Zeitstempel, JQL-Anfragen zum Identifizieren von Problemen bei der Zusammenarbeit

Cloud

ClearQuest für alte Projekte oder kompletter Ersatz

 

Bessere Dashboards und Reports

Vorkonfigurierte und individuelle Filter, Dashboards und Gadges, Export, Wallboards

Cloud

ClearQuest für alte Projekte oder kompletter Ersatz

 

Administrativen Aufwand senken und Integration ins Tagesgeschäft verbessern

Tastatur-Shortcuts, IDE-Integration

Cloud

ClearQuest für alte Projekte oder kompletter Ersatz

 

Testproduktivität vorantreiben, indem der Browser zur Arbeitsumgebung in der QS wird (Bonfire)

Vorgänge im Browser erstellen, kommentierbare Screenshots, Issue Collector

Cloud

ClearQuest für alte Projekte oder kompletter Ersatz

Agile Methoden adaptieren

Agiles Projektmanagement fördern

RapidBoard, Scrum Target, Swimlanes, Report-Gadgets und -Wallboards

Cloud

Jira für einzelne Projekte, ClearQuest für alte Projekte oder kompletter Ersatz

 

Kollaboration verbessern

Kommentare, Aktivity Streams, Filter teilen, Zeitzonensensitive Zeitstempel, JQL-Anfragen zum Identifizieren von Problemen bei der Zusammenarbeit

Cloud

Jira für einzelne Projekte, ClearQuest für alte Projekte oder kompletter Ersatz

Den kompletten ALM-Prozess abbilden

Bessere Upstream-Integration

Application Links, Plugins und Schnittstellen ermöglichendie Integration mit Wikis, CRM-Tools, Sharepoint, Integration mit Design-Elementen, Chart-Tools, etc.

Download

ClearQuest für alte Projekte oder kompletter Ersatz

 

Bessere Dashboards und Reports

Vorkonfigurierte und individuelle Filter, Dashboards und Gadges, Export, Wallboards

Cloud

ClearQuest für alte Projekte oder kompletter Ersatz

 

Bessere Downstream-Integration

SVN-, GIT-, Bitbucket-Integration, Fisheye, Crucible, Bamboo oder andere CI-Servers

Download

ClearQuest für alte Projekte oder kompletter Ersatz

Einfache Erweiterbarkeit

Konfiguration: Sehr flexible und elegante Konfiguration von Vorlagen

Vorlagen für alles, Abhängigkeiten zwischen Vorgängen und Projekten, Custom Fields, keine Code-Anpassungen für die meisten Anpassungen.

Download

ClearQuest für alte Projekte oder kompletter Ersatz

 

Anpassung: Custom Fields und Erweiterungen

JAVA-basierte Customization-Möglichkeiten, Plugin-Exchange, API

Download

ClearQuest für alte Projekte oder kompletter Ersatz

Prototypischer Projektplan

Nachfolgend finden Sie einen groben prototypischer Projektplan. Jeder Schritt umfasst spezifische Maßnahmen, die der Pilotteamleiter vorbereiten, durchführen und nachbereiten muss. Zusätzlich ist die kalendarische Zeit ausgewiesen, die aufgrund von Verfügbarkeiten, Kapazitäten, Freigabeprozessen usw. erfahrungsgemäß länger dauert.

Schritt

Maßnahmen

Aufwandschätzung

Kalenderzeit

1

Beteiligte festlegen

Zwei Tage

Eine Woche

2

Beschätzung der priorisierten Anforderungen / Schmerzpunkte der Stakeholder

Drei Tage

Zwei Wochen

3

Entscheidungskriterien, Methode und Timeline formulieren

Der Tage

Zwei Wochen

5

Arbeitsgruppe für Check-ins der Meilensteine aufsetzen

Drei Tage

Zwei Wochen

6

Technische Implementierung starten

Drei Tage (Cloud), fünf Tage (Download)

Eine Woche

9

Schulung der Pilotgruppe

Ein Tag

Ein Tag

10

Launch des Pilotprojekts

Ein Tag

Ein Tag

Iterativ

Umsetzung der Meilensteine

Ein Vierteltag

Eine Stunde

Iterativ

Pilotsystem auf Basis des Feedbacks der Pilotgruppe anpassen

Ein Tag

Ein Tag

12

Externe Beteiligte einbinden und neue Ideen generieren

Ein Tag

Eine Woche

13

Produktions-Deployment planen

Fünf Tage

Zwei Wochen

14

Pilot-Demonstration und Entscheidung

Ein Tag

Eine Woche

Vorbereitung des Pilotprojekts

Nach dem Aufsetzen einer Testinstanz ist es sinnvoll, etwas Zeit in die Planung der Pilotphase zu investieren. In dieser Phase eröffnet sich vor allem die ganze Flexibilität und Anpassbarkeit von Jira. Es ist nicht empfehlenswert, Jira einfach out of the box zu starten, sondern sich die spezifischen Anpassungsmöglichkeiten zunutze zu machen.

Pilot-Aspekt

Aspekt der Jira-Konfiguration

Kommentare

Beteiligte Projekte wählen

Projekt, User

Es ist empfehlenswert, fruchtbaren Boden für das erste Jira-Projekt zu wählen. Dazu gehört, ein Team auszuwählen, das tatsächlich Nutzen aus Jira ziehen will, etwa durch die Abbildung des ALM-Zyklus oder durch die Adaption agiler Methoden für ein neues Projekt. Von zusätzlichem Nutzen ist es, wenn die Beteiligten zu den sog. Early Adopters gehören. Dies ist beim Änderungsmanagement in den ersten Stadien hilfreich.

Vorgangstypen festlegen

Vorgangstypen, Felder und ihre Konfiguration

Jira bringt ein Set an vorkonfigurierten Vorgangstypen und Feldern mit. Diese kann man jederzeit umbenennen, entfernen und verändern. Hier sollte man sicherstellen, dass sie den Projektanforderungen entsprechen. Auch sollten diejenigen Aufgaben identifiziert werden, die andere Felder und Workflows erfordern, und ihnen ein spezifischer Vorgangstyp zugewiesen werden. Dabei sollten auch die spezifischen im Unternehmen gebräuchlichen Begriffe berücksichtigt werden.

Status und Transitions festlegen

Workflows

Vor der Arbeit mit der Workflow-Designer-Funktion ist es empfehlenswert, auf Papier zu planen und Skizzen der Arbeits- und Freigabeprozesse für die einzelnen Vorgangstypen anzufertigen. In vielen Fällen reicht erfahrungsgemäß ein Workflow der Art „Offen -> In Bearbeitung -> Fertiggestellt“ aus. In anderen Fällen wiederum sind komplexe Workflows nötig, die auch die verschiedenen Stadien der Fertigstellung widerspiegeln. Sind im Unternehmen feste Geschäftsprozesse etabliert, können diese einfach in Jira abgebildet werden.

Beteiligte festlegen

Projektrollen

Es ist möglich, für die Projektbeteiligten spezifische Rollen in Jira zu definieren und sie individuellen Nutzern zuzuweisen. Das ist z.B. sinnvoll, wenn in einer Projektrolle festgelegt ist, dass ein Nutzer nach einer bestimmten Transition automatisch zum Bearbeiter wird.

Komponenten, Versionen und Releases planen

Komponenten, Versionen

Die meisten Projekte haben Unterebenen, für die sich Komponenten anbieten. Dies können etwa Teile eines Software-Produkts sein. Dieses Feld kann dafür genutzt werden, Vorgänge, Anforderungen und Change Requests zu gruppieren. Versionen bieten sich an, um Projekte in z.B. in Software-Versionen, Sprints oder (im klassischen Projektmanagement) Meilensteine zu unterteilen.

Training der Pilotgruppe

Atlassian-Partner, Atlassian University

Auch wenn sich die Jira-Implementierung in der Pilotphase befindet, sollten die Nutzer das System kennen und beherrschen. Neben der offiziellen Dokumentation bieten sich hierfür Schulungen und Workshops von Atlassian-Partnern wie //SEIBERT/MEDIA an. Auch Atlassian selbst bietet mit der Atlassian University Trainingsressourcen an.

Business-Metriken

Dashboards, Reports

Die Geschäftsführung, das Portfoliomanagement und die Buchhaltung verlangen für Projekte Key-Performance-Indikatoren und Metriken. In Jira können leistungsfähige Dashboards und Reports für verschiedene Projekte und Geschäftsbereiche erstellt werden, die diese Kennzahlen, Prognosen und Verläufe detailliert und automatisiert generieren und abbilden.

Pilot-System Feinabstimmung adjustments

Schemes / Custom Fields

Es ist nicht immer möglich, schon zu Beginn das ideale Jira-Szenario zu planen. Daher bietet es sich an, agile Prinzipien schon im Pilotprojekt zu adaptieren. Regelmäßige Review-Meetings mit dem Pilotteam sind eine gute Möglichkeit, um das System und seinen Status zu bewerten und anschließend weitere Implementierungen oder Änderungen vorzunehmen.

Use Cases sammeln

Künftige Projekte / Schemes

Es ist sehr sinnvoll, andere Abteilungen einzubinden, die das System bewerten und seine Flexibilität testen. Hier werden schnell Ideen für die Nutzung über die Software-Entwicklung hinaus generiert. Solche Szenarien können mithilfe von individuellen Schemes visualisiert und demonstriert werden.

ClearQuest nicht in Jira kopieren!

Eine Lektion aus vielen Migrationsprojekten lautet: Die Felder und Projekthierarchien aus ClearQuest sollten nicht eins zu eins in Jira übernommen werden. Jira hat den Vorteil, dass man mehr als ein Projekt erstellen und sie passgenau an die Bedürfnisse des aktuellen Teams und des Unternehmens anpassen kann. Zudem sollte man die Möglichkeit nutzen, mit vielen verschiedenen Vorgangstypen arbeiten zu können (Erweiterungen, Change Requests, User Stories, Epics usw.). Jira hat das Zeug, alle Abteilungen des Unternehmens in den ALM-Prozess zu integrieren.

Weniger ist mehr

Eine Gefahr besteht allerdings darin, dass es zu einem Overkill an Konfiguration und Anpassung kommt. Im Pilotprojekt sind Anpassungen nötig und sinnvoll, aber es sind keine 50 Vorgangstypen und zehn Workflows in der Pilot-Iteration erforderlich. Weitere Anpassungen sollten iterativ und je nachdem, welche Teams und Abteilungen involviert sind, vorgenommen werden.