Wolfgang Tank - JIRA beherrschbar administrieren oder wie mache ich JIRA wirklich enterprisefähig

Dr. Wolfgang Tank

Communardo Community Day 2011

Frankfurt, 27.09.2011

JIRA beherrschbar administrieren oder

wie mache ich JIRA wirklich

enterprisefähig

Vorwort

• Hör ich da Kritik raus?

• Ich dachte doch immer, Jira wäre

enterprisefähig

Communardo Community Day 2011 27.9.2011 2

I love Jira – I hate Jira

Konstruktive Kritik muss erlaubt sein.


Agenda

• Einordnung / Klärung des Kontext

• Schwachstellen von Jira (vor dem Hintergrund

des Kontextes)

• Best-Practises / Workarounds

• Fazit


Kontext

• Verwaltung größerer dynamisch sich

wandelnder Projektportfolios

• Heterogene Workflows

• hohe Feldvarianz


Kontextbezogenes Geschäftsumfeld

• Auftragsbezogene Individualentwicklung

• Hohes Projektaufkommen verteilt auf mehrere

unabhängig agierende Teams

• Jira als Plattform für allgemeines Aufgaben /

Workflowmanagement

• Jira wird von Atlassian mit hohem

Eigennutzungsantrieb entwickelt

– Auftragsunabhängige Produktentwicklung ist homogener und

weniger dynamisch


Kontextbezogene Schwachstellen

• Projekte sind keine Mandanten

– Projektübergreifende Verwendung von Schemadefinitionen

• Administrationsrechte unzureichend

deligierbar

– Projektadmins können Personen, Komponenten, Versionen

verwalten aber

– z.B. keine Felder anpassen (insbesondere Optionen)

• Adminrechte diffundieren

• Administrative Anpassungen bleiben Stückwerk

produzieren ungewollte Seiteneffekte, führen

zu Wildwuchs in den Bezeichnungen



• Handling langer Definitionslisten (Felder,

Screens)

– Keine Filterfunktion

• Handling von Feldkonfigurationen

– Default-Einstellung (sichtbar) für Felder in

Feldkonfigurationen

– Scrolling

• Zuordnung von Workflow-Schemes

– Keine Sammelzuordnung möglich



• Projektglobale Berechtigungs- /

Benachrichtigungsschemata

– Nicht vorgangstypspezifisch

• Dashboard-Verteilung

– Pull-Prinzip über Favoriten ist selten gewünscht

• Project Deployment


Best Practises

• Masterprojekte und Projekte als Vorgänge

• Umgang mit Feldkonfigurationen und

Screendefinitionen

• Namenskonventionen


Masterprojekte / Projekte als Vorgänge

Projektkategorie

Master Produktentwicklungs-

projekte

PE1

PE2

…

Master Kundenprojekte

KP1

KP2

…

Master Servicevertrag

SV1

SV2

…

Master SupportChannel

SC1

SC2

…


Kriterium zur Abgrenzung Master:

- Unterschiedliche Vorgangstypen

- Unterschiedliche Rollen

Umgang mit Vorlagen

• Copy project

– Built-In Script / Groovyrunner-Plugin

• Projekt / Projekt-Verlinkung

– Metadatum am Projekt / Jira Metadata Plugin

• Roll-Out / Synchronisation von

Schemaänderungen am Master auf seine

abgeleiteten Projekte


Projekte als Vorgänge


Projektverzeichnis als Filter


Projektadministration per Transition


Copy Project als Postfunction /

CustomWare Jira Utilities

Change Permission Scheme Postfunction /

catWorkX Utility

Feldkontext / Feldkonfiguration / Screen

• Felder werden global definiert und können

grundsätzlich auf bestimmte Vorgangstypen

oder Projekte eingeschränkt werden

• Achtung: Feldkonfiguration sind zunächst

projekt- und vorgangstypunabhängig

– Kein unmittelbares Feedback über den Kontext eines Feldes


Umgang mit Feldkontexten

• Schränke Felder bei der Definition auf

Vorgangstypen ein, nicht aber auf Projekte, die

aus Masterprojekten abgeleitet werden


Zusammenhang Feldkonfiguration / Bildschirme


Best Practise Feldkonfigurationen / Screens

• Belasse Bildschirmdefinitionen universell und

spezialisiere diese durch die Feldkonfiguration

– Für create, edit und view-Operationen reicht im Best Case

ein Standard-Bildschirm mit allen Feldern

• Leite Feldkonfigurationen aus einer

Defaultkonfiguration ab, die initial alle

möglichen Felder deaktiviert (hide)

– Achtung: Neu definierte Felder sind initial in allen

vorhandenen Feldkonfigurationen aktiviert,

• Feature Request

– Standardverhalten umdrehen oder parametrierbar machen

– Sammeloperation „Hide Field in all Screens“


Best Practise Namenskonvention

• Berücksichtige die Sortierung in

Definitionslisten

• Feldkonfigurations-, Vorgangstyp-Bildschirm-,

Workflow-, Sicherheits-, Benachrichtigungs und

Berechtigungsschema nach Projekt benennen

• Screen Scheme, Feldkonfiguration, Workflow

nach Vorgangstyp benennen

• Felder ggf. sinnvolle Präfixe verwenden

• Screens nach Vorgang und Aktion / Übergang


Namenskonventionen (Schema)


• Schemabezeichner = Projektname

Namenskonventionen (Feldkonfiguration)


• erst nach Vorgangstyp, dann ggf. nach Projekt

Namenskonventionen (Workflow)


• Workflowname = Vorgangsname

Namenskonventionen (Screens)


Filtern in Tabellen


JIRA Admin Speakeasy Extension

Berechtigungs- und Benachrichtigungsschema

• Umgang mit vorgangstyp-übergreifendem

Berechtigungs- und Benachrichtigungsschema

– Problem:

• ggf. für den Kontext genau eines Vorgangstyps zu grob

• Verfeinerung führt ggf. zu einer Explosion von Rollen

– Lösung:

• Führen der berechtigten Personen explizit am Vorgang über (Multi)

User Custom Fields

• Nutzung dieser Felder in den Berechtigungsschemata

• Mengenoperation auf Multi User Custom Field (User hinzufügen,

entfernen aus Liste)


Verteilung von Filtern / Dashboards

– Wie wäre es mit Zwangsdistribution?

– catWorkX stellt hierfür Open Source Distributions

Plugins zur Verfügung


Best Practises - Zusammenfassung

• Masterprojekte anlegen und kopieren (Plugin

erforderlich)

• Frühzeitig Namenskonventionen einführen

– Sortierung beachten

– Kurz und prägnant

– In Abhängigkeit von der Zuordnung auf Projekt oder Vorgangstyp

• Projektübergreifende Abhängigkeiten vermeiden auch

wenn das ggf. zur Redundanz führt

• In der Standard-Feldkonfiguration Felder verstecken

– Feldkonfigurationen neu anlegen und nicht kopieren

• Projekt als Vorgangstyp führen, Administrative

Vorgänge ggf. als Postfunctions implementieren

• Dashboards und Filter zwangsdistribuieren


Wolfgang Tank - JIRA beherrschbar administrieren oder wie mache ich JIRA wirklich enterprisefähig

Documents

Transcript of Wolfgang Tank - JIRA beherrschbar administrieren oder wie mache ich JIRA wirklich enterprisefähig