von Evgeniya Buyuk
Ich bin Evgeniya und habe jetzt, kurz nach Abschluss meines Bachelorstudiengangs in Wirtschaftsinformatik an der TU Braunschweig, direkt den darauf aufbauenden Masterstudiengang an der gleichen Universität angefangen. Zusätzlich arbeite ich seit Mitte des Bachelorstudiengangs parallel zum Studium als Softwareentwicklerin und Datenschutzkoordinatorin in einem IT-Unternehmen, welches – wie viele Unternehmen der Region – für einen Autohersteller Softwarelösungen konzipiert, plant, umsetzt und ausrollt. Die Tätigkeiten erfordern ein breit gefächertes Portfolio an Skills, die man erlernen und beherrschen muss. Die drei wohl wichtigsten, neben den Programmierfähigkeiten, sind aber Teamfähigkeit, Kommunikationsfähigkeit und Planung. In der Mitte meines Studiums brach jedoch die Corona Pandemie aus und veränderte auch bei mir viele Lebensbereiche. Während das Studium praktisch komplett auf online umgestellt wurde, hieß es auch beruflich weniger soziale Kontakte im Reallife. Das tägliche Treffen der Supportler*innen, Tester*innen und Entwickler*innen, Stand-Up-Meetings mit den Projektleiter*innen und auch die Termine mit Kund*innen wurden vom physischen Besprechungstisch, unter Zuhilfenahme von zum Beispiel Microsoft Teams, auf online verlagert. Da ich noch frisch in der beruflichen Welt der Softwareentwickler*innen war, dachte ich aufgrund meiner bisherigen Erfahrung der ersten paar Monate, dass die neue Situation pures Gift für diese Art des Arbeitens sein muss. Aber wie sich zeigen sollte, habe ich mich nicht nur geirrt, sondern konnte viele der Handlungsstrategien des Unternehmens in das Studium übernehmen und Mehrwerte dorthin übertragen. Einer der Punkte war der Einsatz der Atlassian Tool Chain. Auf den folgenden Seiten möchte ich euch erzählen, wie man sie beruflich für große Anwendungen mit vielen Beteiligten einsetzt und sie durch ihre Skalierbarkeit auch im kleineren Maßstab in einen überwiegend technischen Studiengang integriert werden kann, da auch dort ähnliche Mehrwerte geschaffen werden können.
Eine Tool Chain ist eine Sammlung von Werkzeugen, die jeweils auf bestimmte Aufgabenbereiche spezialisiert sind. Jedes Tool ist dabei in sich vollumfänglich für seine Aufgabe. Der sogenannte Chain Effekt entsteht, da diese Tools auch gleichzeitig Module mit Schnittstellen zu den anderen Mitgliedern ihrer Chain sind (s. Abbildung 1). Indem man die Tools einander bekannt macht, kann man Synergieeffekte erzeugen. Wenn man ein Softwareprojekt beginnt und sich dann zum ersten Mal mit der Atlassian Tool Chain beschäftigt, wird man wahrscheinlich entweder zu klein anfangen, indem man sich nur ein Produkt der Kette herausgreift – oder man ist von den Möglichkeiten förmlich erschlagen, indem man versucht auf Anhieb die gesamte Kette vollumfänglich einzubinden. In beiden Fällen ist Frust vorprogrammiert, denn entweder hat man das Gefühl, zu wenig zu umständlich zu erreichen, oder die Software wächst einem schlicht aufgrund der vielen Einstellungen und Möglichkeiten über den Kopf.
Da wir in dem Seminar „How to Co-Work. Zusammenarbeit im Studium und darüber hinaus“ unseren Schwerpunkt allerdings auf Kommunikation, Kooperation und Kollaboration legen wollen, möchte ich mich zu Beginn auch nur mit diesen Schwerpunkten beschäftigen, denn die drei im folgenden vorgestellten Tools der Chain erfüllen perfekt ihre Aufgabe, vor allem, wenn man sie miteinander kombiniert.
Abbildung 1 Atlassian Home als Schaltzentrale
Ich habe es bereits erwähnt: In meinem Beruf, aber auch im Studium ist Kommunikation eine Schlüsseleigenschaft. Hierfür bietet die Atlassian Tool Chain Confluence an. Laut der Selbstdefinition ist es das Mittel der Wahl zur Dokumentation und Kommunikation von Wissen, sowie zum Austausch von Wissen innerhalb einer Organisation oder eines Projekts. Confluence ist für sich allein gestellt eine Art Wiki, aber mit massiv ausgebauter Funktionalität. Möchte ich mehr Produkte aus der Tool Chain verwenden, dann ist Confluence auch die Schaltzentrale für alle anderen Tools. Durch das Bereichsmanagement können hier Rollen und vor allem Gruppen angelegt werden, sowie über eine Userverwaltung toolübergreifend die Rechte bis ins kleinste Detail festgelegt werden.
Hierzu ein kleines Beispiel: Ich erzeuge Gruppen für Entwickler*innen, Kund*innen und Nutzer*innen und schon kann ich die Ansichten bei so ziemlich jedem Projekt sauber aufteilen. Interne How To´s oder Guidlines sind dann nur für Entwickler*innen sicht- und bearbeitbar. Kund*innen können auf die Seiten zugreifen die ihnen KPI´s und Auswertungen liefern. Für die Nutzer*innen können Onlinehandbücher, Newsticker oder auch Messenger Dienste für sofortige Hilfe angeboten werden. Gibt es Inhalte auch für Personen außerhalb des Unternehmens, wie zum Beispiel für die Kundenakquise, dann kann ich anonymen Zugriff auf diese Ressourcen zulassen.
Bei der Wahl wie und in welcher Form Informationen zur Verfügung gestellt werden, kann ich aus einem breiten Portfolio wählen und meine persönlichen Rosinen herauspicken. Durch Editoren unterstützte einfache HTML- und CSS-Inhalte sind hier die Basis. Damit ich aber nicht bei 0 anfange, bietet Atlassian bereits viele Templates für viele verschiedene Themengebiete an. Diese sind unter https://www.atlassian.com/software/confluence/templates frei verfügbar. So kann ich mit wenigen Klicks eine schicke SWOT-Analyse, To-Do Listen, eine Roadmap für mein Projekt und vieles mehr erzeugen. Möchte ich über die Grenzen der „Out of the Box“ Möglichkeiten von Confluence arbeiten, dann gibt es mittlerweile eine sehr breite Community innerhalb des Atlassian Universums, sodass im integrierten App Store hunderte kommerzielle und nichtkommerzielle Lösungen für nahezu jede Aufgabe zur Verfügung stehen.
Ich will Tabellenkalkulationen wie in Excel verwenden? Kein Problem, dafür allein gibt es dutzende Lösungen für verschiedene Vorlieben. Aber vielleicht möchte ich direkt Excel Files hinterlegen und direkt innerhalb von Confluence bearbeiten können. Auch dafür gibt es entsprechende Apps. Bis hin zu komplexen BI Schnittstellen, professionelle Tools für komplexe Datenanalyse, werde ich für nahezu alles fündig.
Anfangs erwähnte ich, dass ich die Corona Welt als Gift für die Produktivität sah, da ich befürchtete, dass die Kommunikation darunter leidet. Es stellte sich aber schnell heraus, dass meine Sorgen unbegründet waren. Die Besprechungen und Stand-Ups wurden in den virtuellen Raum verlegt und mit ein wenig Datenhaltungsdisziplin bot Confluence den Raum, alle relevanten Informationen für alle Beteiligten strukturiert und geordnet zur Verfügung zu stellen (s. Video 1). Auch in der Universität ist ein Confluence gestütztes Projekt sowohl ein Hingucker als auch extrem praktisch für die Projektbeteiligten.
Ich kann also mit jedem uni- und bidirektional kommunizieren. Jetzt möchte ich mir angucken, wie mir die Tool Chain auch bei der Kooperation weiterhelfen kann.
Video 1 „How to get the Most out of Confluence“ ab Minute 3:20.
Confluence ist ideal, wenn ich Wissen verbreiten möchte und auch um Anfragen erstmalig anzunehmen. Geht es aber darum, komplexe Aufgaben zu planen, zu koordinieren und mit mehreren Personen gemeinsam an einem Problem zu arbeiten, dann muss ich anfangen, aus dem Tool nun eine Chain zu machen. Seit mittlerweile 2002 bietet die Firma Atlassian hierfür das plattformunabhängige Tool JIRA. Die Webanwendung wird zur Fehlerverwaltung, zur Problembehandlung und zum operativen Projektmanagement verwendet. Historisch hat es seinen Ursprung zwar in der Softwareentwicklung, aber mittlerweile hat es sich auch bei vielen unterschiedlichen Unternehmen etabliert.
Ich habe in dem oberen Beispiel bereits Rollen in Confluence definiert. Da ich die beiden Tools jetzt gemeinsam nutze, wird auch das Usermanagement automatisch mitverwendet. Es muss also nur zentral an einer Stelle verwaltet werden. Wie aber unterstützt JIRA nun bei der Kooperation? Es bringt ebenfalls eine ganze Palette mächtiger, durchdachter und erprobter Funktionen mit. Die Kernkomponenten sind wohl aber die Workflows und Issues, mit denen Aufgaben definiert werden. Die frei einstellbaren Workflows bieten das Grundgerüst dafür, wie ich mir vorstelle, wie Issues abgearbeitet werden sollen. Hierbei baut sich ein Workflow aus zwei simplen Bausteinen zusammen. Den Status und dem Statusübergang. Jeder Status wird einfach mit einer beliebigen Anzahl anderer Status durch die Statusübergänge verbunden und definieren so, durch welche Prozessschritte ein Issue ablaufen muss. Das kann ich simpel halten und zum Beispiel nur die Status „offen“ und „erledigt“ erzeugen, oder, wenn ein Projekt das erfordert, beliebig komplexe Graphen generieren (s. Video 2). Werden Abnahmen von Kund*innen, Kolleg*innen, Kommiliton*innen oder Professor*innen benötigt, bevor eine Aufgabe wirklich fertig ist? Muss eine andere Rolle zustimmen? Hat sich das Problem als Bedienungsfehler herausgestellt und muss zwar an den Support für die Wissensdatenbank überführt werden, erfordert aber keinen Aufwand? Meinen Anforderungen sind kaum Grenzen gesetzt.
Die Issues sind die Beschreibungen der Aufgaben, welche man auch in Subaufgaben runterbrechen kann. Diese lassen sich mit beliebigen Feldern erweitern, aber bereits in der Standartkonfiguration enthalten sie wichtige Informationen. Typ der Aufgabe, Rich Content Beschreibungen, Zeitvorgaben, Kommentarfunktionen und vieles mehr sind vorkonfiguriert, aber praktisch alles bei JIRA kann auch an die eigenen Anforderungen angepasst werden. Grundsätzlich landen die Issues im Backlog, einem Sammelcontainer für alles, was anfällt. Bis zu diesem Zeitpunkt kann ich Aufgaben zwar verteilen, beschreiben, kommentieren und aufzeigen, in welchen Zustand sie sich befinden, aber die Dimension Zeit als Grundlage einer soliden Planung fehlt bis hier. Hier kann ich innerhalb von JIRA verschieden skalieren. Eine der gängigsten Methoden ist das Zuordnen zu Sprints. Ein kurzes, aber regelmäßiges Zeitintervall von wenigen Tagen bis zu wenigen Wochen. Die Sprints wiederum können Releases und Epics (Große Aufgaben, die sich für gewöhnlich über längere Zeiträume erstrecken) und letztlich auch Meilensteinplänen zugeordnet werden.
Ab diesen Punkt habe ich alle Mittel zur Verfügung, um Aufgaben sinnvoll zu strukturieren, einzuplanen und zu tracken. Damit das Ganze aber repräsentabel und übersichtlich zur Verfügung gestellt werden kann, bietet JIRA zudem eine Echtzeitreportkomponente, die alle Schritte von der Planung, über die Umsetzung bis hin zur Auslieferung umfasst (s. Video 3). Schon mit wenigen Stunden Einarbeitung kann ich dadurch selbst Projekte professionell aufziehen. Da JIRA auch eine eigene Domänensprache mitbringt, deren Syntax ein wenig an SQL angelehnt ist, kann ich sämtliche Reports auch selbst definieren, wenn mir die üppigen Optionen noch nicht reichen.
Video 3 „Jira Work Management Views“ ab Minute 0:20.
Alle Projektbeteiligten sehen so immer alle live den aktuellen Stand und was wer zu wann erledigen möchte. Der Clou ist aber, dass ich dank der Tool Chain meinen Arbeitsstand problemlos live in Confluence einbinden kann, um auch hier wieder zentral meinen Informationsstand zu teilen (s. Video 4).
Video 4 „Reporting Jira Information on Confluence Pages“ ab Minute 0:40.
Bisher kann ich mit Teammitgliedern und mit der Außenwelt kommunizieren und innerhalb des Projekts kooperieren, um meine Ziele zu erreichen. Bei komplexen Problemen kommt es aber oft vor, dass ich innerhalb von Teams oder Projektgruppen in eine Kollaboration gehen muss. War ich bisher in einer offenen Welt für Projekte fast jeder Art unterwegs, bin ich jetzt komplett in der Softwareentwicklung angekommen. BitBucket, als nächsten Kettenglied meiner Tool Chain, ist zur Versionsverwaltung innerhalb eines Softwareprojekts entwickelt wurden. Arbeite ich mit mehr als einer Person an einer Software, dann wird in der Regel ein Repository verwendet. Eine, meist online verfügbare, Verzeichnisstruktur des Programmcodes. Wird eine Anwendung groß genug, dann steigt in der Regel auch die Anzahl der gleichzeitig verwendeten Repositories, da man Daten inhaltlich besser trennt. Teilweise aufgrund der Wiederverwendbarkeit, teilweise um Unabhängigkeit und Portabilität zu gewährleisten und manchmal auch nur weil es eine externe Ressource ist. Das Grundprinzip dahinter ist, dass, wenn mehrere Leute gleichzeitig an einem Modul arbeiten würden, es aufwendig wäre, den Code bei allen auf den aktuellen Stand zu halten. Repositories fungieren als Verteilstationen zwischen den Entwicklern. Dadurch ist es erst möglich, das innerhalb einer Softwarekomponente ernsthaft kollaboriert wird (s. Abbildung 2).
Abbildung 2 Kollaborieren in Softwareprojekten mit BitBucket.
BitBucket bündelt die Repositories dann selbst wieder an einer zentralen Stelle und gibt mir Werkzeuge zur Hand, mit denen ich diese dann verwalten und administrieren kann. So kann ich als Entwicklerin verschiedene Stände anlegen, sie miteinander vergleichen, mir den Code anderer Entwickler*innen in meinen Stand mergen, zurückrollen auf einen alten Stand und meine Änderungen dem Rest des Teams problemlos zur Verfügung stellen. Auch hier kann ich wieder viel konfigurieren, um es an die eigenen Bedürfnisse anzupassen. Darf jeder einfach seinen Code reinpacken, oder gibt es Regeln? Überhaupt, darf nur ein Kreis von Personen den Code sehen, oder ist er öffentlich? Wenn jemand in einen bestimmten wichtigen Stand Code einfügen möchte, müssen Senior Entwickler*innen die Änderungen erst freigeben? Und vieles, vieles mehr.
Auch hier greift wieder der Vorteil einer Tool Chain. Denn bringe ich Code in einem durch BitBucket verwalteten Repository ein und nutze als Kommentar die ID eines JIRA Issues, dann bemerkt JIRA das und bindet automatisch meinen Beitrag an die entsprechende Aufgabe (s. Video 5).
Video 5 „Demo of Jira Software‘s CI/CD Integration“ ab Minute 18:45.
Ich hoffe ich konnte euch mit den – aus meiner Sicht – 3 wichtigsten Tools der Atlassian Chain aufzeigen, wie wertvoll ein intelligenter Einsatz sein kann und wie sehr dieser das gemeinsame Arbeiten im Team oder mit den Kund*innen bereichert. Einzeln eingesetzt sind die Tools zwar auch bereits nützlich, doch entfalten sie sich erst richtig, wenn sie kombiniert werden. Das Thema ist aber noch bei weitem größer und wer sich dort einarbeiten will, wird viele interessante Dinge aus der IT-Entwicklung lernen können. Denn es gibt bei weitem noch mehr Glieder für unsere Kette. Sei es Bamboo, um automatisch Produkte auf Servern auszuliefern, OWASP mit dem Code auf Aktualität und Sicherheitslücken geprüft werden kann, SonarQube zur statischen Qualitätsanalyse des Codes, JFrog als Artifactory, um ganze Softwarepakete in den Prozess aufzunehmen und einige weitere.
Ich kann nur allen Student*innen, die sich ernsthaft später beruflich mit Softwareentwicklung beschäftigen wollen, egal ob in der Entwicklung oder im Management, raten, sich mit dem Thema agiles Projektmanagement auseinanderzusetzen, denn in praktisch jedem Unternehmen wird Atlassian oder ein vergleichbares Derivat eingesetzt. Gerade für Studierende interessant ist hierbei die kostenlose Version, die bei Confluence und JIRA für bis zu 10 Teilnehmer*innen und bei BitBucket für bis zu 5 Projektteilnehmer*innen angeboten wird, da dies meistens mehr als ausreichend für Studienprojekte ist. Ein weiterer klarer Vorteil ist die DSGVO konforme Datenhaltung auf deutschen Servern.
DAS VERBUNDPROJEKT
CO3LEARN
TECHNISCHE UNIVERSITÄT BRAUNSCHWEIG
GOTTFRIED WILHELM LEIBNIZ UNIVERSITÄT HANNOVER
GEORG-AUGUST-UNIVERSITÄT GÖTTINGEN
Das Projekt Co3Learn wird gefördert aus Mitteln der Stiftung Innovation in der Hochschullehre.
Projektlaufzeit: 01.08.2021 – 31.12.2025 mit bewilligten Fördermitteln von
4.760.895,51 Euro.
Universitätsplatz 2
38106 Braunschweig
Welfengarten 1
30167 Hannover
Wilhelmsplatz 1 (Aula)
37073 Göttingen
© Copyright Co3Learn, created with Royal Elementor Addons and Elementor
