Seminararbeit Analyse der M oglichkeiten f ur standort ubergreifende Ticketorganisation

Die Seite wird erstellt Svenja-Meike Pfeifer

Wissenschaft

Deutsch

Like
Teilen
Einbetten
Vollbild
Folien
HTML Herunterladen
PDF Herunterladen
Missbrauch

←

WEITER LESEN

→

Transkription von Seiteninhalten

Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten

Seminararbeit Analyse der M oglichkeiten f ur standort ubergreifende Ticketorganisation

Fachhochschule Aachen
     Fachbereich 9, Studiengang Scientific Programming

                Seminararbeit

     Analyse der Möglichkeiten für
standortübergreifende Ticketorganisation
  Auszubildende:     Claudia Elisabeth Czerkowska
  Matrikelnummer:    3154985
  1. Betreuer:       Prof. Dr. rer. nat. Volker Sander
  2. Betreuer:       Michael Kaiser
                      7. Januar 2020

Inhaltsverzeichnis
1 Einleitung                                                                                  5

2 Arbeitsumfeld                                                                               6
  2.1   Ausbildungsbetrieb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .       6
  2.2   Aktuelle Ticketverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . .        6

3 Anforderungen                                                                               7
  3.1   Projektübergreifende Übersicht . . . . . . . . . . . . . . . . . . . . . . . .       7
  3.2   Time Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      7
  3.3   Preisübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .    7
  3.4   Anbindung an GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . .          7

4 Vorstellung der Systeme                                                                      8

5 GitLab                                                                                      8
  5.1   Allgemeine Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . .         8
  5.2   Analyse anhand der folgenden Anforderungen . . . . . . . . . . . . . . . .             8
        5.2.1   Projektübergreifende Übersicht . . . . . . . . . . . . . . . . . . . .       8
        5.2.2   Time Tracking     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
        5.2.3   Preisübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
        5.2.4   Anbindung an GitLab . . . . . . . . . . . . . . . . . . . . . . . . . 11
  5.3   Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6 Jira (Software)                                                                             11
  6.1   Allgemeine Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
  6.2   Analyse anhand der folgenden Anforderungen . . . . . . . . . . . . . . . . 12
        6.2.1   Projektübergreifende Übersicht . . . . . . . . . . . . . . . . . . . . 12
        6.2.2   Time Tracking     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
        6.2.3   Preisübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
        6.2.4   Anbindung an GitLab . . . . . . . . . . . . . . . . . . . . . . . . . 14

                                              3

6.3   Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

7 Redmine                                                                                  16
  7.1   Allgemeine Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
  7.2   Analyse anhand der folgenden Anforderungen . . . . . . . . . . . . . . . . 16
        7.2.1   Projektübergreifende Übersicht . . . . . . . . . . . . . . . . . . . . 16
        7.2.2   Time Tracking     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
        7.2.3   Preisübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
        7.2.4   Anbindung an GitLab . . . . . . . . . . . . . . . . . . . . . . . . . 17
  7.3   Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

8 Fazit und Ausblick                                                                       19
  8.1   Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
  8.2   Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

                                             4

1 Einleitung
Der Alltag eines Softwareentwicklers beinhaltet zu einem großen Teil das Planen bzw.
Entwickeln von Projekten und aktiven Systemen. Darüber hinaus kommen täglich Fehler-
meldungen, Änderungswünsche oder allgemeine Fragen von Kunden. Weil das Arbeiten
an Projekten viel Zeit in Anspruch nehmen kann, können die Anliegen unter Umständen
nicht sofort bearbeitet werden. Je nach Auslastung des Teams verliert man schnell den
Überblick über Projekte und Kundenanfragen.
Aus diesem Grund werden Issue-Tracking-Systeme1 verwendet. Sie ermöglichen die Ver-
waltung von diversen Abläufen, z.B. das Realisieren eines Softwareprojekts, das Wei-
terentwickeln eines aktiven Systems oder das Verwalten von Tickets. Tickets sind eine
elektronische Form, ein Anliegen oder eine Störungsmeldung.[1]

Im Shopteam meines Ausbildungsbetriebes wird für das Erstellen und Bearbeiten von
Tickets die Webanwendung GitLab verwendet. Das Issue Tracking2 wird mithilfe eines
Whiteboards realisiert. Hier werden alle Tickets aufgeschrieben und dadurch verwaltet.
Die Tickets werden dabei in folgende Kategorien eingeteilt: offen“ (unbearbeitet), in
” ”
Bearbeitung“ und geschlossen“. Für die Übersicht sind alle Teammitglieder mit ihren
”
zugeordneten Tickets aufgelistet.
Problematisch an dieser Vorgehensweise ist, dass das Whiteboard unabhängig von GitLab
ist. Das Verwalten der Tickets erfolgt folglich doppelt. Darüber hinaus ist das Shopteam
auf zwei Standorte verteilt, sodass zwei Whiteboards konstant auf dem gleichen Stand
gehalten werden müssen, was unter Anderem ungewollten Aufwand generiert.
Aus diesem Grund wird im Rahmen der Seminararbeit mithilfe einer Internetrecherche
ein optimales Issue-Tracking-System für eine standortübergreifende Ticketorganisation
gesucht.

1
Im Shopteam werden Issue-Tracking-Systeme neben der Verwaltung von Tickets auch für das Ma-
nagen genutzt.
2
hier: verwalten von Tickets

2         Arbeitsumfeld

2.1         Ausbildungsbetrieb

Die Continue Software GmbH3 ist ein mittelständiges Unternehmen, welches 1997 ge-
gründet wurde und derzeit aus ca. 25 Mitarbeitern besteht. Aufgrund der kontinuierlich
wachsenden Anzahl der Mitarbeiter wurde 2017 neben Aachen ein zweiter Standort in
Baesweiler eröffnet.
Die Einsatzgebiete von Continue liegen hauptsächlich im Bereich der Warenwirtschaft
und des e-Commerce. Unter anderem bietet Continue ein Warenwirtschaftssystem, Web
Shops und eine Zollsoftware an.

2.2         Aktuelle Ticketverwaltung

Wie in der Einleitung bereits erwähnt wird GitLab zur Versions- und Ticketverwaltung im
Shopteam verwendet. Dafür wurde ein leeres Projekt mit dem Namen Support“ angelegt.
                                                                 ”
Über ein firmeneigenes System können Kunden Tickets anlegen, welche dann in dem
Support-Projekt als Issues4 angelegt werden.
Zusätzlich werden intern Tickets für andere Projekte angelegt.

    3
        im Weiteren Verlauf als Continue“ abgekürzt
    4                          ”
        Issues = Tickets

                                                       6

3 Anforderungen
Es soll ein neues System zur Optimierung der Ticketorganisation nach den Anforderungen
des Shopteams gefunden werden. Dafür wurden die folgenden Anforderungen ermittelt:

3.1 Projektübergreifende Übersicht

Gefordert wird eine projektübergreifende Übersicht. Dabei sollen Tickets von allen verfügbaren
Projekten in der Übersicht aufgelistet werden. Dennoch soll erkennbar sein, zu welchem
Projekt ein Ticket gehört.
Die Präferenz liegt dabei in einer Auflistung der Teammitglieder mit ihren zugewiesenen
Tickets. Des Weiteren soll sichtbar sein, an welchen Tickets aktiv gearbeitet wird.

3.2 Time Tracking

Bei Sonderprogrammierungen ist es wichtig zu wissen, wie viel Zeit die Bearbeitung in
Anspruch genommen hat, um dem Endkunden den entstandenen Aufwand in Rechnung
stellen zu können. Folglich soll das System die Möglichkeit bieten die Zeit zu messen und
den Gesamtaufwand zu ermitteln.

3.3 Preisübersicht

Die meisten Issue-Tracking-Systeme bieten verschiedene Versionen mit unterschiedlichen
Features an. Je nach Version ist die Nutzung des Systems kostenpflichtig. Idealerweise
sollte der Kostenafuwand für die Nutzung eines solchen Systems möglichst gering ausfal-
len.

3.4 Anbindung an GitLab

GitLab wird für die Versionsverwaltung im Shopteam verwendet, weswegen eine Ver-
knüpfung zu GitLab möglich sein muss. Wenn demnach ein Ticket in dem anderen System
angelegt wird, soll es auch automatisch in GitLab angelegt werden und umgekehrt.

4 Vorstellung der Systeme
Der Markt bietet eine Vielzahl an verschiedenen Issue-Tracking-Systemen. Da eine Ana-
lyse aller möglichen Systeme den Rahmen der Seminararbeit übersteigen würde, werden
im weiteren Verlauf drei bekannte Systeme vorgestellt.
Die ausgewählten Systeme sind GitLab, Jira (Software) und Redmine.
Für die Bewertung wird ein dreistufiges Schema verwendet, welches die Features5 mit
unzureichend“, hinreichend“ oder optimal“ bewertet.
” ” ”

5 GitLab

5.1 Allgemeine Informationen

Die Webanwendung GitLab wurde 2011 von Dmitri Saparoschez und Valery Sizov mithilfe
des Webframeworks Ruby on Rails entwickelt. GitLab hilft bei der Versionsverwaltung
und basiert dabei auf Git.[2] Git ist eine Open Source Software zur verteilten Versions-
kontrolle von Dateien.[3]
GitLab bietet diverse Werkzeuge/Tools für eine bessere Planung bzw. Organisation von
Projekten und die Möglichkeit zum Bug-Tracking an.[2]

Weil GitLab im Team bereits genutzt wird, bietet es sich an, die hier gegebenen Möglichkeiten
für die Ticketverwaltung näher zu analysieren.

5.2 Analyse anhand der folgenden Anforderungen

5.2.1 Projektübergreifende Übersicht

Bezüglich der Übersichten für Tickets existieren in GitLab sogenannte Issue Boards. Auf
diesen Issue Boards werden die Tickets in Listen organisiert und angezeigt. Zu Beginn exis-
tiert eine Liste mit allen offenen Tickets und eine zweite mit den geschlossenen Tickets.
5
Funktion eines Systems

Es besteht die Möglichkeit mehrere Listen anzulegen, welche allerdings einem Label zu-
geordnet werden müssen. Labels sind wie eine kleine Notiz um den Kontext eines Tickets
anzugeben.
Tickets werden innerhalb dieser Listen als Karten angezeigt. Von dort aus können alle
möglichen Aktionen für Tickets durchgeführt werden.

Es ist möglich, ein oder mehrere Issue Boards für jedes Projekt selbst anzulegen. Da-
mit sind Tickets innerhalb der jeweiligen Projekte organisiert. Jedoch wird dadurch die
Anforderung von einer projektübergreifenden Übersicht nicht erfüllt.
GitLab bietet darüber hinaus die Möglichkeit, Issue Boards für Gruppen anzulegen. Da-
durch hat man eine übergreifendere Übersicht über die Projekte der jeweiligen Gruppe.
Im Shopteam existieren allerdings mehrere Gruppen, sodass auf den Boards nicht alle
Projekte zu sehen wären.
Wenn alle Projekte in einer Gruppe verwaltet werden, wäre eine projekt-übergreifende
Übersicht realisierbar. Dafür werden Listen mit den Namen der Teammitglieder erstellt,
in denen alle zugewiesenen Tickets aufgelistet sind. Je nach Anzahl der Teammitglieder
kann dies aber schnell unübersichtlich werden. Deshalb könnte die Möglichkeit von meh-
reren Boards Abhilfe schaffen. So kann ein Board pro Teammitglied und für jedes Projekt
eine eigene Liste angelegt werden.
Trotz allem ist es nicht erkennbar, an welchem Ticket ein Teammitglied aktiv arbeitet.
Darüber hinaus sind die Features von benutzerabhängigen Listen und mehreren Issue
Boards für eine Gruppe nicht für alle Versionen verfügbar.[4]

Abschließend lässt sich sagen, dass GitLab die Anforderung einer projektübergreifenden
Übersicht hinreichend erfüllt. Die Umsetzung der geforderten Übersicht ist in der Theorie
realisierbar, jedoch ist dies in diesem Fall mit Aufwand verbunden. Darüber hinaus entste-
hen unter Umständen Kosten, wenn benötigte Features nur in kostenpflichtigen Versionen
verfügbar sind.

5.2.2 Time Tracking

Zum Aspekt des Time Tracking bietet GitLab die Möglichkeit, die Zeit in einem Ticket
einzutragen, die das Bearbeiten in Anspruch genommen hat. Man fügt dafür den Kommen-
tar im Format /spend 00d 00h 00m“ ein. Wenn man mehrmals an dem Ticket gearbeitet
”
hat, rechnet GitLab die Zeiten zusammen.
Es kann außerdem auch festgehalten werden, wie viel Zeit geschätzt wird um das Ticket
zu bearbeiten. Dies erfolgt mit dem Kommentar in der Form /estimate 00d 00h 00m“.[5]
”

GitLab bietet somit die Möglichkeit, beanspruchte Zeit einzutragen und zu speichern.
Weil die Zeit allerdings nicht mit GitLab selbst gemessen werden kann, ist die Anforde-
rung für das Time Tracking nur hinreichend realisiert.

5.2.3 Preisübersicht

GitLab bietet zum einen die Variante an, dass die Instanz von GitLab selbst verwaltet
wird und zum anderen die Variante, in der man die Instanz auf einem eigenen Server
hostet6 . Innerhalb dessen wird anschließend zwischen den verschiedenen Versionen unter-
schieden, die sich jeweils um zusätzliche Features erweitern. Für beide Möglichkeiten gibt
es eine kostenfreie und 3 kostenpflichtige Versionen. Allgemein ist bei den kostenpflichti-
gen Versionen jährlich ein bestimmter Betrag zu zahlen. Bei GitLab wird pro Benutzer
ein Betrag pro Monat bezahlt.
Wenn die Instanz von GitLab verwaltet wird, gibt es die Versionen Free“, Bronze“,
” ”
Silver“ und Gold“. Bei einer selbst verwalteten Instanz wird zwischen Core“, Star-
” ” ” ”
ter“, Premium“ und Ultimate“ unterschieden. Die Versionen Free und Core, Bronze und
” ”
Starter, Silver und Premium und zuletzt Gold und Ultimate kosten jeweils gleich viel und
unterscheiden sich nur in der Variante für eine eigene oder eine von GitLab verwaltete
Instanz.[6]
Um für das Shopteam eine projektübergreifende Übersicht realisieren zu können, müsste
die Premium Version erworben werden, da erst hier die mehreren Issue Boards für Grup-
6
in diesem Kontext = selber verwalten

pen und die benutzerabhängigen Listen zur Verfügung stehen. Diese Version kostet 19
US-Dollar pro Nutzer. Da das Team aus 10 Mitarbeitern besteht, würden Kosten in Höhe
von 2.280 US-Dollar pro Jahr anfallen.

Folglich ist das Kriterium für einen geringen Kostenaufwand unzureichend erfüllt, da
ein Betrag von 2.280 US-Dollar pro Jahr nicht kostengünstig ist.

5.2.4 Anbindung an GitLab

Diese Anforderung ist automatisch erfüllt, weil hier das Issue Tracking von GitLab selbst
näher behandelt wird.

5.3 Zusammenfassung

Allgemein kann mit GitLab die standortübergreifende Ticketorganisation realisiert wer-
den. Es werden viele Möglichkeiten für eine individuelle Vorgehensweise beim Verwalten
und Organisieren angeboten. Allerdings sind die vielen Möglichkeiten durch die Einteilung
in kostenpflichtige Versionen eingeschränkt.

6 Jira (Software)

6.1 Allgemeine Informationen

Jira ist eine Webanwendung mit welcher Fehler und Probleme behandelt und darüber
hinaus Projekte geplant werden können. Das System wurde von dem Unternehmen At-
lassian Corporation plc entwickelt.[7]
Jira bietet mehrere Produkte für unterschiedliche Anwendungsbereiche an: Jira Software,
Jira Core, Jira Service Desk und noch viele weitere. Bei der Anschaffung von einem der
Produkte kann man jederzeit auch weitere Produkte erwerben und auch in der Anwen-
dung miteinander kombinieren.[8]
Aufgrund der möglichen Features erweist sich Jira Core als ein System, dass eventuell in

Frage kommen könnte. Praktischerweise sind für alle Produkte kostenlose Testversionen
verfügbar, um einen besseren Einblick in das Programm zu gewinnen. Aus diesem Grund
wurde im Rahmen der Recherche eine Testversion von Jira Core erworben.

6.2       Analyse anhand der folgenden Anforderungen

6.2.1      Projektübergreifende Übersicht

Allgemein können Projekte angelegt werden, in denen Aufgaben verwaltet werden. Hierfür
nutzen Projekte ein Board, welches alle zu erledigenden Aufgaben anzeigt. Beim Erstellen
eines Projektes muss eine Vorlage ausgewählt werden, welche anschließend die Struktur
des Boards bestimmt. Je nach Vorlage sind unterschiedliche Listen vorhanden, mit de-
nen die Aufgaben verwaltet werden können. Die Struktur ist festgelegt und kann nicht
durch weitere Listen erweitert werden. Im Allgemeinen können folgende Attribute gesetzt
werden:

      – eine Beschreibung

      – ein zugewiesenes Teammitglied

      – eine Priorität

      – Sub-Tasks7

      – die beanspruchte Zeit

      – ein Kommentar

Darüber hinaus besitzen Aufgaben einen Status, welcher von der Liste abhängt in der die
Aufgabe eingetragen ist. Per Drag’n’Drop können Aufgaben zwischen den Listen verscho-
ben werden, wodurch der Status anschließend angepasst wird.
Für die projektübergreifende Übersicht ist die Möglichkeit vorhanden, zu einer ausgewählten
Kategorie alle Vorgänge anzuzeigen. Dabei gibt es zwei Ansichtsmöglichkeiten.
Zum einen werden alle Aufgaben in einer einzelnen Liste aufgelistet. Allerdings sieht man
  7
      kleinere Aufgaben, die zu der eigentlichen Aufgabe gehören

                                                    12

nur den Titel der Aufgabe und den Schlüssel zum zugehörigen Projekt. Man kann nicht er-
kennen, welches Ticket welchem Teammitglied zugewiesen ist. Erst durch das Auswählen
der jeweiligen Aufgabe erhält man alle nötigen Informationen.
Zum anderen können alle Aufgaben in einer Tabelle angezeigt werden. Hier kann auch
bestimmt werden, welche Informationen zu der Aufgabe in einer Spalte angezeigt werden
soll. Im Gegensatz zur Listenansicht kann man demnach z.B. das zugewiesene Teammit-
glied sehen.

Allgemein ist es möglich, mit beiden Varianten eine projektübergreifende Übersicht zu
realisieren. Jedoch ist die Umsetzung nicht ideal, weil Aufgaben nur angezeigt und be-
arbeitet werden können. Das Erstellen einer Aufgabe ist außerdem nur im Board eines
Projektes möglich. Darüber hinaus wird in keiner der beiden Varianten angezeigt, an wel-
chem Ticket ein Teammitglied aktiv arbeitet. Folglich setzt Jira die projektübergreifende
Übersicht nur hinreichend um.

6.2.2 Time Tracking

Jira Core bietet die Möglichkeit, innerhalb der Tickets die bereits aufgewendete und
geschätzte noch benötigte Zeit einzutragen. Dafür existiert ein Label Zeiterfassung“ im
”
Ticket, welches die eingetragene Zeit anzeigt. Durch einen Klick auf das Label öffnet sich
ein Fenster, in dem die benötigte Zeit eingetragen werden kann.

Da die Zeit selbst gemessen werden muss, es aber dennoch die Möglichkeit gibt die
benötigte Zeit zu speichern, wird die Anforderung des Time Tracking hinreichend erfüllt.

6.2.3 Preisübersicht

In Bezug auf die Kosten gibt es die Variante, mit welcher eine Instanz in der Cloud von
Jira verwaltet wird oder die Variante, eine Instanz selbst auf einem eigenen Server zu
verwalten.
Bei allen Varianten ist der Preis abhängig von der Benutzeranzahl.

Bei der von Jira verwalteten Variante gibt es eine kostenlose- und eine Standardversion.
Jira ist an sich für maximal 10 Benutzer kostenfrei, danach kann nur noch die Standard-
Version erworben werden. Diese kann aber auch schon von Anfang an gekauft werden für
10 US-Dollar pro Monat. Danach fallen bei bis zu 100 Benutzern pro Benutzer Kosten
von 5 US-Dollar an. Ab 100 Benutzern sinkt der Preis pro Benutzer im Monat.
Wenn eine Instanz auf einem eigenen Server gehostet werden soll, dann zahlt man bei ma-
ximal 10 Benutzern einmalig 10 US-Dollar. Danach startet der Zähler mit 25 Benutzern,
für die einmalig 2.200 US-Dollar bezahlt werden müssen. Für jede neue Benutzergrenze
wird einmalig ein neuer Preis gezahlt.[9]
Im Shopteam würden wir Jira Core auf einem eigenen Server verwalten. Zurzeit besteht
das Team aus 10 Mitgliedern, was eine einmalige Bezahlung in Höhe von 10 US-Dollar be-
deuten würde. Auf den ersten Blick erscheint dies ideal, jedoch könnte das Team jederzeit
wachsen. Geht man von 25-30 Benutzern aus, läge der Preis einmalig bei 2.200 US-Dollar.
Dafür, dass die Anzahl der Benutzer für eine längere Zeit sich in diesem Rahmen befinden
würde, ist der Preis angemessen und gut vertretbar.

Jira erfüllt somit optimalerweise die Anforderung eines geringen Kostenaufwandes.

6.2.4 Anbindung an GitLab

Laut der Dokumentation von GitLab selbst ist die Verknüpfung zwischen einer Instanz
von Jira und GitLab möglich.
Wird in GitLab ein Merge-Request oder Commit erstellt, ist es mit bestimmten Befeh-
len möglich im Kommentar auf ein ausgewähltes Jira Ticket zu verlinken. Somit wird im
entsprechenden Ticket die Aktion in einem Kommentar erwähnt. Dabei wird dann die
zugehörige GitLab-Aktion verlinkt.[10]
Eine direkte Verknüpfung zwischen den Tickets in GitLab und Jira scheint dennoch nicht
möglich zu sein. Dies würde bedeuten, dass in Jira manuell das gleiche Ticket angelegt
werden müsste, was in GitLab über das firmeneigene Ticketsystem erstellt wurde. Dies

erzeugt doppelten Aufwand und die Gefahr, dass die Übersicht in Jira nicht immer auf
dem aktuellen Stand ist, wenn einmal das Erstellen eines Tickets vergessen wird.

Da diese Aspekte schon bei der Realisierung mit dem Whiteboard vorhanden sind und
in Zukunft vermieden werden sollen, ist das Kriterium für die Anbindung zu GitLab
unzureichend erfüllt.

6.3    Zusammenfassung

Zusammenfassend ist Jira Core keine ideale Lösung für eine standortübergreifende Ticke-
torganisation. Eine projektübergreifende Übersicht ist zwar gegeben, jedoch ist die Um-
setzung nicht optimal strukturierbar. Darüber hinaus ist die geforderte Anbindung zu
GitLab nicht möglich.
Dennoch ist Jira ein System, dass eine hohe Vielfalt an Möglichkeiten für die Verwaltung
und Planung von Projekten durch die unterschiedlichen Produkte anbietet.

                                           15

7 Redmine

7.1 Allgemeine Informationen

Redmine ist eine Opensource Webanwendung die am 25. Juni 2006 veröffentlicht wurde
und weltweit in verschiedenen großen Projekten eingesetzt wird. Das System bietet unter
anderem die Möglichkeit Benutzer, Projekte und Tickets zu verwalten.[11]
Darüber hinaus existiert die Webanwendung Easy Redmine“, welche ein Upgrade von
”
Redmine ist. Sie bringt ein neues Design und erweitert Redmine um weitere nützliche
Features.[12]
Im Folgenden wird für die Recherche das System Redmine näher betrachtet. Hierfür wurde
die von Redmine angebotene Demoversion erworben um einen genauen Einblick in das
System zu gewinnen.

7.2 Analyse anhand der folgenden Anforderungen

7.2.1 Projektübergreifende Übersicht

Redmine bietet sowohl eine Übersicht für Projekte als auch für Tickets an.
In der Projektübersicht werden alle verfügbaren Projekte mit ihrer Beschreibung aufge-
listet. Wenn ein Projekt ausgewählt wird, erscheint eine Übersicht des Projektes. Dabei
werden alle Mitglieder des Projektes und Details zu vorhandenen Tickets angezeigt. In
Redmine haben Tickets einen Typ, der den Anwendungsbereich angibt. Es wird dabei
zwischen Fehlermeldungen (Bug), Änderungen (Feature) und Support unterschieden. In
Projekten existiert auch eine Übersicht über die zugehörigen Tickets. Hier werden sie mit
allen wichtigen Informationen in einer Tabelle angezeigt, wie z.B. das zugewiesene Team-
mitglied, den Status oder die Priorität.
Neben der Projektübersicht besteht die Möglichkeit, sich alle Tickets von allen Projekten
anzeigen zu lassen. Die Übersicht erfolgt dabei ebenfalls über eine Tabelle. Hier kann je-
doch selbst entschieden werden, welche Informationen angezeigt werden sollen. Allerdings
ist nicht zu erkennen, an welchem Ticket ein Teammitglied aktiv arbeitet.

Allgemein ist eine eizelne Tabelle für die Übersicht aller Tickets eher ungeeignet. Für eine
große Anzahl an Tickets ist die Tabelle schnell überfüllt und wird unübersichtlich. Es
wäre besser, wenn die Tickets in mehreren Tabellen angezeigt werden könnten um in der
Übersicht eine deutlichere Struktur zu erhalten.

Alles in allem setzt Redmine die Anforderung für eine projektübergreifende Übersicht
optimal um. Es ist jedoch wichtig zu beachten, dass die Übersicht bei hoher Anzahl an
Tickets schnell verloren gehen kann.

7.2.2 Time Tracking

Zum Kriterium der Zeiterfassung bietet Redmine die Möglichkeit die Zeit einzutragen,
die zur Bearbeitung eines Tickets benötigt wurde. Dabei muss angegeben werden, ob in
der Zeit am Design gearbeitet oder programmiert wurde. Redmine rechnet dann mehrere
Zeiteinträge zusammen.
Darüber hinaus kann auch eine Zeit angegeben werden, die zur Bearbeitung des Tickets
benötigt wurde.

Abschließend lässt sich sagen, dass die Anforderung für das Time Tracking nur hinrei-
chend erfüllt wird. Es besteht zwar die Möglichkeit für das zugehörige Ticket die Zeit
einzutragen, allerdings muss die beanspruchte Zeit trotzdem selbst gemessen werden.

7.2.3 Preisübersicht

Das Kriterium für einen geringen Kostenaufwand wird optimal erfüllt, da es sich bei
Redmine um eine kostenlose Webandwendung handelt.

7.2.4 Anbindung an GitLab

Laut der offiziellen Webseite von GitLab ist eine Verknüpfung zwischen Redmine und
GitLab möglich.
Dafür muss in dem jeweiligen GitLab-Projekt in den Einstellungen der Service Redmine

aktiviert und konfiguriert werden. Die Konfiguration ist sehr simpel, weil nur die URL’s
zum entsprechenden Projekt in Redmine eingetragen werden. Nach erfolgreicher Konfi-
guration wird im GitLab-Projekt ein Link zu dem Redmine-Projekt angezeigt.
Zum einen kann in GitLab ein Ticket erstellt werden und im Kommentar ein Ticket aus
Redmine verlinkt werden. Jedoch muss das Ticket in Redmine dafür schon existieren.
Dies würde bedeuten, dass Tickets doppelt erstellt und zusätzlich manuell verlinkt wer-
den müssen. Allerdings ist das nicht die Art von Verknüpfung, die gefordert wird.
Zum anderen existiert die Möglichkeit, dass das Anlegen eines Tickets in GitLab auch ein
entsprechendes Ticket in Redmine anlegt. Hiermit wäre die Anforderung für eine Anbin-
dung zu GitLab zwar erfüllt, jedoch weist die Webseite von GitLab darauf hin, dass diese
Möglichkeit nicht genutzt und deshalb in Zukunft abgeschafft wird.[13]

Schlussfolgernd wird die Anforderung für eine Verknüpfung zu GitLab unzureichend rea-
lisiert. Die eigentlich gewünschte Verbindung zwischen den Tickets innerhalb der zwei
Systeme wird abgeschafft und kann somit für die Recherche nicht mehr gewertet werden.
Die Alternative mit der manuellen Verlinkung der Tickets stellt allerdings keine ideale
Alternative dar.

7.3 Zusammenfassung

Redmine bietet sich allgemein als simple und vielfältige Webanwendung zur Verwaltung
von Benutzern, Projekten und Tickets an.
Eine mögliche Lösung für das gesuchte Issue-Tracking-System stellt das System jedoch
nicht dar. Es bietet zwar eine akzeptable projektübergreifende Übersicht an und ist kos-
tenlos, allerdings ist die gewünschte Verknüpfung zu GitLab nicht gegeben.

8 Fazit und Ausblick

8.1 Fazit

Ziel der Seminararbeit war es, ein ideales Issue-Tracking-System für eine standortübergreifende
Ticketorganisation zu finden. Dabei wurden die Systeme GitLab, Jira (Software) und Red-
mine in Bezug auf die gegebenen Anforderungen näher betrachtet und analysiert.
Um ein resümierendes Fazit ziehen zu können, werden die Ergebnisse nochmal in einer
Tabelle veranschaulicht:

GitLab Jira Redmine
Projektübergreifende
o o +
Übersicht
Time Tracking o o o
geringer Kostenaufwand - + +
Anbindung an GitLab + - -
rot = unzureichend; gelb = hinreichend; grün = optimal

Tabelle 1: Übersicht der Anforderungen

Verglichen mit den anderen Systemen stellt sich Jira (Software) als unzureichende Möglichkeit
für die standortübergreifende Ticketorganisation heraus. Im Hinblick auf die gestellten An-
forderungen erfüllt Jira nur die Anforderung für den geringen Kostenaufwand. Jedoch hat
dies keinen großen Nutzen für die Umsetzung der Ticketorganisation. Die hierfür wichti-
gen Anforderungen werden nicht oder nur hinreichend umgesetzt.
Redmine hat eine Umsetzung für die Organisation von Tickets zu bieten. Hinzu kommt,
dass es sich bei Redmine um eine kostenlose Anwendung handelt. Trotz allem wird die
wichtigste Anforderung, die Anbindung an GitLab, unzureichend erfüllt. Aus diesem
Grund wird auch Redmine nicht für die Umsetzung der Ticketorganisation verwendet.
Als letzte Option bleibt GitLab offen. Hier werden unter anderem diverse Möglichkeiten
geboten, welche allerdings nicht zielführend sind. Darüber hinaus ist nur eine alternative
Lösung für die projektübergreifende Übersicht verfügbar. Die Umsetzung dieser Alterna-
tive gestaltet sich jedoch viel zu umständlich, als dass sie verwendet werden kann. Es wäre

theoretisch möglich, die Alternative mit anderen Features zu verbessern, was allerdings
erst mit einer kostenpflichtigen Version möglich ist. Infolgedessen wird auch GitLab nicht
für die Umsetzung der Ticketorganisation genutzt.

Ausgehend von den dargestellten Ergebnissen ist keines der hier genannten Systeme für
eine standortübergreifende Ticketorganisation geeignet. Somit ist das Ergebnis für die
Seminararbeit, dass für die gegebenen Anforderungen kein ideales Issue-Tracking-System
gefunden werden konnte.

8.2    Ausblick

Da das Ergebnis der Seminararbeit aussagt, dass kein geeignetes Issue-Tracking-System
im Rahmen der gegebenen Anforderungen gefunden werden konnte, entsteht das Interesse
ein eigenes System zu entwickeln. Folglich soll in naher Zukunft ein ideales Issue-Tracking-
System entwickelt werden, welches die hier genannten Anforderungen erfüllt.

                                            20

Literatur
 [1] Wikipedia:    Issue     Tracking    System.      https://de.wikipedia.org/wiki/
    Issue-Tracking-System. [Zuletzt Besucht am 07.01.2020].

 [2] Wikipedia: GitLab. https://de.wikipedia.org/wiki/GitLab. [Zuletzt Besucht
    am 07.01.2020].

 [3] Wikipedia: Git.       https://de.wikipedia.org/wiki/Git.     [Zuletzt Besucht am
    07.01.2020].

 [4] GitLab: Issue Boards. https://about.gitlab.com/product/issueboard/. [Zuletzt
    Besucht am 07.01.2020].

 [5] GitLab: Time Tracking.            https://docs.gitlab.com/ee/user/project/time_
    tracking. [Zuletzt Besucht am 07.01.2020].

 [6] GitLab: Preisübersicht. https://about.gitlab.com/pricing. [Zuletzt Besucht am
    07.01.2020].

 [7] Wikipedia: Jira. https://de.wikipedia.org/wiki/Jira_(Software). [Zuletzt Be-
    sucht am 07.01.2020].

 [8] Pix   Software:       Versionen    von   Jira.      https://www.pixsoftware.de/
    was-ist-jira-und-welche-versionen-gibt-es. [Zuletzt Besucht am 07.01.2020].

 [9] Atlassian: Jira Core preisübersicht. https://www.atlassian.com/de/software/
    jira/core/pricing. [Zuletzt Besucht am 07.01.2020].

[10] GitLab: Anbindung Jira an GitLab. https://docs.gitlab.com/ee/user/project/
    integrations/jira. [Zuletzt Besucht am 07.01.2020].

[11] Wikipedia: Redmine. https://de.wikipedia.org/wiki/Redmine. [Zuletzt Besucht
    am 07.01.2020].

                                              21

[12] Easy   Redmine:     Redmine    vs        Easy   Redmine.        https://www.
    easyredmine.com/de/faq-uber-easy-redmine/uber-die-software/
    3059-was-ist-der-unterschied-zwischen-redmine-und-easy-redmine.          [Zu-
    letzt Besucht am 07.01.2020].

[13] GitLab: Anbindung Redmine an GitLab.        https://docs.gitlab.com/ee/user/
    project/integrations/redmine. [Zuletzt Besucht am 07.01.2020].

                                         22

Sie können auch lesen