bootstrap slider

FALLSTUDIE:
Agiles Projekt-management mit Jira

Bild-Quelle: https://goo.gl/MBYhVZ

Im Mittelpunkt der Fallstudie steht die Dokumentation einer möglichen Umsetzung in Jira Software, um agile Softwareentwicklungsprojekte Tool begleitend zu unterstützen. Daneben werden auch beispielhaft Werkzeuge angesprochen, die neben Jira Software notwendig sind, um Softwaresysteme agil entwickeln zu können.

Inhaltsverzeichnis

I.               Abbildungsverzeichnis

II.              Abkürzungsverzeichnis

III.             Tabellenverzeichnis

1                Einleitung
2                Vorstellung des fiktiven Unternehmens
3                Vorstellung des Tools Jira Software
4                Dokumentation der Umsetzung in Jira Software
        4.1             Grundlegende globale Systemeinstellungen
        4.2            Das Lifecycle Level (Feld: Security Level)
        4.3            Von der Geschäftsstrategie bis zum Portfoliomanagement
        4.4            Die Umsetzung des agilen Projektmanagements
        4.5            Die Umsetzung eines Projekts mit Scrum
5                Fazit

IV.              Literaturverzeichnis

I.    Abbildungsverzeichnis

Abb. 1: Grobe Planung der Projekte- und Aufgaben-Strukturen in Jira Software 

Abb. 2: Übersicht aller angelegten Jira-Nutzer 

Abb. 3: Übersicht aller Gruppen in Jira 

Abb. 4: Übersicht der angelegten Rollen 

Abb. 5: Übersicht der Vorgangstypen 

Abb. 6: Übersicht (Teilausschnitt) über die Events 

Abb. 7: Übersicht aller angelegten Projekte 

Abb. 8: Übersicht aller angelegten Berechtigungsschemas, mit Zuordnung zu den Projekten 

Abb. 9: Übersicht über alle angelegten Issue Security Level 

Abb. 10: Übersicht der Verteilung der 20 Lifecycle Levels 

Abb. 11: Erster Teil der Übersicht über angelegte Security Level 

Abb. 12: Zweiter Teil der Übersicht über angelegte Security Level 

Abb. 13: Ausschnitt aus den Berechtigungen für das Portfoliomanagement Projekt 

Abb. 14: Fehlermeldung eines nicht berechtigen Nutzers, auf ein Projekt zugreifen zu dürfen 

Abb. 15: Fehlermeldung eines nicht berechtigen Nutzers, auf ein Issue zugreifen zu dürfen 

Abb. 16: Ausschnitt aus den Berechtigungen für das Portfoliomanagement Projekt 

Abb. 17: Sicht eines Nutzers, auf ein Projekt, aber nicht auf dessen Issues, zugreifen zu dürfen 

Abb. 18: Fehlermeldung eines nicht berechtigen Nutzers, auf ein Issue zugreifen zu dürfen 

Abb. 19: Teilausschnitt nach der Bearbeitung der Lifecycle Level Berechtigungen 

Abb. 20: Anzeige des Boards des Portfoliomanagement-Projekts 

Abb. 21: Anzeige der Issues des Portfoliomanagement-Projekts 

Abb. 22: Screen zur Erstellung eines neuen Portfolio Backlog Item 

Abb. 23: Screen (Reiter: Plandaten) zur Erstellung eines neuen Portfolio Backlog Item 

Abb. 24: Screen (Reiter: Checkliste) zur Erstellung eines neuen Portfolio Backlog Item 

Abb. 25: Workflow für das Portfoliomanagement 

Abb. 26: Anzeige der Einstellungen des Workflow-Übergangs "In Portfolio aufnehmen" 

Abb. 27: Ein Item beim Verschieben von einer aktuellen Spalte zu einer anderen 

Abb. 28: Teilausschnitt des Projektmanagement Berechtigungsschemas 

Abb. 29: Workflow des Projektmanagements 

Abb. 30: Zugeordnete Nutzer zum Projektmanagement 

Abb. 31: Anlegen eines neuen Projekts im agilen Projektmanagement (Reiter: Stammdaten) 

Abb. 32: Anlegen eines neuen Projekts im agilen Projektmanagement (Reiter: Plandaten) 

Abb. 33: Bearbeitung eines neu angelegten Projekts im agilen Projektmanagement (Reiter: Plandaten)

Abb. 34: Bearbeitung eines neu angelegten Projekts im agilen Projektmanagement (Reiter: Story map & TTM-Matrix)

Abb. 35: Bearbeitung eines Projekts im agilen Projektmanagement (Reiter: Technische Schulden) 

Abb. 36: Bearbeitung eines Projekts im agilen Projektmanagement (Reiter: Checkliste) 

Abb. 37: Ein Projekt wird auf dem Board des agilen Projektmanagement verschoben 

Abb. 38: Übersicht Product Backlog mit Sprints in einem Scrum-Projekt 

Abb. 39: Workflow eines Scrum-Projekts 

Abb. 40: Übersicht aktiver Sprint mit Sprint Backlog Items in einem Scrum-Projekt 

Abb. 41: Erstellung eines neuen Product Backlog Item im Scrum-Projekt (Reiter: Checkliste) 

Abb. 42: Erstellung eines neuen Product Backlog Item im Scrum-Projekt (Reiter: Stammdaten)

II.    Abkürzungsverzeichnis

CMS. Content-Management-System Continuous Integration-Server.

Continuous Integration-Server

CRM. Customer-Relationship-Management

RE. Requirements Engineer

TTM-Matrix. Things-that-matter-matrix

III.    Tabellenverzeichnis

Tab. 1: Übersicht der Nutzer-Zuordnungen zu Gruppen

Tab. 2: Übersicht der Nutzer-Zuordnungen zu Rollen

1    Einleitung

Zwischen unternehmerischem Handeln und der Konsumgesellschaft existiert eine Wechselwirkung. Konsumenten fragen immer stärker nach schneller produzierten und optional veränderbaren Waren und Dienstleistungen.

Wenn sich die Bedürfnisse von Menschen verändern, so tragen Konsumenten selbst dazu bei, dass Unternehmen immer stärker über Agilität 1 nachdenken müssen. Das führt in der angesprochenen Wechselwirkung in abschließender Konsequenz dazu, dass Arbeitnehmer auch agiler werden müssen.

Unternehmen produzieren Produkte und/oder Dienstleistungen, auch durch den Einsatz von Softwaretechnik. Dabei sind Unternehmen gezwungen, ihre Produkte und Dienstleistungen schneller im Absatzmarkt zu platzieren (Time-to-Market 2 ). Dies hat nicht nur Einfluss auf die Produktionsprozesse, sondern auch Softwareprozesse sind davon betroffen. Unternehmen können durch einen Wettbewerbsvorteil von agilem Vorgehen erfolgreicher sein. Zu diesem Ergebnis kommt auch eine Studie von Olbert, Prodoehl und Worley (2017), die bestätigt, dass die agilsten Unternehmen einer Branche durchschnittlich 2,7 Mal erfolgreicher sind, als ihre Mitbewerber.

Im Mittelpunkt der Fallstudie steht die Dokumentation einer möglichen Umsetzung in Jira Software, um agile Softwareentwicklungsprojekte Tool begleitend zu unterstützen. Daneben werden auch beispielhaft Werkzeuge angesprochen, die neben Jira Software notwendig sind, um Softwaresysteme agil entwickeln zu können.

Ziel der Fallstudie ist die Beantwortung der Frage, ob Jira Software eine geeignete Anwendung zur Tool begleitenden Umsetzung eines agilen Portfoliomanagements, Projektmanagements und Scrum-Projekts ist.

1 Synonym für: Gewandtheit, Vitalität oder Wendigkeit.
2 Dauer der Produktion und Einführung eines neuen Produkts am Markt.

2    Vorstellung des fiktiven Unternehmens

Die Internet Connection GmbH, mit Sitz in Bonn, beschäftigt 1.700 Mitarbeiter an fünf Standorten (Bonn, Köln, Frankfurt, Düsseldorf und Hamburg). Das Unternehmen wurde 2002 gegründet und ist der drittgrößte Anbieter von Webhosting-Leistungen.

Die Internet Connection GmbH stellt ihre Webserver 3 und dazugehörige Netzwerkanbindungen zur Nutzung zur Verfügung, damit Kunden beispielsweise über eine Domain eine eigene Website betreiben können. Dazu gehört auch die Anbindung an Datenbanken und die Nutzung von ContentManagement-Systemen (CMS) 4 .

Das Unternehmen bietet neben Domain-, Mail- und Webhosting 5 auch dedizierte Server-HostingLösungen 6 mit Windows- und Linux-Servern für seine Kunden an.

Weltweit nutzen mehr als vier Millionen Kunden die Produkte der Internet Connection GmbH, die zu unterschiedlichen Produkt-Paketen zusammengestellt sind.

Die Internet Connection GmbH möchte langfristig ihren Kunden die Möglichkeit anbieten, Produkte ohne ein Basis-Paket, durch das Hinzufügen von Optionen, zu mieten.

Das Unternehmen nutzt bereits ein Customer-Relationship-Management (CRM 7 ), das aber funktional nicht ausreichend ist, um verschiedene Datenerhebungen in einem System zusammenfließen zu lassen.

Darüber hinaus wurden alle Softwareentwicklungsprojekte in der Vergangenheit nach dem Wasserfallmodell durchgeführt. Um zukünftig Produkte schneller auf dem Markt platzieren zu können, muss die intern genutzte Software schneller 8 weiterentwickelt werden. Deshalb ist ein Ziel der Internet Connection GmbH, zukünftig alle Softwareentwicklungsprojekte agil und mittels der Vorgehensweise Scrum durchzuführen. Als Pilot-Projekt wird die Erstellung der CRMEigenentwicklung von Grund auf mit Scrum und agilen Prinzipien umgesetzt. Eine Herausforderung bestand in der Anschaffung und Implementierung diverser Werkzeuge, die für agiles Vorgehen notwendig sind.

3 Computersystem in einem Rechenzentrum, auf dem verschiedene Dienste installiert sind und KundenAccounts einen Teil der Hardware-Ressourcen zugewiesen bekommen, um z. B. eine Webseite betreiben zu können.
4 Ein Softwaresystem, das meistens bei redaktionellen Webauftritten zum Einsatz kommt. Mehrere Redakteure arbeiten gemeinschaftlich an unterschiedlichen Inhalten. Bekannte Vertreter sind Tools wie: Wordpress, Joomla, Drupal oder TYPO3.
5 Beim Domain-Hosting wird eine IP-Adresse in einen Domain-Namen übersetzt. Alle Domain-spezifischen Daten werden auf sogenannten Name-Servern bereitgestellt. Beim Mail-Hosting werden Server und installierte Dienste genutzt, um mittels E-Mail-Adresse mit anderen Menschen elektronisch zu kommunizieren. Beim Webhosting bieten Firmen Computer-Ressourcen an, um Kunden die Möglichkeit zu geben, eine Website bereitzustellen.
6 Sogenannte Dedicated Server nutzen alle Ressourcen des Systems, um einen bestimmten Einsatzzweck zu erfüllen.
7 Ein Softwaresystem, das zur Kundenpflege eingesetzt wird, z. B. durch Festhalten aller Kontaktaufnahmen und deren Inhalten.
8 Bei der Internet Connection GmbH werden durchschnittlich 17 Wochen für die Auslieferung eines Releases benötigt. Dies soll um circa 75 %, auf circa vier Wochen, gesenkt werden.

3    Vorstellung des Tools Jira Software

Jira Software wird von der Firma Atlassian entwickelt, die im Jahr 2002 gegründet wurde und ihren Sitz in London hat.

Der Kern der Anwendung liegt im Sammeln und Verwalten von Vorgängen, die entlang eines Workflows 9 (der erweitert werden kann) bearbeitet werden. Nutzer der Software haben u. a. bei der Handhabung von Feldern und Screens, die an den Workflow angepasst werden können, eine größtmögliche Flexibilität. Das betrifft z. B. auch Rollen, Gruppen und Berechtigungen.

Neben dem Produkt Jira Software bietet Atlassian u. a. die folgenden Softwareprodukte an:

        • Jira Service Desk (IT-Servicedesk und Kundenservice, Fehler-Monitoring)

        • Jira Core (Zentrales Unternehmensmanagement, Projektmanagement)

        • Confluence (Dokumentenmanagementsystem)

Auf dem Atlassian Marketplace sind einige hundert Erweiterungen im Zugriff, mit denen Jira Software um neue Funktionalitäten erweitert werden kann. Mithilfe der JIRA API 10 kann Jira Software in die Unternehmensprozesse integriert werden, um technische Schnittstellen zu realisieren.

9 Ein wiederkehrender Arbeitsablauf, der durch Regeln und Bedingungen flexibel bleibt.
10 Programmierschnittstelle eines Systems, um dieses an bestehende Software-Infrastruktur anzubinden.

4    Dokumentation der Umsetzung in Jira

Nachfolgend ist eine Lösung beschrieben, mit der mittels Agilität und Scrum das Portfoliomanagement, Projektmanagement sowie ein Softwareentwicklungsprojekt der Internet Connection GmbH in Jira Software umgesetzt wurde.

Zur Realisierung wurde Jira Software, in der Cloud-Version, mit zehn Benutzern angewandt. Es kamen keine Apps zum Einsatz.

Abbildung 1 zeigt die grobe Planung der Projekt- und Aufgaben-Strukturen, die in Jira Software umgesetzt wurden.
Mobirise

Abbildung 1: Grobe Planung der Projekte- und Aufgaben-Strukturen in Jira Software

4.1    Grundlegende globale Systemeinstellungen

Für die Bildung von verschiedenen Teams wurden neben dem Administrator, neun weitere Nutzer mit Profilbild und E-Mail-Adresse angelegt. Die Nutzer wurden in der Jira Software auf Administrationsebene (Site Administration) erstellt und sind auf dieser Ebene noch keinen Jira-Projekten zugeordnet. Abbildung 2 veranschaulicht eine Auflistung der angelegten Nutzer.
Mobirise

Abbildung 2: Übersicht aller angelegten Jira-Nutzer

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/admin/
users (zugegriffen: 12. Oktober 2017)

Auf der Administrationsebene wurden darüber hinaus Gruppen angelegt. Abbildung 3 zeigt eine Übersicht in Jira Software und Tabelle 1 die Zuordnungen zwischen Nutzern und Gruppen. Die angelegten Rollen sind in Abbildung 4 dargestellt.
Mobirise

Abbildung 3: Übersicht aller Gruppen in Jira

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/admin/
groups (zugegriffen: 12. Oktober 2017)

Mobirise

Tabelle 1: Übersicht der Nutzer-Zuordnungen zu Gruppen


Mobirise

Abbildung 4: Übersicht der angelegten Rollen

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/secure/
project/ViewProjectRoles.jspa (zugegriffen: 13. Oktober 2017)

Tabelle 1 führt zwei Nutzer auf, die der Gruppe ‚External Teams‘ zugeordnet wurden. Die beiden Anwender arbeiten für einen Dienstleister, der für die Internet Connection GmbH die Programmierung der Software übernommen hat. Die Nutzer, die den drei Tech Team-Gruppen zugeordnet sind, bilden die sogenannten Komponententeams, da die Organisationsform aus einer Mischform eines Funktions- und drei Komponententeams besteht.

Grundsätzlich besteht in Jira Software die Möglichkeit, Berechtigungen auf Gruppen und Rollen anzuwenden. In der Fallstudie wurden die Berechtigungen ausschließlich mit den angelegten Rollen verknüpft.

Tabelle 2 verdeutlicht die Zuordnungen von Nutzern zu Rollen. Die konkrete Umsetzung der Entwicklungsteams wird nicht durch Scrum oder dem Agilen Manifest vorgeschrieben. Es sollte beachtet werden, dass ein Scrum-Team aus Scrum Master, Product Owner und Entwicklungsteam besteht.
Mobirise

Tabelle 2: Übersicht der Nutzer-Zuordnungen zu Rollen


Wie in Abbildung 5 erklärt wird, wurden vier weitere sogenannte ‚Issue Types‘ angelegt: Product, Project, Project Idea und Software.

In Jira Software wurden eigene Events (siehe Abb. 6) angelegt. Events werden benutzt, um diese an einer bestimmten Stelle in einem Workflow auszulösen.
Mobirise

Abbildung 5: Übersicht der Vorgangstypen

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/secure/
admin/ViewIssueTypes.jspa (zugegriffen: 13. Oktober 2017)

Mobirise

Abbildung 6: Übersicht (Teilausschnitt) über die Events

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/secure/
admin/ListEventTypes.jspa (zugegriffen: 14. Oktober 2017)

In der Fallstudie wird beispielsweise ein Event genutzt, um einen Product Owner per E-Mail zu informieren, wenn sein Account als Team Leader in einem Portfolio Backlog Item eingetragen wurde.

Abbildung 7 zeigt alle drei Projekte, die für diese Fallstudie angelegt wurden.
Mobirise

Abbildung 7: Übersicht aller angelegten Projekte

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/secure/
BrowseProjects.jspa (zugegriffen: 14. Oktober 2017)

Die Projekte für die Abbildung eines Portfoliomanagements und Projektmanagements sind vom Typ ‚Business‘. Das Projekt zur Abbildung eines einzelnen Projekts (hier: Contact Manager XL RC 1) ist vom Typ ‚Software‘. Der wesentliche Unterschied besteht darin, dass Projekte vom Typ Software mehrere Taskboards besitzen können.

Da die Internet Connection GmbH das Projekt mit einer Mischform aus Funktionsteam und Komponententeams umsetzt, eignen sich verschiedene Taskboards für die drei Komponententeams. Grundsätzlich können die Komponententeams auch außerhalb der Taskboards auf die Vorgänge zugreifen, die sie nach dem Lifecycle Level und ihrer Rolle(n) sehen dürfen.

Für jedes Projekt wurde ein Berechtigungsschema, wie in Abbildung 8 dargestellt, angelegt.
Mobirise

Abbildung 8: Übersicht aller angelegten Berechtigungsschemas, mit Zuordnung zu den Projekten

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/secure/
admin/ViewPermissionSchemes.jspa (zugegriffen: 14. Oktober 2017)

4.2    Das Lifecycle Level (Feld: Security Level)

Der hier zum Einsatz kommende Wert (Issue Lifecycle Level, siehe Abb. 9) beruht nicht auf einem Prinzip des Agilen Manifest oder der Scrum-Vorgehensweise. 
Mobirise

Abbildung 9: Übersicht über alle angelegten Issue Security Level

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/secure/
admin/ViewIssueSecuritySchemes.jspa (zugegriffen: 13. Oktober 2017)

In Jira Software handelt es sich dabei um ein sogenanntes Issue Security Scheme. Allen drei angelegten Projekten wurde ein Security Scheme zugeordnet. In den Vorgängen (auch: Issues) erscheint ein zusätzliches Feld: Security Level.

Das Lifecyle Level erfüllt drei Aufgaben bei der Internet Connection GmbH:

        • rollenbezogene Anzeige der Issues,

        • Identifikation, auf welchem Teilstück sich ein Vorgang befindet und

        • Filterung nach bestimmten Lifecycle Leveln über Projektgrenzen hinweg.

Zu jedem Issue Security Scheme muss in Jira Software mindestens 1 Issue Security Level angelegt werden. In der Fallstudie wurden 20 Level zur Steuerung eingesetzt (siehe Abb. 10).
Mobirise

Abbildung 10: Übersicht der Verteilung der 20 Lifecycle Levels


Die Abbildung 11 und 12 zeigen die angelegten Level in Jira Software. Jedem Level sind 1..*11 viele Rollen zugeordnet.

In Verbindung mit Workflow-Übergängen lässt sich das Lifecycle Level in Abhängigkeit von Bedingungen (z. B.: Rolle Developer verschiebt Issue) kontrolliert steuern.
Mobirise

Abbildung 11: Erster Teil der Übersicht über angelegte Security Level

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/secure/
admin/EditIssueSecurities!default.jspa?schemeId=10002 (zugegriffen: 13. Oktober 2017)

Mobirise

Abbildung 12: Zweiter Teil der Übersicht über angelegte Security Level

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/secure/
admin/EditIssueSecurities!default.jspa?schemeId=10002 (zugegriffen: 13. Oktober 2017)


11 Bedeutung: ‚1 bis unendlich‘.

Es existiert eine Unterscheidung zwischen Level 9 und 10. Legt ein Nutzer, in der Rolle als Product Owner, einen neuen Vorgang im Product Backlog an, so wird Level 9 vergeben. Beim Anlegen eines neuen Vorgangs durch ein Teammitglied wird Level 10 zugeordnet.

Beispiel: Ein Entwickler identifiziert beim Testen im Rahmen von Integrationstests eine Programmcode-Stelle, aus der eine Idee für eine neue Anforderung entsteht. Der Entwickler stellt ein Issue in Jira Software ein, der den Security Level ‚(Level 10) Projekt -> Product Backlog Item angelegt (Team)‘ erhält. Im Workflow ist zu dem entsprechenden Übergang eine Aktion definiert, sodass der Product Owner eine E-Mail – bei neu angelegten Issues – erhält. Der Product Owner bearbeitet den Vorgang und ordnet diesem den Lifecyle-Level 09 (Feld: Security Level) zu.

Alle Issues bis Level 11 sind bei der Internet Connection GmbH nicht ‚Definition of Ready‘ 12 und dürfen deshalb nicht in Level 12 (User Story wird zur Umsetzung einem Sprint zugeordnet) übergehen.

Wie im Verlauf der Fallstudie noch beschrieben wird, ist der Zugriff auf die Issues über verschiedene Einstiegspunkte möglich: entweder über den direkten Aufruf im Menü ‚Issues‘, von wo auch angelegte Filter aufgerufen werden oder über den Aufruf eines Jira-Projekts und eventuell eines vorhandenen Boards 13 .

12 Eine Liste von Kriterien, die zusammen ein Gate darstellen, das durch Einhaltung aller Kriterien überwunden werden muss.
13 Besteht in der Regel aus einer Tafel mit vier Spalten, die den Weg einer User Story, von der Idee bis zur fertigen Umsetzung, zeigt. Jede User Story wird dabei durch eine Karte symbolisiert, die auf der Tafel von links nach rechts verschoben wird.

4.3    Von der Geschäftsstrategie bis zum Portfoliomanagement

Das Top-Management der Internet Connection GmbH hatte die Idee, den Kundenservice und die Kundenbindung zu verbessern, indem das Kundenverständnis gesteigert wird. Es entstand eine Geschäftsstrategie und daraus wurden drei IT-Strategien abgeleitet. In Jira Software wurden drei Projekte angelegt. Ein Projekt davon wird für das agile Portfoliomanagement genutzt.

Am Beispiel des Portfoliomanagements wird nun nachfolgend das Berechtigungskonzept veranschaulicht. Wie in Abbildung 13 zu sehen, muss ein Nutzer der Rolle ‚EAM‘ 14 zugeordnet sein, um Zugriff auf das Portfoliomanagement und zugehörige Issues zu erhalten.
Mobirise

Abbildung 13: Ausschnitt aus den Berechtigungen für das Portfoliomanagement Projekt

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/secure/
admin/EditPermissions!default.jspa?schemeId=10003 (zugegriffen: 14. Oktober 2017)

Die Abbildungen 14 und 15 verdeutlichen, dass die Nutzerin Claudia Bauer nicht auf das Projekt und auch nicht auf ein spezielles Issue zugreifen darf, was im Portfoliomanagement angelegt wurde.
Mobirise

Abbildung 14: Fehlermeldung eines nicht berechtigen Nutzers, auf ein Projekt zugreifen zu dürfen

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/
projects/ICGMBHAP/board (zugegriffen: 11. Oktober 2017) eines fiktiven Nutzers mit Profilbild von Pexels (2017), verändert durch Ausschnitt – URL: https://www.pexels.com/photo/woman-in-black-scoop-neck-shirt-smiling-38554/ (zugegriffen; 16. September 2017)

Mobirise

Abbildung 15: Fehlermeldung eines nicht berechtigen Nutzers, auf ein Issue zugreifen zu dürfen

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/
projects/ICGMBHAP/issues/?filter=allissues (zugegriffen: 11. Oktober 2017)

Die Nutzerin ist der Rolle ‚Software Designer‘ zugeordnet. Werden die Berechtigungen dahingehend geändert (siehe Abb. 16), kann Frau Bauer auf das Projekt zugreifen (siehe Abb. 17), aber keine Issues in dem Portfolio sehen (siehe Abb. 18).
Mobirise

Abbildung 16: Ausschnitt aus den Berechtigungen für das Portfoliomanagement Projekt

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/secure/
admin/EditPermissions!default.jspa?schemeId=10003 (zugegriffen: 14. Oktober 2017)

Mobirise

Abbildung 17: Sicht eines Nutzers, auf ein Projekt, aber nicht auf dessen Issues, zugreifen zu dürfen

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/
projects/ICGMBHAP/board (zugegriffen: 14. Oktober 2017) eines fiktiven Nutzers mit Profilbild von Pexels (2017), verändert durch Ausschnitt – URL: https://www.pexels.com/photo/woman-in-black-scoop-neck-shirt-smiling-38554/ (zugegriffen; 16. September 2017)

Mobirise

Abbildung 18: Fehlermeldung eines nicht berechtigen Nutzers, auf ein Issue zugreifen zu dürfen

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/
projects/ICGMBHAP/issues/?filter=allissues (zugegriffen: 14. Oktober 2017) eines fiktiven Nutzers mit Profilbild von Pexels (2017), verändert durch Ausschnitt – URL: https://www.pexels.com/photo/woman-in-black-scoop-neck-shirt-smiling-38554/ (zugegriffen; 16. September 2017)


14 Ein Enterprise Architecture Management ist für die strategische Ausgestaltung der gesamten IT-Landschaft in einem Unternehmen zuständig. Es legt die Strategie fest und bestimmt die Investitionen.

Selbst wenn die Anwenderin Frau Bauer alle weiteren Berechtigungen für das Portfoliomanagement besitzen würde, würde die Nutzerin keine Issues angezeigt bekommen. In Abbildung 10 ist zu erkennen, dass beispielsweise Lifecycle Level 3 bis 5 dem Portfoliomanagement zugeordnet wurden. Werden die Berechtigungen in den entsprechenden Lifecycle Leveln geändert (siehe Abb. 19), so kann die Anwenderin die Vorgänge sehen (siehe Abb. 20 und 21).
Mobirise

Abbildung 19: Teilausschnitt nach der Bearbeitung der Lifecycle Level Berechtigungen

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/secure/
admin/EditIssueSecurities!default.jspa?schemeId=10002 (zugegriffen: 14. Oktober 2017)

Mobirise

Abbildung 20: Anzeige des Boards des Portfoliomanagement-Projekts

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/
projects/ICGMBHAP/board (zugegriffen: 14. Oktober 2017) eines fiktiven Nutzers mit Profilbild von Pexels (2017), verändert durch Ausschnitt – URL: https://www.pexels.com/photo/woman-in-black-scoop-neck-shirt-smiling-38554/ (zugegriffen; 16. September 2017)

Mobirise

Abbildung 21: Anzeige der Issues des Portfoliomanagement-Projekts

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/
projects/ICGMBHAP/issues/?filter=allissues (zugegriffen: 14. Oktober 2017) eines fiktiven Nutzers mit Profilbild von Pexels (2017), verändert durch Ausschnitt – URL: https://www.pexels.com/photo/woman-in-black-scoop-neck-shirt-smiling-38554/ (zugegriffen; 16. September 2017) und eines fiktiven Nutzers mit Profilbild von Pexels (2017), verändert durch Ausschnitt – URL: https://www.pexels.com/photo/adult-beautiful-blonde-blur-324658/ (zugegriffen; 16. September 2017)

Im Portfoliomanagement (dem Portfolio Backlog) werden Projekte, Produkte oder Anwendungen (siehe Abb. 22, Feld: ‚Issue Type‘) in einem zyklischen Prozess verwaltet und überprüft. Dabei startet jedes neue Portfolio Backlog Item als Projektidee. Ziel ist es, relevante Issues als aktive Projekte zu begleiten.
Mobirise

Abbildung 22: Screen zur Erstellung eines neuen Portfolio Backlog Item

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/
secure/CreateIssue!default.jspa (zugegriffen: 14. Oktober 2017) eines fiktiven Nutzers mit Profilbildes von Pexels (2017), verändert durch Ausschnitt – URL: https://www.pexels.com/photo/adult-beautiful-blonde-blur-324658 (zugegriffen; 16. September 2017)

Im Portfoliomanagement werden für jedes Item die Verzögerungskosten (siehe Abb. 23, Feld: ‚Verzögerungskosten‘) geschätzt und angegeben. Außerdem folgt die Zuordnung, von welchem Verzögerungskostenprofil ausgegangen wurde (siehe Abb. 23, Feld: ‚Verzögerungskostenprofil‘). Verzögerungskosten fallen für Projekte, Produkte und Anwendungen an, die verspätet ausgeliefert werden. Es gibt vier Verzögerungskostenprofile: lineare Verzögerungskosten15 , sofortige steigende Verzögerungskosten16 , fester Termin17 und plötzliche Kostensprünge18 .

Neben den Verzögerungskosten wird auch eine Schätzgröße (siehe Abb. 23, Feld: ‚Schätzgröße‘) bestimmt. Bei der Internet Connection GmbH wurden die T-Shirt-Größen: XS, S, M, L, XL, XXL und 3XL festgelegt.

Daneben muss für jedes Portfolio Backlog Item regelmäßig die Wirtschaftlichkeit (auch: Definition of Profitability, siehe Abb. 23, Feld: ‚Wirtschaftlichkeit‘) überprüft werden.

Mobirise

Abbildung 23: Screen (Reiter: Plandaten) zur Erstellung eines neuen Portfolio Backlog Item

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/
secure/CreateIssue!default.jspa (zugegriffen: 30. Oktober 2017)


15 Ab dem Zeitpunkt der Verspätung steigen die Verzögerungskosten linear mit der Anzahl an verspäteten Tagen.
16 Ab dem Zeitpunkt der Verspätung sind die Verzögerungskosten einmal hoch und steigen danach erst linear mit der Anzahl an verspäteten Tagen.
17 Am ersten Tag der Verspätung müssen einmalig Verzögerungskosten bezahlt werden, z. B. bei Vertragsbruch.
18 ie Verzögerungskosten sind für einen undefinierten Zeitraum nicht vorhanden oder niedrig und plötzlich fallen Verzögerungskosten an.

Die Herausforderung im Portfoliomanagement besteht darin, zu jeder Zeit für ausreichend Nachschub zu sorgen, ohne dabei mit zu vielen aktiven Projekten die Teams zu überlasten. Das Starten von Items ist nach dem sogenannten WIP-Limit (Work In Process, siehe Abb. 23, Feld: ‚WIPLimit‘) ausgerichtet. Für jedes Portfolio Backlog Item wird ein WIP-Limit geschätzt. WIP-Limit 1 entspricht dabei einem kompletten Team, die eingeübt und auf eine Anwendung spezialisiert sind. Erst wenn die Anzahl an Teams (komplette Besetzung) für einen Einsatz zur Verfügung steht, wird eine Projekt-, Produkt- oder Anwendungsumsetzung gestartet.

Abbildung 24 beschreibt den Inhalt des Reiters ‚Checkliste‘. Die Checkliste unterstützt bei der Abarbeitung der Aktivitäten, die es zu erledigen gilt, bevor ein Portfolio Backlog Item überhaupt gestartet werden darf.
Mobirise

Abbildung 24: Screen (Reiter: Checkliste) zur Erstellung eines neuen Portfolio Backlog Item

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/
secure/CreateIssue!default.jspa (zugegriffen: 30. Oktober 2017)

Abbildung 25 zeigt den Workflow für das Portfoliomanagement. In Abbildung 26 werden die Einstellungen für den Workflow-Übergang ‚In Portfolio aufnehmen‘ dargestellt. Beim Anlegen eines neuen Portfolio Backlog Items wird das Lifecycle Level 3 gesetzt.
Mobirise

Abbildung 25: Workflow für das Portfoliomanagement

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/
secure/admin/workflows/
WorkflowDesigner.jspa?workflowMode=draft&wfName=
ICGMBHAP%3A+
Project+Management+Workflow (zugegriffen: 15. Oktober 2017)

Mobirise

Abbildung 26: Anzeige der Einstellungen des Workflow-Übergangs "In Portfolio aufnehmen"

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/secure/
admin/workflows/
ViewWorkflowTransition.jspa?
workflowMode=draft&workflowName=
ICGMBHAP%3A+Project+
Management+Workflow&
workflowTransition=1&descriptorTab=
postfunctions& (zugegriffen: 15. Oktober 2017)

Das angelegte Issue erscheint im Board in der Spalte ‚Projektideen‘. Sobald ein Issue bearbeitet wird, wird es vorher in die Spalte ‚Geplante Projekte‘ verschoben. Abbildung 27 zeigt beispielsweise ein Verschieben von einer Ausgangsspalte zu einer Zielspalte. Dabei werden immer nur diejenigen Übergänge angezeigt, die auf Basis der Workflow-Einstellungen und Berechtigungen erlaubt sind.

Nachdem ein Portfolio Backlog Item gestartet wurde, wird es als neuer Vorgang im agilen Projektmanagement in Jira Software angelegt (siehe Kapitel 4.4).

Das Portfolio Backlog Item wird mit der Grenznutzenrechnung kontinuierlich bewertet. Bei dieser Prüfung soll im ersten Schritt festgestellt werden, ob die nächste Investition gerechtfertigt ist. Kann diese Frage nicht positiv beantwortet werden, wird überprüft, ob beispielsweise bei einem Softwareprojekt Funktionen vorhanden sind, die ausgeliefert werden sollten. Kann dies auch nicht positiv beantwortet werden, so wird im letzten Schritt geprüft, ob eine Alternative existiert. Ist das auch nicht der Fall, wird das Projekt eingestellt.
Mobirise

Abbildung 27: Ein Item beim Verschieben von einer aktuellen Spalte zu einer anderen

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/
projects/ICGMBHAP/board (zugegriffen: 4. Oktober 2017) mit Anzeige eines Profilbildes von Pexels (2017) eines fiktiven Nutzers, verändert durch Ausschnitt – URL: https://www.pexels.com/photo/adult-beautiful-blonde-blur-324658 (zugegriffen; 16. September 2017)

4.4    Die Umsetzung des agilen Projekt-managements

Sobald im agilen Portfoliomanagement ein Portfolio Backlog Item als aktives Projekt gekennzeichnet wurde, wird im Projektmanagement der Internet Connection GmbH ein neues Issue angelegt. Abbildung 28 beschreibt die Berechtigungen für das Projektmanagement. Nur der Product Owner hat auf seine Projekte Zugriff.
Mobirise

Abbildung 28: Teilausschnitt des Projektmanagement Berechtigungsschemas

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/secure/
admin/EditPermissions!default.jspa?schemeId=10004 (zugegriffen: 15. Oktober 2017)

In Abbildung 29 ist der Workflow für das Projektmanagement abgebildet. Ein neu angelegtes Issue erhält den Lifecycle Level 6.

Der Anwender ‚Uwe Lang‘ ist für das Fallstudien-Projekt ‚Contact Manager XL RC 1‘ zuständig. Da die Internet Connection GmbH aktuell nur ein Projekt als Testlauf gestartet hat, ist in Abbildung 30 nur ein Product Owner abgebildet.
Der Product Owner legt im Projektmanagement ein neues Projekt an. Abbildung 31 zeigt den Reiter ‚Stammdaten‘. Hier vergibt der Product Owner, nach den Vorgaben des Portfoliomanagements, den Namen des Projekts und erklärt die Projektvision.
Mobirise

Abbildung 29: Workflow des Projektmanagements

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/secure/
admin/workflows/
ViewWorkflowSteps.jspa?atl_token=
a84c8e6e-ff10-4ecb-b95d-5dcd96176ec9%7C2180fc6ab4307ec
12ab218e40cd5f2e034e3182a%7Clin&
workflowMode=live&workflowName=
CMXLAP%3A+Project-Management+Workflow (zugegriffen: 15. Oktober 2017)

Mobirise

Abbildung 30: Zugeordnete Nutzer zum Projektmanagement

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/plugins/
servlet/project-config/CMXLAP/people (zugegriffen: 15. Oktober 2017) mit Anzeige eines Profilbildes von Pexels (2017) eines fiktiven Nutzers, verändert durch Ausschnitt – URL: https://www.pexels.com/photo/portrait-of-young-man-against-sky-249761 (zugegriffen; 16. September 2017)

Mobirise

Abbildung 31: Anlegen eines neuen Projekts im agilen Projektmanagement (Reiter: Stammdaten)

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/projects/
CMXLAP/board (zugegriffen: 15. Oktober 2017) eines fiktiven Nutzers mit Profilbild von Pexels (2017), verändert durch Ausschnitt – URL: https://www.pexels.com/photo/portrait-of-young-man-against-sky-249761 (zugegriffen; 16. September 2017)

Die Projektvision beschreibt den Zweck und die Motivation sowie allgemeine Rahmenbedingungen.

Im Reiter ‚Plandaten‘ (siehe Abb. 32) übernimmt der Product Owner drei Werte aus dem Portfolio Backlog Item: Schätzgröße, Verzögerungskostenprofil und WIP-Limit.

Zu diesem Zeitpunkt wird das Projekt zunächst angelegt und zu einem späteren Zeitpunkt bearbeitet.
Mobirise

Abbildung 32: Anlegen eines neuen Projekts im agilen Projektmanagement (Reiter: Plandaten)

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/projects/
CMXLAP/board (zugegriffen: 15. Oktober 2017) eines fiktiven Nutzers mit Profilbild von Pexels (2017), verändert durch Ausschnitt – URL: https://www.pexels.com/photo/portrait-of-young-man-against-sky-249761 (zugegriffen; 16. September 2017)

Vor der Bearbeitung muss sich der Product Owner mit den Stakeholdern abstimmen. Es wird u. a. eine Anzahl an Releases sowie die Sprint-Dauer festgelegt. Nach Abstimmung mit den Stakeholdern, bearbeitet der Product Owner das Projekt. Die fehlenden Angaben werden in den Reiter ‚Plandaten‘ eingetragen (siehe Abb. 33). Die ‚Projektvision‘ kann im Reiter ‚Stammdaten‘ bearbeitet werden.
Mobirise

Abbildung 33: Bearbeitung eines neu angelegten Projekts im agilen Projektmanagement (Reiter: Plandaten)

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/projects/
CMXLAP/issues/CMXLAP-3?filter=allopenissues (zugegriffen: 15. Oktober 2017) eines fiktiven Nutzers mit Profilbild von Pexels (2017), verändert durch Ausschnitt – URL: https://www.pexels.com/photo/portrait-of-young-man-against-sky-249761 (zugegriffen; 16. September 2017)

Sobald der Requirements Engineer19 (kurz: RE) eine Story Map20 oder eine ‚Things-that-matterMatrix‘21 (TTM-Matrix) erstellt hat, wird diese im Reiter ‚Story map & TTM-Matrix‘ abgelegt (siehe Abb. 34).
Mobirise

Abbildung 34: Bearbeitung eines neu angelegten Projekts im agilen Projektmanagement (Reiter: Story map & TTM-Matrix)

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/projects/
CMXLAP/issues/CMXLAP-3?filter=allopenissues (zugegriffen: 15. Oktober 2017) eines fiktiven Nutzers mit Profilbild von Pexels (2017), verändert durch Ausschnitt – URL: https://www.pexels.com/photo/portrait-of-young-man-against-sky-249761 (zugegriffen; 16. September 2017)


19 Englische Berufsbezeichnung für ‚Anforderungsmanager’, die Anforderungen sammeln, dokumentieren und mit den Stakeholdern abstimmen.
20 Anforderungen die auf Karten notiert wurden, werden gruppiert und priorisiert zu einem Modell zusammengestellt, um die Funktionen der Lösung zu verstehen und eventuelle Lücken zu identifizieren.
21 Anforderungen werden den unterschiedlichen System-Komponenten zugeordnet und ihrem entsprechenden Einfluss auf die Komponente geschätzt.

Im Reiter ‚Technische Schulden‘22 (siehe Abb. 35) wird der aktuelle Systemzustand dokumentiert.

Im Reiter ‚Checkliste‘ (siehe Abb. 36) gibt es neben der Checkliste auch die Möglichkeit, die aktuelle Phase des Projekts bzw. die Versionsnummer abzuspeichern.

Sobald ein Projekt im agilen Projektmanagement soweit bearbeitet wurde, dass ein Product Backlog initial befüllt werden kann, wird das Projekt von der ‚Projekt-Bearbeitung‘ in den ‚Projekt-Start‘ verschoben (ähnlich Abb. 37).
Mobirise

Abbildung 35: Bearbeitung eines Projekts im agilen Projektmanagement (Reiter: Technische Schulden)

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/projects/
CMXLAP/issues/CMXLAP-3?filter=allopenissues (zugegriffen: 30. Oktober 2017) mit Anzeige eines Profilbildes von Pexels (2017) eines fiktiven Nutzers, verändert durch Ausschnitt – URL: https://www.pexels.com/photo/portrait-of-young-man-against-sky-249761 (zugegriffen; 16. September 2017)

Mobirise

Abbildung 36: Bearbeitung eines Projekts im agilen Projektmanagement (Reiter: Checkliste)

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/projects/
CMXLAP/issues/CMXLAP-3?filter=allopenissues (zugegriffen: 30. Oktober 2017) mit Anzeige eines Profilbildes von Pexels (2017) eines fiktiven Nutzers, verändert durch Ausschnitt – URL: https://www.pexels.com/photo/portrait-of-young-man-against-sky-249761 (zugegriffen; 16. September 2017)

Mobirise

Abbildung 37: Ein Projekt wird auf dem Board des agilen Projektmanagement verschoben

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/projects/
CMXLAP/issues/CMXLAP-3?filter=allopenissues (zugegriffen: 31. Oktober 2017) mit Anzeige eines Profilbildes von Pexels (2017) eines fiktiven Nutzers, verändert durch Ausschnitt – URL: https://www.pexels.com/photo/portrait-of-young-man-against-sky-249761 (zugegriffen; 16. September 2017)


22 Es handelt sich um eine Metapher, um die Konsequenzen unzureichender technischer oder zu schnellen Softwareumsetzungen aufzuzeigen

4.5    Die Umsetzung eines Projekts mit Scrum

Sobald ein Projekt im agilen Projektmanagement in ‚Projekt-Start‘ verschoben wurde, legt der Product Owner in Jira Software ein eigenständiges Projekt vom Typ ‚Software‘ an. Der Unterschied zum Typ ‚Business‘ in Jira Software besteht darin, dass ein Projekt vom Typ Software ein Backlog Katalog besitzt und beliebig viele Sprints, Komponenten und Releases beinhalten kann.

Abbildung 38 zeigt das Scrum Projekt ‚Contact Manager XL RC 1‘. Der Product Owner befüllt initial den Product Backlog mit sogenannten User Stories. Jede User Story erhält dabei den Lifecycle Level 9. Wie bereits beschrieben, können die Teammitglieder User-Storys erst sehen, wenn der Product Owner diese in einem Sprint platziert, da erst durch diesen Vorgang die betreffenden User Stories den Lifecycle Level 10 erhalten.

Abbildung 39 beschreibt den Workflow des Scrum-Projekts.
Mobirise

Abbildung 38: Übersicht Product Backlog mit Sprints in einem Scrum-Projekt

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/secure/
RapidBoard.jspa?rapidView=3&projectKey=CMXLRC1&view=
planning.nodetail&selectedIssue=CMXLRC1-24 (zugegriffen: 31. Oktober 2017) mit der Anzeige von Profilbildern von Pexels (2017) eines fiktiven Nutzers, verändert durch Ausschnitt – URL: https://www.pexels.com/photo/portrait-of-young-man-against-sky-249761 (zugegriffen; 16. September 2017)

Mobirise

Abbildung 39: Workflow eines Scrum-Projekts

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/
secure/RapidBoard.jspa?rapidView=3&projectKey=CMXLRC1&view=
planning.nodetail&selectedIssue=CMXLRC1-24 (zugegriffen: 31. Oktober 2017)

Mobirise

Abbildung 40: Übersicht aktiver Sprint mit Sprint Backlog Items in einem Scrum-Projekt

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/secure/
RapidBoard.jspa?rapidView=3&projectKey=CMXLRC1&
selectedIssue=CMXLRC1-31 (zugegriffen: 31. Oktober 2017) mit der Anzeige von Profilbildern von Pexels (2017) eines fiktiven Nutzers, verändert durch Ausschnitt – URL: https://www.pexels.com/photo/portrait-of-young-man-against-sky-249761 (zugegriffen; 16. September 2017)

Bevor ein Product Backlog Item in einen Sprint übergehen darf, muss es die Checkliste ‚Definition of Ready‘ (siehe Abb. 41) erfüllen.
Mobirise

Abbildung 41: Erstellung eines neuen Product Backlog Item im Scrum-Projekt (Reiter: Checkliste)

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/projects/
CMXLRC1?selectedItem=com.atlassian.jira.jira-projects-plugin:report-page (zugegriffen: 31. Oktober 2017)

Sobald die Story Map angefertigt wurde, sieht der RE welche User Story als nächstes verfeinert werden muss, damit das Entwicklerteam die Anforderung umsetzen kann. Im Reiter ‚Anhänge‘ werden Dokumente abgelegt. Im Reiter ‚Stammdaten‘ (siehe App. 42) werden anhand der TTMMatrix die betroffenen Komponenten ausgewählt und im Verlauf Angaben zum Release und dem Sprint gesetzt.
Mobirise

Abbildung 42: Erstellung eines neuen Product Backlog Item im Scrum-Projekt (Reiter: Stammdaten)

Quelle: Screenshot aus Web-Oberfläche von Jira Software der Firma Atlassian (2017) – URL: https://pierrebraun.atlassian.net/projects/
CMXLRC1?selectedItem=com.atlassian.jira.jira-projects-plugin:report-page (zugegriffen: 31. Oktober 2017)

Wie bereits beschrieben, ist es möglich, die aktuelle Story Map und/oder TTM-Matrix zusätzlich im agilen Projektmanagement vom Product Owner in das Projekt-Item anhängen zu lassen.

Sind ausreichend Product Backlog Items ‚Definition of Ready‘, werden diese priorisiert, mit Beachtung der Velocity23 , in einen Sprint übertragen24 .

Nachdem der Sprint gestartet wurde, nehmen sich die Teammitglieder ein Sprint Backlog Item und bearbeiten dieses.

Die Bearbeitung beginnt mit dem Erstellen des Programmcodes. Aufgrund der Integration von JUnit25 und Maven26 , unterstützt der Bearbeitungsprozess das sogenannte Continuous Delivery27 .

Das Plugin Maven kompiliert dabei den Programmcode, lädt benötigte Programmbibliotheken sowie Binär-Daten aus Repositories, legt eine Version an und testet die vom Entwickler erstellten UnitTests. Diese Art von Tests fällt im Workflow unter ‚Programmcode-Tests‘28 . Danach werden die sogenannten Akzeptanztests durchgeführt. Auch die Akzeptanztests werden durch ein Tool (mit JBehave29 ) unterstützend durchgeführt. Bei der Internet Connection GmbH zählen die Akzeptanztests zur Teststufe der ‚Komponententests‘, die auch im Workflow so bezeichnet sind.

Die Internet Connection GmbH hat sich dafür entschieden, nach den funktionalen Änderungen eine technische Bearbeitung (Stichwort: Refactoring30 ) folgen zu lassen. Die funktionalen Änderungen werden durch ein Funktionsteam und die technische Bearbeitung durch sogenannte Komponententeams durchgeführt. Mit der technischen Bearbeitung werden mögliche technische Schulden minimiert oder vollständig beseitigt. Die Komponententeams setzen sich aus Experten für die jeweiligen Komponenten zusammen. Sobald die funktionalen Änderungen programmiert und jeweils die entsprechenden Komponenten (inklusive Akzeptanztests) getestet wurden, folgt die Bearbeitung durch die Komponententeams.

23 Kennziffer für die Anzahl (und den Umfang) von Anforderungen, den ein Entwicklungsteam in einem bestimmten Zeitraum vollständig umsetzen kann.
24 Die Vorgehensweise entspricht den Regularien der Internet Connection GmbH. Es ist auch denkbar, erst die Product Backlog Items, anhand der Story Map, in einen Sprint zu übertragen und der RE nimmt sich die Items zur Verfeinerung aus der Spalte ‚Offen‘.
25 Ein speziell für Java entwickeltes Framework, für die Erstellung von automatisierten Tests.
26 Basiert auf Java und ist von der Firma Apache Software Foundation. Damit lassen sich Java-Programme durch einen Build-Prozess standardisiert erstellen.
27 Eine Menge von Werkzeugen und Prozessen, die den Auslieferungsprozess von Softwaresystemen automatisiert.
28 Es handelt sich um sogenannte White-Box-Tests, da der Entwickler Zugriff auf den Programmcode besitzt. Der Programmcode wird nach der Erstellung automatisiert getestet.
29 Der Kunde/Auftraggeber kann durch die Anwendung seiner Muttersprache Testfälle beschreiben, die dann durch JBehave in Testfälle umgewandelt werden. Durch den Einsatz solcher Werkzeuge testen Entwickler nach dem Erstellen des Programmcodes funktionale Anforderungen automatisiert.
30 Gemeint ist der Prozess von Programmcode-Überarbeitungen zur Verbesserung der Qualität, der Stabilität und der Vermeidung des Anwachsens von technischen Schulden.

Sobald alle Arbeiten abgeschlossen sind, werden die Integrations- und Systemtests durchgeführt. Mittels Maven werden alle Programmpakete auf einen Continuous Integration-Server (CI-Server) überführt. Ein ausführbares Programm wird dann auf einem Testserver bereitgestellt. Ab dem Zeitpunkt der Übertragung auf den CI-Server, startet das sogenannte ‚Continuous Integration‘31 . Auf dem Testserver wird das Zusammenspiel der einzelnen Komponenten sowie des gesamten Systems getestet. Dies geschieht teilweise automatisch und unter Umständen auch manuell. Außerdem werden Tool unterstützend sogenannte Lasttests32 und Security-Tests33 durchgeführt.

Sobald alle Sprint Backlog Items die Checkliste ‚Definition of Done‘34 (siehe Abb. 41) erfüllen, endet der Sprint. Das Team stellt seine Ergebnisse vor und der Product Owner nimmt den Sprint offiziell ab.

Während eines Sprints hat der Product Owner bereits einen neuen Sprint vorbereitet. Nach der Sprint-Abnahme werden bedeutende Angaben zur Velocity und den technischen Schulden im Item des agilen Projektmanagements durch den Product Owner bearbeitet. Danach startet ein neuer Sprint.

31 Beschreibt das Zusammenfügen einzelner Programmanteile zu einem ausführbaren Softwaresystem.
32 Ein Test, um die Belastbarkeit von Softwaresystemen unter besonderer Last zu testen, beispielsweise durch viele gleichzeitige Nutzeraktionen.
33 Alle Tests, die notwendig sind, um Angriffsszenarien durchzuspielen und Schwachstellen zu identifizieren.
34 Eine Liste von Kriterien, die zusammen ein Gate darstellen, das durch Einhaltung aller Kriterien überwunden werden muss.

5    Fazit

Unternehmen haben einen Wettbewerbsvorteil, wenn sie die Produkte und/oder Dienstleistungen schneller auf dem Markt anbieten können. Im Rahmen von Softwareerstellungsprozessen bietet es sich an, Software unter dem Einsatz von agilen Prinzipien und der Vorgehensweise Scrum zu entwickeln.

Die Fallstudie verdeutlicht, dass Jira Software ein geeignetes Tool ist, um darin agile Softwareentwicklungsprojekte zu verwalten, ohne dabei alle Möglichkeiten der Anwendung voll ausgeschöpft zu haben: beispielsweise durch den Einsatz von Erweiterungen aus dem Atlassian Marketplace und das Anschließen an die bestehende IT-Infrastruktur durch die Jira API.

Durch die Nutzung eines Lifecycle Level wurde das Berechtigungskonzept dahingehend erweitert, dass auch der Zugriff auf einzelne Vorgänge gesteuert wird. Außerdem dient es zur Anzeige, auf welchem Teilstück sich ein Vorgang aktuell befindet.

Benutzerdefinierte Felder wurden erstellt, unterschiedliche Screens gestaltet und die Workflows entsprechend nach eigenen Vorgaben geändert. Die Workflows könnten beispielsweise so erweitert werden, dass Vorgänge nur dann weitergereicht werden dürfen, wenn die jeweiligen Checklisten erfüllt wurden.

Agile Projekte für Portfoliomanagement, Projektmanagement und Scrum sorgen für eine nahtlose Integration, auch wenn auf die Nutzung eines Lifecyle-Level ähnlichen Werts verzichtet werden würde. Selbst der Verzicht auf zwei Projekte für Portfoliomanagement und Projektmanagement wäre ausreichend, um mittels Scrum Softwareentwicklungen begleiten zu können.

In der Fallstudie wurde nicht auf die zahlreichen Projekt- und Board-Einstellungen sowie die Möglichkeiten der Filterungen eingegangen.

IV    Literaturverzeichnis

Olbert, Sebastian, Hans Gerd Prodoehl und Christopher G. Worley. 2017. Agilität als Wettbewerbsvorteil. goetzpartners, NEOMA Business School. https://www.goetzpartners.com/uploads/tx_gp/2017_goetzpartners_Agile_Performer_Index.pdf (zugegriffen: 5. Oktober 2017).
Mobirise
Adresse

Pierre Holger Braun                     
Monikastraße 17
53757 Sankt Augustin Menden

Erreichbarkeiten

E-Mail: kontakt@pierreholgerbraun.de

Telefon: +49 2241 8462250
Telefax: +49 2241 8462251
Mobil: +49 171 1000102

Büro-Zeiten

Montag: 08:00 bis 16:00 Uhr
Dienstag: 08:00 bis 16:00 Uhr
Mittwoch: 08:00 bis 16:00 Uhr
Donnerstag: 08:00 bis 16:00 Uhr
Freitag: 08:00 bis 16:00 Uhr

Samstag: 08:00 bis 12:00 Uhr
Sonntag: geschlossen