Kai Gottschalk – Atlassian Tipps und Tricks

Transparenz und Effizienz durch bessere Kollaboration

summit2015


Hinterlasse einen Kommentar

Die interessantesten Neuigkeiten vom Atlassian Summit 2015

Auch wenn ich in diesem Jahr nicht persönlich vor Ort in San Francisco beim Atlassian Summit 2015 dabei sein kann, möchte ich hier über die wichtigsten Neuerungen berichten. Dank der Livestreams und der Videoaufzeichnungen vieler Sessions gibt es viele Informationen zu den von Atlassian verkündete Neuigkeiten.

HipChat öffnet sich Entwicklern

Wie u.a. Techcrunch berichtet wird die Integration von HipChat in die Firmen-IT künftig deutlich über das Empfangen von Notifications hinausgehen. Über HipChat Connect ist es künftig möglich bidirektional mit anderen Anwendungen zu kommunizieren, diese also quasi in das HipChat Userinterface zu integrieren und aus HipChat Aktionen in diesen Anwendungen zu triggern. Andere Team Chat-Produkte, allen voraus Slack, begnügen sich überwiegend mit einer unidirektionalen Kommunikation.

Dies könnte künftig ein wichtiger Grund sein sich für HipChat zu entscheiden.

Update 26.11.2015:
Mit Convergely, Meekan und Tempo gibt es bereits die ersten vielversprechenden Integrationen für HipChat Connect.

Convergely ist hierbei eine einfache und leichtgewichtigte Integration von schnellen Umfragen in HipChat.

Meekan bzw. genauer gesagt der Meekan-Bot kann Teams dabei unterstützen gemeinsame, freie Slots in ihren Terminkalendern zu finden, und einen Termin zu buchen und Tempo für HipChat Connect bietet die Möglichkeit, einen vorher definierten Status (Urlaub, Krankeit, Reisetätigkeit) zu hinterlegen und diesen dann bei Abwesenheit an Chatpartner zu kommunizieren.

Mehr zu Convergely und Meekan findet ihr in dem Blogbeitrag von Atlassian, mehr zur Tempo-Integration in dem Blog von Tempo.

JIRA and Confluence go mobile

Ein häufig geäußerter Wunsch, wenn es um JIRA oder Confluence geht, ist die mobile Nutzung. Auf dem Weg zur Arbeit kurz einen Blick in das Produkt-Backlog werfen, den Status eines Issues ändern, oder einen kurzen Blick auf die Meeting-Notizen aus der letzten Woche werfen.

Ja, es gibt mobile Apps, aber zum einen ist deren Funktion momentan stark eingeschränkt und die Kosten für die brauchbaren Lösungen stehen meiner Meinung nach bislang nicht im Verhältnis zum Mehrwert.

Atlassian hat sich endlich dieser Herausforderung angenommen und launcht in Kürze native Apps sowohl für JIRA, als auch für Confluence. Zunächst wird dies für die Cloud-Versionen der beiden Tools geschehen und sich auf die iOS-Plattform beschränken. Ich hoffe, dass bald eine Android-Version und vor allem der Support für JIRA Server und Confluence Server folgt.

Interessierte können sich zeitlich begrenzt hier zum Beta-Test anmelden.

Performance, Performance, Performance

„Wer langsam ist, wird verlassen!“

Dieses Zitat stammt von einem ehemaligen Kollegen von mir und ist im Kontext auf Webanwendungen zu sehen. Schon Millisekunden Verzögerungen im Aufbau einer Website führen kurzfristig zu Unzufriedenheit und können langfristig der Grund sein, den Service oder das Tool zu wechseln.

Wohl genau deshalb fokussiert sich Atlassian bei sämtlichen Produkten, wie nie zuvor, auf Performance. Unter anderem am Beispiel von Confluence Cloud wurde gezeigt, dass in weniger als einem Jahr die Ladezeiten der Seiten um durchschnittlich 54% geringer liegen und die Anzahl der Confluence-Seiten, welche in unter einer Sekunde laden um 500% (!) zugenommen haben.

Kurznachrichten und weitere Eindrücke

summit2015


Hinterlasse einen Kommentar

Atlassian Summit 2015 – SMARTER. BETTER. FASTER. STRONGER.

In wenigen Tagen – genauer gesagt vom 3. bis zum 5. November findet in San Francisco DAS Ereignis des Jahres statt: Der Atlassian Summit 2015!

In den vergangenen drei Jahren hatte ich das große Vergnügen jeweils live vor Ort dabei zu sein. Ähnlich, wie bei anderen Ereignissen dieses Kalibers (Google IO, Apple WWDC) präsentiert Atlassian beim Summit jedes Jahr neue Produkte. 2013 wurden zum Beispiel JIRA Service Desk und Confluence Questions vorgestellt (hier geht es zu meinem Nachbericht des Summit 2013), im letzten Jahr war es u.a. JIRA Portfolio, welches den Teilnehmern erstmalig präsentiert wurde. Dieses Jahr werde ich leider nicht in San Francisco dabei sein, bin aber sehr gespannt, was Atlassian berichten wird.

Was ist der Atlassian Summit?

Der Summit birgt neben Produktneuheiten eine ganze Menge mehr. Dieses Jahr sind mehr als 2500 Atlassian-Kunden und Nutzer registriert. Sie werden vor Ort auf über 300 Produktgurus und -Verantwortliche treffen und in den drei Tagen aus 70 Sessions in sieben (!) Tracks die spannendsten Vorträge auswählen müssen. Die sieben Tracks unterscheiden sich diesmal inhaltlich, wie folgt: „Innovate, Plan, Build, Interact, Service, Scale und Enhance„. Es ist also für technisch Interessierte, Kollaborations-Experten, DevOps, Administratoren, IT-Entscheider, Projektmanager und Nutzer gleichermaßen etwas dabei.

Neben den 70 Vorträgen u.a. von Nutzern für Nutzer gibt es die Möglichkeit die Produktverantwortlichen von nahezu allen wichtigen Atlassian-Produkten zu sprechen, und Kontakt mit über 50 Plugin-Herstellern und Atlassian-Partnern aufzunehmen. Neben den Pausen zwischen den Tracks und den gemeinsamen Mahlzeiten eignet sich hierzu der Summit Bash, der traditionell am Ende des ersten richtigen Konferenztages stattfindet, vortrefflich.

summit2013jirastateoftheunion summit13foodtrucks

Hilfe, ich kann nicht dabei sein!

Da geht es Dir dieses Jahr leider, wie mir und man muss das Beste draus machen. Zum einen sollte man dem Twitter-Account von Atlassian folgen, dann gibt es über diverse Social Media-Kanäle natürlich noch weitere Möglichkeiten über sämtliche News informiert zu werden.

Die beste aller Möglichkeiten sind allerdings fünf Livestreams, der wichtigsten Vorträge. So wird neben der Keynote, auch noch jeweils die „kleine“ Keynote für die Produktreihen (IT, Software und Business) übertragen und natürlich der Fireside Chat, in welcher Mike und Scott (die Gründer und Co-CEOs von Atlassian) abseits von Produkt und Marketing im interessanten Interviewmodus über die Kultur, die Bedeutung und die Zukunft von Atlassian sprechen. Wer, wie ich, an diesen Sessions interessiert ist kann diese Live unter https://summit.atlassian.com/ verfolgen und zwar im Einzelnen, wie folgt:

CEO Fireside Chat: Cultivating Company Culturesummit2013keynote
04.11. 2:30 – 3:30 Uhr
Scott Farquhar and Mike Cannon-Brookes

Opening Keynote: Smarter, Better, Faster, Stronger Teams
04.11. 18:00 – 19:00 Uhr
Scott Farquhar and Mike Cannon-Brookes

Keynote: Atlassian for Software Teams
05.11. 1:15 – 2:00 Uhr
Eric Wittman, General Manager, Developer Tools

Keynote: Atlassian for IT Teams
05.11. 18:00 – 18:45 Uhr
Didier Moretti, General Manager, Confluence & JIRA Service Desk

Keynote: Atlassian for Business Teams
05.11. 18:50 – 19:35 Uhr
Bryan Rollins, General Manager, JIRA

Alle Zeiten sind MEZ, also kann es zum Teil ganz schön spät/früh werden. Und zum Schluß noch ein Tipp an alle, die schon länger zweifeln: Ja, der Atlassian Summit ist definitiv einen Besuch wert. Denn neben den ganzen genannten Argumenten, ist San Francisco eine sehenswerte und besondere Stadt. Zudem ist das Netzwerken mit den Experten vor Ort sehr wertvoll, es gibt interessante, teils schräge Messe-Stände und eine Menge Swag und Eindrücke. Ergo: Let’s go Summit!

01_panorama_by_tiago


Hinterlasse einen Kommentar

4. Treffen 2015 der Atlassian Usergroup Hamburg

a11bAm vergangenen Montag war es soweit. Das höchste jemals in Deutschland durchgeführte Atlassian Usergroup Treffen – zumindest soweit mir bekannt – fand hier in Hamburg statt.

Das Höchste? Ja, wir waren dieses Mal mit einer wirklich atemberaubenden Aussicht gesegnet, denn zu unserem vierten Treffen im Jahr 2015 konnten wir freundlicherweise Smaato als tollen Gastgeber gewinnen.

„Was für eine Aussicht!“

Smaato sitzt zentral in Hamburg (am Valentinskamp) im 23-geschössigen, knapp 100 Meter hohen Emporio-Haus. Auch wenn die 19. Etage zunächst nicht sonderlich hoch klingt, muss man – gerade als gebürtiger Hamburger, wie ich – schon staunen, wenn man einen solchen Blick über die Alster, das Hamburger Zentrum und die vermeintlich kleine Elbphilharmonie genießen kann.

So kamen dann zu dem Treffen etwa 35 JIRA-Experten, Confluence-Enthusiasten und Kollaborations-Freunde, welche von der beeindruckenden Aussicht begeistert waren. Neben der tollen Aussicht dankt die AUG Hamburg Smaato herzlich für die umfangreiche und schmackhafte Versorgung mit Bagels, Obst, Kuchen und Getränken.

a05a07

 

Nachdem Nils den Abend mit ein paar einleitenden Worten eröffnet hatte, ging es unmittelbar mit dem ersten Vortrag los. Julian Radünz von der comosoft GmbH präsentierte seinen Vortrag

„The All-in-One-Solution: Issue Tracking and User Helpdesk in JIRA“,

welche bei comosoft zur Anwendung kommt.

a04 a09

 

Seit einiger Zeit unterstützt Atlassian Firmen mit ähnlichen Anforderungen, wie sie comosoft seit längerem hat mit JIRA Service Desk. Mit JIRA Service Desk können klassische Helpdesk-Szenarien in JIRA sehr gut abgebildet werden.

Exkurs: Helpdesk Szenarien in der Pre-Service Desk – Ära

Diejenigen JIRA-Administratoren unter uns, die vor dem Launch von Service Desk vor der Herausforderung standen Helpdesk-Szenarien mit Hilfe von JIRA zu lösen, wissen, dass dies auf verschiedenste Art und Weisen mit einer Menge manueller Arbeit (z.B. JEMH, Exocet, Groovy Scripts, etc.) bereits vor einigen Jahren möglich war.

Ist dies komfortabel? Nun ja, wenn es einmal läuft und man die Lösung kennt ist es komfortabel und flexibel. Der Weg bis dahin ist zwar manchmal steinig, aber diejenigen, die den manuellen Weg „gegangen“ sind, haben eine flexible Lösung, die Ihre Anforderungen abdeckt und mit verhältnismäßig wenig Aufwand „mitwachsen“ kann. Nebeneffekt hiervon sind eine Menge Kenntnisse in der fortgeschrittenen Administration von JIRA.

Warum dieser Exkurs? Weil die von Julian auf eine sehr angenehme norddeutsche Art und Weise vorgestellte Lösung aus einer Zeit stammt, in der es eben noch kein JIRA Service Desk gab. Es wurde eine technisch ausgefeilte Lösung präsentiert, bei der die technisch versierten Anwesenden ganz besonders neugierig wurden.

Daher fand ich es auch ganz besonders toll, dass Julian gegen Ende seines Vortrags auf die jeweiligen Stärken (und Schwächen) der beiden Lösungen: „JIRA Service Desk“ vs. „(seine) manuelle Lösung“ eingegangen ist. Die folgende Q&A-Session zeigte dann auch das Interesse der anwesenden Teilnehmer für dieses Thema.

Ein Wiki als Dreh- und Angelpunkt des Unternehmens

Im Anschluss hieran – nach einer kurzen Pause – übernahmen Inga Koreng und Sarah Bär vom Atlassian Platinum Expert //SEIBERT/MEDIA die Bühne und berichteten über die Einführung eines Social Intranet auf Basis von Confluence bei DER Touristik. Die vorgestellte Lösung hat quasi als Unterbau Confluence und HipChat, sowie eine ganze Reihe weiterer Add-Ons, welche zum Großteil von //SEIBERT/MEDIA selber entwickelt werden. Die Summe aus allem heißt dann „Linchpin“, was in etwa mit „Dreh- und Angelpunkt“ zu übersetzen ist. Und eben dieser Dreh- und Angelpunkt sollte ein gutes Intranet für die Mitarbeiter einer Firma sein.

a10

Spannend könnte Linchpin insbesondere für diejenigen Firmen sein, welche an verschiedenen Standorten arbeiten und neben dem klassischen Wiki-Prinzip (oft Bottom-Up), auch eine effektive Top-Down-Kommunikation realisieren möchten. So wunderte es dann auch nicht, dass die Kolleginnen von //SEIBERT/MEDIA zu berichten wussten, dass der Auftraggeber bei DER Touristik die Abteilung „Interne Kommunikation“ war.

Wer jetzt Interesse bekommen hat, dem kann ich nur wärmstens das obige kurze Video zu Linchpin empfehlen. Bei Fragen könnt ihr Euch jederzeit an //SEIBERT/MEDIA wenden. Bei Bedarf stelle ich auch gerne den Kontakt her.

One more thing…

Vielleicht für den einen oder anderen Interessierten noch die folgende Information:

Momentan arbeitet //SEIBERT/MEDIA daran eine Dokumentation zusammenzustellen, in welcher ein Weg beschrieben ist, wie man – sofern die einzelnen Produkte (Confluence und HipChat) schon vorliegen und man manuelle Arbeit nicht scheut – eine Art „Linchpin – (do it) yourself“-Lösung mit verhältnismäßig geringen Kosten auf die Beine stellt.

Wir Organisatoren der Hamburger Atlassian User Group (#AUGHH) haben uns an diesem Abend ganz besonders über das zahlreiche positive Feedback, sowie die fachlichen Diskussionen zum Ende des Abends gefreut.

Ganz nebenbei wurden natürlich auch aktuelle Themen, wie JIRA 7, der Atlassian Summit 2015 (wer aus der AUGHH noch ermäßigte Karten benötigt, meldet sich gerne bei mir), sowie ein möglicher IPO von Atlassian diskutiert.

Wie man sieht: Eine Menge Gründe beim nächsten Mal dabei zu sein. Wir freuen uns schon jetzt!


3 Kommentare

Evaluiere frühzeitig nützliche JIRA Add-ons

Nachfolgend möchte ich eine Übersicht über wichtige JIRA Add-ons geben, mit welchen ich allesamt sehr gute Erfahrungen gemacht habe.

Das Ökosystem um JIRA ist in den letzten Jahren – insbesondere seit der Einführung des Atlassian Marketplace in 2012 – immens gewachsen und bei der Vielzahl an verfügbaren Add-ons muss man zunächst einen Überblick bekommen und dann eine für sich optimale Lösung finden.00marketplace

Dabei ist neben den Kosten, dem Nutzen und der Nutzbarkeit („Usability“) auch der Punkt „Wartbarkeit und Upgrade-Kompatibilität“ immens wichtig. Was hilft es die schönsten und exotischsten Add-ons zu installieren, wenn man dann monatelang nicht auf eine neue JIRA-Version wechseln kann, weil das mittlerweile unverzichtbar gewordene Add-on einfach nicht kompatibel mit der aktuellen JIRA-Version ist?

Ich habe unten eine Liste von zehn JIRA Add-ons erstellt, die in den Gesichtspunkten:

Kosten/Nutzen (7 x kostenflichtig / 3 x kostenlos)

Usability, und

Wartbarkeit

meiner subjektiven Meinung nach deutlich überdurchschnittlich abschneiden. Die Liste erhebt keinerlei Anspruch auf Vollständigkeit und ich würde ich freuen, wenn ich von JIRA-Experten oder -Anfängern Vorschläge und Tipps zu weiteren Kandidaten bekommen würde (gerne per Mail oder als Kommentar)

1. JIRA Agile – früher Greenhopper (kostenpflichtig)

01jiraagileEigentlich kein Add-on im engeren Sinne – eher ein eigenes Produkt bzw. ein UI, welches sich nahezu nahtlos über die JIRA-Datenbank legt und ein sehr komfortables Planen, Priorisieren und Verfolgen des Fortschritts einzelner Tasks bzw. des Gesamten Backlogs ermöglicht.

In meinen Augen fehlt JIRA ohne JIRA Agile mindestens die Hälfte seiner Kraft/Möglichkeiten und daher gehört es in jede gute JIRA-Installation. Auch wenn es immer wieder im Kontext mit agilem Projektmanagement –  SCRUM und Kanban – genannt wird, assistiert JIRA Agile auch bei klassischen Projekten oder (einfachen) Abteilungs-Arbeitsabläufen erstklassig.

2. JIRA Suite Utilities (kostenlos)

02jsuJIRA ist ohne Erweiterungen schon sehr konfigurierbar. Dennoch bietet das Add-on JIRA Suite Utilities (JSU) eine Vielzahl sinnvoller Custom Field-Typen, und Workflow-Erweiterungen (Bedingungen, Validatoren und Post-Functions), ohne welche es meist nicht möglich ist spezielle Workflow-Anforderungen von Stakeholdern abzubilden.

Die Anzahl der abgedeckten Anwendungsfälle ist schier unendlich, weshalb ich interessierten Administratoren nur empfehlen kann sich in der Dokumentation des Add-ons Anregungen zu holen

3. JIRA Misc Workflow Extensions (kostenpflichtig)

03jmweÄhnlich, wie das JSU Add-on, bieten auch die JIRA Misc Workflow Extensions (JMWE) eine große Anzahl unterschiedlicher Erweiterungen bei den Workflow-Bedingungen, Validatoren und Postfunctions.

Beispielsweise kann eine Transition durch die „Previous Status“-Condition in Abhängigkeit von vorherigen Transitionen angezeigt werden. Werte können zwischen Issue und Subtask (auch umgekehrt) und verlinkten Vorgängen automatisch innerhalb von Transitionen umher kopiert werden und dergleichen mehr. Die JMWE haben in den letzten Jahren den Schwenk von einem kostenfreien zu einem kostenpflichtigen Add-on vollzogen. Im Gegenzug gibt es aber seitens des Herstellers Innovalog einen hervorragenden und schnellen Service bei Fragen oder potenziellen Bugs.

Wichtig: Da es beim JSU und JMWE Add-on jeweils einige Überschneidungen gibt, empfehle ich den IST-Bedarf an Funktionen exakt festzustellen und dann abzuwägen, welches der beiden Add-ons das jeweils Geeignetere ist.

4. ScriptRunner a.k.a Groovyrunner (kostenpflichtig)

04scriptrunnerMit JIRA und den o.g. Add-ons lässt sich schon sehr viel anstellen. „Leider“ sind unsere Kunden in Ihren Anforderungen manchmal sehr kreativ und denken sich noch exotischere Anforderungen aus, als sie mit all diesen Mitteln abzudecken wären.

Auch dafür gibt es eine Lösung: Den ScriptRunner von Jamie Echlin. Bis vor einiger Zeit wurde „nur“ Groovy unterstützt, nun auch Python (jython), Ruby (JRuby), JavaScript, etc.

Mittels des ScriptRunners kann man z.B. direkt über die grafische Oberfläche von JIRA aus dem Admin-Bereich Scripts aufrufen, welche Issues beeinflussen (also spezifizierte Werte von gewissen Vorgängen modifizieren).

Zudem lassen sich innerhalb von JIRA-Workflows über Conditions, Valdidations und Postfunctions serverseitig hinterlegte Scripts ausführen und auf diese Weise z.B. über bedingte Funktionen die ohnehin schon vielfältigen Steuerungsmöglichkeiten der Workflows weiter immens steigern.

Erwähnenswert sind zudem die bereits eingebauten Scripts – man kann auf Knopfdruck ganze JIRA-Projekte klonen (mit oder ohne Inhalt), oder jeder andere User werden (ähnlich dem SU Add-on, und zeitweise nützlich, wenn es um das Reproduzieren gewisser Fehler, oder Verhaltensweisen geht).

Abgerundet wird das Ganze durch eine signifikante Erweiterung der sogenannten „Erweiterten Suche“ (advanced search) durch scripted JQL.

Spätestens nun – Kenntnisse in einer der oben genannten Sprachen, sowie entsprechende Kreativität vorausgesetzt – sind den Möglichkeiten von JIRA nahezu keine Grenzen gesetzt. Man merkt wahrscheinlich, dass ich bekennender Fan dieses tollen Add-ons bin, aber bei aller Euphorie dürfen zwei Dinge nicht unerwähnt bleiben:

  1. Mit den Scripts kann man auch eine Menge Dinge machen, die sonst über die Oberfläche von JIRA nicht möglich sind. Vorgänge können nicht existierenden Nutzern zugeordnet werden, oder haben (beispielsweise durch einen Typo) nicht definierte Status erreicht. Ich kann daher nur explizit dazu raten immer zuerst auf dem (hoffentlich vorhandenen) Testsystem ausgiebig zu testen.
  2. Der ScriptRunner alleine reduziert die Performance einer JIRA Instanz, genauso wenig, wie der Einsatz von Scripts. Unsauber geschriebene Scripts, suboptimale JQL-Abfragen, oder kalkulierte/gescriptete Felder können hingegen für eine Minderung der (Gesamt-) Performance verantwortlich sein (vergleiche hierzu auch diesen Thread). Es gilt – wie bei allem – man sollte sehr gut wissen, was man tut.

 

Update: Bis September 2015 (und zur Version 3.x) war der ScriptRunner kostenlos. Ab der Version 4.x ist dieses tolle Add-On kostenpflichtig geworden.

5. JIRA Enterprise Mailhandler (kostenpflichtig)

05jemhAls ich den JIRA Enterprise Mail Handler (JEMH) zum ersten Mal installiert und evaluiert habe, war ich aufgrund der Komplexität der einzelnen Konfigurationsmöglichkeiten ehrlich gesagt abgeschreckt. Es gibt eine Vielzahl von Menüs und Untermenüs. Dies geht bis in die vierte Ebene hinunter und ich bin mir bis heute nicht sicher, ob es nicht auch irgendwo eine fünfte Unterebene gibt.

Die Komplexität, welche sich meiner Meinung nach negativ auf die Usability auswirkt ist aber zugleich auch die Stärke des JEMH:

Man kann schon mit der blanken JIRA-Installation JIRA-Vorgänge per Mail erstellen lassen und hat bereits ein paar Möglichkeiten. Spätestens, wenn man aufgrund des Mailinhalts bestimmt Parameter (Projekt, Komponente, Labels, Assignee, etc.) automatisch setzen möchte stößt man jedoch schnell an Grenzen. Genauso verhält es sich mit dem Anlegen und effektiven zurückverfolgen von Vorgängen per Mail von Nutzern, die – zum Beispiel aus Lizenzgründen – keinen eigenen JIRA-Login besitzen. Auch hier kann der JIRA Enterprise Mail Handler die Möglichkeiten von JIRA erweitern. Kurz gesagt gibt es kaum Anwendungsfälle, sowohl eingehend, als auch ausgehend (einfache Template-Bearbeitung, zu versendende Anhänge, etc.), welche in Bezug auf das Mailhandling nicht abgedeckt werden. Der JEMH macht seinem Namen also alle Ehre.

6. Structure Plugin (kostenpflichtig)

06structureVon Haus aus kommt JIRA mit zwei Hierarchie-Ebenen bei  Vorgängen: Parent und Child(task). Wer etwas mehr benötigt, kann dies mit dem Structure-Plugin abbilden.

Theoretisch lassen sich beliebig viele Hierarchie-Ebenen einziehen. So kann man die vorhandenen Issues pro Projekt dann in entsprechende Ebenen bringen und (ausgewählten) Nutzern  so visuell Abhängigkeiten untereinander besser aufzeigen. Kompatibel mit JIRA Agile und den nativen JIRA-Links. Mein Bekannter Jörg Spiegelhoff von Codecentric ist in einem älteren Blog-Beitrag näher auf die Details des Structure-Plugins eingegangen.

7. JIRA Automation Plugin (kostenlos)

07automationDas JIRA Automation Plugin stammt von Atlassian direkt, wird dort auch sehr intensiv eingesetzt und ist offiziell nicht supported. Es gibt in JIRA immer wieder Momente, in denen man auf eine bestimmte Gruppe von Vorgängen eine gewisse Aktion ausführen möchte.

Beispiele gefällig?

– Vorgänge, welche möglicherweise drei Wochen potenziell gelöst und ohne Feedback sind, sollen final geschlossen werden.

– Vorgänge in Status „X“ sollen nach einer Woche ohne Update mit einem Kommentar versehen werden.

– In Vorgängen eines Supportprojekt, welche von eine bestimmten Personenkreis erstellt wurden, soll nach einem Zeitraum X ohne Reaktion die Priorität von „hoch“ zu „blocker“ geändert werden (was wiederum eine Mail an bestimmt Support-Engineers triggert, etc.

Dies alles sind Anwendungsfälle, welche z.B mit Jelly-Scripts (bis JIRA 6.3), oder dem o.g. ScriptRunner abgebildet werden können. Hierzu sind aber Script-Kenntnisse, eine entsprechende Testumgebung und teilweise eine Menge Geduld notwendig. Mit dem Automation Plugin lassen sich alle diese Fälle (und sehr viele weitere ebenfalls abbilden). Es lohnt sich also bei entsprechenden Anforderungen definitiv einen Blick auf dieses Add-on zu werfen.

8. eazyBI für JIRA (kostenpflichtig)

08eazybiNicht selten werden im Rahmen von Neuinstallationen und –Konfigurationen Fragen nach der Messbarkeit von Durchlaufzeiten (pro Projekt/Komponente, etc.) gestellt. Andere Fragen betreffen einen Drilldown über einen gewisse Datenbestände.

JIRA bietet ein solides und teilweise gutes Basis-Reporting, wenn es um den Ist-Zustand geht. Wenn es um „besondere“ Anforderung in Bezug auf das Reporting geht, sind die Bordmittel von JIRA ziemlich beschränkt. Dies liegt in erster Linie daran, dass JIRA ursprünglich für die Softwareentwicklung und nicht für den Enterprise-Einsatz angedacht war. Auch wenn sich im Laufe der Jahre Vieles geändert hat, so gehört ein tiefergehendes Reporting nicht zu den Stärken von JIRA. Man kann mit einigen Kniffen das solide Basis-Reporting etwas erweitern, gerät dann aber doch recht schnell an die Grenzen.

Diese Tatsache hat sich die Firma EazyOne aus Lettland zunutze gemacht. Vor einigen Jahren haben die Entwickler des Add-ons eazyBI zum einen die „Lücke“ in JIRA und zum anderen den kundenseitigen Bedarf erkannt und eben dieses Plugin entwickelt und bis heute in weit über 1000 Instanzen weltweit im Einsatz. Wenn es also um spezifische Anforderungen in Bezug auf Charts und Reports geht, führt kein Weg an eazyBI vorbei. Ich rate – nicht zuletzt aufgrund der Kosten – immer dazu genau zu prüfen, welche Anforderungen wirklich notwendig sind, und welche ggf. auch mit ein wenig Mehraufwand (workarounds) mit Bordmitteln umsetzbar sind.

9. Agile Cards for JIRA (kostenpflichtig)

09agilecardsUnzählige Diskussionen habe ich – auch bei meinen Einsätzen als JIRA-Consultant – schon zum Thema “haptische Boards vs. digitale Boards (in JIRA)“ geführt. Mein derzeitiger Stand hierzu: Es gibt kein richtig und kein falsch. Die Situation ist vielschichtig und komplex und hängt von vielen Faktoren ab (Team-Allokation, Zielsetzung, Nutzung in verschiedenen Situationen, persönliche Präferenzen).

Ich kann Verfechter beider Varianten verstehen und im Prinzip geht es meist darum die „Schmerzen“ eines Medienbruchs möglichst erträglich zu machen. Genau hier setzt das Add-on Agile Cards for JIRA des polnischen Softwareentwicklers Spartez an: Mit Hilfe des Agile Cards – Add-ons lassen sich JIRA-Issues optisch ansprechend als Karten für die Scrum-Wall oder das Kanban-Board ausdrucken. Hierbei liegt der Schwerpunkt auf einer kompletten Gestaltung was auf den jeweiligen Karten angezeigt werden soll. Diese Templates lassen sich zum einen Global und dann – bei Bedarf – auch pro Projekt konfigurieren, sodass im Prinzip jedes Team/Projekt (s)ein eigenes Layout haben kann. Ich kenne aus der Praxis Teams, die derartige Herausforderungen eine Weile mit Hilfe von Greasemonkey-Scripts in Firefox gelöst haben, dann aber spätestens nach jedem JIRA-Update wieder eine Menge Arbeit in die Anpassungen stecken mussten. Für derartige Fälle ist die es also eine klare und rationale „make or buy“-Entscheidung.

10. JIRA Syntax Highlighter Plugin (kostenlos)

10syntaxhighlighterSchließen möchte ich diesen Artikel mit einem kleinen, aber feinen Add-on, mit welchem man den Entwicklern unter den JIRA-Nutzern eine große Freude bereiten kann: Dem JIRA Syntax Highlighter Plugin.

In JIRA gibt es von Haus aus die Möglichkeit Code in sogenannten Code-Blöcken lesbarer zu gestalten. Man kann größere Code-Snipplets in einem Codeblock deutlich besser lesen.

Dies hat dem Entwickler des Syntax Highlighter Add-ons offenbar noch nicht ganz ausgereicht. Je nach verwendeter Programmiersprache werden Befehle innerhalb eines Codeblocks nach der Installation des Add-ons in der typischen Farbe dargestellt bzw. eben ge-highlighted. Unterstützt werden hierbei u.a. Java, Ruby, PHP, Perl, Python, JavaScript, C#, C++, SQL, XML, HTML, CSS und weitere.

Die Liste ist natürlich nicht vollständig und ich freue mich immer über Ergänzungen, Anregungen und Kommentare (gerne unterhalb des Artikels, oder per Mail).

Weitere Tipps gibt es in meinem übergeordneten Beitrag Zehn wertvolle Tipps für JIRA – Administratoren.


Ein Kommentar

Nutze sprechende Namen bei Filtern in JIRA

JIRA nametagAus meiner Blog-Serie „Zehn wertvolle Tipps für JIRA-Administratoren“ möchte ich mich heute dem Thema „Filter in JIRA“ widmen.

JIRA bietet nicht nur die Möglichkeit wiederkehrende Suchen als Filter abzuspeichern. Vielmehr kann man eine Reihe nützlicher Anwendungsfälle mit diesen Filtern abdecken.

So kann man:

  • sich die Suchergebnisse in regelmäßigen Intervallen per Email zusenden lassen („Subscriptions“)
  • seine Filter in Dashboard Gadgets einbauen (warum man dies tun sollte)
  • den Inhalt seiner Filter exportieren (RSS, CSV, etc.), um ihn dann in anderen Tools zu verwenden, und
  • seine Filter mit anderen Nutzern teilen

Gerade die letzte Funktion bietet eine ungeahnte Vielfalt an Möglichkeiten, weshalb es sich häufig anbietet für die Anwender Filter und Dashboards anzulegen um Duplikate und verwaiste Filter zu vermeiden.

Hier kann ich aus Erfahrung dazu raten frühzeitig die Filter mit technischen Nutzern (entweder Global, oder jeweils auf Projekt-Ebene) zu erstellen.

Exkurs: Technische Nutzer in JIRA

Ich möchte hierbei hervorheben, dass ich kein Freund von entpersonalisierten operativen Usern bin, welche anonym Issues bearbeiten. Häufig erlebe ich in meinen Einsätzen als JIRA-Consultant Situationen, in welchen Unternehmen gerne Lizenzen „sparen“ möchten, indem sie z.B. Kunden einen „Sammeluser“ erstellen. Dies ist aus wirtschaftlichen Gründen durchaus nachvollziehbar, hat aber mindestens zwei negative Seiteneffekte:

  1. Die Transparenz, wer einen Vorgang erstellt, oder kommentiert hat, bzw. wer die Freigabe für einen Auftrag (via JIRA) erteilt hat, leidet im Zweifel stark. Ein eindeutiger Ansprechpartner fehlt im Zweifel.
  2. Thema Sicherheit: Teilen sich bei 3 Kunden jeweils zehn Mitarbeiter die Logins (man „spart“ also 27 Lizenzen), und ein Mitarbeiter des Kunden verlässt den Kunden, muss man als Administrator dies zum einen mitbekommen und zum anderen mit einer Änderung des Passworts hierauf reagieren.

Es gibt sehr gute und kostengünstige Möglichkeiten hier z.B. mit Hilfe von JIRA Servicedesk das Beste aus beiden Lösungen zu kombinieren. Sprechen Sie mich gerne an!

Zurück zum Thema

Auch wenn ich aus oben genannten Gründen operativen technischen Nutzern eher ablehnend begegne, können technische Nutzer generell einen Mehrwert bieten. Gerade in Projekten mit vielen geteilten Objekten (Filtern, Dashboards und ggf. Rapid Boards), macht es manchmal Sinn, dass diese von mehr als nur einem Kollegen gepflegt und aktualisiert werden. Spätestens dann macht der Einsatz eines technischen „Teamnutzers“ Sinn, da über den geteilten Account (=Besitzer der Items)  in Abwesenheit eines Kollegen das Dashboard umkonfiguriert, der Filter angepasst, und auch das Rapid Board optimiert werden kann.

Eine weitere Alternative oder gegebenenfalls sinnvolle Ergänzung kann auch das JIRA Filter Distribution-Plugin sein, welches einmal angelegte Filter bestimmter Nutzer oder Gruppen auf Knopfdruck mit allen Nutzern teilt (via push in die Favoriten), die den jeweiligen Filter sehen dürfen. Dies hilft dabei technisch weniger versierten Nutzern (nicht jeder Nutzer ist ein JIRA-Experte!) den Zugang zu relevanten Filtern zu vereinfachen.

Unabhängig davon, welchen Weg man nimmt, wichtig ist es klare und sprechende Namen zu verwenden. Dies erleichtert einem selber, wie auch allen anderen Nutzern die Auffindbarkeit und erhöht somit die Akzeptanz von JIRA ungemein.

Der Name eines Filters sollte also weniger „Wichtige neue Bugs Projekt A“, sondern eher „Projekt A: Bugs ohne Lösung, erstellt binnen der letzten 2 Stunden (Prio ‚hoch‘+)“ lauten. Für technische Nutzer mit (potenziell) sehr vielen Filtern kann es zudem sinnvoll sein diese nach einem (z.B. vierstelligen) Zifferncode zu ordnen. Dies könnte in etwa so aussehen:

„0800 Projekt A: Bugs ohne Lösung, erstellt binnen der letzten 2 Stunden (Prio ‚hoch‘+)“

Es geht hierbei weniger darum eine exakte Wissenschaft daraus zu machen, als sich frühzeitig Gedanken zu machen, in welche Richtung die Reise der JIRA-Installation gehen könnte.

Weitere Tipps gibt es in meinem übergeordneten Beitrag Zehn wertvolle JIRA Tipps für Administratoren.


Hinterlasse einen Kommentar

2. Treffen 2015 der Atlassian Usergroup Hamburg

An dieser Stelle möchte ich wie gewohnt das zweite Treffen 2015 der Atlassian Usergroup in Hamburg (#AUGHH) zusammenfassen.

nametagatlassianbackpackswag

 

 

 

goodgamelogoAm 22. Juni ab 18.oo Uhr hatten wir zu unserem Gastgeber Goodgame Studios in Hamburg-Bahrenfeld geladen und knapp 50 Kollaborations-Enthusiasten, JIRA-Experten, Confluence-Profis, und Development-Tool-Ninjas folgten dem Ruf.

Nachdem uns Sebastian Frank, Head of Production bei Goodgame Studio freundlich begrüßt und das reichhaltige Bagel-Büfett eröffnet svenpetershatte, somit also für das leibliche Wohl bestens gesorgt war, sind wir mit einem kurzen, exklusiven Video von Sven Peters – dem deutschen Atlassian Evangelisten – in den Abend gestartet. Themen von Sven waren u.a. der neue Release Hub in JIRA 6.4, sowie das Atlas Camp 2015 in Prag.

Direkt danach ging es mit dem ersten Vortrag los: Anke Schaffrek von Bauer Excel Media beschrieb in Ihrem Vortrag „Mit JIRA und JIRA Agile den Wandel begleiten„, wie der geschickte Einsatz von JIRA Agile die Reorganisation von Team-Strukturen und Arbeitsmethoden bei Bauer Excel Media begleitet, und sich mit relativ einfachen Mitteln neue Organisationstrukturen und Prozesse abbilden lassen.

 

complexworkflow takingpictureankeschaffrek

 

 

 

Die Referentin berichtete hierbei über den Weg der Einführung von JIRA, über komplexe und sehr spezifische Workflows, eine Simplifizierung selbiger, bis hin zum „Jetzt“, wo es einen generischen Workflow für die Entwicklungsteams gibt. Die Besonderheit ist in diesem Fall die Art und Weise, wie verschiedene Boards für unterschiedliche Schritte der Entwicklung als Schicht über den einen Workflow gelegt werden. Somit schafft es die „Produktion“ allen Stakeholdern (Business Ownern, Product Ownern, sowie den Teams) gerecht zu werden und die benötigte Transparenz über Fortschritte zu generieren.

Die nachfolgende Diskussion der Teilnehmer bis hin zum Thema „Haptische Boards vs. Digitale Boards“ zeigte meiner Meinung sehr gut, inwiefern das Thema den Nerv der Gruppe getroffen hat.

Nach einer kurzen Pause ging es dann mit dem Vortrag „Add-Ons for JIRA“ von Dr. Raimar Falke im Namen der Codecentric AG weiter.

Besonders interessant – insbesondere für die nicht so technisch versierten Teilnehmer – war die Einleitung über verschiedene Customization Level in JIRA:

  • Level 0 – „As downloaded“(Arbeiten mit Standard-Elementen)
  • Level 1 – „Out of the box“ (Erste Anpassungen und Individualisierungen von Workflows)
  • Level 2 – “Marketplace to the rescue” (Erste Schritte mit Add-Ons aus dem Atlassian Marketplace)
  • Level 3 – “Code” (Javascript und/oder Groovy warden eingesetzt)
  • Level 4 – „Custom Add-Ons“ (Benötigte Funktionalität wird in einem eigenen Add-On gebündelt)

Ich denke jeder erfahrene JIRA-Administrator ist bewusst oder unbewusst diesen Weg, oder zumindest einen Teil hiervon gegangen. Schön war es, dass der Referent sowohl auf die Vorteile, als auch auf mögliche Nachteile der Add-On-Entwicklung eingegangen ist und so kein eindimensionales Bild gezeichnet hat.

Die anschließende Diskussion zum Thema „make or buy“ bei Custom Add-Ons wurde dann auch gleich als Auftakt für den Ausklang des Abends genutzt. So konnten in kleineren Gruppen bei einem Getränk die jeweils interessantesten Themen noch einmal von verschiedensten Standpunkten aus diskutiert werden.

_DSC8947_DSC8913 _DSC8945

 

 

 

Was mich an diesem Abend besonders gefreut hat:

  • Das tolle Ambiente inklusive Catering (nochmals vielen Dank an Goodgame Studio!);
  • Vorträge, die – so zumindest das Feedback – die Gruppe interessiert haben;
  • Die Vielzahl der Diskussionen zu unterschiedlichsten Themen;
  • Die Tatsache, dass unserem Aufruf nach Vorträgen aus der Community bislang drei (!) potentielle Vorträge entsprungen sind. Das freut uns sehr und sorgt dafür die nächsten Termine zeitnah zu planen!
  • Plugin = Add-On = OSGi-Bundle🙂

Als nächstes haben wir, ich hatte es in dem einen oder anderen Gespräch bereits kurz angerissen, ein AUG Hamburg-Treffen der etwas anderen Art geplant. Wir werden Euch in Kürze in der AUG Hamburg Gruppe auf XING informieren. Bis zum nächsten Mal – Wir freuen uns!

PS: Ein herzliches Danke an den Fotografen von Goodgame, welcher uns freundlicherweise die Bilder zur Verfügung gestellt hat!


2 Kommentare

Verkaufe JIRA über smarte Dashboards

Nachdem ich vor einigen Jahren auf dem Communardo Community Day (CCD) eine interessante Präsentation zu dem im Titel erwähnten Thema erlebt habe, konnte ich mit schöner Regelmäßigkeit in verschiedensten Situationen feststellen, welche Auswirkungen der clevere Einsatz von gut gemachten Dashboards auf JIRA-Nutzer hat.

Die Herausforderung

Wie bereits an anderer Stelle erwähnt, wird JIRA von Nutzern häufig als komplex und unübersichtlich wahrgenommen. Oft erschließt sich – gerade den nicht technischen Anwendern oder Teams – der ernorme Nutzen JIRAs nicht auf den ersten Blick.

JIRA Datenbank

JIRA besitzt eine unglaublich mächtige Datenbank. Die Herausforderung ist an die relevanten Daten heranzukommen und sie zielgruppengerecht aufzubereiten

Neben der sehr umfangreichen Workflow-Engine, die das Rückgrat von JIRA ist, besitzt das Atlassian-Tool eine Datenbank mit schier endlosen Informationen. Nur, wie kommt man am besten an diese Daten heran?

Nun, zum einen können versierte Nutzer mit der einfachen Suche („simple search“) oder der erweiterten Suche („advanced search“) sehr gute Adhoc-Abfragen durchführen. Wiederkehrende Abfragen können als Filter gespeichert und ggf. weiterverwendet werden. Dies alles gilt wie gesagt für versierte Nutzer („power user“). Was aber ist mit den weniger techischen Nutzern von JIRA? Der Marketing-Abteilung? Dem Community Management? Wie helfen wir der Vertriebsabteilung, oder gar dem Management?

Die Lösung

Der Mehrwert den JIRA bietet, kann meist durch geschickte und personalisierte Aggregation von relevanten Daten innerhalb von Dashboards ziemlich einfach aufgezeigt werden.

Wichtig ist hierbei, dass Dashboards Emotionen ansprechen und zu Aktionen führen. Dies erreicht man z.B. durch zielgruppenspezifische Dashboards, durch Einholen von Feedback der Nutzer und durch die ein oder andere Iteration. Auch hier gilt: Ein perfektes Dashboard gelingt selten auf Anhieb. Möglicherweise startet ihr bereits mit einem guten Dashboard, aber erst, wenn mehr Feedback eingearbeitet wird, kann aus dem guten ein sehr gutes Dashboard werden.

Der Vollständigkeit halber: Es gibt nicht das eine perfekte Dashboard („one fits it all“). Arbeitet stattdessen lieber mit vielen, an die Bedürfnisse einzelner Nutzertypen (z.B. Reporter, Entwickler, Produktmanager, externer Stakeholder, Marketing Abteilung, Management, Teamleads, etc.) angepassten Dashboards.

Der Aufbau von Dashboards

Wie oben kurz skizziert ist der Ausgangspunkt eines Dasboards eine Suche bzw. ein Suchergebnis.

Beispiele für ein Suchergebnis (JQL – advanced search):

Aufgabe: „Zeige alle Vorgänge des Marketing-Projektes.“

Abfrage: project = Marketing


Aufgabe: „Zeige alle ungelösten Vorgänge des Besitzers Chuck Norris, welche binnen der letzten zwei Wochen erstellt wurden.“

Abfrage: assignee = chuck.norris AND created >=-14d AND resolution is EMPTY


Aufgabe: „Zeige aus den Projekten Vertrieb und Marketing alle ungelösten Vorgänge, welche vom derzeit betrachtenden Nutzer (!) erstellt wurden und in den vergangenen zwei Wochen keinerlei Update bekommen haben.“

Abfrage: (project = „Vertrieb“ OR project = „Marketing“) AND reporter = currentUser() AND NOT updated >= -2w AND resolution is EMPTY


Diese Suchergebnisse können als Filter gespeichert – und dann in sogenannte Dashboard-Gadgets eingebaut werden.Pyramide_bunt

Auswahl geeigneter Dashboard-Gadgets

Okay, die ersten Suchen sind ausgeführt (Anregungen gefällig?), Filter sind gespeichert und die relevanten Informationen liegen vor? Doch wie präsentieren wir sie dem Nutzer? Standardmäßig kommt JIRA bereits mit etwa 50 verschiedenen Dashboard-Gadgets daher – diese lassen sich durch Addons, wie z.B. JIRA Agile beliebig erweitern. Jedes Gadget kann Informationen aus den angelegten Filtern auf unterschiedliche Weise darstellen. So gibt es Tortengrafiken („pie charts“), Zweidimensionale Filterstatistiken („two dimensional filter statistics“), Aktivitätsströme („activity streams“) und eine Vielzahl weiterer nützlicher Gadgets. Viele Gadgets haben zudem unterschiedliche Konfigurationsmerkmale.

Nicht den Überblick verlieren

Bei so vielen Optionen und Konfigurationen kann man sehr leicht den Überblick verlieren. Damit dies nicht geschieht, habe ich nachfolgend eine Art Checkliste bzw. Fragenkatalog zusammengestellt:

1.) Wer ist die Zielgruppe des Dashboards?

2.) Was hat meine Zielgruppe für Anforderungen bzw. Fragestellungen in Bezug auf Transparenz und Übersichtlichkeit?

3.) In Abhängigkeit von den Anforderungen der Zielgruppe: Welche Filter lege ich an bzw. was sind die Informationen, die ich aufbereiten möchte?

4.) Wie präsentiere ich die Informationen am besten? Welches Gadget nutze ich und wie konfiguriere ich dieses?

Arbeitet man sich sorgfältig durch diese Liste, präsentiert das Ergbnis dann der Zielgruppe und arbeitet in ein, zwei Zyklen Feedback ein, kommt man dem optimalen Dashboard schon recht nahe.

Solltet Ihr vor eben einer solchen Herausforderung stehen Euren Nutzern spezifische Dashboards zu erstellen, die Mehrwert durch Transparenz bieten und alleine icht weiterkommen, meldet Euch gerne per Kommentar oder Mail bei mir. Eines meiner bevorzugten Aufgabengebiete liegt in der gemeinsamen Analyse und Erstellung eben solcher Dashboards!

Lust auf mehr?

Folgende Gastbeiträge im Atlassian Blog vertiefen dieses Thema sehr gut:

Implement Role-Based JIRA Dashboards to Keep a Process Flowing

7 steps to a beautiful and useful agile dashboard

Weitere Tipps gibt es ferner in meinem übergeordneten Beitrag 10 wertvolle JIRA Tipps für Administratoren.

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.