Teams sollten in der Lage sein, erfolgreich zu sein und geniale Software zu produzieren. Dies kann durch Agile Best Practices erreicht werden, aber es kann nicht schaden, wenn Ihre Tools die Sache für jedes Ihrer Teammitglieder einfacher und effektiver machen.

Ich bitte um Applaus für JIRA Softwares neuste Berechtigungen: Manage Sprint. Dieser Artikel dreht sich um diese neuen Berechtigungen und darum, was hinter den Kulissen passiert, um Ihr Team zu beeinflussen. Wir werden Ihnen außerdem einen Überblick darüber geben, wie Manage Sprint-Berechtigungen Planung und Überwachung einfacher machen, Overhead entfernen und allgemein das Risiko minimieren – keine Single Points of Failure mehr und stattdessen ein Umfeld, in dem das gesamte Team agiler sein kann.

Berechtigungen in JIRA Software

Um zu verstehen, wie die neuen Sprint-Berechtigungen funktionieren, lassen Sie uns einen Schritt zurück machen, um Berechtigungen im Allgemeinen zu verstehen. In JIRA Software sind Berechtigungen Einstellungen und steuern, was die Benutzer sehen können; ob Sie ein Admin sind oder nicht, sie beeinflussen die Art und Weise, wie Sie arbeiten. Berechtigungen reichen von Einstellungen, die einschränken, wer ein neues Projekt erstellen kann, oder ob ein Benutzer einen Kommentar zu einer bestimmten Issue abgeben kann, bis hin zu Einstellungen die festlegen, welche Gruppe von Leuten das Design eines Workflows ändern können. In der Berechtigungshierarchie gibt es drei verschiedene Berechtigungstypen:

• Globale Berechtigungen: Diese gelten für JIRA Software als Ganzes, nicht für einzelne Projekte (zum Beispiel, ob Benutzer andere Benutzer sehen können).
• Projektberechtigungen: Diese gelten für Projekte und sind in Berechtigungsschemata organisiert (zum Beispiel, wer kann Projekt-Issues sehen, erstellen, bearbeiten oder zuordnen). Berechtigungen auf Projektebene helfen Ihnen dabei festzulegen, was Benutzer innerhalb eines Projekts tun können.
• Issue-Berechtigungen: Issue-Berechtigungen beziehen sich auf das Sichtbarkeitslevel, das einzelne Issues für bestimmte Teammitglieder oder bestimmte Rollen haben. Issue-Berechtigungen erlauben es Ihnen beispielsweise, Arten von Issues so zu erstellen, dass diese nur von Projekt-Administratoren gesehen werden können.

Ein Teil des Agil-seins und des Arbeitens in einem agilen Team, ist die Fähigkeit funktionsübergreifend zu arbeiten und das „Eigentum“ miteinander zu teilen.

Wenn ein Produktmanager oder Teamleiter nicht anwesend war und das Team einen Sprint abschließen musste, dann musste man warten, bis diese Person zurückkehrte (oder eine andere Person mit den richtigen Berechtigungen finden). Um dieses Problem zu beheben und Teams mehr Kontrolle über ihre Arbeitsweise zu geben, wurden Sprintberechtigungen erstellt. Das Feature in JIRA Software heißt nun Manage Sprint.

Sprintverpflichtungen und Management

Die neuen Sprintberechtigungen lösen die meisten der oben genannten Probleme, indem sie zwei Dinge tun: 1) sie ermöglichen es Teams, besser zu organisieren, wie sie mit Sprints arbeiten, und 2) sie schaffen eine neue Ebene des Vertrauens dafür, wie die Teams und wie die einzelnen Teammitglieder die Sprintverpflichtungen angehen.

Bevor Sie nun aber eine Entscheidung darüber treffen, wie Sie die neuen Sprintberechtigungen nutzen wollen, ist hier eine Liste der Sprintverpflichtungen, die durch die Manage Sprint-Berechtigung zugelassen wird:

• Erstellen von Sprints
• Beginnen von Sprints
• Abschließen von Sprints
• Bearbeitung von Sprintinformationen (Sprintname und Termine)
• Neuordnen von Sprints (derzeit nur zukünftige Sprints)
• Löschen von Sprints (derzeit nur zukünftige Sprints)
• Wiedereröffnung von Sprints
• Bewegen des Sprintfooters

Denjenigen, die bereits mit Berechtigungen vertraut sind, erscheint die oben aufgeführte Liste vielleicht vertraut, da sie im Grunde die bestehenden Projektadministratorberechtigungen auflistet. Wenn Sie mit Berechtigungen nicht sonderlich vertraut sind, dann stellen Sie sich einfach vor, dass Manage Sprint-Berechtigungen Ihrem Team gewisse Türen öffnen, um agiler zu werden.

Wenn Sie beispielsweise in einem Sprintplanungsmeeting sitzen und sich fragen: „Wie sieht die Schätzung für den Sprint aus?“, weil Sie die Menge der zu erledigenden Arbeit im kommenden Sprint nervös macht, können Sie anstatt auf jemanden mit den richtigen Berechtigungen zu warten, den Sprintfooter während des Meetings bewegen und Ihre Bedenken überprüfen, um entweder herauszufinden, dass alles in Ordnung sein wird, oder dass eine Issue neu bewertet werden muss.

Sprintberechtigungen und Best Practices

Wenn Sie bereits bestehender Nutzer sind und sich wohlfühlen, was Berechtigungen angeht, dann denken Sie darüber nach, wie Ihr Team mit Sprints arbeitet. (Beachten Sie, dass mit diesem neuen Feature jeder in der Administer Project-Mitgliedschaft automatisch zu den Manage Sprint-Berechtigungen kopiert wird). Muss der Projektadministrator für das Starten und Stoppen eines Sprints verantwortlich sein? Oder möchten Sie eine Gruppe erstellen, die den Scrum Mastern ähnlich ist?

Ein häufiger Anwendungsfall, der für Letzteres sprechen würde, ist wenn Ihr Team mit einem Auftragnehmer wie beispielsweise einem engagiertem Scrum Master oder einem agilen Coach zusammenarbeitet. Wenn diese Person Berechtigungen benötigt, um Sprintinformationen zu bearbeiten, Sie aber nicht wollen, dass die Person Versionen oder Komponenten in einem Projekt bearbeiten kann, dann können Sie dieser Person Sprintberechtigungen geben, um die Auswirkungen auf das Projekt als Ganzes zu minimieren.

Dieser Anwendungsfall trifft möglicherweise nicht auf Ihr Team zu, aber es gibt Ihnen eine Vorstellung davon, wie Sie über die Verwendung von Sprintberechtigungen nachdenken sollten. Wer in Ihrem Team soll in der Lage sein, Sprints erneut zu öffnen, oder abzuschließen, aber nicht die Projektinfrastruktur zu ändern? Für Atlassian bedeutet dies in der Regel, dass Sprintberechtigungen an das gesamte Team vergeben werden, weil wir darauf vertrauen, dass jedes Teammitglied das Richtige tun wird – das Team sollte das Gefühl haben, dass es in der Lage ist, voranzukommen und durch einen Sprint zu arbeiten, selbst wenn ein Produktmanager oder Teamleiter abwesend ist. Um agil zu sein, müssen wir schnell sein und kontinuierlich Software abliefern.

Diese neue Berechtigung hilft Ihrem Team außerdem dabei, mehr Kontrolle über den Sprint zu haben, an dem es Tag für Tag arbeitet, während sie auch Projekt- und globalen Admins Vorteile bietet.

Finden Sie heraus, wo Berechtigungen Ihr Team zurückhalten – wenn überhaupt – und finden Sie heraus, wie diese Berechtigungsstufe Ihrem Team dabei helfen kann, so zu arbeiten, wie es will.

Wenn Sie eine neue Instanz erstellen, dann werden Manage Sprint-Berechtigungen standardmäßig für alle Projekte aktiviert und jeder Benutzer wird die Möglichkeit haben, alle oben aufgeführten Sprintverpflichtungen durchzuführen. Das ist ideal für neue Teams und / oder neue Teammitglieder, für die nichts gesperrt sein muss.

Sprintberechtigungen sorgen für bessere und agilere Entwicklung

Durch das Einrichten einer neuen Berechtigungsstufe, welche Sprints und Boards enger miteinander verbindet, rückt Atlassian die Prinzipien der agilen Softwareentwicklung in den Vordergrund Ihrer Erfahrung mit JIRA Software. Einen Sprint laufen zu lassen, ist eine der agilen Kernzeremonien und eine Teamleistung. Genauso wie andere agile Zeremonien, die mit Sprints in Verbindung stehen, wie Sprintplanung, Stand-Ups und Sprintreviews. Jede dieser Zeremonien ist, bis zu einem gewissen Grad, auf Sprintberechtigungen angewiesen. In einem Sprintplanungsmeeting müssen Sie in der Lage sein, den Sprintfooter für Schätzungen zu verwenden, und wenn Sie bereit sind, müssen Sie den Sprint starten. Wenn ein Sprint läuft, dann müssen Sie manchmal Informationen, wie den Namen und die Termine bearbeiten. Oder Sie müssen einen Sprint erneut öffnen, wenn er aus Versehen oder zu früh geschlossen wurde.

Außerdem geschieht es ziemlich häufig, dass Produktmanager und Entwicklungsleiter vorausplanen und versuchen, zukünftige Sprints zu organisieren, indem Sie Backlog-Items in verschiedene Sprint-Backlogs bewegen, ohne zu bemerken, dass der zukünftige Sprint bereits existiert (in diesem Fall müssen Sie das Duplikat löschen). Manage Sprint-Berechtigungen entfernen viele Blockaden, die Teammitglieder an der Durchführung dieser Maßnahmen hindern würden. Vor allem liegt es in der Verantwortung des Teams, das herauszufinden.

Indem Atlassian diese beiden Aktionen über Sprintberechtigungen zugänglich macht, wird die Nutzererfahrung noch angenehmer, um Ihnen dabei zu helfen, für Ihr Team auf effektive Art und Weise mit Sprints arbeiten zu können.

Wenn ein Unternehmen wächst, entwickelt es je nachdem, wie die Mitarbeiter in kleinen Teams zusammenarbeiten, seine ganz eigene Kultur. Wie ein Team funktioniert, hängt größtenteils von seinem Workflow ab. Dies ist ein wiederholbarer Prozess, der es Leuten ermöglicht, in einem gewissen Maßstab zusammenzuarbeiten.

Werfen wir zunächst einen Blick darauf, was einen Workflow definiert. Ein Workflow besteht aus vier einzigartigen Komponenten: Zustände, Übergänge, Verantwortliche und Lösungen. Bibliotheken besitzen beispielsweise bestimmte Arbeitsabläufe, was die Materialien angeht, die sie verleihen. Jedes Element kann in JIRA Software als ein Issue gespeichert werden, und anschließend in folgendem simplen Workflow verwaltet werden:

Status: Wo?

Zustände repräsentieren die Position des Issues innerhalb eines Workflows. Im Falle der Bibliothek kann sich ein Buch an einem der folgenden drei Orte befinden: In der Bibliothek, bei einem Kunden, oder es wurde aus dem Bestand entfernt. Jeder Status sollte ein einzigartiger Zustand im Workflow sein.

Übergänge: Wie?

Übergänge sind die Brücken zwischen den Zuständen; die Art und Weise, auf die sich ein Issue von Status zu Status bewegt. In der Bibliothek werden Bücher von Bibliothekaren verliehen, von den Kunden zurückgegeben und durch das Bibliothekspersonal überprüft, um sicherzustellen, dass die Bücher zum Verleih geeignet sind. Beachten Sie dabei, dass Kunden nicht beurteilen können, ob der ausgeliehene Artikel immer noch für den Verleih geeignet ist – diese Entscheidung muss durch das Bibliothekspersonal getroffen werden. Mit JIRA Software sind Sie in der Lage, Workflowberechtigungen festzulegen, damit nur die richtigen Leute die Erlaubnis haben, den Status eines Issues zu ändern.

Verantwortliche: Wer?

Workflows legen fest, auf welche Weise Menschen zusammenarbeiten. In JIRA Software definiert der Verantwortliche die verantwortliche Partei für ein bestimmtes Issue. In unserem Bibliotheksbeispiel würden wir festlegen, dass der Entleiher der Verantwortliche ist, damit die Bibliothek weiß, welcher Kunde momentan im Besitz des Buches ist. Wenn das Buch in den Bestand zurückkehrt, würden wir anschließend den Verantwortlichen wieder entfernen, nachdem wir das Buch wieder dem Bestand zugeführt haben.

Lösungen: Warum?

Lösungen liefern den Grund dafür, warum ein Issue von einem offenen Zustand in einen geschlossenen Zustand übergeht. Wenn beispielsweise ein Buch aus dem Bestand entfernt wird, können wir eine Lösung für dieses Buch eintragen. In diesem Beispiel können wir eine Lösung, wie beispielsweise „beschädigt“, „veraltet“ oder „verloren“ verwenden. Die beiden größten Fehler, die frischgebackene Administratoren in JIRA Software machen können, sind folgende:

• Lösung mit Status verwechseln – Ein Status beschreibt, wo sich ein Element im Workflow befindet, während Lösungen erklären, warum ein Issue nicht mehr in Bearbeitung ist. Um diese Funktionen effektiv zu nutzen und ein Buch aus dem Verkehr zu ziehen, sollte unser Bibliothekar einen Status namens „im Ruhestand“ erstellen, und Optionen für die Lösung, wie beispielsweise „verloren“, „beschädigt“ oder „veraltet“ festlegen. Dadurch, dass Sie nach allen Dingen suchen können, die im Ruhestand (oder gelöst) sind – mit der Möglichkeit, über die Optionen nach dem Grund für die Lösung zu suchen – können Sie wesentlich bessere Berichtsmesswerte erhalten. Deshalb verwendet JIRA Software Lösungen, um herauszufinden, ob das Issue vom Unternehmen als inaktiv betrachtet wird. Am besten verwenden Sie das Erstellt versus Abgeschlossen-Gadget, um herauszufinden, ob Sie es richtig gemacht haben. Wenn ein Issue mit einer Lösung markiert und offiziell geschlossen wurde, können Sie einen Workflow dazwischen haben. Viele Organisationen überprüfen abgeschlossene Issues, um sicherzustellen, dass sie wegen des richtigen Grundes geschlossen wurden.

• Lösung nicht korrekt einstellen – Sie müssen eine Lösung festlegen, wenn ein offenes Issue geschlossen wird. Wenn ein Issue erneut geöffnet wird, dann muss die Lösung wieder entfernt werden. Wenn die Bibliothekare in unserem Beispiel entscheiden, dass sie ein Buch wieder in Umlauf bringen möchten, dann müssen sie die Lösung, die für dieses Buch festgelegt wurde, wieder entfernen. Wenn beispielsweise ein Buch überprüft werden kann, dann sollte es nicht die Lösung „verloren“ besitzen.

Wie erstelle ich einen Workflow?

Hier sind einige Ratschläge:

Versammeln Sie alle Ihre Interessengruppen

Bei Workflows geht es darum, Kultur zu skalieren, und Kultur hat immer mit Menschen zu tun. Immer wenn es an der Zeit ist, einen Prozess um eine Gruppe von Leuten herum zu erstellen, dann identifizieren Sie alle Stakeholder in diesem Workflow. Wenn Sie zum Beispiel versuchen, einen Workflow zwischen Produktmanagement, Softwareentwicklung und Support aufzubauen, dann sollten Sie einen Vertreter aus jeder Gruppe in Ihrem Meeting haben. Als die Person, die den Workflow entwirft, sollten Sie mit jeder Interessengruppen sprechen, um herauszufinden, was für jede einzelne Gruppe wichtig ist. Vor dem Beginn des Meetings sollten Sie einen Entwurf des Workflows auf das Whiteboard zeichnen, während des Meetings dann jeden Fall durchgehen und anschließend Feedback von den Interessengruppen sammeln. Workflows sind ein empfindliches Thema, da sie festlegen, wie Menschen zusammenarbeiten. Seien Sie also geduldig und Ihre Investition wird sich später bezahlt machen.

Der Entwurf auf dem Whiteboard sollte nur wenig genau sein, damit es in diesem Stadium einfacher ist, Feedback zu bekommen.

Gestalten Sie den Workflow simpel: Weniger ist mehr

Meistens möchten die Interessengruppen für jeden Teil des Workflows einen Status. Im Grunde ist das eine gute Sache, aber vergessen Sie nicht: Jeder Status fügt mehr Übergänge und Komplexität zum Workflow hinzu. Workflows sollen die Dinge jedoch einfacher und skalierbar machen. Jedes Mal, wenn Sie einen neuen Status zu einem Workflow hinzufügen, sollten Sie sicherstellen, dass die jeweilige Interessengruppe keine andere Wahl hat, als den Workflow zu vergrößern. Schauen wir uns zwei Beispiele an.

1) In vielen Unternehmen ist Code-Review ein wichtiger Bestandteil des Software-Entwicklungsprozesses. Jane, die Entwicklungsmanagerin, will einen bestimmten Status namens Code-Review hinzufügen, damit es für das Team ersichtlich ist, welche Issues aktiv bearbeitet werden und welche Issues überprüft werden müssen. Code-Reviewing unterscheidet sich deutlich vom Schreiben des Codes. Es ist sinnvoll, einen neuen Status hinzuzufügen, da der Überprüfungsprozess anzeigt, dass die Entwicklung abgeschlossen ist und jemand anderes nun verantwortlich ist.

2) Bill, der Testmanager, will einen neuen Status namens „abgelehnt“ für all diejenigen Issues hinzufügen, die von seinem Team abgelehnt wurden. Ich würde davon jedoch abraten, da die Tester ein Issue einfach erneut öffnen können, wenn die Überprüfung nicht erfolgreich ist. Eine Alternative wäre, das Issue als abgeschlossen zu markieren und mit der Entscheidung „abgelehnt“ zu versehen.

Als JIRA Software-Administrator sind Sie es sich und Ihren Nutzern schuldig, den Workflow simpel zu halten.

Jeder Übergang zählt

JIRA Software bietet eine Reihe von Optionen, die Administratoren verwenden können, wenn Issues den Status wechseln.

• Bedingungen – Bedingungen legen fest, wer einen Übergang durchführen kann. So kann beispielsweise nur ein Mitarbeiter in der Bibliothek ein Buch aus dem Bestand entfernen.
• Validatoren – Validatoren stellen sicher, dass ein Übergang durchgeführt werden kann. Wenn beispielsweise ein Buch aus dem Verkehr gezogen werden soll, weil es angeblich von einem Kunden beschädigt wurde, dann möchten wir sicherstellen, dass das Buch mindestens einmal überprüft wurde, um die Behauptung zu verifizieren.
• Post Functions – Post Functions führen Aktionen an Issues durch, nachdem die Bedingungen und Validatoren genehmigt wurden. Die am häufigsten verwendete Post Function ist, eine Lösung zu löschen, wenn ein Issue erneut geöffnet wurde. Wenn in unserem Beispiel ein Buch in den Umlauf zurückgebracht wird, dann würden wir eine Post Function nutzen, um den Grund, aus welchem das Buch aus dem Verkehr gezogen wurde, zu löschen. JIRA Software speichert einen detaillierten Verlauf aller Issues, weshalb wir nachsehen können, wann und weshalb das Issue abgeschlossen wurde.
• Bevollmächtigte – Immer wenn ein Übergang stattfindet, fragen Sie, wer der neue Eigentümer des Issues ist. Stellen Sie sicher, dass es für jeden Übergang eine Standardaktion gibt, welches das Issue an den richtigen Ort leitet. Benutzer können die Standardaktion auch umgehen.
• Eigenschaften – JIRA Software kennt bei den Übergängen einige Eigenschaften. Die häufigste ist, die Entscheidungen, die dem Nutzer für einen bestimmten Übergang angezeigt werden, zu limitieren. Zum Beispiel möchten wir, dass für CDs und DVDs die Entscheidung „zerkratzt“ angezeigt wird, wenn wir diese aus dem Umlauf nehmen, bei Büchern soll diese jedoch nicht angezeigt werden.

So bauen Sie in JIRA Software einen Workflow

Sobald Sie bereit sind, Ihre Arbeitsabläufe in JIRA Software zu erstellen, sollten Sie sich Zeit nehmen, um sicherzugehen, dass die Qualität Ihres Workflow-Diagramms für eine Präsentation geeignet ist. Sie sollten das Diagramm mit allen Interessengruppen teilen, um zum Abschluss noch einmal Feedback zu sammeln. Sie sollten außerdem die Option in JIRA Software aktivieren, mit der Sie sehen können, wo genau sich das aktuelle Issue innerhalb des Workflows befindet. Nutzer müssen dann nur noch auf „Workflow ansehen“ klicken.

Abschließend

Das Beste am Entwickeln von Workflows mit JIRA Software ist es, Menschen dabei zu helfen, effizienter zusammenzuarbeiten. Hören Sie immer auf Ihre Kunden, haben Sie Einfühlungsvermögen, und helfen Sie ihnen dabei zu verstehen, weshalb ihre Herangehensweise ineffizient sein könnte und auf welche Arten man die Arbeitsweise verbessern kann. Wenn die Leute gut zusammenarbeiten, haben sie mehr Spaß und können mehr Arbeit erledigen. Wer möchte das nicht?

Zu Beginn des Artikels sagte ich, dass es wichtig ist, Workflows richtig zu verstehen. Im nächsten Artikel werden wir uns ansehen, wie sich Daten innerhalb von JIRA Software basierend auf Workflows visualisieren lassen.

Dies ist der zweite Beitrag einer zweiteiligen Serie über die Verwendung von Workflows in JIRA Software. Wenn Sie den ersten Beitrag Workflows genial konzipieren noch nicht gelesen haben, dann sollten Sie diesen zuerst lesen. Für diejenigen, die den ersten Artikel bereits gelesen haben, werden wir in diesem Beitrag alle Fragen beantworten, die Sie vielleicht haben. Wir werden uns dieses Mal auf praktische Anwendungen konzentrieren, um Ihr Wissen zu verfestigen, was das Erstellen und die effektive Verwendung von Workflows innerhalb Ihrer Organisation angeht.

Viele der Produkte, mit denen wir tagtäglich arbeiten, haben einen Lebenszyklus, welcher innerhalb des Workflows dargestellt werden kann. Wenn wir nun auf unser Beispiel mit der Bibliothek aus dem ersten Beitrag zurückkommen, sehen wir, dass die Bücher solange ein- und ausgecheckt werden, bis sie das Ende ihrer Lebensdauer erreicht haben und folglich in den Ruhestand geschickt werden. Bugs in einem Software-Projekt werden protokolliert, überprüft, behoben, überprüft, und dann geschlossen. Die nächste Frage, die wir uns stellen müssen ist, welche Daten wir von unserem Workflow wollen. Lassen Sie uns die vier Hauptkonzepte des Workflows erneut betrachten:

• Status: Wo?
• Bevollmächtigter: Wer?
• Auflösung: Warum?
• Übergang: Wie?

Wie man einen Status in einem Workflow einrichtet

Jeder Zustand im Workflow sollte eine Phase oder einen Prozess im Lebenszyklus des Issues darstellen. Mit JIRA Software ist es leicht, ein Board zu erstellen, welches die Arbeitsabläufe für die Lebenszyklen aller Issues zeigt. Sehen wir uns einmal an, wie ein solches Board in Aktion aussieht:

Wir können jede Arbeitsphase ansehen und überprüfen, wie viele Issues in jeder einzelnen Phase enthalten sind. Es ist ein leichtes für Teams, die Arbeitsabläufe maximieren wollen, Work-in-Progress-Limits wie Code-Review einzurichten. Damit lässt sich verhindern, dass sich ein Rückstand aus Issues bildet, welche auf eine Überprüfung warten. Dass der Workflow Teil der Kernerfahrung ist, stellt der vielen Vorteile eines agilen Boards dar. Beachten Sie, dass sich mehrere Zustände in einer Spalte befinden können. Wenn beispielsweise die Zielgruppe eine Interessengruppe außerhalb des Teams ist, dann könnten „im Gange“ und „Code-Review“ in der gleichen Spalte sein. In ihren Augen stehen beide Zustände für „im Gange“.

Was, wenn wir einen High-Level-Überblick darüber erhalten möchten, wo genau sich die Arbeit in einer Reihe von Veröffentlichungen versteckt? Die empfohlene Standardlösung für dieses Problem ist das zweidimensionale Filter-Statistiken-Gadget. Dazu lege man den Status auf die X-Achse, die Version auf die Y-Achse, und wähle Gesamtzahlen aus. Das Ergebnis ist eine einfach zu lesende Matrix Ihres Projektes. Durch Klicken auf eine Zahl können Sie die Issues ansehen, für die diese Zahl steht.

So konfigurieren und verwenden Sie das „Bearbeiter“-Feld

Workflows sollen Menschen dabei helfen, effizienter miteinander zu arbeiten. Wenn Sie in JIRA Software noch keine Profilbilder verwenden, dann empfehlen wir Ihnen, dass Sie diese Funktion auf jeden Fall nutzen. Es ist von entscheidender Bedeutung, den Beitrag des Teams anzuzeigen. Das zweidimensionale Filterstatistiken-Gadget macht es einfacher, die Arbeitsverteilung im Team zu erkennen, wenn Sie das „Bevollmächtigter“-Feld konfigurieren. Ich finde es hilfreich Bevollmächtigter und Priorität gemeinsam anzusehen, um sicherzustellen, dass kein Teammitglied zu viele kritische Issues hat.

Wann ist ein Issue abgeschlossen?

Jeder Workflow besitzt einen „Tipping Point“, oder einen Höhepunkt. Wenn beispielsweise ein Buch im Ruhestand ist, dann ist es ganz klar auf dem Weg zum Status „abgeschlossen“. Wenn im Software-Engineering-Workflow ein Entwickler eine Änderung aufgibt, dann beginnt das ursprüngliche Issue mit der Überprüfungsphase seines Lebenszyklus. Nur weil für ein Issue eine Entscheidung getroffen wurde, bedeutet das nicht, dass es abgeschlossen ist. Lassen Sie es mich wiederholen: Ein Issue mit einer Lösung unterscheidet sich von einem Issue, das geschlossen ist. Ein Buch in unserem Bibliotheksbeispiel kann im Ruhestand sein, weil es abgenutzt ist; wir könnten einen Status namens „Bestellung im Gange“ hinzufügen, während wir auf ein Ersatzbuch warten.

Der hervorgehobene Übergang in blau würde als Lösung „Ersatz wird benötigt“ festlegen. Wenn das neue Buch ankommt, dann würde die Bibliothek ein neues Issue für das neue Buch erstellen. Bei Softwareteams sollte die Lösung für ein Issue „behoben“ lauten, wenn ein Entwickler eine Änderung durchgeführt hat. Das Issue geht anschließend in einen Überprüfungszustand über, damit jemand anderes es überprüfen kann. Das Issue ist noch offen, aber „gelöst“. Sobald die Lösung für das Issue überprüft wurde, kann es geschlossen werden.

Wir können das zweidimensionale Filterstatistiken-Gadget nutzen, um die Lösung nachzuverfolgen. Häufig betrachten Entwickler das Einreichen einer Änderung als „ich bin fertig“. Die Verwendung dieses Gadgets zum Nachverfolgen von entschiedener-aber-nicht-abgeschlossener Arbeit hilft allen Beteiligten dabei, ein Gesamtbild über alle noch nicht vollständig erledigte Arbeit abzuliefern.

So erstellen und verfolgen Sie Übergänge

Wie ich bereits im vorherigen Artikel erwähnt habe, sind Übergänge ein extrem wichtiger Teil von Workflows. Wenn Sie verstehen wollen, wie die Arbeit in Ihrer Organisation abläuft, dann werfen Sie einen genaueren Blick auf Ihre Issues, indem Sie JQL verwenden. JQL ist die Abfragesprache von JIRA Software. JQL hilft Ihnen dabei, einen detaillierten Blick darauf zu werfen, wie die Arbeit in Ihrer Organisation abläuft. Fehlerbehebungen, welche die Überprüfung nicht erfolgreich bestehen, sind eine wichtige Kennzahl für Ihre Softwareteams. Nehmen wir an, dass wir sehen möchten wie viele Überprüfungen von Issues im letzten Monat gescheitert sind. Hier ist der entsprechende JQL-Code:

project TIS STATUS changed "Quality Review" "In Progress" after 4w


Wie viele Fehler wurden ohne eine Fehlerbehebung aufgelöst? Wir können JQL verwenden, um alle Issues mit den Lösungen ungültig oder nicht reproduzierbar anzeigen zu lassen. Fehler, die eingereicht werden, aber nicht behoben werden, sind eine Last für alle Beteiligten.

JQL-Code:
project TIS STATUS changed Resolved after 4w resolution Fixed

Über das Reporter- und das Erstellen-Feld können wir außerdem den Erstellen-Übergang abfragen. Die JQL-Funktion membersof () macht es einfacher, mit Gruppen von Menschen zu arbeiten. Wenn Sie eine Gruppe in JIRA Software namens Produkt-Engineering haben, können Sie sehen, wie viele Fehler außerhalb des Kernprodukts-Team gemeldet wurden.

JQL-Code:
project TIS reporter membersof product engineering created > 4w


Übergänge zwischen Zuständen zu analysieren, ist der beste Weg, um zu verstehen, wie Ihr Workflow verbessert werden kann. Wenn Sie in einem bestimmten Zustand einen Rückstau an Issues bemerken sollten Sie die Gründe, weshalb die Issues diesen Zustand erhalten und wieder verlieren genauer untersuchen. Hier sind einige Fragen, die Sie sich in diesem Fall stellen können:

• Stelle ich sicher, dass alle Issues mit diesem Zustand exakt definiert sind?
• Wie viele Issues mit diesem Zustand sind zu ihrem ursprünglichen Zustand zurückgekehrt?
• Wie lange haben Issues diesen Zustand? Befindet sich das im Einklang mit den Erwartungen des Teams?
• Warum kehren Issues zu diesem Zustand zurück?

Wenn Sie mit JQL Übergänge nachverfolgen, können Sie konkrete Verbesserungsvorschläge für Ihren Workflow liefern und dafür sorgen, dass Ihr Team optimal funktioniert.

Lassen Sie den Workflow die Arbeit erledigen

Die beste Methode, um den Workflow zu verbessern lautet Messung. Der größte Vorteil von Workflows ist, dass Sie quantifizieren und nachvollziehen können, wie Menschen zusammenarbeiten. Mit JIRA Software müssen Sie dabei aber nicht das „Wie“ opfern. Wie bei allen agilen Dingen: Nutzen Sie Ihren Basispunkt, definieren Sie Kennzahlen für Messungen, verfolgen Sie die Ergebnisse und führen Sie die erforderlichen Änderungen und Team-Retrospektiven durch.

Die meisten Unternehmen implementieren agile Entwicklung in ihre Kultur, weil sich ihre Teams nach Freiheit und Flexibilität sehnen und nach ihren eigenen Vorstellungen arbeiten möchten. Je mehr das Unternehmen wächst, umso schwieriger wird es, den Überblick über alle laufenden Initiativen zu behalten. Den Status und Fortschritt, wer arbeitet an was und welche Teams und Projekte sind voneinander abhängig, im Blick zu behalten ist nicht einfach. Daraus ergibt sich folgendes Dilemma: Projektleiter benötigen Sichtbarkeit, um Entscheidungen zu treffen – ohne dabei die Autonomie der Teams zu begrenzen.

Agile Portfolio-Management-Tools wie Portfolio für JIRA helfen Ihnen dabei, ein besseres Verständnis darüber zu erlangen, was in Ihren Teams und Projekten vor sich geht.

Wenn Sie sich regelmäßig eine der folgenden fünf Fragen stellen, dann sollten Sie es selbst einmal ausprobieren.

1. Frage: Woran arbeiten die Teams wirklich, und wie tragen sie zu den Zielen des Unternehmens bei?

Wenn Sie mehrere Teams haben, die an mehreren Projekten arbeiten, dann lässt sich nur schwer erkennen, woran die einzelnen Teammitglieder arbeiten. Und wenn Sie nicht wissen, woran die Leute arbeiten, lässt sich unmöglich feststellen, ob Sie in Ihrem Portfolio die richtige Reihe von Investitionen priorisieren. Stellen Sie sich vor, wie komplex die Sache erst wird, wenn Sie zunächst 10 Teams und dann 50 Teams und schlussendlich mehr als 100 Teams haben.

Ein agiles Portfolio-Management-Tool gibt Ihnen einen geballten Überblick über alle Ihre Teams und bietet Ihnen zudem die Möglichkeit, Geschäftsziele zu setzen und deren Fortschritt nachzuverfolgen. So lässt sich sicherzustellen, dass Sie Ihre Strategie erfüllen. Außerdem verleiht das Tool auch den Team-Mitgliedern diese Transparenz, damit jeder die gleichen Ziele verfolgt und dieselben Prioritäten hat.

2. Frage: Wie können wir Abhängigkeiten zwischen Teams und Projekten nachverfolgen?

Wenn Sie nur ein einziges oder nur eine Handvoll Teams haben, dann ist die Verfolgung von Abhängigkeiten relativ einfach, aber wenn die Anzahl der Teams und Projekte wächst, dann steigt auch die Anzahl der Abhängigkeiten. Mit der Zeit ergeben sich Abhängigkeiten, bei denen bestimmte Teams auf andere Teams angewiesen sind, Abhängigkeiten, die mehrere Teams und Projekte betreffen, und nicht zu vergessen, die ständigen Veränderungen, die auftreten, wenn sich Dinge verschieben und verändern, während das Projekt Fortschritte macht. Es ist äußerst wichtig, dass Sie jederzeit einen Gesamtüberblick über alle Abhängigkeiten aufrufen können, und dass sich diese Abhängigkeiten in Echtzeit aktualisieren, wenn sich die Dinge ändern.

Durch ein agiles Portfoliomanagementtool erhalten Sie einen genauen Einblick in Ihre Teams und Projekte, wodurch Sie Abhängigkeiten auf Ebene von Storys, Epics und Initiativen planen, verwalten und nachverfolgen können. So kommt es in späten Stadien des Entwicklungszyklus nicht plötzlich zu bösen Überraschungen, die eigentlich vermeidbar gewesen wären.

3. Frage: Wann können wir liefern? Sind wir in der Lage, unsere Releasetermine einzuhalten?

„Wann können wir liefern?“ ist wahrscheinlich die häufigste Frage, die Stakeholder stellen werden und ist zudem eine Frage, die sich kaum mit Sicherheit beantworten lässt. Ohne diesen Grad an Sichtbarkeit lässt sich unmöglich feststellen, ob die Teams tatsächlich ihren Verpflichtungen nachkommen können oder nicht. Wenn Sie eine Prognose haben, kann sich die Situation trotzdem noch ändern, und Sie müssen sicherstellen, dass sich Ihre Prognose ebenfalls ändert.

Wenn Sie das Gefühl haben, dass Sie nicht wirklich wissen, wann genau Sie ein Release abliefern können, oder Sie an den prognostizierten Releaseterminen zweifeln, weil Sie den Daten nicht vertrauen, dann kann Ihnen ein agiles Portfoliomanagementtool helfen. Das Tool erstellt für Sie dynamisch Prognosen zu realistischen Releaseterminen, damit Sie einerseits wissen, wann Sie liefern können und Sie andererseits Ihren Zeitplan in Echtzeit optimieren können, um frühzeitig mögliche Engpässe erkennen und auf diese reagieren können, bevor sie zu einem Problem werden.

4. Frage: Wer befindet sich auf dem kritischen Pfad für das Release, und wo sind die Engpässe?

Sie müssen wissen, wo sich das schwächste Glied in Ihrem Zeitplan befindet. Ist es die Gesamtkapazität oder sind es spezielle Skillsets, die für Ihre Projekte erforderlich sind? Fällt durch Abhängigkeiten zwischen den Arbeitseinheiten am Ende alles zusammen, wenn es zu einem Problem kommt? Sie müssen außerdem verstehen, welche Auswirkungen es auf Ihr Projekt hat, wenn Teammitglieder in den Urlaub fahren oder sich krankschreiben lassen. Management-Teams müssen über Projekte und deren benötigte Ressourcen informiert sein, um ihre Ziele erfüllen zu können, und wollen zudem in der Lage sein, Ressourcen zu verlagern, um neue Initiativen zu finanzieren, und möchten gleichzeitig sehen, welche Auswirkungen dies auf den Portfolioplan hat.

Ein agiles Portfolio-Management-Tool sorgt dafür, dass Sie genauer planen können. Idealerweise lässt es Sie die Skillsets und Verfügbarkeiten Ihrer Teams verwalten, wodurch Sie Engpässe vermeiden. Damit lässt sich sicherstellen, dass die richtigen Leute zur Verfügung stehen, wenn diese benötigt werden.

5. Frage: Warum verbringen wir mehrere Stunden damit, Status- und Fortschrittsberichte zu erstellen?

Sind Programmmanager stundenlang damit beschäftigt, sich durch Tabellen und Gantt-Diagramme zu wühlen, um Status- und Fortschrittsberichte zu erstellen? Dann ist dies ein Zeichen dafür, dass sich etwas ändern muss. Einen (unterbrochenen) Zeitplan auf dem neusten Stand zu halten, diesen womöglich an die tatsächliche Situation in den Teams anzupassen und den Leuten hinterherzulaufen, um diese nach den neusten Updates zu fragen, ist praktisch ein Vollzeitjob – vor allem, wenn Sie mit einer Vielzahl von Tools arbeiten – und ist besonders bei wachsenden Unternehmen ein häufiges Problem.

Ein direkt mit der Arbeit Ihrer Teams verknüpftes und sich bei Änderungen und Fortschritten in Echtzeit aktualisierendes agiles Portfolio-Management-Tool wird Ihnen viel Zeit und Arbeit ersparen, die Sie sonst mit dem Erstellen von Fortschrittsberichten verbracht hätten.

Tech Support ist ein mächtiger, vielschichtiger Prozess: Es kann Produkte in Ordnung bringen oder verbessern, zukünftige Kundenanforderungen verringern und Kundenzufriedenheit stärken. Aber macht dieses Feedback seinen Weg tatsächlich zurück zur Produktentwicklung?

Atlassian hat mit Hilfe von HDI, der größten Vereinigung von Tech Support-Experten, untersucht, ob und wie Tech Support-Teams mit Entwicklungsteams zusammenarbeiten. Die Ergebnisse der Studie bringen fünf überraschende Fakten zu DevOps und technischer Unterstützung ans Tageslicht.

1. 73% der Unterstützungsteams sind mit ihrer Beteiligung an der Produkt-Entwicklung unzufrieden

Das Forscherteam fand heraus, dass die meisten Teams der technischen Unterstützung nur nach der Freigabe in den Entwicklungsprozess eingebunden wurden.

Tatsächlich berichten 99% der Experten für Tech Support, dass es ein bestehendes Problem für ihr Team ist, meist unvorbereitet in die Freigabe hereinzurutschen. „Unterstützungsteams müssen viel früher eingebunden werden. Die Übergabe von der Entwicklung zur Unterstützung ist schleppend, die Dokumentation ist begrenzt, ohne definierte Standards und manchmal sind die Unterstützungsteams genauso überrascht, wie der Rest über Änderungen, die auf ein Produktivsystem veröffentlicht werden.“, behauptet ein Umfrageteilnehmer.

Eine wenig belustigende Tatsache: 73% der Unterstützungsteams sind mit ihrer Einbindung in die Produkt-Entwicklung unzufrieden.

2. Nur 28% benutzen ein Werkzeug, welches sich auf das Entwicklungswerkzeug abstimmt

Wie können Sie wissen, was Sache ist, wenn Sie nicht informiert sind? Die meisten Support-Teams sagen, sie können die Updates, die vom Entwicklungs- bzw. QS-Werkzeug nachverfolgt werden, nicht sehen.

HDI zufolge ist Wissensmanagement das am zweithäufigsten benötigte Vorgehen im ITSM und hilft Organisationen, Unterstützung für Endkunden bereitzustellen. Jedoch tauschen lediglich 41% der Organisationen Wissen zwischen dem IT Support und der Entwicklung aus.

3. 51% haben keinen effektiven Änderungsmanagementprozess

Und Änderungsmanagement? HDI berichtet, dass dies der am zweithäufigsten verwendete ITSM-Prozess ist, welcher Organisationen hilft, Systemänderungen zu verwalten. Während 89% der Organisationen Change Management implementiert haben, haben nur 49% einen, der auch funktioniert.

Laut Gartner belaufen sich 80% der Vorfälle auf Änderungen. Es ist wichtig, diese Änderungen sinnvoll abzuwickeln. Anders gibt es mehr Vorfälle, mehr Probleme und es wird mehr Unterstützung nötig. Organisationen mit einem erfolgreichen Änderungsmanagementprozess wurden mehr in allen Phasen der Entwicklung beteiligt – von der Konzeption bis zum Testen – und auch nach erfolgter Freigabe.

4. 21% haben DevOps in einigen Betriebs- und Entwicklungsbereichen adaptiert

DevOps ist ein wachsender Trend und ist dem Bedürfnis entsprungen, die Zusammenarbeit zwischen Betrieb und Entwicklung zu verbessern. Gerade weil DevOps noch so jung ist, gibt es noch viele Dinge, die begeistern, noch nicht in Stein gemeißelt und offen für neue Ansätze sind.

Atlassian hat herausgefunden, dass lediglich 21% der Teams für technischen Support die DevOps-Praktiken annehmen. Aber diejenigen, die es tun, werden dafür belohnt.

5. Teams, welche DevOps-Praktiken adaptieren, erfahren positive Auswirkungen

DevOps sollte die Zusammenarbeit zwischen IT und Entwicklung verbessern, aber es hat sich inzwischen zu einem Werkzeug für die cross-funktionale Zusammenarbeit in der gesamten Organisation entwickelt. 21% der Organisationen haben geantwortet, dass sie DevOps zumindest in einigen Bereichen einsetzen. Diejenigen, die DevOps vollständig adaptiert haben, berichteten von positiven Auswirkungen auf verschiedenste Bereiche des Support-Betriebs:

• Verbesserte Zykluszeiten im Change Management
• Verbesserte Zykluszeiten im Release Management
• Verbesserte Kommunikation innerhalb des IT-Betriebs
• Höhere Zufriedenheit im Job
• End-Benutzern werden dank besserer Unterstützung mehr geholfen

„Der Support wird gewöhnlich nur kontaktiert, nachdem die Software operationalisiert ist. Jedoch könnte die gesamte Organisation von der ständigen Sichtbarkeit und Beteiligung des Support-Teams am Entwicklungsprozess vom Anfang bis Ende profitieren“, sagt HDI.

Atlassian hat ebenfalls eine Infografik zu den Erkenntnissen aus der Studie angefertigt:

Klicken Sie auf die Grafik, um diese in voller Größe anzuzeigen.

Wie steht es um Ihren IT Support?

Wenn Sie erfahren möchten, wie JIRA Service Desk Ihnen dabei helfen kann, Ihren Support zu verbessern, kontaktieren Sie uns.

Quellen und Links

• HDI: Atlassian Customer Survey Results
• VictorOps DevOps Survey 2015
• TechRadar: Continous Delivery Trends

Die entscheidende Frage – „Wann wird meine Änderung live sein?“ – muss jeder Entwickler beantworten können.
Aber die Entwicklungsabteilung ist nicht die einzige Gruppe, die darüber Bescheid wissen muss. Das gesamte Team muss wissen, wie es weitergeht und was die nächsten Schritte sind. Das Produktmanagement muss in der Lage zu sein, für die nächsten Ankündigungen von Features zu planen. Entwickler sind auf Feedback für ihre Arbeit aus. Zusammenfassend lässt sich sagen: Es ist immer eine Teamleistung.

In der Welt von DevOps wird die erledigte Arbeit oft mehrfach täglich in den master-Zweig integriert, aber es ist nicht immer sofort ersichtlich, wann Änderungen ausgeliefert werden. Entwickler haben die komplette Kontrolle darüber, wann Änderungen an den Kunden ausgeliefert werden. Damit ist es noch wichtiger, alle Vorgänge auch zu verfolgen. So können IT und Betrieb genau nachvollziehen, welche Änderungen mit welchem Release veröffentlicht wurden, und entsprechende Regressionen im Störfall identifizieren.

Mit JIRA Software oder JIRA Service Desk lassen sich die wichtigsten Schritte automatisieren. Hier sind die sechs Schritte für ein besseres Release-Management mit der JIRA-Produktfamilie:

1) Änderungen in Form von JIRA-Vorgängen festhalten

Nun, was beinhaltet eine Änderung eigentlich? Ist es ein einzelner Commit? Sind es mehrere Commits? Typischerweise bestehen lieferbare Arbeitspakete aus dem Letzteren — mehrere Arbeitsschritte gebündelt als neue Version.

Der wohl gängigste Weg, Änderungen zu verfolgen, besteht darin, Feature-Branches zu verwenden. Ist die Arbeit abgeschlossen, werden der Feature-Zweig mithilfe eines Pull Requests in master gemerget. Der Pull Request ist eine bessere Repräsentation für eine in sich geschlossene Arbeitseinheit. Oft gibt es jedoch trotzdem noch viele kleine, aber wichtige Änderungen die nachträglich — nachdem ein Pull Request gemerget wurde — durchgeführt werden müssen. So muss vielleicht die Farbe eines GUI-Elements angepasst oder der Text an einer anderen Stelle überarbeitet werden.

In diesem Fall gibt es vielleicht mehrere Pull Requests zu eigentlich derselben Änderungseinheit.

Anstatt nun mehrere einzelne, kleine Pull Requests zusammenzuflicken, sollte man diese in einer Änderungseinheit zusammenfassen. Genau hier ist es sinnvoll, JIRA Issues einzusetzen und damit Code, Prozesse und Menschen zusammenzubringen.

JIRA dient nicht nur der Nachverfolgbarkeit von Änderungen, es benachrichtigt auch Interessierte über den Fortschritt. Jeder im Unternehmen kann einem JIRA-Vorgang folgen und wird im Falle eines Kommentars oder einer Statusänderung benachrichtigt.

2) Den Workflow fürs Release Management in JIRA festlegen

Standardmäßig hat ein Workflow in JIRA keinerlei Informationen zum Stand der Veröffentlichung. Glücklicherweise ist die JIRA-Plattform flexibel und anpassbar. Wir können also einfach zusätzliche Status rund um den Zustand der Veröffentlichung hinzufügen.

Als Ausgangsvorlage dient der Standard-Workflow für Vorgänge in JIRA mit drei Zuständen:

Wir fügen dem bestehenden Workflow noch einige weitere Zustände hinzu. In unserem Fall möchten wir anstelle eines Übergangs von In Progress nach Done noch ein paar Zwischenschritte einfügen:

• Awaiting Release: Die Arbeit ist abgeschlossen und bereit zur Auslieferung.
• Released to Staging: Die Veröffentlichung in eine Testumgebung wurde ausgeführt.
• Released to Production: Endlich! Die Änderung wurde dem Kunden zur Verfügung gestellt.

Anbei ein Beispiel, wie der neue Arbeitsfluss mit den zusätzlichen Zuständen und Übergängen aussehen kann. Atlassian stellt auch eine umfangreiche Dokumentation rund um Workflows zur Verfügung.

3) Die agilen Boards konfigurieren

Sobald der neue Workflow abgespeichert wurde, kann dieser über die Projektkonfiguration aktiviert werden. Falls Ihre Entwickler Boards einsetzen, stellen Sie sicher, dass die neuen Zustände auch entsprechend zugeordnet werden.

Der einfachste Weg: Über die Board-Konfigurationsseite unter Spalten lassen sich die entsprechenden Zustände via Drag&Drop der Done-Spalte zuordnen:

Falls jetzt Entwickler Vorgänge von In Progress nach Done verschieben möchten, müssen sie den korrekten Zustand auswählen. In diesem Fall können sie mitteilen, ob eine Änderung bereit für die Veröffentlichung ist.

4) JIRA-Vorgänge Veröffentlichungen zuordnen

Nehmen wir an, ein Release wird aus einem Git-Repository heraus erzeugt. In diesem Fall können wir die Git-History verwenden, um alle Änderungen, die es in das Release schaffen, nachzuverfolgen. Trotzdem müssen wir die einzelnen Commits irgendwie Vorgängen in JIRA zuordnen.

Setzen wir den aktuellen Vorgangsschlüssel als Präfix vor die Commit-Nachricht, lässt sich der Commit einem Vorgang zuordnen:

$ git commit -am 'PROJ-255: change publish button colour to blue'


Dies erzeugt zwar etwas Overhead im Entwicklungsprozess ist aber eine gängige und gute Praktik, da dieses Vorgehen Nachverfolgbarkeit und Historisierung sicherstellt. Alternativ kann man den Vorgangszweig nach dem Vorgangsnamen in JIRA benennen. So werden alle Commits innerhalb des Zweiges dem Vorgang zugeordnet.

Erzeugt man einen solchen Zweig aus JIRA Software heraus, wird dieser automatisch nach dem Vorgangsschlüssel benannt.

5) Alle relevanten Änderungen für die nächste Veröffentlichung finden

Der wichtigste Teil: Nachverfolgen, welche der Änderungen in eine Veröffentlichung gepackt werden sollen. Nachdem ein Release zusammengestellt wurde, sollten Sie den Commit mit der Versionsnummer versehen.

Ein Beispiel für ein Kommando, welches man dem Buildscript hinzufügen kann:

$ git tag -s -a 6.0.0-OD-2016.12.1-1106 && git push $remote 6.0.0-OD-2016.12.1-1106


Wir nutzen Git, um alle Commits zwischen dem aktuellen und vorigen Release-Tag herauszufinden. Aus der Git-History können wir mit folgendem Kommando die passenden Vorgangsschlüssel aus den Commits extrahieren:

$ git log 6.0.0-OD-2016.11.1-1091..6.0.0-OD-2016.12.1-1106 --pretty=oneline | perl -ne '{ /(\w+)-(\d+)/ && print "$1-$2\n" }' | sort | uniq
CONF-38645
CONF-40446
CONF-40973
CONF-41003
CONF-41014
CONF-41035


Und hier ist sie: Die Liste der JIRA-Vorgänge für die nächste Veröffentlichung!

Mit ein wenig mehr Arbeit kann aus dieser Liste eine JQL-Anfrage für den JIRA-Server gebastelt werden:

issue in ('CONF-41003', 'CONF-40973', 'CONF-38645', 'CONF-40446', 'CONF-41014', 'CONF-41035') and status = 'AWAITING RELEASE'


Manche dieser Commits beschreiben unter Umständen erst teilfertige Arbeit, deshalb möchten wir alle Vorgänge filtern, die nicht im Awaiting Release-Zustand sind.

Nachdem wir die Liste aller Vorgänge für die neuste Version erhalten haben, müssen wir diese aktualisieren. Dies kann entweder manuell mit dem Bulk Update-Feature von JIRA direkt aus der Suchanfrage oben geschehen, oder man führt im Rahmen des Release-Builds ein Script aus. Ein Beispiel hierfür ist das Python jira-Paket, mit welchem via Python mit der JIRA Rest API kommuniziert werden kann.

6) Veröffentlichen und Beteiligte informieren

Jetzt sind wir in der Lage, eine neue Version zu veröffentlichen – was nun? Es ist an der Zeit, auszuliefern. JIRA-Vorgang updaten, Beteiligte informieren und ab die Post. Zur Veröffentlichung benötigt man die entsprechende Version und Umgebung, in welche veröffentlicht wird. Im Anschluss lassen sich alle Vorgänge in den passenden Zustand überführen: Released to Staging oder Released to Production.

Sobald ein Deployment erfolgreich durchgeführt wurde, können Sie nach allen Vorgängen innerhalb des Releases mit dieser JQL-Anfrage suchen (dies lässt sich entweder als Teil des Buildvorgangs oder manuell ausführen):


fixVersion = '6.0.0-OD-2016.12.1-1106'


Mit dem Bulk Update-Feature oder Script-Update über die REST API können die zutreffenden Vorgänge nun abhängig von der Umgebung, in welche veröffentlicht wurde, nach Released to Staging oder Released to Production überführt werden.

Wenn die Vorgänge aktualisiert werden, werden alle Entwickler und Beteiligte, die dem Ticket folgen, darüber benachrichtigt, dass die Änderung in die Testumgebung oder zum Kunden ausgeliefert wurde.

Erfolgreich neue Produkte einführen, ist ein komplexer Prozess – mehrere Teams sind beteiligt und jeder hat viele verschiedene Aufgaben zu erfüllen. Eine solche Leistung erfordert die Zusammenarbeit mehrerer Teams. So braucht es Software-Teams, um das Produkt zu entwickeln, und Marketing-Teams, die das Bewusstsein und die Nachfrage generieren.

Software- und Marketing-Teams arbeiten jedoch in einer Vielzahl von sich teilweise drastisch unterscheidenden Workflows. Während Software-Teams überwiegend in agilen Umgebungen mit Sprints und Aufgaben arbeiten, welche auf Basis von Erfahrungswerten (Velocity) geschätzt werden, agieren Marketing-Teams eher spontan. Manchmal arbeiten diese Teams auch auf der ganzen Welt verteilt, sprechen unterschiedliche Sprachen und benutzen spezifische Fachtermini.

Wie hält man also zwei so unterschiedliche Arbeitsweisen an weit entfernten Orten Up-To-Date? Wie lassen sich Zusammenarbeit und Kommunikation trotz eigener Kultur und Sprache im Einklang halten?

Die Grenzen zwischen Teams aufbrechen

Mit JIRA Core und JIRA Software lassen sich die Lücken zwischen Software und Marketing überbrücken. Das heißt, beide Teams arbeiten zusammen in der gleichen JIRA-Instanz. So ist sich das Marketing-Team bewusst, auf welchem Stand das Software-Team ist und umgekehrt.

Globale Admins als Retter

Administratoren kommt eine besondere Rolle zu, wenn es darum geht, global agierende Teams zu vernetzen. Globale Admins sorgen dafür, dass Teams zusammenarbeiten und alle Beteiligten ihre Kernkompetenzen ausspielen können.

Lassen Sie uns an einem Beispielszenario zeigen, wie ein globaler Administrator mithilfe von Collaboration-Software das Marketing- und Software-Team synchron halten kann:

• Warren, globaler Admin – verantwortlich für JIRA Core
• Daniel, Produktmanager und JIRA Software-Benutzer
• June, Marketing Manager

Im nächsten Monat steht ein Produkt-Launch an. Aus diesem Grund arbeitet June intensiv am Marketing-Material. Daniel arbeitet hart, damit es alle Funktionen ins Produkt schaffen und das Produkt ausgeliefert werden kann. In der Welt agiler Software können sich Produktumfang und der Status ändern, also muss June stets mit aktuellen Informationen über das Produkt versorgt sein.

Früher hat June unzählige E-Mails an Daniel senden oder langwierig Sitzungen oder Status-Updates aufsetzen müssen. Was passiert außerdem, wenn die Anfrage nicht ankommt, eine E-Mail vergessen oder das Treffen abgesagt wird und Daniel June nicht über etwaige Verspätungen im Bilde halten kann?

Warren ist der globale JIRA-Admin. Daniel und June bitten ihn um Hilfe. Warren erkennt, dass diese beiden Teams ein Produkt fertigbekommen müssen, jedoch weder koordiniert noch effektiv kommunizieren. Er weiß, dass durch die Einrichtung von JIRA Core das Marketing-Team im Einklang mit der Software-Abteilung sein wird, da er den Marketing-Workflow und die JIRA-Vorgänge an die aus dem JIRA Software-Projekt anpassen kann. Damit können beide Teams ihre Arbeit auf ähnliche Weise verrichten.

Tipps für die Umsetzung

Wie kann man den beiden Teams konkret helfen? Angenommen, Daniel hat die Aufgabe ein neues Feature zu erstellen. Und die Aufgabe von June ist es, eine entsprechende Pressemeldung über dieses Feature und dessen Vorteile zu veröffentlichen. Damit June ihre Arbeit sinnvoll verrichten kann, muss sie wissen, ob das Feature überhaupt im nächsten Release enthalten sein wird. Mit JIRA Core kann June mit Daniels Fortschritt verbunden und über den Zustand seines Projektes informiert bleiben.

1. Konfigurieren Sie die JIRA-Core / Software-Dashboards

Das Erste, was Benutzer nach einem Login in JIRA Software oder JIRA Core sehen, ist ein Dashboard voller Statistiken und Graphen zum Status ihrer aktuellen Projekte. Sowohl Software als auch Marketing können mithilfe ihrer Dashboards einen Blick auf den Fortschritt des jeweils anderen werfen.

Der Artikel Das JIRA Core Dashboard: Ihr Projektstatus auf einen Blick beschreibt, wie globale Administratoren diese so einrichten, dass beide Teams Zugriff auf den gemeinsamen Projektstatus haben.

2. Marketing-Aufgaben mit Software-Vorgängen verbinden

Marketing- und Software-Teams arbeiten zwar in unterschiedlichen JIRA-Projekten, aber die tägliche Arbeit und Aufgaben sind über JIRA-Vorgänge definiert. Vielleicht kapselt das Marketing-Team die Arbeit in Aufgaben und Unteraufgaben, während die Software-Abteilung von Epics und Stories spricht.

Es ist nicht möglich, zwei JIRA-Projekte miteinander zu verbinden. Es lassen sich aber zwei Vorgänge aus unterschiedlichen Projekten miteinander verknüpfen. In unserem Beispiel ist die Aufgabe von June, eine Pressemeldung zu verfassen, mit Daniels Aufgabe, ein neues Feature zu erstellen, verbunden. June kann beide Aufgaben miteinander verknüpfen, damit sie stets darüber im Bilde ist, wie der Fortschritt an der neuen Funktion ist. Damit kann sie auf Änderungen reagieren und ihre Zeitplanung entsprechend anpassen.

Mithilfe des Link-Knopfs im More-Menü eines Vorgangs kann June aus mehreren Optionen wählen, um die Vorgänge miteinander zu verbinden. Dort kann sie festlegen, wie die Vorgänge miteinander in Relation stehen. In diesem Fall handelt es sich bei Daniels Feature um einen Blocker für die Pressemeldung von June – ohne dieses Feature im nächsten Release ist eine entsprechende Marketing-Aktion nutzlos.

Arbeitet June an ihrer Aufgabe zur Pressemeldung, sieht sie stets den Status der Software-Aufgabe:

Es lassen sich auch Links in den entsprechenden Fachtermini einer Abteilung anlegen. So können Administratoren auch Link-Optionen wie abhängig von oder Kopie von anlegen, um die Beziehung zwischen Aufgaben besser zu beschreiben.

3. Fügen Sie einen Link in der Seitenleiste des Projektes hinzu

Als globaler Administrator können Sie Links (URLs) in die Seitenleiste hinzufügen. So kann jeder im Team mit Zugriff auf das Projekt die Verknüpfung sehen.

Sie können einen Link zu dem Software-Projekt im Marketing-Projekt und umgekehrt in der jeweiligen Seitenleiste hinzufügen. Nun können beide Teams schnell die Projekte (und Dashboards) des jeweils anderen besuchen.

4. Nutzer zu Beobachtern erziehen

Als Administrator ist es normal, über die Funktionen JIRA Core und JIRA Software im Bilde zu sein. Benutzer sind wahrscheinlich nicht ganz so versiert. Das praktische Beobachter-Feature ist so ein Fall. Arbeitet das Software Team an einer Aufgabe, die für das Marketing-Team von Bedeutung ist, so ist sinnvoll, dass sich eine Person der Marketingabteilung als Beobachter für diese Aufgabe einträgt. Anders formuliert: Wartet June auf das Feature aus dem Software-Team, kann sie sich als Beobachter eintragen und wird bei jeder Änderung am Vorgang informiert.

Ebenso kann Daniel sich als Beobachter für die Marketing-Aufgabe eintragen, falls er sich dafür interessiert, einen Blick auf den Entwurf der Pressemeldung zu werfen, um sicherzustellen, dass diese auch korrekt ist.

Beobachtet man Vorgänge, muss man nicht mehr alle paar Stunden die andere Partei wegen Status-Updates nerven.

Alle Teams im Einklang

Mit JIRA Core und JIRA Software im Einklang können Sie Marketing und Software-Teams dabei helfen, synchron und effektiv miteinander zu arbeiten und zum Beispiel eine erfolgreiche Produkteinführung gewährleisten. Marketing-Teams wissen, ob das Produkt rechtzeitig oder zu spät ist und Software-Teams können sich auf ihre Arbeit konzentrieren und trotzdem zur gleichen Zeit alle im Bilde halten. Und denken Sie daran: Auch für alle anderen Team-Arten können Sie diese Methode verwenden.

Obwohl Ihre Teams vielleicht agil arbeiten – geplant werden muss trotzdem. Es kann jedoch zur Herausforderung werden, wenn neben der alltäglichen Arbeit mit dem Ziel, einen Sprint abzuschließen, noch zusätzlicher Druck durch Vorausplanung entsteht.

Mit dem Wissen, dass JIRA Software der Ort ist, an dem Teams ihre alltägliche Arbeit durchführen, hat Atlassian mit Portfolio for JIRA ein Werkzeug geschaffen, welches die Planung in der JIRA-Produktfamilie noch einfacher macht.

Dieser Artikel beleuchtet en detail wie man Portfolio for JIRA zum Vereinen von Produkt- und Sprintplanung, zum Verfolgen von Abhängigkeiten, zur optimalen Auslastung der Skills im Team und zum Spielen mit Was-Wäre-Wenn-Szenarien nutzen kann.

Produkt- und Sprintplanung vereinen

Um Geschäftsziele zu erreichen, muss die tägliche Arbeit eines Softwareteams ganz auf die langfristige Produktplanung ausgerichtet sein. Jedoch werden die Produktplanung und der eigentliche Backlog des Teams oftmals in verschiedenen Werkzeugen verwaltet. Während die Planung vielleicht im Groben übereinstimmt, entwickeln sich die beiden Varianten stets auseinander. Feinheiten abstimmen kostet viel Zeit. So muss für die Produktplanung der aktuelle Backlog des Teams mühselig abgeglichen werden und wenn das Team die Sprintplanung abgeschlossen hat, muss der Produktplan wiederum angepasst werden.

Wäre es nicht wunderbar, wenn die Produktplanung automatisch mit der Arbeit des Teams in JIRA Software verbunden und in Echtzeit aktuell gehalten werden würde? Genau dies leistet Portfolio for JIRA. Die Erweiterung verbindet sich automatisch mit den Boards Ihres Teams und hat somit Zugriff auf alle Daten, die benötigt werden, um realistische Vorhersagen für die Produktplanung zu generieren. Unter Berücksichtigung von Fakten wie Team-Verfügbarkeit, Vorgangsabfolgen und Abhängigkeiten kann Portfolio for JIRA die Terminierung und Vorausplanung für Sie übernehmen.

Und wie erzeugt Portfolio eigentlich so einen Terminplan?

Die grundlegende Formel lautet immer: Prioritätenabfolge + Schätzungen + Kapazität des Teams = Terminplan, d.h. übersetzt bekomme die Arbeit gemäß Prioritätenabfolge so schnell wie möglich erledigt. Weiterhin gibt es noch Releases. Man möchte Feature B in Version 1.0 und Feature C in Version 1.5 – und Feature A bitte dort, wo es am besten hineinpasst. In diesem Fall ist die beste Reihenfolge: Zuerst B, dann C dann A, da A kein must-have ist. Aber nur solange es keine Abhängigkeiten gibt. Vielleicht benötigt B ja, dass A vorher abgeschlossen wird. Nun ist die einzig logische Abfolge natürlich A, B und dann C. Leuchtet ein. Aber was passiert, wenn irgendwo eine Deadline lauert oder jemand Urlaub eingereicht hat und die Kapazität sich verringert? Oder vielleicht benötigt Feature B eine bestimmte Team-Fähigkeit, um erledigt werden zu können. All diese Einschränkungen beeinflussen den Terminplan und werden von Portfolio for JIRA berücksichtigt, damit Sie sich nicht mehr darum kümmern müssen.

Atlassian stellt auf einer gesonderten Seite der Dokumentation das sog. Scheduling Behaviour im Detail vor.

Wie bekommt man nun die realistische Produktplanung ins nächste Sprintplanungs-Meeting? Portfolio for JIRA ist mit den JIRA-Boards dynamisch verbunden und kann demnach vorschlagen, was alles in den nächsten Sprint übernommen werden könnte. So können die Vorgänge, die in Portfolio for JIRA geplant wurden, direkt in die Sprints Ihres Teams übernommen werden. Das ist ein großartiger Startpunkt für Ihre Meetings. Dort können dann die Einzelheiten mit dem Team diskutiert und verfeinert werden.

Die Abhängigkeiten im Blick behalten

Es gibt einige Dinge, die ein Burn-Up- oder Burn-Down-Chart einfach nicht berücksichtigen kann. Zum Beispiel Abhängigkeiten. Auch wenn Kapazität und Burn-Rate vollkommen in Ordnung sind, kann das Team durch Abhängigkeiten daran gehindert werden, die wichtigsten Aufgaben erledigen zu können. Verlinken Sie Vorgänge in JIRA Software, wird dies von Portfolio in der Terminierung berücksichtigt.

Ist zum Beispiel Vorgang A ein Blocker für Vorgang B, dann setzt Portfolio for JIRA Vorgang A vor Vorgang B in den Zeitplan. Das bedeutet: Ihr Team wird immer an der richtigen Aufgabe in der richtigen Reihenfolge arbeiten und wird nicht von Abhängigkeiten behindert. Im Portfolio-Zeitplan werden Vorgänge mit Abhängigkeiten mit einer deutlich sichtbaren Markierung der Seite hervorgehoben. Wenn Sie auf den Vorgang klicken, wird die abhängige Aufgabe farblich markiert. Wenn Sie neue Abhängigkeiten hinzufügen oder Änderungen in Portfolio vornehmen, können Sie diese zurück nach JIRA Software als Issue-Link ablegen.

Das Beste aus den Fähigkeiten des Teams herausholen

In einem idealen Team kann jeder alles erledigen, was die Planung flexibel und einfach macht. Und es ist kein Problem, falls mal jemand abwesend sein sollte. In der Realität ist das leider so gut wie nie der Fall. Manchmal muss während der Planung berücksichtigt werden, wer was wann in welcher Reihenfolge erledigen kann, damit die Planung akkurat bleibt und Flaschenhälse vermieden werden.

Um den Zeitplan zu verfeinern und genauer zu machen, kann man in Portfolio for JIRA Team-Mitgliedern Fähigkeiten zuweisen. Fähigkeiten verweisen auf die Spezialisierung eines Team-Mitglieds und berücksichtigen die Skills, die ein Team-Mitglied haben muss, um einen Vorgang erfolgreich lösen zu können. So ist es vielleicht notwendig, zum Schreiben einer User-Story Product Owner und Design-Team zu Rate zu ziehen.

Sobald Sie entsprechende Fähigkeiten in Portfolio angelegt haben, können Sie Vorgänge anhand der benötigten Skills herunterbrechen und definieren, wer die benötigten Fähigkeiten hat. Die Erweiterung kann dann automatisch die Vorgänge anhand der Spezialisierungen der Team-Mitglieder zuweisen und berechnen, ob es noch freie Kapazitäten für entsprechende Skills gibt oder manche Skills überbucht sind und Flaschenhälse erzeugen.

Mit Was-Wäre-Wenn-Szenarien spielen

Wenn Sie das nächste Mal mit Stakeholdern sprechen und diese Sie fragen, warum Feature X nicht im nächsten Release eingebaut wird, oder warum nicht nächste Woche anstelle im nächsten Monat ausgeliefert werden kann, öffnen Sie einfach mit ihnen gemeinsam Portfolio for JIRA. Führen Sie vor den Augen der Beteiligten ein Was-Wäre-Wenn-Szenario durch; ändern Sie das Release-Datum, spielen Sie mit dem Umfang eines Sprints und visualisieren Sie in Echtzeit die Auswirkungen auf den Zeitplan. Was-Wäre-Wenn-Szenarien sind ein großartiger Weg, um offen mit Stakeholdern zu kommunizieren und klarzustellen, welche Abstriche nötig sind, da die Planungsalgorithmen so realistische Vorhersagen wie möglich treffen. Entscheidungen werden immer anhand der aktuellsten Daten getroffen, da Portfolio und JIRA Software stets synchron gehalten werden.

Ein Self-Service-Informationsportal erstellen

Sind Sie es leid, ständig gefragt zu werden, wie der Plan ist, wie der Fortschritt sei? Nervt es Sie, ständig Statusupdates zu verschicken? Es ist mit Portfolio for JIRA möglich, eine Single Source of Truth zu besitzen, die alle Beteiligten auf dem Laufenden hält. Die Berichte-Seiten in Portfolio for JIRA stellen eine Auswahl an Berichten zur Verfügung, die allen Stakeholdern zufriedenstelle Antworten liefert. Egal ob die Fortschritte in strategischen Fokusbereichen, eine Zusammenfassung aller Releases oder ein Zeitplan mit Vorhersagen für Release-Daten – alles ist vorhanden.

Es ist nicht nötig, manuell Daten zu exportieren, um Fortschritte und Statusupdates für Meetings zu erstellen. Einfach allen Beteiligten Bescheid geben, in den Portfolio-Plan zu schauen. Selbstverständlich kann mit Berechtigungen gearbeitet werden, damit ein Portfolio-Plan für bestimmte Benutzer nur Lesezugriff bietet.

Welche Berichte gibt es in Portfolio for JIRA?

• Der Themes-Bericht vergleicht die geplante strategische Ausrichtung mit den Schätzungen und tatsächlich erreichten Zielen.
• Der Releases-Bericht zeigt alle Releases eines jeden Projektes und auch über verschiedene Projekte hinweg. Sie sehen das Release-Datum, den Fortschritt und alle verwandten Vorgänge.
• Der Zeitplan-Bericht zeigt vorhergesagte Release-Daten und zusätzliche Details basierend auf Projekten, Teams und Team-Mitgliedern.
• Der Kapazitäten-Bericht zeigt, wie viel der potentiellen Arbeitskapazität eines Teams tatsächlich eingesetzt wird – inklusive freier Kapazität, geplanter Kapazität und Auslastung pro Sprint.
• Der Sprints-Bericht zeigt alle Sprints im Plan pro Team und die zugewiesenen Vorgänge und Zeiten.
• Der Umfang-Bericht zeigt eine Übersicht über alle Arbeitspakete, deren Schätzung, Fortschritt und geplante Zeitpunkte zur Fertigstellung.

Atlassian hat bekanntgegeben, dass JIRA Service Desk den ITIL-Zertifizierungsprozess erfolgreich abgeschlossen hat. JIRA Service Desk ist damit nun in vier Prozessen offiziell von PinkVerify und Axelos zertifiziert. Für viele IT-Teams stellt sich bei der Evaluation eines neuen Software-Tools als allererstes die Frage: Unterstützt es ITIL?

Die ITIL-Zertifizierung stellt eine Garantie dar, dass das Produkt in der Lage ist, den ITIL-basierten Prozess in Ihrem Unternehmen zu unterstützen.

Was bedeutet „ITIL-zertifiziert“ überhaupt?

ITIL ist der Gold-Standard für IT Teams in aller Welt. Es handelt sich dabei um eine Sammlung von Anleitungen, die auf die IT-Organisation in Unternehmen abzielen, und steht für „IT Infrastructure Library“. In den Anfängen handelte es sich um eine reine Sammlung und Dokumentation von Best Practices, also den erfolgreichen Umsetzungen von Aktivitäten oder Prozessen im IT-Bereich.

Das Hauptaugenmerk von ITIL ist die Maximierung des Nutzens der IT für das Unternehmen, indem die Ressourcen in der IT nach den Anforderungen Geschäftsalltags ausgerichtet werden.

Welche Zertifizierungen hat JIRA Service Desk erhalten?

JIRA Service Desk 3 besitzt die Zertifikate ITIL for PinkVerify 2011 und ISS Bronze ITIL für die folgenden Prozesse:

• Anfragenerfüllung (Request fulfillment)
• Vorfallsmanagement (Incident management)
• Problemverwaltung (Problem management)
• Änderungsmanagement (Change management)

Um ein PinkVerify-Zertifikat zu erhalten, muss ein Softwarehersteller 100% der geforderten Kriterien dieser Prozesse erfüllen. JIRA Service Desk wurde auf ITIL-kompatible Produktfeatures, Terminologien, Workflows und funktionale Anforderungen geprüft.

Das folgende Video beschreibt die Zertifizierung und die Vorteile im Detail:

Vorteile beim Einsatz von JIRA Service Desk

ITIL hilft Unternehmen, IT-Dienstleistungen bestmöglich zu verwalten und zu verknüpfen. Damit einher geht die Möglichkeit zur Steigerung von Produktivität und Effizienz, sowie zur Verringerung des Gesamtaufwandes für IT-Prozesse.

JIRA Service Desk ist schnell und einfach zu implementieren und stellt eine flexible Lösung für das IT-Management dar. Damit bietet JIRA Service Desk einen optimalen Ausgangspunkt, um im Rahmen von ITIL die geforderten Best Practices umzusetzen und das Tool an entsprechende Workflows anzupassen.

Zum jetzigen Zeitpunkt hat Atlassian die Kernprozesse im ITIL abgedeckt. Später folgen weitere Prozesse wie Wissensmanagement. Derzeit liegt der Fokus aber klar auf den am weitesten verbreiteten Prozessen.

Durch die Zertifizierung ergeben sich für unterschiedliche Teams unterschiedliche Vorteile:

• Für kleine IT-Teams stellt diese Zertifizierung einen wunderbaren Ausgangspunkt für die Umsetzung von ITIL und die Verbesserung der eigenen Prozesse dar.
• Für große Unternehmen stellt diese Zertifizierung die nötige Validierung dar, um das Werkzeug großflächig einzusetzen.
• Teams, die mit Entwicklern zusammenarbeiten, bekommen einen Ausgangspunkt für Umsetzung des ITIL-Frameworks im Rahmen ihrer Entwicklungsprozesse.

Dabei ist wichtig, zu behalten, dass ITIL keine Software und kein fertiges Programm ist, das Unternehmen übergestülpt wird. Die Verwendung von ITIL erfordert geschulte Mitarbeiter, die das flexible Modell, als das ITIL fungiert, auf die speziellen Erfordernisse des jeweiligen Unternehmens hin anpassen können.

Die JIRA-Produktfamilie von Atlassian lässt sich auch jenseits von Software-Teams effizient einsetzen. Zum Beispiel in Marketing-Abteilungen. Wie JIRA Core in einem Marketing-Team eingesetzt werden kann, wird in diesem Artikel näher betrachtet.

Marketing-Abteilungen bestehen in der Regel aus verschiedenen Teams. E-Mail-Marketing, Inhaltserstellung, PR, Produkt-Marketing und so weiter. Zwar hat jedes Team verschiedene Aufgaben, dennoch gibt es Gemeinsamkeiten: Projekte müssen verwaltet und Arbeitsergebnisse zeitig geliefert werden.

Die meisten Marketing-Teams lösen dies, indem sie den Projektfortschritt in einer abenteuerlichen Mischung aus simplen, gleichzeitig doch beängstigend komplexen Spreadsheets und einer E-Mailflut verfolgen. Inhalte, die gemeinsam verwendet werden? Schwierig. Kurzum: Die Arbeit ist organisiertes Chaos.

Das bedeutet vor allem, dass die von Marketing-Experten für ihre Arbeit benötigten Informationen überall verstreut sind. Die Folge sind Verzögerungen und Flaschenhälse.

Gibt es eine bessere Methode für Marketing-Teams? Ideal wäre eine Single Source Of Truth, über welche jedes Marketing-Team alle relevanten Projekte und Informationen verwalten kann. Optimale Sichtbarkeit des gesamten Fortschritts an einem Ort und Zugriff auf alle Inhalte? Klingt nach heißer Marketing-Luft, ist mit JIRA Core aber Realität.

JIRA Core: Geeignet für Teams aller Art

JIRA Core lässt sich sofort zum Verwalten von Aufgaben verwenden. Ein einfacher Workflow mit den Schritten To-Do, In Progress und Done ist der ideale Ausgangspunkt. Dieser lässt sich mit spezifischen Details ihres individuellen Arbeitsprozesses ergänzen. Beispielsweise lässt sich der Status eines Blogbeitrags, einer E-Mailanfrage oder dem Verfassen einer Pressemitteilung ganz einfach im Workflow abbilden. Alle notwendigen Prozessschritte von Erstellen bis zum Abschluss einer Aufgabe lassen sich an einem Ort erfassen.

Im Beispiel unten kann der Mitarbeiter den fertigen Entwurf eines Blogbeitrags in den Zustand Under Review überführen, damit ein Verantwortlicher einen Blick darauf werfen kann.

Ein weiteres Beispiel: Workflows können angepasst werden, sodass spezifische Arbeitsschritte eines jeden Marketingteams abgebildet werden können. Der Workflow unten zeigt die Schritte vom Entwurf bis zur Veröffentlichung eines Blogbeitrags. Interessant ist der neue Schritt „Add Web Tasks“: Befindet sich die Aufgabe in diesem Status, weist dies darauf hin, dass zwecks Zugriffsauswertung Tracking hinzugefügt und eine entsprechende SEO-Optimierung durchgeführt wird.

Das folgende Bild zeigt einen Vorschlag der Felder, die ein Marketing-Team wahrscheinlich in der Aufgabenbeschreibung benötigt. So weiß das Team über Ziele, betreffende Produkte und die Zielgruppe sowie das Veröffentlichungsdateum Bescheid. Eventuell benötigen andere Teams wiederum Felder für Grafiken, Videos oder Links zu einer Landing Page.

Einige Beispiele, wie verschiedene Marketing-Teams JIRA Core einsetzen können

Die folgenden fünf Beispiele zeigen, wie unterschiedliche Marketing-Teams JIRA Core zum Verfolgen von Aufgaben einsetzen können:

1. E-Mail-Marketing

Es ist die Aufgabe eines E-Mail-Vertrieblers sicherzustellen, dass Kunden sinnvolle Nachrichten ins E-Mailfach bekommen. Diese Teams können JIRA Core einsetzen, damit entsprechende Inhalte zum richtigen Zeitpunkt an die richtige Zielgruppe versandt werden. Möchten drei Mitarbeiter eine E-Mail in der selben Woche verschicken, kann das E-Mail-Team die Anfragen prüfen und mithilfe der Informationen, die in JIRA Core erfasst wurden, eine entsprechende Segmentierung durchführen und sicherstellen, dass die Kunden jeweils nur eine E-Mail mit dem für sie interessantesten Inhalt bekommen.

2. Social Media

Vielleicht haben Sie nur einen Social Media-Account aber mehrere Mitarbeiter, die verschiedene Produkte und Themen bewerben? Dies mithilfe von E-Mails im Blick zu behalten ist keine einfache Sache.

Mit JIRA Core können Social Media-Teams diese Anfragen einfach verfolgen, analysieren und Details erfassen. Mit den Informationen rund um Social Media-Posts an einem Ort kann die Social Media-Pipeline optimiert werden. Aufaben wie Prüfung des Posts, des Veröffentlichungsdatums und weitere Arbeitsschritte können im Workflow festgehalten werden.

3. Produktmarketing

Die Veröffentlichung eines neuen Features oder Produkt benötigt die Zusammenarbeit und Koordination von mehreren Teams – und das Timing muss auch noch stimmen. JIRA Core hilft dabei, alle Zeitpläne einzuhalten. Alle Beteiligten, Aufgaben und Fortschritte werden an einem Ort erfasst werden.

Sind alle Informationen rund um ein Projekt in JIRA Core festgehalten, sind Produktmanager immer auf dem Laufenden. Alle Screenshots, Videos und Inhalte lassen sich vor der Veröffentlichung prüfen und freigeben.

4. Kreative Teams

Kreative Teams werden von Deadlines und Creative Briefings gesteuert. Sie müssen wissen, welche Grafiken oder Videos zu erstellen sind. Setzt man JIRA Core zum Verwalten der vielen Marketing-Projekte ein, können die Teams alle nötigen Informationen sammeln und festhalten. Dinge wie Richtlinien, Spezifikationen, Anforderungen und Feedback lassen sich an einem Ort nachverfolgen. Feedbackzyklen für Freigaben sind dank Status wie In Progress, Under Review oder Rejected einfacher handzuhaben.

5. Pressemitteilungungen

Worte sind das Werkzeug der Wahl eines jeden Marketing-Teams. Egal ob Blog, Broschüre, Präsentation oder Pressemitteilung – es gilt immer die passenden Worte für die passende Zielgruppe zu finden.

Wenn das PR-Team die passenden Impulse verteilen soll, müssen die Beziehungen zu Medien und Analysten gepflegt werden. Soll eine aufregende Geschichte verbreitet werden, müssen Domänenexperten Feedback geben. Wird die Pressemitteilung mit JIRA Core verwaltet, kann man sicherstellen, dass die richtigen Leute die passende Arbeit zur richtigen Zeit erledigen und alles geprüft wird.

Dies sind nur einige wenige Beispiele dafür, wie verschiedene Ausprägungen einer Marketingabteilung ihre Arbeit und Projekte mit JIRA Core verwalten können. Wie genau Sie JIRA Core für Ihre Marketingabteilung einrichten, ist Ihnen überlassen. Wir helfen Ihnen gerne dabei.

Ganz egal, welches agile Vorgehensmodell Sie in Ihrem Team einsetzen – Portfolio for JIRA kann dabei helfen, eine realistische Roadmap für Ihre Produkte und Projekte zu erzeugen. Die vorherigen Beiträge zu Portfolio for JIRA haben sich hauptsächlich mit Scrum befasst. Man kann auf Umwegen jedoch auch Kanban mit Portfolio for JIRA verbinden. Dieser Artikel betrachtet, wie Kanban-Teams zuverlässig planen können.

Ein Hinweis: Derzeit ist Portfolio for JIRA nicht direkt dazu in der Lage mit Kanban umzugehen, aber es gibt eine simple Lösung. Es gibt eine Team-Konfiguration für Kanban, die sich wunderbar für die Planung einer Roadmap eines Kanban-Teams verwenden lässt. Diese Konfiguration orientiert sich zwar an der ursprünglichen Kanban-Praxis, ist aber nicht zu 100% akkurat. Atlassian hat einen Workaround entwickelt, mit dem man Roadmaps für Kanban-Teams kalkulieren kann. Wie mit jedem agilen Prozess und insbesondere Kanban wird die detaillierte, langfristige Planung jedoch immer zu einem Teil für die zuverlässige, konstante Auslieferung von hoher Qualität geopfert. Anforderungen und Geschäftsziele werden regelmäßig angepasst, was sich wiederum auf die Planung auswirken kann. Portfolio for JIRA ist zwar dazu in der Lage Veränderungen „on-the-fly“ in die Planungen der Roadmaps zu übernehmen und neue Szenarien und Änderungen automatisch einzupflegen, aber es liegt noch immer an Ihnen zu entscheiden, welche Commitments gemacht werden und was erreicht werden kann.

Was ist Kanban überhaupt?

Kanban ist eine lean agile-Methode, die sich aus dem Japanischen kan ban ableitet. Grob übersetzt bedeutet „kan ban“ in etwa „Karte, die man sehen kann“. Von der in der Toyota-Produktion eingesetzten Just-In-Time-Methode abgeleitet, lässt sich dieses Prozessmodell wunderbar auf die Entwicklung von Software und deren kontinuierlicher Auslieferung abbilden.

Kanban visualisiert alle anstehenden Arbeiten als ein in selbst geschlossenes System, in dem alle anstehenden Aufgaben als Karten auf einem Board in einer Anzahl von Spalten visualisiert werden. Das Team priorisiert eine Liste aller Aufgaben in der To-Do-Spalte und wenn an einer Aufgabe gearbeitet wird, wandert diese in die In Progress-Spalte.

Sobald die Arbeit an den Aufgabenpaketen voranschreitet, rutschen sie in den Workflow-Spalten weiter. In JIRA werden diese Spalten mit Backlog, Für Entwicklng ausgewählt, In Arbeit und Erledigt tituliert. Um weitere Planungs- oder Qualitätssicherungsmechanismen einzubauen, können die Spalten selbstverständlich auch feingranularer gestaltet werden. Sowohl Scrum als auch Kanban funktionieren gut als agile Methoden, wieso also ausgerechnet Kanban nutzen? Kanban ist ein viel schlankere agile Methodik, die sich für Teams mit klar definierten zu erledigenden Aufgaben eignet. Es wird mehr Augenmerk auf Sichtbarkeit, Flexibilität und der Erledigung von wertschöpfenden Aufgaben gelegt als auf das Management von Team-Prozessen.

Das von Atlassian postulierte Vorgehen lässt sich in folgende Schritte unterteilen:

1. Ein Projekt oder Board in JIRA Software erstellen

Falls Sie vorhaben, Kanban in JIRA Software ohne ein bereits existierendes Projekt einzusetzen, müssen Sie zuerst ein neues Projekt oder Board mit der Kanban-Funktion erstellen. Es ist zwar nicht unbedingt erforderlich ein Kanban-Board zu benutzen (ein Filter oder Projekt würde genauso gut funktionieren) aber ein Kanban-Board stellt sicher, dass ein konsistenter Abgleich zwischen Portfolio For JIRA und JIRA Software möglich ist. Falls Sie bereits ein Board, Projekt oder Filter besitzen, dann können Sie direkt nach Portfolio for JIRA wechseln.

2. Einen Portfolio-Plan erstellen

Im Portfolio For JIRA-Menü wählen Sie Plan erstellen, um den Plan-Erstellungs-Wizard zu starten. Seit Portfolio for JIRA 2.0 führt dieser Assistent durch die Erstellung eines neuen Planes in unter einer Minute. Dazu müssen zuerst der Name des Plans, die Vorgangs-Quelle und „Story Points“ als Schätzungsgrundlage gewählt werden. Über Releases geht es weiter zur Team-Seite. Auf der Seite zur Team-Definition muss für diesen Workaround eine Scrum-Iterationslänge von einer Woche gesetzt und die Velocity des Teams auf den Durchsatz des Teams gesetzt werden. Falls der Durchsatz des Teams nicht bekannt ist, wird weiter unten beschrieben, wie Sie diesen bestimmen.

Keine Angst, falls Sie keinen Zeitplan sehen sollten. Wer Kanban einsetzt hat meist keine Schätzungen für Aufgaben zur Hand. Falls Sie von Neuem beginnen und Sie noch keine Vorgänge im Plan haben, wäre jetzt ein guter Zeitpunkt ein paar Tickets zu erstellen. Es lässt sich entweder auf einem höheren Level beginnen, indem zuerst Epics erstellt, die dann heruntergebrochen werden oder Sie listen einfach alle zu erledigenden Aufgaben als von Folge von Tasks auf. Falls Sie auf einer noch höheren Ebene als Epics planen, können Sie die Hierarchie in Portfolio for JIRA auch anpassen und um weitere Hierarchie-Ebenen ergänzen.

3. Den Durchsatz des Teams bestimmen

Der wichtigsten Wert den Portfolio For JIRA liefert, ist die Berechnung einer realistischen, datengestützten Zeitplanung für die Aufgaben Ihres Teams. Während der Algorithmus viele unterschiedliche Variablen benutzt, können alle Pläne auf Kosten, Umfang und Zeit reduziert werden. Diese Formel ist für Projektmanager nichts Neues. Kanban hat keine Sprints, demnach lässt sich nicht einfach die Definition von Velocity anwenden. Schätzungen werden ebenfalls in Kanban-Teams eher weniger genutzt, da jede Aufgabe den ungefähr gleichen Umfang aufweisen sollte. Wie können wir eine passende Metrik für langfristige Zeitplanung bestimmen?

Wir sollten mit einer realistischen Velocity, welche angibt, wie viel Arbeit Ihr Team in einer gewissen Zeitspanne zu leisten vermag, beginnen. Wir möchten den Durchsatz des Teams bestimmen, also die Anzahl an Aufgaben, die ein Team typischerweise in einer gewissen Zeit erledigen kann. Kanban-Teams, welche auf Story Points setzen können dies mithilfe ihrer Story Points bewerkstelligen, ansonsten lässt sich diese Zahl anhand der pro Woche erledigten Aufgaben ablesen. Falls Sie bereits mit JIRA Software arbeiten, können Sie diese Informationen aus Berichten ablesen. Mit dem Control Chart und Cumulative Flow Diagram lassen sich die Durchlaufzeit und in Arbeit befindlichen Pakete (Work in Progress-Items) ablesen. Umn de Durchsatz zu bestimmen, setzen wir auf Little’s Law: Durchsatz = Work in Progress / Durchlaufzeit .

4. Den Umfang bestimmen

Wer auf Kanban setzt, hat ungefähr gleich große Aufgabenpakete. Wir definieren 1 Story Point = 1 Vorgang, damit ist die Velocity des Teams äquivalent zum Durchsatz an Aufgaben. Für jeden Vorgang muss also ein Story Point zum Umfang des Plans hinzugefügt werden. Falls es Aufgaben geben sollte, die größer oder kleiner als sonst sind, kann dies durch herauf- bzw. herabsetzen der Schätzung dargestellt werden.

Beispiel: Falls eine Story nur die Hälfte der sonst üblichen Zeit in Anspruch nehmen wird, so setzt man deren Schätzung einfach auf 0.5. Falls man wohl doppelt so lange dafür braucht, setzt man die Schätzung auf 2.0. Wenn Sie jetzt die Zeitplanung berechnen, wird eine Vorhersage zu allen Vorgängen in der Planung bestimmt.

Bei der Schätzung von Epics, die noch nicht in Stories unterteilt wurden, liegt es an Ihnen zu schätzen, wie der ungefähre Aufwand bestimmt wird.

Atlassian arbeitet auch an Standard-Schätzungen (JPO-1483).

5. Meilensteine und Releases

Jetzt wo Portfolio for JIRA über alle Ressourcen und Umfänge informiert ist, muss der Abschnitt Zeit – genannt Releases – noch mit Informationen befüllt werden. Im Releases-Tab können Sie Releases und Meilensteine für jedes Projekt festlegen. Kanban-Releases sind eher ungeplanter Natur, da sie in der Regel einfach dann ausgeliefert werden, wenn ein Feature fertiggestellt ist. Falls dies bei Ihnen so gehandhabt wird, können Sie mithilfe der Dynamischen Release-Daten-Funktion Portfolio For JIRA automatisch bestimmen lassen, wann welches Feature zur Veröffentlichung bereit steht.

Vielleicht möchten Sie aber bestimmte Releases in gewissen Zeitrahmen festlegen. In diesem Fall lässt sich mit der fixen Endzeitpunkt-Funktion bestimmen, wann ein Arbeitspaket abgeschlossen sein muss. Portfolio For JIRA lässt Sie wissen, falls Sie in Gefahr laufen, ein bestimmtes Datum zu verpassen. Falls Sie davor stehen, eine Deadline zu verpassen, müssen Sie entweder den Umfang reduzieren oder mehr dem Team mehr Ressourcen zur Verfügung stellen. Portfolio For JIRAs einfache Commit/Rücksetz-Funktion für Änderungen lässt Sie ganz einfach mit „Was-Wäre-Wenn“-Szenarien spielen.

6. Änderungen nach JIRA Software speichern

Bisher haben wir einen allgemeinen Zeitplan anhand von simplifizierten Daten des Teams bestimmt, um ein ungefähres Gefühl für die Auslieferungszeiten zu bekommen. Sind Sie mit dieser Granularität zufrieden, können Sie die Änderungen zurück nach JIRA Software speichern, um alle Planungsänderungen dem Team zugänglich zu machen. Hier steht es Ihnen frei, neue Vorgänge zu erstellen, die Priorität von Vorängen zu ändern, bestimmte Team-Mitglieder hinzuzufügen und ihnen bestimmte Vorgänge innerhalb des Portfolio-Plans zuzuweisen.

Mit Work Stages und Skills lässt sich die Planung noch viel detaillierter ausführen, Flaschenhälse visualisieren, Abhängigkeiten bestimmen und noch viel mehr.

Sobald Sie eine Änderung durchführen, lassen Sie Portfolio for JIRA einfach die Vorhersage für den Zeitplan aktualisieren und lassen die Änderungen zurück nach JIRA Software schreiben. Dank der „Was-Wäre-Wenn“-Szenarien in Portfolio, lassen sich Vorhersagen für Kanban-Pläne treffen. Sie können auch Kanban und Scrum im gleichen Plan verwenden – dies ermöglicht Ihnen maximale Flexibilität in der Planung.

Atlassian hat die beliebte Projektmanagement-Software-Suite JIRA Software in Version 7.2 freigegeben. Die Australier haben wieder viele Feature-Requests von Nutzern in die Tat umgesetzt. So wurden beispielsweise für JIRA Software 7.2 die 4 am meisten gefragten neuen Features bzw. Verbesserungen implementiert.

Der Fokus der neuen Version sind effizienteres Arbeiten dank voll editierbarer Vorgänge in der Detail-Anzeige, Vereinfachung der Bedienung und verbesserte Performance. Smartere Arbeit bedeutet, die Effizienz und Effektivtät und damit die Produktivität zu steigern. Atlassian hat JIRA Software effizienter gemacht, damit Sie einfach mehr Arbeit erledigt bekommen.

Vorgänge in der Detail-Anzeige bearbeiten

Sie kennen das Problem: Während einer Sprintplanung prescht Ihr Team mit einem Wahnsinnstempo durch den Backlog. Ideen sprudeln, Aufgaben werden verteilt und Schätzungen gemacht. Doch jedes mal wenn ein Vorgang in JIRA aktualisiert wird, muss jemand das Ticket in einem neuen Tab öffnen und die Änderungen vornehmen. Im Anschluss muss zurück gewechselt und alles für den nächsten Vorgang wiederholt werden.

Mit JIRA Software 7.2 können alle Felder der Vorgänge innerhalb der Detail-Anzeige des Issue-Browsers bearbeitet werden. Damit ist es möglich, Änderungen ohne Kontextwechsel schnell und einfach durchzuführen.

Rich-Text-Bearbeitung für Kommentare und Beschreibungen

Manchmal möchte man ein Wort in einer Beschreibung hervorheben oder einen Kommentar besonders formatieren. Bisher musste mithilfe von Wiki-Markdown-Syntax im Text formatiert werden. Änderungen musste man stets mit der Preview-Funktion prüfen. Mit Version 7.2 hat Atlassian jetzt WYSIWYG-Funktionalität zu allen Textfeldern hinzugefügt,

Texte via Copy-and-Paste aus anderen Anwendungen oder Tabellen lassen sich jetzt ohne Wiki-Markup einfügen. Wer die Syntax nicht auswendig kann, an trotzdem vollumfänglich Inhalte beitragen.

Markdown Syntax lässt sich über die Toolbar oder direkt im Text einfügen. Der Text-Modus zeigt die Formatierbefehle an, während der Visual-Mode die fertig formatierten Elemente anzeigt – genau so wie sie nach dem abspeichern aussehen.
Man muss sich nicht mehr merken, wie Text kursiv oder fett gemacht wird.

Flexibler CSV-Exporter

Manchmal möchte man die Daten in einem Format abspeichern, mit welchem man Daten beliebig manipulieren kann. Hier ist ein simples Format wie CSV mit komma-getrennten Werten die beste Wahl. Daten lassen sich in einer Tabellenkalkulation laden, Charts und Auswertungen nach gusto erstellen. Mit JIRA Software 7.2 wurde eine CSV-Export-Option für alle Vorgänge und Felder im aktuellen Suchergebnis eingeführt.

Das leichtgewichtige CSV-Dateiformat sorgt für kleine Exports, das Limit von 1000 Vorgängen pro Export entfällt. Es werden nun alle Vorgänge exportiert, die eine Suche liefert.

Den Kontext im Blick

Mit JIRA 6.4 hat Atlassian damit begonnen, dafür zu sorgen, dass die Arbeit stets im Kontext des jeweiligen Projekts oder Boards stattfinden kann. JIRA- und Projektadministratoren können nun die Änderungen im Kontext des aktuellen Projekts mit einem Klick auf Project Settings aufrufen. Damit lässt sich nach Änderungen direkt zur Arbeit zurück wechseln. In Anzeige von Berichten wird nun stets die Seitenleiste eingeblendet, über welche direkt ins Projekt gewechselt werden kann.

Releases, Versionen und Komponenten

Atlassian hat ebenfalls daran gearbeitet, die Handhabung von Versionen und Komponenten für Projektadministratoren zu vereinfachen.

Werden Releases aus der Seitenleiste ausgewählt, so lassen sich neue Versionen inline hinzufügen und mit dem entsprechenden …-Button verwalten. Komponenten werden auf die gleiche Weise gehandhabt.

Änderungen für JIRA Software

Neben den Änderungen an der Plattform an sich, hat Atlassian folgende JIRA Software-spezifische Änderungen und Verbesserungen durchgeführt:

• Es kann nun gewählt werden, ob das Sprint-Feld beim Klonen eines Vorgangs mit kopiert wird
• Der Backlog lässt sich von nun nach nach Bearbeiter filtern
• Vorgänge können vom agile Board über das Rechtsklick-Menü gelöscht werden
• JIRA Administratoren werden von einer neuen Onboarding-Funktion beim ersten Login begrüßt, welcher die Erstellung von neuen Projekten und den Import externer Daten vereinfacht.

Kleine Änderungen: Ein Überblick

Wie immer hat Atlassian eine Anzahl von kleinen Detailänderungen vorgenommen, die hier in aller Kürze aufgelistet werden:

• Smart Mentions zeigen beim Tippen von „@“ zuerst die Leute an, die bereits an der Konversation zum Ticket beteiligt sind. Hierdurch muss nicht mehr geprüft werden, wer überhaupt an einem Vorgang beteiligt ist.
• Weiterhin hat Atlassian die Suche für Mentions verbessert. Suchbegriffe müssen nicht mehr genau passen, die Suche nach Steve Smith zeigt nun also auch neben Steve Smith andere Personen wie Steven Smithers oder Steven Smith an.
• Ein Board, welches über mehrere Projekte hinweg verwendet wird, kann kompliziert sein. Aus diesem Grund können die Swimlanes eines Boards nun aufgrund der Projekte geteilt werden, was es leichter macht, die richtigen Vorgänge zu finden.
• JIRA unterstützt nun die Sprachen Portugiesisch, Russisch und Koreanisch.

Performance verbessert

Atlassian hat für JIRA Software 7.2 einige Performance-Flaschenhälse beseitigt. Die Verbesserungen machen sich vor allem bei großen Installationen bemerkbar.

Highlights der Verbesserungen sind:

• Vorgang anzeigen – Die Ladezeiten und Durchsatz wurden verbessert. Damit lassen sich Vorgänge schneller anzeigen und bearbeiten
• Dashboards – Die Antwortzeiten der Server wurden verbessert und der Durchsatz wurde signifikant beschleunigt. Damit bleiben Dashboards unter Last stabiler und werden schneller angezeigt.

Der Hauptfokus der vorliegenden Verbesserungen waren Antwortzeiten und Durchsatz des Servers, was sich vor allem bei sehr großen Installationen positiv auf die Geschwindigkeit auswirkt.

Quellen & Links

• JIRA Software 7.2 Release Notes
• JIRA Software 7.2 Release Blog Post

Atlassian hat neue Major-Versionen der JIRA Produktfamilie veröffentlicht. Nach JIRA Software 7.2 wurde nun auch die ITIL-zertifizierte Helpdesk-Lösung JIRA Service Desk in Version 3.2 vorgestellt.

Besonderer Fokus in dieser Version sind die Verbesserungen für Kunden im Service Desk. Freigaben lassen sich mit nur einem Klick erteilen, Kunden können den Zustand ihrer eigenen Anfragen ändern und im neu gestalteten Portal nach Anfragetypen suchen. Das Team kann mit JIRA Service Desk 3.2 effizienter arbeiten. Agenten sind in der Lage, zu Anfragen verwandte Wissensartikel zu finden und zu verknüpfen. Die Automatisierungs-Engine lässt sich dank Webhooks in Drittanbieter-Software integrieren und Berichte bieten verbesserte Drill-Downs für mehr Überblick.

Freigaben an Workflows binden

Von nun an können Freigabeschritte in Workflows integriert werden. Kunden können auswählen, wer sich um die Freigabe kümmern soll. So kann es sein, dass ein Anwender einen neuen Laptop anfragen möchte, aber die Freigabe von einem Manager benötigt.

So funktioniert das Ganze:

1. Ein Anwender erstellt eine Anfrage im Kundenportal und wählt den Genehmiger aus
2. Falls die Anfrage in den Zustand gerät, welcher einen Freigabeschritt (Approval) enthält, so wird der Genehmiger (Approver) benachrichtigt.
3. Im Kundenportal, kann der Genehmiger die Anfrage freigeben oder ablehnen
4. Die Anfrage wird in den nächsten Zustand des Workflows überführt

Fügen Administratoren einen Freigabeschritt zu einem Workflow hinzu, so können mehrere Freigabeschritte hinzugefügt sowie eine Liste von Genehmigern erstellt werden und die Aktion, die nach einer Freigabe oder Ablehnung durchgeführt wird, festgelegt werden.

Zustand einer Anfragen im Portal verändern

Mit JIRA Service Desk 3.2 können Sie Kunden erlauben, Anfragen innerhalb des Portals selbst in andere Zustände zu überführen. Anfragen können so zum Beispiel vom Anfragesteller gelöst oder erneut geöffnet werden.

Angenommen, ein Agent weist einen Kunden in einer Anfrage auf einen Wissenartikel hin und der Kunde findet die Lösung zum vorliegenden Problem im Artikel, so kann der Kunde selbstständig die Anfrage als gelöst markieren. Oder falls ein Vorgang bereits gelöst ist, aber die Problematik erneut auftritt, kann die Anfrage erneut geöffnet werden.

Benachrichtigungen stummschalten

Falls Ihre Kunden sich nach ein wenig Ruhe und Frieden sehnen, können diese nun die Portal- oder E-Mail-Benachrichtigungen zu ihren Anfragen de-aktiveren.

Anfragen dank integrierter Wissensdatenbank schneller lösen

Wissen abzuspeichern und zu teilen ist mit JIRA Service Desk 3.2 noch einfacher und schneller geworden. So ist es nun möglich, Wissensartikel in einen Vorgang zu integrieren, so dass empfohlene Artikel angezeigt, die Wissensdatenbank durchsucht und Artikel geteilt werden können – alles im selben Tab.

Anfragen teilen und Beteiligte entfernen

Atlassian hat die Handhabung von Beteiligten bei Anfragen geändert. Möchten Kunden weitere Beteiligte zu einer Anfrage hinzufügen, so wird dies anstatt mit Add Participants nun mit Share bezeichnet. Kunden können Beteiligte von einer Anfrage auch wieder entfernen.

Ereignisse an Drittanbieter-Software senden

Mit Automatisierungsregeln lassen sich Service Desk-spezifische Ereignisse an externe Software und Add-Ons übermitteln. So lassen sich beispielsweise Status Updates zu einer gelösten Anfrage an ein CRM-Werkzeug schicken. Oder SMS-Benachrichtigungen versenden, sobald eine kritische Anfrage in die Warteschlange kommt oder eine externe Anwendung darüber benachrichtigen, falls es droht, dass ein SLA nicht mehr eingehalten werden kann.

Um ein Ereignis an externe Anwendungen zu senden, fügt man einen Webhook hinzu und ergänzt eine Automatisierungsregeln um eine THEN-Aktion. Atlassian beschreibt auch detailliert, wie Webhooks funktionieren.

Automatiserungsregeln und Ereignisse lassen sich für folgende Szenarien erstellen:

• Ein Vorgang ändert seinen Zustand
• Eine Freigabe wird benötigt
• Ein Beteiligter wird einer Anfrage hinzugefügt
• Ein Vorgang verändert den Status

Tiefer in Berichte eintauchen

Atlassian hat die Berichte in JIRA Service Desk überarbeitet. So ist es nun leichter, Einblicke in die Interaktionen von Kunden mit dem Portal und die Auswirkungen der bereitgestellten Services zu erhalten. Datenpunkte lassen sich anklicken und mehr Details aufrufen. Möchte man die Daten noch weiter untersuchen, so kann man die Resultate als CSV-Datei exportieren.

Mit Quicklinks schneller in der Seitenleiste navigieren

Atlassian hat einige allgemeine Aufgaben in die Projektseitenleiste zwecks einfacherer Auffindbarkeit integriert:

Eigene Icons für Anfragetypen verwenden

Es ist nun möglich, eigene Icons für Anfragetypen hoch zu laden. Es ist auch einfacher geworden, mit Anfragetypen zu arbeiten. Diese können nun via Drag-And-Drop neu angeordnet werden und Anfragetypen lassen sich zwecks Debugging oder Sandboxing im Portal auch verstecken.

Atlassian hat das Leben für Anwender leichter gemacht, für den Fall, dass Sie viele Anfragetypen in Ihrem System verwalten – im Portal lässt sich nun auch nach Anfragetypen suchen.

Kleine Änderungen

Wie immer wurde JIRA Service Desk 3.2 auch im Detail überarbeitet. So sind folgende kleine Änderungen eingeflossen:

• Mit Beispieldaten experimentieren: Vielleicht möchten Sie neue Szenarien testen, ohne die eigenen Queues zu belasten. Das ist nun möglich, indem man ein Projekt mit vorgefertigten Beispieldaten erstellen kann.
• Im Kundenportal wird Wiki-Markup angezeigt, so können Tabellen, Panels und Codeblöcke direkt im Portal angezeigt werden
• Falls die Kommentare zu lang werden, lassen sich Zitate nun auch aus via E-Mail verschickten Antworten filtern. Die Einstellung findet sich unter JIRA Administration > Applications > JIRA Service Desk > Email requests

Quellen & Links

• JIRA Service Desk 3.2 Release Notes

Verwaltet man als Projektmanager webbasierte Projekte, steht man vor Problemen, die ein Kunde gar nicht auf dem Radar hat. In den Augen des Auftraggebers sind Webseiten oder webbasierte Projekte elegant, einfach zu benutzen und simpel gehalten – dann kann deren Erstellung ja auch nicht so schwer sein. Die ganze Arbeit, die in Design, User Experience, Integrationen und Schnittstellen fließt, ist keineswegs eine simple Angelegenheit. Mit JIRA Core können Website-Projekte um einiges leichter von der Hand gehen.

Website-Projekte sind kompliziert

Egal ob Sie einer Webagentur angehören oder ein In-House-Projekt verwalten – Sie verstehen den Prozess der Webseitenerstellung. Ihnen ist der enorme Aufwand bewusst, den ein neues Projekt mit sich bringt. Sie wissen um die Erwartungen und Anforderungen des Teams, stellen die Projektverfolgung und pünktliche Auslieferung sicher. Sie müssen die Arbeit vieler Beteiligter koordinieren. Auftraggeber, Entwickler, Designer, UX-Experten und Texter sprechen alle unterschiedliche Sprachen, wenn es um die Definition und Beschreibung eines Projektes geht.

Ihre Entwickler verfolgen Ihre Aufgaben vielleicht in Sprints in JIRA Software, während das restliche Team eine andere Lösung verwendet. Viele Agenturen oder In-House-Teams setzen auf Spreadsheets oder E-Mail, um Anforderungen und Termine zu regeln. Diese Werkzeuge setzen jedoch eine Menge manueller Pflege voraus und können nicht alle Aspekte eines Webseiten-Projektes bedarfsgerecht abbilden. Falls auch nur eine Information unzureichend abgelegt ist, kann das gesamte System zusammenbrechen. Aus diesem Grund benötigen auch Webentwicklungsprojekte eine hieb- und stichfeste Prozesslandschaft, in welcher alle Beteiligten ihre jeweils benötigten Informationen zuverlässig abrufen können. So bleiben Kunden zufrieden und Teams produktiv und motiviert.

Was Prozesse leisten können

Einen durchorganisierten Prozess zu haben, hilft Teams dabei, Aspekte wie Umfang, benötigte Ressourcen, involvierte Stakeholder und Prioritäten vernünftig zu verwalten.

Weiß ein Team von vornherein, wie viel Aufwand ein bestimmtes Projekt erfordert, ist es einfacher, die passende Anzahl an Entwicklern und Designern zuzuweisen. Falls die Anforderungen nicht den Möglichkeiten der Leistungserbringung des Teams entsprechen, kann dies rechtzeitig kommuniziert und gegebenenfalls Arbeitspakete punktuell ausgelagert werden. Priorisierung ist ebenfalls ein probates Mittel, um kritische Fehler schnell zu beheben. Denn viele Webseiten sind geschäftskritisch für die Wertschöpfung oder müssen zeitlich zu einem Produkt-Launch passend veröffentlicht werden oder eine strategische Neuausrichtung kommunizieren.

Sind alle Beteiligten in denselben Prozess eingebunden, können technik-orientierte Mitarbeiter und andere Teams besser miteinander kommunizieren. Wie soll ein Projektmanager ohne die Möglichkeit, Anforderungen und Umfang eines Projektes und das Team im Bilde zu halten, vernünftig arbeiten können?

Mit JIRA Core Komplexität den Kampf ansagen

Glücklicherweise gibt es mit JIRA Core die Möglichkeit, selbst die umfangreichsten Projekte effizient zu verwalten. JIRA Core ist ein Projektmanagement-Werkzeug aus dem Hause Atlassian, welches auf die Anforderungen von Teams aller Art zugeschnitten ist. Das Werkzeug erlaubt die Verfolgung von Ideen, Aufgaben und Projekten und kann die verschiedensten kreativen Inputs, Anforderungen und Spezifikationen in einem Vorgang bündeln. Stakeholder und Bearbeiter sind an einem Ort vereint und stets über den Projekt-Fortschritt im Bilde.

So kann JIRA Core Ihnen helfen, Projekte noch besser im Griff zu halten:

Anforderungen erfassen

Ihr Team kann individuelle Eingabemasken erstellen, um spezielle Informationen wie bestimmte Design-Elemente abzufragen, an die ein Auftraggeber noch nicht einmal gedacht hat. Sketches, Prototypen oder Design-Konzepte können an Aufgaben angehängt werden, damit die passenden Dateien stets an einem zentralen Ort verfügbar sind.

Workflows

JIRA Core stellt mit einer Standard-Vorlage ein Businessprojekt für den schnellen Einstieg zu Verfügung. Sie können auch individuelle Workflows (Prozesse) für Ihr Team erstellen, damit ein Projekt durch die einzelnen Phasen wie Anforderungserhebung, Design und Umsetzung wandern kann. Workflows helfen dem Team zudem, die einzelnen Schritte einer Aufgabe von der Erstellung bis zur Fertigstellung einzuhalten.

Erwartungen im Zaum halten

Anstatt in den Untiefen eines Excel-Sheets oder E-Mailfächern zu wühlen, kann mit JIRA Core mithilfe von Dashboards der Projektfortschritt visualisiert werden. So ist auf einen Blick sichtbar, welche Projekte offen und in Arbeit sind und unterstützt bei der Planung von Team-Kapazitäten. Indem Fortschritt und Arbeitsleistung akkurat gemessen werden, können Sie realistische Zeitfenster prognostizieren und auch einhalten oder gegebenenfalls Anpassungen in der Zeitplanung vornehmen.

Eine gemeinsame Sprache

Sind alle Beteiligten auf einer Plattform vereint, so arbeiten Teams auch über Abteilungen hinweg besser zusammen. Anstatt die Arbeit von technischen und nicht-technischen Teams via E-Mail zu überbrücken, hilft JIRA Core dabei, die Aufgaben aller an einem Ort sichtbar und verfolgbar zu halten. So geht nichts mehr verloren. Weiterer Vorteil: Änderungen in letzter Minute und Aufgaben von niedriger Priorität lassen sich besser verwalten und alle Stakeholder verstehen, was warum geschieht.

Ein Projektmanagement-Werkzeug wie JIRA Core hilft beim Management von Webprojekten, wird zum Liebling Ihres Teams und Ihrer Kunden. Projektmanager können schnell Aufträge erfassen, priorisieren und den Entwicklern ungestörtes Arbeiten ermöglichen, damit großartige Arbeit zeitig ausgeliefert werden kann.

Eine häufige Frage unter Kunden ist „Wie kann ich Prioritäten verwenden, um Issues innerhalb von JIRA Software besser zu verwalten?“. Im Laufe der Geschichte der Softwareentwicklung verwendeten Teams Prioritäten, um verschiedene Prozesse innerhalb ihrer Issue-Trackingsysteme zu kommunizieren. Wenn die Definition der Prioritäten nicht eindeutig ist, dann sorgt das bei der Arbeit für Verwirrung.

Legen wir einige allgemeine Definitionen fest, um einen Rahmen für unsere Diskussion zu bilden:

• Priorität – Die relative Wichtigkeit, die eine Issue im Vergleich zu anderen Issues für das Team hat
• Schweregrad– Die relative Auswirkung einer Issue, im Vergleich zu anderen Issues, die in Tests, der Entwicklung oder dem Feld gemeldet wurden
• Häufigkeit – Wie oft eine bestimmte Issue auftaucht
• Blockiert – Ein Fall, in dem ein Teammitglied keinen Fortschritt machen kann

Die Priorität spiegelt die Reihenfolge wider, in der die Entwickler an Issues arbeiten müssen. Wenn wir dieser Definition nicht folgen, dann wird es schwieriger, die Arbeit zu vollenden, weil das Team nicht immer weiß, was der nächste richtige Schritt ist.

Priorisieren Sie konsequent

Effektive Teams priorisieren Issues durchgehend, während sich die Teamkultur entwickelt. Möglicherweise haben Sie bereits eines der folgenden Statements gehört, während Sie Issues für die nächste Iteration organisiert haben.

• „Diese Issue sollte oberste Priorität haben, denn sie ist sehr schwerwiegend!“ (Hoher Schweregrad)
• „Viele Leute werden dieses Problem haben, wir sollten ihm also eine hohe Priorität einräumen.“ (Hohe Häufigkeit)
• „Ich kann keinen Fortschritt machen, diese Issue sollte also hohe Priorität haben.“ (Blockiert)

Werfen wir einen Blick auf einige Folgefragen, die wir stellen sollten:

• Was ist die schlimmste Folge, die dieses Problem nach sich ziehen kann?
• Wird der Nutzer etwas von signifikantem Wert verlieren?
• Wie viele Nutzer sind schätzungsweise betroffen?
• Beschränkt sich das Problem auf einen bestimmten Bereich des Produkts, oder werden alle Nutzer dieses Problem haben?
• Verhindert das Problem, dass Endnutzer, oder jemand im Entwicklerteam Fortschritte machen kann?

Softwareentwicklung ist ein ökonomischer Prozess. Wenn Sie sich dafür entscheiden, ein Problem zu lösen, dann verzögern Sie damit die Bearbeitung einer anderen Aufgabe. Es ist deshalb wichtig, die Reihenfolge in der Probleme gelöst werden zu optimieren, damit Ihr Team den größtmöglichen Wert abliefert. Egal, wie Probleme priorisiert werden, die Priorität ist nur die Reihenfolge, in der sie behoben werden sollten.

Traditionelle Teams: Prioritäten-Feld in JIRA Software verwenden

Traditionelle Entwicklerteams sollten das Prioritätsfeld in JIRA Software verwenden. JIRA Software enthält fünf Standard-Prioritäten (Blocker, Kritisch, Wichtig, Untergeordnet, Trivial). Teams können Prioritäten in JIRA Software hinzufügen und ändern, um sie an die Anforderungen des Teams anzupassen.

Prioritäten existieren typischerweise innerhalb von Versionen, damit Entwickler zuerst alle Probleme einer Version, basierend auf den Prioritäten beheben, bevor sie mit der nächsten Version fortfahren. Besser ausgedrückt, ein Blocker in Version 2 würde erst nach einer wichtigen Issue in Version 1 bearbeitet werden. Das zweidimensionale Filterstatistikengadget fasst die Prioritäten aller parallel zueinander existierenden Versionen zusammen. Projektmanager können so auf einen Blick einen Überblick über das gesamte Projekt erhalten. Klicken Sie einfach auf einen der Links, um mehr zu erfahren.

Verwenden Sie das „Behobene Version“-Feld, um anzupeilen, in welchem Release ein Problem behoben sein sollte. Das „Betrifft Version“-Feld protokolliert, in welcher Version das Problem gefunden wurde.

Agile Teams: Verwenden Sie Ränge

Agile Teams priorisieren Issues auf etwas andere Art und Weise. Agile Teams liefern neue Arbeit, indem sie sich durch ein Backlog arbeiten, welches eine Liste aller bekannten Issues ist. Die Liste ist stets in einer priorisierten Reihenfolge, damit das Team die Arbeit direkt vom Anfang der Liste beziehen kann. Iterationsbasierte Scrumteams arbeiten mit Sprints. Sie holen sich ein Set von Issues vom Anfang des Backlogs und arbeiten diese während einer Iteration durch. Flowbasierte Kanban-Teams beziehen Issues kontinuierlich aus dem Backlog.

Agile Teams benötigen das Prioritätsfeld, da die Reihenfolge des Backlogs die Priorität festlegt. Wenn sich Prioritäten innerhalb des Backlogs verändern, ist das Team davon nicht betroffen, da es sich ausschließlich mit den ersten paar Issues am Anfang der Liste beschäftigt. JIRA Software macht es einfach, Arbeit nach Version zu filtern, damit Produktbesitzer die Prioritäten innerhalb einer Version und der gesamten Arbeit verändern können. Manche Teams verwenden gerne Ränge und das Prioritätsfeld, da es eine gesammelte Gruppierung der relativen Priorität bietet. Sie können diese Sammlungen mithilfe der Issuesuche und verschiedenen Dashboard-Gadgets abfragen.

Verwendung von Flags

Es kann passieren, dass während der Bearbeitung einer Issue ein weiteres Problem auftaucht, das den Fortschritt verhindert. In diesem Fall ist der Fortschritt blockiert. Mit JIRA Software können Teammitglieder eine Issue markieren, um zu notieren, dass sie blockiert sind. Im Agile Board wird die Issue gelb hinterlegt und mit einem Flaggensymbol markiert.

Die Priorität der Issue erhöht sich nicht automatisch, wenn der Fortschritt blockiert ist. Das Team wiegt dann die Konsequenzen der Blockade gegen die aktuelle Arbeitslast ab und entscheidet dann, ob sich die Prioritäten ändern müssen.

Ausrichtung durch Eindeutigkeit

Teams, die bereits auf die Priorität der kommenden Arbeit ausgerichtet sind, arbeiten flüssiger und liefern schneller. Hören Sie stets auf Ihr Team, um herauszufinden, ob die Prioritäten klar sind. Fragen Sie während Retrospektiven „Lässt sich leicht feststellen, was die nächste Priorität des Teams ist?“. Wenn es Unklarheiten gibt, sollten Sie sich auf die Priorisierungspraktiken des Teams konzentrieren und diese Praktiken dann in JIRA Software nachbilden.

Bei agilen Strategien lässt sich leicht von Prozessen, Zeremonien und Workflows reden, es ist aber ebenso einfach, das Team aus dem Blick zu verlieren. Für gewöhnlich setzen sich agile Teams aus fünf bis sieben Entwicklern zusammen. Diese kleine Gruppe von Entwicklern besitzt überlappende, gemeinsame Skillsets, wodurch keine einzelne Person ein kritischer Pfad oder Blocker sein kann. Während das Team zusammenarbeitet, wachsen die Skillsets, Wissen wird geteilt und die Velocity erhöht sich, wodurch sich das Team schneller durch das Programm-Backlog arbeiten kann.

In diesem Artikel werden wir uns die Dynamik hinter der Bildung von schnellen agilen Teams ansehen, und einen Blick darauf werfen, wie man JIRA Software konfiguriert, damit es mehrere Teams unterstützt. Sie erhalten außerdem zusätzliche Tipps, mit denen Sie den Arbeitsaufwand über ein Set von Teams hinweg optimieren können.

Veränderung kann eine gute Sache sein

Veränderung ist beständige Realität. Sie findet in jeder Unternehmenssituation statt. Normalerweise ist es die beste Praxis, die agilen Teams zusammenzuhalten. Die zwischenmenschlichen Beziehungen die dabei geformt werden und die dabei geteilten Prozesse sind sehr wertvolle Fähigkeiten und es ist meistens einfacher, den Workflow eines bestehenden Teams zu ändern, als ein brandneues Team zu bilden. Manche Änderungen sind jedoch so signifikant, dass neue Skillsets erforderlich werden, um die Änderungen zu bewältigen.

Wann also bildet sich ein neues agiles Team? Integrationsprojekte benötigen häufig Skillsets aus zwei unterschiedlichen Codebasen. Die Entwicklertool-Integration in JIRA Software benötigt beispielsweise Entwickler aus dem JIRA Software-Team und Entwickler aus dem Entwicklertools-Team. Es macht deshalb Sinn, Wissen aus beiden Codebasen zusammenzutragen und ein neues Team zu formen, um diese Arbeit anzugehen.

JIRA Software für Subteams konfigurieren

Wenn ein großer Arbeitsaufwand auf mehrere Subteams aufgeteilt werden soll, stellt sich die Frage, wie die Arbeit in JIRA Software am besten strukturiert werden sollte. Die größte Frage ist: Braucht jedes Subteam sein eigenes JIRA Software-Projekt? Wenn jedes Team die gleiche Releasekadenz besitzt (JIRA-Versionen), dann sollten Sie die gesamte Arbeit in einem JIRA Software-Projekt belassen. Im JIRA Software-Team verwenden wir beispielsweise ein benutzerdefiniertes Feld namens Team, um zu kennzeichnen, welches Team sich um die Issue kümmert.

Wenn jedes Team die gleichen agilen Prozesse und Iterationszyklen nutzt, sollten Sie außerdem ein agiles Board für das gesamte Projekt erstellen. Anschließend können Schnellfilter oder Swimlanes das benutzerdefinierte Team-Feld verwenden, um die Arbeit zu organisieren und auf die Teams zu verteilen.

Schnellfilter

Schnellfilter sind additiv (Denken Sie an AND statt OR), wenn sie zusammen verwendet werden. Durch Auswahl des Team-Schnellfilters und eines anderen Schnellfilters, wird die Arbeit nur auf dieses Team konzentriert. Im Bild unten, finden Sie oben in der Mitte die ausgewählten Schnellfilter des Teams:

Swimlanes

Swimlanes strukturieren Arbeitsaufwand in allen Bereichen, wodurch sich die Arbeit leichter im Kontext für jedes Team sehen lässt. Vergessen Sie aber nicht, dass jedes Team die gleichen agilen Prozesse nutzen muss, damit Schnellfilter und Swimlanes funktionieren.

Im Bild unten können Sie in der linken Spalte die verschiedenen Teamnamen sehen (Swimlanes lassen sich für bessere Lesbarkeit einklappen):

Separate Agile Boards

Für Teams, die unterschiedliche agile Prozesse nutzen, aber die gleiche Releasekadenz haben, sollten Sie innerhalb des gleichen Projekts ein Agiles Board für jedes Team erstellen. Passen Sie einfach die JQL-Query (im Bild rechts unten) für jedes einzelne Board innerhalb des Projekts an.

Wenn die Releasekadenz aller agilen Teams unterschiedlich ist, sollten Sie möglicherweise ein separates JIRA Software-Projekt für jedes einzelne Team erstellen. Dadurch hat jedes Team seine eigene Version, um das Release der Software zu verwalten.

Wie funktionieren Subteams beim JIRA Software-Team?

Atlassian plaudert hier aus dem Nähkästchen: Das JIRA Software-Team an sich hat ebenfalls ein neues agiles Team gebildet, als zwei unterschiedliche Teile des Produktentwicklungsteams zusammen kamen und sich ein großes Team von insgesamt 20 Leuten formierte. Zwanzig Leute waren zu viel für ein einzelnes Team, weshalb Atlassian sich einige Tipps von Spotifys Entwicklerstruktur holte und sechs schnelle Squads bildete, um den Arbeitsaufwand zu bewältigen.

Teams sind wesentlicher Bestandteil der Organisationskultur. Die Optimierung von Teams steigert die Motivation, verteilt den Arbeitsaufwand, verringert das Risiko und sorgt mithilfe von agilen Methoden für schnellere Lieferung.

Wenn Sie schon einmal eine Marketingkampagne gestartet haben, werden Sie wissen, dass das keine leichte Aufgabe ist. Es gibt eine Vielzahl von Dingen, um die Sie sich kümmern und die Sie berücksichtigen müssen. Beispielsweise Creative Assets, Textmaterial, Mitarbeiter und am allerwichtigsten Termine. Es scheint, als würde die Hälfte der Zeit nur damit verbracht werden, Teamkollegen wegen Statusupdates hinterherzujagen, während die andere Hälfte damit verbracht wird, all das zu organisieren, was für die Kampagne erforderlich ist.

Wie organisiert Ihr Marketingteam seine Kampagnen und Produktveröffentlichungen? Vielleicht erstellen Sie eine Checkliste, die ungefähr so aussieht:

Zu erledigen:

• Messaging und Positionierung erstellen
• Webseiten erstellen
• Blog schreiben
• E-Mail-Ankündigungen verschicken
• Social Media-Plan erstellen
• Video filmen
• Verträge unterzeichnen
• Entwurf für die Pressemitteilung ausarbeiten
  Und so weiter…

Diese Liste scheint nie ein Ende zu nehmen. Und wenn Sie genau darüber nachdenken steht am Ende jede Aufgabe für eine Person oder eine Gruppe, die diese Aufgabe bis zu einem bestimmten Termin erledigen muss. Und diese Person, bzw. dieses Team unterteilt diese Aufgabe in viele verschiedene Deliverables, die koordiniert und bearbeitet werden müssen.

Kurz gesagt, es braucht quasi ein ganzes Dorf, um eine Marketingkampagne zu starten. Ganz egal, ob dieses „Dorf“ ein großes Marketingteam mit über 100 Mitgliedern oder nur eine Handvoll Kollegen ist, die mit externen Anbietern zusammenarbeiten – Sie müssen dafür sorgen, dass jeder mit anpackt.

Und während Sie die Checkliste Ihrer Kampagne bearbeiten, müssen Sie sich bei Ihrem Manager melden, der wahrscheinlich ein Update haben möchte. Wie protokolliert man all diese Aufgaben, Unteraufgaben und die Leute, die an ihnen arbeiten? Es gibt dafür einige bekannte Methoden.

1. Sie benachrichtigen einen Kollegen.
2. Sie versammeln alle Kollegen und halten (mehrere) Meetings ab.
3. Sie verschicken E-Mails und vergessen versehentlich ein „CC:“

Wenn Sie sich bei einem Kollegen melden, kann dass dessen Konzentration stören. Auch Meetings können Ihre Teamkollegen stören und deren wertvolle Zeit verbrauchen. Und E-Mails – ist es nicht das Schlimmste, die Antworten und weitergeleiteten Nachrichten eines jeden Teamkollegen zu lesen? Wir haben bereits viele Teams gesehen, die diese Qualen erleiden mussten. Und es endet immer mit Fehlkommunkation, verspäteten Deliverables, inkorrekten Assets und allem, was einem Marketingverantwortlichen sonst noch Kopfschmerzen bereitet.

Manche Teams sind in die Fußstapfen ihrer Kollegen aus dem Softwareteam getreten, welche auf JIRA Software setzen und konnten so wieder zu Seelenfrieden gelangen. JIRA Software ist ein Projektmanagament-Tool, welches Softwareteams bei der Planung, Protokollierung und Priorisierung ihrer Aufgaben hilft, damit sie großartige Software produzieren können. Produktmangagement-Teams und andere Arten von Marketingteams können mit JIRA Core den gleichen Methoden folgen, jedoch im Kontext ihrer Geschäftsanforderungen.

Wie ist das möglich? JIRA Core ist die Lösung für das Projekt- und Aufgabenmangement, die für Businessteams und insbesondere für Marketingteams entwickelt wurde, um beim Planen, Protokollieren und dem rechtzeitigen Abliefern von Projekten zu helfen. Werfen wir einen Blick darauf, wie JIRA Core Ihnen helfen kann, Ihre Arbeit zu organisieren.

JIRA Core hilft Produktmarketing-Teams dabei, den Fortschritt eines Projekts zu begutachten und zu analysieren

Szenario 1: Ihr Manager benötigt ein Update zum Fortschritt des Projekts.
Manager: „Schaffen wir es, pünktlich zu starten?“
Sie: [Sie sehen schnell in Ihrem JIRA Core Dashboard nach.] „Wir haben erst ein Viertel unserer Aufgaben abgeschlossen und haben noch nicht einmal die Hälfte angefangen. Es sieht so aus, als ob John im Moment nur 1 Aufgabe bearbeitet. Ich werde nachsehen, ob wir nicht einige Aufgaben neu vergeben können.“

Mit dem JIRA Core Dashboard erhalten Sie einen High Level-Überblick über Ihr Projekt – was wurde erledigt und was muss noch getan werden. Sie können dieses Dashboard so aufbauen, dass nicht nur Ihre Aufgaben hervorgehoben werden, sondern auch die Ihres restlichen Teams, unterteilt in beauftragte Person, Aufgabenstatus und das, was noch bestätigt werden muss. Außerdem können Sie über die Kalenderansicht alle Aufgaben sehen, die fällig sind und herausfinden, ob Ihr Team das Projekt rechtzeitig abliefern kann.

Verschiedene Farben kennzeichne die Priorität der Aufgaben. Rot bedeutet, dass die Priorität hoch ist, Sie sollten also einen wachsamen Blick auf diese Aufgaben werfen. Grau bedeutet, dass die Priorität niedrig ist, es könnte also in Ordnung sein, wenn der Termin um einige Tage verpasst wird. Und weil diese Dashboards anpassbar sind, können Sie sehen, wie viele Aufgaben Ihrem Team zugewiesen wurden, oder Filter verwenden, um die Aufgaben anzeigen zu lassen die für Sie am wichtigsten sind. Wenn Sie in der Kalenderansicht auf eine Aufgabe klicken, erhalten Sie die Aufgabendetails.

PS: Die Screenshots dienen nur als Beispiele. Wir wissen alle, dass in einem Launch mehr als 8 Aufgaben stecken.

JIRA Core hilft Produktmarketing-Teams dabei, alle Informationen an einem zentralen Ort zu sammeln

Szenario 2: Sie erhalten ein Statusupdate von Ihrem Teamkollegen.

Sie: „Wie sieht es mit den Webseiten aus?“

Mit JIRA Core werden Sie diese E-Mail nicht wirklich abschicken und in eine „FW: RE:“-Spirale rutschen. Sie können direkt zu JIRA Core gehen und dort alle Informationen abrufen, die Sie benötigen. Sie werden wissen, wer für welche Aufgabe verantwortlich ist und den Status, sowie alle abgegebenen Kommentare ansehen. Sie können außerdem alle Unteraufgaben-Abhängigkeiten sehen, um sicherzustellen, dass alle Aufgaben abgeschlossen sind. Zudem müssen Sie nicht nach der aktuellsten Datei suchen, sie befindet sich direkt an diesem Ort. Während der Abgabetermin näher rückt, wissen Sie stets, ob Ihr Team die Aufgabe (und die Unteraufgaben) rechtzeitig abzuliefern kann.

JIRA Core stellt die grundlegenden Informationen bereit, die Sie für Ihre Aufgabe benötigen und weil jeder Aufgabenbildschirm anpassbar ist, können Sie die dazugehörigen Informationen, die Ihr Team benötigt, zum Detailbereich hinzufügen. Sie können beispielsweise ein Feld für eine URL, ein Textfeld für einen Zielmarkt, oder eine Checkbox hinzufügen, mit dem sich das Produkt auswählen lässt, das zu dieser Aufgabe gehört. Sie können immer noch auf dem neusten Stand bleiben, indem Sie sich selbst als „Beobachter“ für die Aufgabe eintragen, damit Sie bei jedem Update benachrichtigt werden. Nun wird jedes Teammitglied immer auf dem neusten Stand sein, denn alle Projekt- und Aufgabeninformationen befinden sich an einem gemeinsamen Ort.

Checklisten in Ihrem Notizbuch – Nicht mehr nötig.
Updates per E-Mail – Nicht mehr nötig.
Meetings – Nun, größtenteils unnötig.

Jetzt müssen Sie nicht länger ins Schwitzen kommen, oder Ihre Teammitglieder stalken, um Updates zu erhalten, Sie können alle Informationen für Ihr Marketingprojekt in einem einzigen Tool organisieren, das speziell für Sie gemacht wurde – JIRA Core.

Unternehmen sind unabhängig von ihrer Größe auf Technologie angewiesen. Und das bedeutet, dass die kontinuierliche Verfügbarkeit von IT-Diensten sehr wichtig für den Geschäftsbetrieb ist – und das sowohl aus der Perspektive der Angestellten, als auch des Kunden und des Unternehmens selbst. Aber was passiert, wenn die Technologie einen (unausweichlichen) Fehler macht?

In größeren Unternehmen würde ein Angestellter den IT Help Desk kontaktieren, um das Problem zu melden und Überwachungstools würden Alarm schlagen, sollte etwas schief gehen. Das Help Desk-Team folgt dann den Praktiken des IT-Service Managements (ITSM), um das Problem zu erfassen, zu priorisieren und zu lösen. Sobald das Problem gelöst ist, wird die Lösung möglicherweise in einem Artikel in der Wissensdatenbank festgehalten und das Management wird Systemdaten verwenden, um Entscheidungen bezüglich der Help Desk-Tätigkeiten und möglichen Verbesserungen zu treffen.

Bei kleineren Unternehmen ist das IT-Support-Team möglicherweise weniger systematisiert, falls es überhaupt existiert. Manchmal ist „IT“ sogar eine Ad-hoc-Tätigkeit, die einfach an das Teammitglied mit der meisten „Computererfahrung“ vergeben wird. So oder so, das IT-Team eines kleinen Unternehmens jongliert ständig Anfragen und Probleme, während es versucht sein Bestes zu geben. Probleme könnten zum Beispiel auf folgende Weise behandelt werden:

• Bei der Bearbeitung von Problemen gilt, „wer zuerst kommt, mahlt zuerst“ und nicht die Notwendigkeit oder Priorität
• Sie werden mit Verspätung behandelt, oder gehen sogar verloren
• Die Probleme sind repetitiv, sollte ein anderer IT-Supportmitarbeiter sie bereits in der Vergangenheit gelöst haben

Oder vielleicht nutzt überhaupt niemand den IT-Support regelmäßig. Diese und andere Faktoren sind der Grund, warum größere Unternehmen in eine Help Desk-Software investieren, da so die Effizienz des IT-Supports gesteigert wird und vor allem die Nutzererfahrung für den Endnutzer verbessert wird. Und selbst wenn kleine Unternehmen ein weniger systematisiertes Supportteam besitzen, gibt es trotzdem gute Gründe, weshalb auch sie von einer Help Desk-Software profitieren würden.

1. Bieten Sie ein besseres Kundenerlebnis an

Help Desk-Software erlaubt es dem IT-Supportpersonal, einen professionelleren Service anzubieten und den Endnutzer und dessen IT-Verlauf besser zu verstehen. Es macht den Vorgang transparenter, sorgt für besseres Erwartungsmanagement und eine schnellere Lösung von Problemen.

2. Reduzieren Sie den Druck, indem Sie Self-Service anbieten

Simple IT-Probleme und Anfragen können mithilfe eines Endnutzer-Portals vom Endnutzer selbst gelöst werden. Endnutzer können auf FAQs und andere Selbsthilfe-Artikel zugreifen, Tickets erstellen, den Ticketstatus überprüfen, oder auf automatisierte Dienste zugreifen, wie beispielsweise das Zurücksetzen eines Passworts – all das ist über das Self-Service-Portal möglich.

3. Erreichen Sie mehr und erlangen Sie eine bessere Work-Life-Balance

Mit Help Desk-Software können Sie Probleme priorisieren, wodurch Zeit klüger investiert wird, oder automatisch gesteuerte Tickets einstellen, damit Anfragen direkt an den richtigen Supportmitarbeiter weitergeleitet werden. Indem Sie einen Workflow und eine Automatisierung erstellen, kann Ihr Supportpersonal mehrere Probleme gleichzeitig bearbeiten. Mobiler Zugriff sorgt außerdem dafür, dass Leute jederzeit Support erfragen und erhalten können, ganz egal ob sie gerade im Büro sind oder nicht.

4. Haben Sie alle erforderlichen Informationen stets zur Hand

Help Desk-Software bietet einen Einblick in die Assets, das Personal, die Software und vergangene Probleme, die an der aktuellen Aufgabe beteiligt sind. Außerdem können Artikel aus der Wissensdatenbank sowohl von den IT-Supportmitarbeitern, als auch den Endnutzern über das Self-Service-Portal genutzt werden. Dadurch, dass Sie diese Informationen stets zur Hand haben, sparen Sie nicht nur Zeit, sondern treffen bessere Entscheidungen und gelangen schneller zu einer Lösung des Problems.

5. Verwenden Sie Reports, um die Performance zu verbessern

Egal, ob Sie hierbei die Performance des IT-Supports verbessern – die durchschnittliche Zeit für die Lösungsfindung verkürzen, die erreichten Service-Level-Targets erhöhen – oder die IT-Serviceerbringung verbessern, die Berichts- und Analysefunktionen der Help Desk-Software kann wichtige Einblicke in vergangene Leistungen bieten, die zukünftige Entscheidungen, einschließlich Verbesserungsmöglichkeiten beeinflussen können. Diese Informationen können außerdem verwendet werden, um die Verbesserung des IT-Supports, und möglicherweise den Nutzen, gegenüber wichtigen Key-Stakeholdern zu demonstrieren. Help Desk-Software kann den IT-Support kleinerer Unternehmen verbessern, wo Endnutzer und der Geschäftsbetrieb so schnell wie möglich arbeiten – idealerweise wird außerdem ein großartiges Kundenerlebnis geboten.

Bei der Veröffentlichung von JIRA Service Desk im Jahr 2013 hatte Atlassian eine simple Vision: Einen modernen und flexiblen Service Desk für Techniksupport-Teams entwickeln. Anstatt seinen Kunden spezifische Support-Workflows vorzuschreiben, hat Atlassian das Produkt flexibel gestaltet. Über die letzten drei Jahre hinweg hat Atlassian beobachtet, wie JIRA Service Desk unter IT-, Kundendienst- und sogar Business-Teams, darunter Marketing und HR, immer beliebter wurde.

Der Wandel von IT hat die Anforderungen von Mitarbeitern und Kunden verändert und man sieht mehr und mehr JIRA Service Desk-Nutzer, die sowohl Ihren Kunden, als auch Ihren Angestellten Support anbieten. Die Angestellten wünschen sich mobile, Multi-Channel-Self-Service-Lösungen und wie sich herausstellt, wollen die Kunden das auch. Vorbei sind die Tage von getrennten Support-Teams für IT und Kundendienst.

In Anbetracht dieser Angleichung hat Atlassian stark in die Entwicklung von Features investiert, die für alle Teams vorteilhaft sein können. JIRA Service Desk kann nicht nur internen IT-, sondern auch externen Support-Teams helfen, einschließlich der Teams, die Kundenfeedback nutzen möchten, um die Produktentwicklung zu lenken.

Atlassian veröffentlicht nun mehrere neue Funktionen, die allen technischen Teams und insbesondere Kundendienst-Teams dabei helfen werden, großartigen externen Support anzubieten.

Kunden nach Unternehmen gruppieren

Viele Atlassian-Nutzer haben nach einem Weg gefragt, um Kunden zu gruppieren, um das Ansehen und Teilen von Anfragen zu erleichtern. Atlassian verkündete nun, dass JIRA Service Desk jetzt auch Organisationen unterstützt. Service-Teams können jetzt:

• Warteschlangen filtern: Sie können nun Ihre Warteschlangen abhängig von der Organisation durchsuchen, welche abgeschickt hat und dann Teammitglieder, die bereits mit den Bedürfnissen dieser Organisation vertraut sind mit der Bearbeitung beauftragen. Teams außerhalb des Service-Teams können nun auch die Warteschlangen beobachten, um zu sehen welche Issues am dringlichsten sind. Apropos dringliche Issues…
• Service Level Agreements (SLA) anpassen: Manche Unternehmen haben unterschiedliche Anforderungen, was SLAs angeht. Nun können Sie Ihre SLAs für jede einzelne Organisation anpassen, um Stress zu vermeiden und sicherzustellen, dass Sie nie einen wichtigen Abgabetermin verpassen.
• Berichte abrufen: Wenn ein Kunde oder ein Unternehmen sehen möchte, wie Ihr Service-Team ihnen hilft, können Sie jetzt Berichte zu einzelnen Unternehmen abfragen.
  Dieses Feature ist auch für Ihre Kunden nützlich. Sie können untereinander Anfragen ansehen und teilen, und sich für Benachrichtigungen anmelden.

E-Mails an Kunden personalisieren

Jetzt da Sie Ihre Kunden in ihre entsprechenden Unternehmen gruppiert haben, können Sie auch die E-Mails anpassen, die Sie an sie verschicken.

Sie können Designelemente zu Ihren E-Mail-Vorlagen hinzufügen, welche Ihre Unternehmensmarke widerspiegeln – beispielsweise Farben und Logos. Und um ein noch individuelleres Erlebnis zu kreieren, können Sie nun auch Regeln und Templates erstellen, die den Inhalt Ihrer Kunden-E-Mails personalisieren. Außerdem können Sie Zeitpläne und Regeln festlegen, um zu kontrollieren, wann und wie Ihre E-Mails verschickt werden, wodurch Sie Ihren Kunden eine großartige Erfahrung bieten können, ohne dass bei Ihnen ein zusätzlicher Arbeitsaufwand entsteht.

Agent Knowledge-Ansicht

JIRA Service Desk kann man ganz einfach in Confluence integrieren, um so eine Support-Wissensdatenbank zu erstellen, damit Endnutzer ihre Fragen zu bekannten und häufig auftretenden Problemen über das Service-Desk-Portal ganz einfach selbst beantworten können. Mit der Agent Knowledge-Ansicht werden Wissensartikel wie beispielsweise How-To-Guides oder Troubleshooting-Beiträge auf intelligente Weise und basierend auf dem Inhalt des Tickets an den empfohlenen Agenten weitergeleitet und in dessen Agentenkonsole angezeigt. Der Artikel kann vom Agenten angesehen werden während er das Ticket bearbeitet, wodurch ein Hin- und Herwechseln zwischen JIRA Service Desk und Confluence nicht mehr erforderlich ist.

Indem Sie Ihren Agenten die Antworten zur Verfügung stellen, können die Agenten schnellen und einfachen Support für Kundenfragen bereitstellen. Sollte es für die aktuelle Anfrage keinen Wissensartikel geben, kann der Agent ganz einfach einen solchen Artikel erstellen und per Knopfdruck mit dem Kunden teilen.

Atlassian hat Version 2.1 der JIRA-Erweiterung Portfolio for JIRA freigegeben. Wie immer haben die Australier die am höchsten bewerteten Feedbacks von Kunden umgesetzt. Planen wird mit Portfolio for JIRA 2.1 einfacher und leichter in JIRA Software zu verfolgen – dank automatisch synchronisierten Custom Fields, Labels und Komponenten. Mit nicht geschätzten Einträgen, Standard-Schätzungen und gemischten Schätzungen entsteht mehr Flexibilität. Es ist nun auch möglich, Berichte auf verschiedene Weisen mit allen Involvierten zu teilen.

Im Kontext planen

JIRA Software beinhaltet alle für die Planung und Entscheidungen relevanten Informationen Ihrer Teams. Setzt man auf Custom Fields um die Geschäftswerte eines Vorgangs zu verfolgen oder Labels und Komponenten um weitere Daten zu speichern, so müssen diese auch in Portfolio for JIRA zugänglich sein. Mit Version 2.1 ist dies der Fall: Von nun an
können Custom Fields, Labels und Komponenten direkt in Portfolio for JIRA editiert werden.

Es ist nun ebenfalls möglich, Portfolio-spezifische Felder wie Teams und Hierarchie-Ebenen direkt in JIRA Software-Vorgängen anzuzeigen. So können Sie nun Ihre Teamnamen direkt als Feld in JIRA Software synchronisieren; die in Portfolio zugewiesenen Teams werden nach JIRA Software über das neue „Team“-Feld zugänglich gemacht. Und falls Sie neue Hierarchie-Ebenen in Portfolio for JIRA erstellt haben, um das große Ganze zu sehen – so können Sie dieses nun direkt von JIRA Software aus anzeigen und durchforsten. Das Team-Feld und Hierarchie-Felder sind ebenfalls via JQL durchsuchbar.

Mehr Flexibilität in der Planung

Manchmal werden Pläne für weit in die Zukunft gemacht, sodass es fast unmöglich ist, zu wissen, wie viel Aufwand eine Aufgabe für ein Team bedeutet. In Portfolio for JIRA 2.1 kann man nun mit noch nicht geschätzten Arbeitspaketen planen. Die Arbeit kann trotzdem mit einem Release oder Sprint verknüpft und mit in die Planung aufgenommen werden.

Um eine Planung zu beginnen mag das nützlich sein, aber denken Sie daran: für eine realistische Vorhersage müssen Schätzungen sehr wahrscheinlich irgendwann hinzugefügt werden. Atlassian hat eine alte Funktion wieder eingeführt: Standard-Schätzungen können nun für Epics, Stories und individuelle Hierarchie-Ebenen wieder hinzugefügt werden. Dies kann dabei helfen, wenn man noch nicht bereit zum Schätzen ist, aber dennoch ein Gefühl für den zu erstellenden Plan benötigt.

Teams arbeiten unterschiedlich – und das ist okay so. Manche Teams schätzen vielleicht mit Zeit, andere wiederum mit Story Points – aber vielleicht benötigen Sie einen Plan, welcher beide Teams beinhaltet. Mit Portfolio for JIRA 2.1 können Sie gemischte Schätzungen in Planungen verwenden. Sie können mit einer Mischung aus Story Points und Zeit planen. Einfach die Umrechnungswerte für die Schätzungstypen angeben, damit Sie sowohl mit zeitbasierter und Story-Point-basierter Schätzung arbeiten können.

Alle auf dem Laufenden halten

Das nächste Mal, wenn Sie jemand nach einem Fortschrittsbericht oder „Wann X veröffentlicht wird“ fragt, können Sie einfach einen Bericht aus Portfolio for JIRA teilen. Berichte lassen sich auf zwei unterschiedlichen Wegen mit anderen teilen: Ein Nur-Lesen-Link für Stakeholder, die dann den Bericht mit allen Filtern und Einstellungen genau wie Sie sehen können, oder einen in einem IFrame einbettbaren Bericht. Atlassian hat auch einen neuen CSV-Export hinzugefügt, mit dem sich Scope- und Release-Berichte im CSV-Format herunterladen lassen.

Quellen & Links

• Atlassian Blog: Portfolio for JIRA 2.1
• Portfolio for JIRA 2.1 Release Notes