Zugegeben, nach über 15 Jahren (fast) täglicher Nutzung, Beratung und Konfiguration von Jira verliert man etwas den Blick dafür, dass der Jira Strukturaufbau doch eine gewisse Komplexität mit sich bringt und - vor allem die Konfiguration - nicht an allen Punkten selbsterklärend ist.
Häufiger habe ich in der letzten Zeit Fragen gehört, wie:
Sind Jira Service Work Management, Jira Service Management und Jira Software unterschiedliche Produkte?
Wo und wie grenzen sich die Produkte in der Konfiguration ab?
Können die "unterschiedlichen" Jira Produkte miteinander agieren?
Diese Fragen habe auch ihre Berechtigung, denn dies ist nicht immer ganz klar und Jira ist heutige deutlich umfangreicher, als es noch für 5 oder gar 10 Jahren war.
Ich denke, es hilft, wenn man die Geschichte/Entwicklung von Jira versteht. Anfangs installierte man Jira als JAVA-Anwendung auf seinem Server. Es gab lediglich eine Ausprägung von Jira. Hinzu kamen im Laufe der Jahre Jira Agile (heute Software) sowie Jira Service Desk (heute Service Management), beides waren aber lediglich Add-Ons (Apps), welche via UPM (Universal Plugin Manager) installiert wurden (wie alle anderen Apps heute auch noch). Dies bedeutet, es gab und gibt immer einen einzigen Unterbau (sozusagen Jira Core), welcher für alle Ausprägungen genutzt wird. So erklärt sich auch, dass der unterliegende Konfigurationsaufbau immer identisch ist, nach "oben hin" ergeben sich allerdings sehr individuelle Konfigurationsoptionen, je nach Produktauswahl.
Um dies zu verdeutlichen, möchten wir gerne nachfolgende Darstellung empfehlen:
Die Funktionen und Konfigurationsoptionen in den jeweiligen Produkten gewinnen immer weiter als Vielfalt und Möglichkeiten, dies freut uns als Atlassian Enthusiasten - wirkt für Menschen, die neu in dieser Produktwelt unterwegs sind, häufig komplex und auch teilweise überladen. Aus diesem Grund versuchen wir die Konfigurationen zu simpel wie möglich zu halten und nicht benötigte Elemente, Objekte und Funktionen wo möglich erst dann einzusetzen, wenn der Nutzen wirklich gebraucht (und verstanden) wird.
Keep it simple - manchmal aber gar nicht so einfach umzusetzen, denn wie finde ich als Nutzer heraus, was wirklich gebraucht wird? Ein Teil unserer Beratungsleistung liegt hier in der Abwägung von minimaler Komplexität und angemessen hoher Funktionsbereitstellung. Denn: Nur weil etwas möglich ist, muss es nicht unbedingt sinnvoll sein, es auch umzusetzen.
Comments