Im Rahmen eines Projektes sollte ich das Team Architektur als Scrum Master unterstützen. Das Projekt arbeitet nach Scrum. Nach geraumer Zeit stellte sich natürlich die Frage bei uns, welche Hilfsmittel und Tools wir als Team verwenden wollen – besser(!), welche uns im Rahmen unserer Tätigkeiten unterstützen können. D. h., dass sich die Hilfsmittel und Tools uns unterordnen sollen und nicht umgekehrt.

Voraussetzungen 

Als Team haben wir uns dazu natürlich Gedanken gemacht und uns ein paar Leitplanken überlegt. Die Hilfsmittel und Tools müssen auf jeden Fall einer Revisionsprüfung standhalten und die Kommunikation sicherstellen. Das bedeutet in dem Fall für uns Auskunftsfähigkeit innerhalb des Teams und gegenüber Dritter, unabhängig davon, wer von dem Team „anwesend" ist oder nicht.

Dann müssen klassischerweise Transparenz, Nachvollziehbarkeit und Ablage für die dokumentierten Resultate sichergestellt sein. Des Weiteren muss noch erklärt werden, dass wir als Team architekturübergreifend tätig sind, wir uns mit vielen Teams innerhalb des Projekts abstimmen müssen, und dass wir ganz stark von Zulieferleistungen abhängig sind. Vor diesem Hintergrund gibt es bereits eine Einschränkung für das Team Architektur. Die Einschränkung besagt, dass die Ziele nicht an Sprintzeiträume gebunden werden können. Damit musste für das Team eine reine Scrum-Vorgehensweise ausgeschlossen werden. Daher wird im Team Architektur die Mischung aus Scrum und Kanban (Scrumban) eingesetzt. Des Weiteren mussten wir uns als Team Architektur gewissen Prämissen unterwerfen. Diese sind u. a.: Jedes Team-Mitglied muss auf die Hilfsmittel und Tools Zugriff haben, die in dem Projekt bereits existieren und unseren Anforderungen genügen.

Die Tools:

Schritt 1: Wir analysieren welche Tools in dem Projekt bereits eingesetzt werden:

• MS Project
• GitLab
• weConnect
• Jira
  
  

Schritt 2: Aus-/Bewertung aus der Sicht des Teams:

Um den Rahmen eines Blog-Artikels nicht zu sprengen, wird diese Wertung hier nur schematisch und komprimiert wiedergegeben.

MS Project bietet seit November 2017 die Möglichkeit für eine agile Planung an. Die agile Planung ist verfügbar für Project Online Professional und Premium-Abonnenten. Daher bietet MS Project folgende Methodiken an: Agile, Wasserfall oder Hybrid. Im Rahmen des Projektes kann MS Project nicht genutzt werden, da es nicht übergreifend eingesetzt wird.

GitLab umfasst im Kern Funktionen zur Quellcode-Verwaltung und Versionskontrolle, unterstützt Projektmanagement-Aspekte; wird übergreifend eingesetzt und ist im Projekt vorhanden.

weConnect dient der allgemeinen Bereitstellung und Verfügbarkeit von Informationen, Daten und Dokumentation im teamübergreifenden Umfeld; wird übergreifend eingesetzt und ist im Projekt vorhanden.

JIRA eignet sich nicht nur für Scrum, sondern ebenso für die Managementmethode Kanban sowie für hybride Mischformen wie Scrumban. Die Software gruppiert die einzelnen Sprints nach Priorität, dokumentiert/visualisiert die Fortschritte in sogenannten Burn-Down-Charts, organisiert die „Kommunikation" und eignet sich für strukturierte Workflows, einschließlich Ablage von Dokumentation, u. a. Protokolle, Konzepte; wird übergreifend eingesetzt und ist im Projekt vorhanden.

Fazit

Wir als Team Architektur sind zu folgendem Fazit für uns gekommen: Anhand der vorhergehenden aufgeführten und genannten Rahmenbedingungen sowie unter Einhaltung der Prämissen, fällt die Entscheidung für das Hilfsmittel bzw. Tool auf JIRA. Der Grund für die Entscheidung ist der, dass mit dem Tool die Rahmenbedingungen und Prämissen erfüllt werden und das Hilfsmittel bzw. Tool die hybride Mischform Scrumban ermöglicht. Dies entspricht der Arbeitsweise vom Team Architektur.