Einstieg

Der Artikel gibt einen “ersten” Einblick wenn man sich mit der Einführung von Atlassian JIRA beschäftigt. Es geht hier insbesondere darum, meine Erfahrungen aus der Praxis als Projektmanager. Insofern ist dieser Artikel der Auftakt von weiteren Artikeln zu Atlassian JIRA und dessen Einführung.

Was ist Atlassian JIRA für ein Tool?

JIRA ist ein Tool mit dem man auf Basis von Tickets Aufgaben verwalten, planen und “controllen” kann inkl. Reporting. Allgemein als Ticketsystem bezeichnet. JIRA unterstützt insbesondere Softwareentwicklungsprojekte, wobei verschiedene Projektmanagement-Methoden/Frameworks durch diverse Add-Ons unterstützt werden. So wird z.b. agiles Projektmanagement mit Scrum durch diverse “Möglichkeiten/Funktionalitäten” sowie Kanban als Prozesssteuerungsmethode unterstützt.

Cloudvariante vs. Serverinstallation

Im ersten Schritt werden wohl die Meisten auf die von dem Hersteller Atlassian cloudbasierte Version von JIRA zurückgreifen. Man zahlt für den Einstieg 10€ für bis zu 10 Teilnehmer. Für den Start reichen die Funktionalitäten auch vollkommen aus, alledings muss man dennoch konstatieren das viele notwendige, wenigsten jedoch sinnvolle Erweiterungen nur auf der “selbst”-gehosteten Variante installierbar sind. (Bedeutet JIRA läuft dann auf den eigenen Servern) Somit sollte man sich unbedingt vorher Gedanken machen, wie JIRA später verwendet werden soll. Einige Fragen die Sie sich stellen sollten hier noch einmal aufgeführt:

  • Werden Projekte klassisch oder agil durchgeführt?
  • Wird das Tool eher für die “interne” Entwicklung verwendet oder in einer Agentur mit hoher Kundenorientierung- und Beteiligung?
  • WirdJIRA in der Softwareentwicklung eingesetzt?
    • Soll der gesamte Projektlifecycle abgebildet werden?
  • Wird bereits ein GIT-Werkzeug benutzt und wenn ja welches? Lassen sich die in JIRA erstellten Tickets/Anforderungen damit verbinden?
  • Gibt es die Notwendigkeit eines umfangreichen Rollen-bzw. Berechtigungskonzept?
  • Sollen Aufwände projektübergreifend geplant werden können?
  • Ist eine Ressourcenplanung mit JIRA gewünscht?
  • und viele Fragen mehr…

All diese Fragen sollten als VORAB diskutiert werden bzw. während einer Evaluationsphase beantwortet werden können. Mehr dazu in einem späteren Beitrag.

Die Einführung ist zeitaufwendig!

Unabhängig vom Agenturgeschäft und/oder anderen Branchen, dort wo JIRA zum Einsatz kommen soll, wird man, ohne sich mit den Grundlagen zu beschäftigen – nicht sehr weit kommen. Ein “Learning by Doing” kann ich nur sehr bedingt empfehlen, da der Funktionsumfang und auch die Bedienung als solche gerade Anfangs nicht nur sehr komplex und umfangreich anmuten, sondern man bei der Erkundung der Möglichkeiten wirklich viel Zeit verliert. Man wird ein wenig erschlagen – wobei es weniger die Masse an Funktionen sind, als vielmehr die sehr “gewöhnungsbedürftige” oder “JIRA-spezifische” Bedienungsphilosophie. Die Empfehlung lautet daher im besten Fall einen Mitarbeiter im Unternehmen mit entsprechender Vorkenntnis zu identifizieren, je nach Vorhaben evtl. sogar einen entsprechenden Kollegen dafür einzustellen oder sich “Hilfe” von Aussen in Form von Beratung zu besorgen.

Die relevanten Parameter

Unabhängig ob Agentur oder interne Entwicklungsabteilung, die folgenden administrativen Parameter und Einstellungen habe ich als relevant für den Einstieg identifiziert. Grundsätzlich gibt es 3 Ebenen der Administration die man unterschiedet, da diese gerade zu Beginn allgegenwärtig sind:

  • Globale Einstellungen (Inkl. Plug-Ins)
    • Roles and Permissions-Scheme (Wer hat wann wie Zugriff),
    • IssueType-Scheme (Welche Tickettypen werden definiert bsp. Bugs, Taste, Subtasks etc.),
    • Workflow-Scheme (Beschreibt den Prozess den ein Ticket durchläuft oder auch als DEVEL-Cycle bezeichnet),
    • Screen-Scheme (Konfiguration wann welche Fields angezeigt werden…)
    • Security Scheme (Regelt bsp. welche Rollen, Gruppen etc. Tickets erstellen, ändern dürfen…)
  • Die Administration auf Projektebene
    • Die angelegten Schemes in den globalen Einstellungen können dann je nach Projekt ausgewählt werden und angepasst werden. Projektspezifische Einstellungen sind darüber hinaus;
    • Versions (Bsp. im Sinne von Releases und deren definierten Auslieferungsumfang),
    • Components,  (bsp. nach Bereichen der Entwicklung wie Frontend, Backend, Grafik, Konzept) nach denen man dann später Aufgaben sortieren und Filtern sowie Notifications wo definiert werden kann bei welcher Aktion Benachrichtigungen an welche definierten Rollen versendet werden.
  • Die Einstellungen in Bezug auf die im Projekt verwendeten Boards (Scrum-board, Kanban-Board)
    • Das Board visualisiert die Anzahl der Aufgaben und deren Status. Bsp. im einfachsten Fall hat eine Aufgabe den Status ToDo, in Progress und Done.

Agenturen und JIRA

Wie zu Beginn des Artikels angekündigt, möchte ich diesen ersten Artikel zu JIRA nicht beenden ohne noch einmal auf die besondere Situation von Agenturen einzugehen und welche Rolle dies bei der Einführung von JIRA spielt. Ich hatte ja bereits angedeutet das es sinnvoll ist, sich zu Fragen wo und wie JIRA eingesetzt werden soll. Das Agenturgeschäft ist zunehmend ein agiles, kundenorientiertes und sehr dynamisches Business.

Bedenkt man also das in einem zunehmend agilen Produktionsprozess immer häufiger auch Kunden beteiligt sind, so ist das eben auch in Bezug auf die Integration von JIRA im Unternehmen zu bedenken. Doch genau hier offenbart JIRA scheinbar seine Schwächen. Man kann JIRA nur bedingt so konfigurieren das der Zugriff sich auf kundenrelevante Tickets/Prozesse beschränkt.

JIRA und der Kunde

Beispielszenario: Ziel soll es sein den kompletten, agilen Entwicklungsprozess abzubilden. Denken wir also an Scrum reden wir von Product Backlog dem Sprint Backlog und eben den Sprint am Ende dessen ein Release anstehen kann bzw. ein entsprechendes fertiges Softwareprodukt ausgeliefert wird.

Der Prozess den eine Aufgabe durchläuft könnte mit Kundenbeteiligung so aussehen – hier nur angedeutet:

1. Product Backlog: Eine Aufgabe, – idealerweise als User-Story formuliert – wird durch einen Produktmanager oder entsprechenden Verantwortlichen im Product Backlog hinterlegt.

2. Freigabe Aufwand Kunde: Das geschätze Aufgabe aus dem Product Backlog wandert eben nur dann in das Sprint Backlog wenn der Aufwand entsprechend durch den Kunden freigegeben wurde.

3. Sprint Backlog: Für den nächsten Sprint landet die User-Story  im Sprint Backlog  – bedeutet – die Aufgabe soll im nächsten Sprint bearbeitet werden. (Sprint = Ein Sprint ist ein Arbeitsabschnitt, in dem ein Inkrement einer Produktfunktionalität implementiert wird. Quelle: wikipedia)

4. ToDo: Die im Sprint Backlog definierten Aufgaben werden als zu bearbeitende “Tickets” im Bereich “ToDo” den Entwicklern zur Verfügung gestellt…

Weitere Schritte könnten so aussehen: Request for CodeReview, Codereview…

An der Stelle scheint dann Punkt 2 recht spannend:
Erhält der Kunde in dem hier angedeuteten Prozess Zugriff auf das AgileBoard so ist es aus meiner Erfahrung nicht möglich bsp. den Zugriff auf den hier angedeutete “Freigabe” zu beschränken. Bedeutet der Kunde hat auch Zugriff auf alle anderen Tickets, Aufwandsschätzungen etc.
Sicherlich wäre JIRA nicht JIRA wenn man nicht für alles doch auch noch eine Alternative finden würde, jedoch ist das Thema nicht trivial und in der Gesamtbetrachtung bei der Einführung von JIRA nicht zu vernachlässigen.

Mehr dazu in Teil 2 zu JIRA im Agentur-Einsatz…

Sie haben Fragen zu dem Beitrag? Spreche Sie mich an:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

%d Bloggern gefällt das: