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 / | Vorteil | Details der Vorteile | Empfohlene Plattform | Empfohlene |
|---|---|---|---|---|
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.