Eine fortlaufende und stetig zunehmende Digitalisierung bringt enorm viele Vorteile mit sich, welche wir auf unserer Trivadis Homepage detaillierter vorstellen. Auch die immer weiter ansteigende Cloudifizierung von IT-Infrastrukturen, welche das Ziel verfolgt, Systeminseln abzubauen und Datensilos abzuwenden, schafft ebenfalls Wettbewerbsvorteile. Viele Softwareanbieter wie Atlassian, Salesforce, SAP und Co. hosten bereits ihre Anwendungen in der Cloud. Bekannte Public Cloud Anbieter sind u. a. Amazon (AWS), Microsoft (Azure), Google (GCP) und IBM. Migrationsvorhaben mit dem Ziel, digital zu werden, bedürfen auch des Einsatzes agiler Methoden, um schneller und effizienter Wert zum Kunden zu bringen. Allerdings stellt die Migration einer Systemlandschaft in eine Cloud kein typisches Vorhaben für Projektmanagement-Methodiken wie Scrum und Extreme Programming dar. Folglich ist eine Anpassung der Verfahrensweise nötig. Folgender Blog-Beitrag befasst sich damit und hat den Zweck, den Umgang mit User Stories an einem CI/CD-Toolchain-Aufbauprojekt im Infrastruktur-Bereich aufzuzeigen.

User Story? Was ist das?

User Stories stellen eine Nutzergeschichte dar und bilden die Brücke zwischen Entwicklung und Kunden. Ein Anwender beschreibt hierbei, wie dieser sich den Liefergegenstand (Product Increment) eines agilen Entwicklungsprojektes vorstellt. Gleiches gilt sowohl für typische Softwareentwicklungsprojekte als auch im Infrastrukturbereich. Die Besonderheit einer User Story liegt darin, dass sie sich auf die nicht-funktionale Unterstützung eines Systems konzentriert.

Gute User Stories sind klar formuliert, enthalten nur die notwendigsten Details und Informationen und lassen sich einfach lesen. Der typische Aufbau einer User Story sieht wie folgt aus:

  • As a <role>, I want <feature>[ so that <reason>]
  • Als <Rolle> möchte ich <Funktionalität>[, um <Nutzen/Grund>]

Wozu benötige ich User Stories?

  • User Stories ermöglichen die Zusammenarbeit zwischen Product Owner, Requirement Engineer und anderen Mitgliedern der Organisation.
  • User Stories findet man in einem Sprint und/oder Product Backlog wieder.
  • User Stories dienen dazu, Anforderungen und Wünsche in einem iterativen inkrementellen Verfahren als Team in geeigneten Arbeitshypothesen zu zerlegen.
  • User Stories ermöglichen zudem die leichtgewichtige Verhandlung über die einerseits gewünschten Aspekte des Liefergegenstandes und den möglich zu realisierenden Aspekten (im zeitlichen Rahmen eines Sprints).
Hierarchische Beziehung von User Stories

Hierarchische Beziehung von User Stories

User Stories in der Atlassian Welt (Jira Software, Jira Core)

„Eine User Story ist eine informelle, allgemeine Erklärung eines Software-Features, die aus der Perspektive des Endbenutzers geschrieben wurde. Ihr Zweck ist es zu artikulieren, wie ein Software-Feature dem Kunden einen Mehrwert bietet.“ (https://www.atlassian.com/agile/project-management/user-stories). User Stories stellen demnach keine Systemanforderung dar. Diese werden erst nach Vereinbarung mit dem Team ergänzt. Im Scrum Kontext werden User Stories dem Sprint (Backlog) zugeordnet und werden über die Dauer des Sprints abgearbeitet. Im Kanban durchlaufen diese den Workflow. Dieser Umgang hilft den Teams dabei, die Arbeitspakete einer User Story besser abzuschätzen und für zukünftige Sprintplanungen und weiteren Prognosen stichhaltige Referenzwerte zu haben.

Beispiel: Aufbau einer vollautomatisierten CI/CD Toolchain mit Atlassian Tools

INITIATIVE

Unser Unternehmen benötigt eine vollautomatisierte CI/CD Pipeline, um IT-Produkte schneller zum Kunden zu bringen.

EPIC 1

Als Product Owner möchte ich die Möglichkeit haben, ein neues Feature im aktuellen Sprint bereits zu testen, um schnell auf Probleme und Erfolge reagieren zu können.

EPIC 2

Als Portfoliomanager möchte ich meine Teams entlasten und ihnen die bestmögliche Arbeitsumgebung anbieten, um sie vor Stress, Überbelastung und ineffizienten Prozessen zu beschützen.

USER STORY 1

Als Entwickler möchte ich, dass Jira automatisch einen Bitbucket Branch erstellt, um diese bis dahin manuelle Aufgabe zu automatisieren.

Mehr Informationen zu Jira für Continuous Integration und Delivery

USER STORY 2

Als Entwickler möchte ich nach einem erfolgreich bestandenen Test des Codes, eine automatisierte Deployment-Freigabe, um Prozessschritte, die zeitintensiv sind, zu optimieren.

USER STORY 1

Als Product Owner möchte ich für mein Team ein automatisierbares Deployment-Tool bereitstellen, um ihnen die Möglichkeit zu geben, sich auf die Kernaufgabe, das Programmieren, zu konzertieren.

 

 

Jira Advanced Roadmaps

Abbildung von Initiativen, Epics und User Stories über Advanced Roadmaps in Jira Cloud

 

Unterschiede zwischen Softwareentwicklungs- und Infrastrukturprojekten

Die IT-Infrastruktur stellt die notwendigen Bedingungen für den Betrieb einer Softwareanwendung sicher. Aus technischer Sicht findet man unter dem Sammelbegriff IT-Infrastruktur folgende Handlungsfelder:

  • Hardware (Betrieb von Rechenzentren, Peripheriegeräte, ggf. auch Roboter, sowie auch mobile Endgeräte)
  • Softwareprodukte (Datenbanken, spezielle Rollback/Backup-Pläne)

Technische (funktionale) User Stories im IT-Betrieb, auch bekannt als Operations, konzentrieren sich darauf, Aufgaben wie die Durchführung technischer Analysen und auch Architekturthematiken zu beschreiben. Der Fokus einer User Story im Infrastruktur-Bereich liegt in der Beschreibung der Systembestandteile der Infrastruktur. Vor dem Hintergrund eines Digitalisierungsvorhabens sollten im Sinne der agilen Praktiken kleine aufeinander aufbauende Lösungen erarbeitet werden, die als Basis für Diskussion und zu Feedbackzwecken dienen. Von einer „Big Bang“ Lösung sollte hier abgesehen werden. Ein gutes Demonstrationsbeispiel bietet die mögliche Initiative: Als Developer benötige ich eine vollautomatisierte CI/CD Toolchain, um nach DevOps arbeiten zu können. Hierdurch wird auch die Relevanz Unterscheidung zwischen Dev (IT-Entwicklung) und Ops (IT-Betrieb) deutlicher. DevOps verbindet und vereint beide Abteilungen, die bis heute getrennt gelebt haben, und führt agile Praktiken im IT-Betrieb ein.

Besondere Eigenschaften von Technical User Stories

Eine Trennung zwischen funktionalen und nicht-funktionalen User Stories wird bei Infrastrukturprojekten nicht benötigt. Vielmehr ist es wichtig zu definieren, dass die Persona nicht der Endnutzer einer Anwendung, sondern eine IT-Abteilung oder im allg. das Testmanagement ist. Entsprechend kann von Stakeholder Stories die Rede sein. Technische User Stories gehören zu den nicht-funktionalen Arbeitspaketen eines Sprints und zeigen die Voraussetzungen zur Erstellung eines Softwareprodukts. Ein geeignetes Beispiel für ein IT-Operations Projekt ist der Aufbau einer automatisierten CI/CD-Toolchain. Je nach Cloud-Anbieter (AWS, Azure, Google) variieren die Anforderungen, und somit sind die User Stories anders zu handhaben und auch zu priorisieren.

Elemente eines Infrastruktur Product Backlogs

  1. Technische Infrastruktur: diese Stories unterstützen in direkter Weise funktionale User Stories – Mithilfe dieser Stories soll beschrieben werden, wie die neue IT-Umgebung auszusehen hat (Abbau Systeminseln, Datenbankendezentralisierung, Cloud-Migration).
  2. Enabler Stories: solche Stories helfen dem Team, bessere Software zu liefern – Dazu gehören u. a. Tools (z. Bsp. Atlassian Jira, CI/CD-Toolchain), Frameworks, Software Development Kits, Metriken, sowie vorgegebene Entwicklungsrichtlinien, die Einfluss auf das Arbeitsumfeld der Teams haben.
  3. Fehlerbehebung / Bug Fixing Items: Hintergrundprozesse sollen effizienter werden – Testautomatisierung ist ein wesentlicher Bestandteil der Softwareentwicklung, und die Einführung neuer kleinerer Update-Intervalle soll die Effizienz steigern.
  4. Refactoring: Architekturtechnisch soll nicht nur ein Code in seiner Struktur optimiert werden – Rahmenwerke, Tools und möglicherweise die Prozessdokumentation auf Confluence sind davon betroffen.
  5. Spikes: stellen zeitliche begrenzte (time-boxed) explorative Aktivitäten dar, um nicht abschätzbare Feature-Wünsche auf die Eignung und Umsetzbarkeit zu überprüfen. Ziel eines Spikes ist die Einschätzung und Planbarkeit zukünftiger Stories.

Empfehlungen für den Umgang mit einer User Story im Infrastruktur-Bereich

In einer nach SAFe Prinzipien agilen Welt, wo Projekte funktionsübergreifend realisiert werden, unterstützt der Architectural Runway einen kontinuierlichen Wertfluss durch die Continuous-Delivery-Pipeline und bietet die notwendige technische Grundlage für die Entwicklung von Geschäftsinitiativen und die Implementierung neuer Features. Somit ist der Architectural Runway eines der primären Werkzeuge zur Umsetzung einer Agile Architecture Strategie im SAFe Kontext. Verantwortlich für diesen Runway ist der System Architekt. Nach dem Priorisierungsmodell Weighted Shortest Job First (WSJF) sollen die einzelnen Epics und/oder Features, die einen wirtschaftlich höheren Nutzen erzielen, vorrangig behandelt werden. Beispielhaft ermöglicht eine vollautomatisierte CI/CD Pipeline neue Geschäftschancen. Hinzu kommt die Risikoreduzierung von manuellen (menschlichen) Fehlern beim Code Testing, Deployment und Provisionieren. Diese agile Architektur macht es also möglich, einerseits Prozesse zu optimieren, die zu neuen Features führen, und andererseits schafft sie eine schnellere Time-to-Market, was ökonomisch betrachtet gewinnbringend ist.

Oftmals ist es der Fall, dass eine User Story einen Vorgang größeren Inhaltes beschreibt und dieser zugleich eine Vielzahl von Akzeptanzkriterien erfüllen muss. Dies erfordert das Upgrade einer User Story zu einem Epic. In SAFe unterscheidet man zwischen Portfolio Epics, Program Epics, Business Epics und Architectural Epics, die für Infrastruktur-Projekte relevant sind. Scaled Agile empfiehlt auch eine Priorisierung dieser Epics. Beschreibt die User Story einen umsetzbaren Gegenstand, ist dessen Kontrolle mittels Akzeptanzkriterien einfacher zu handhaben und daher auch empfehlenswerter. Letztlich sollten Sie den User Stories technische User Stories zuordnen, sodass deutlich wird, wie die zu entwickelnde Funktionalität mit der User Experience zusammenhängt.

Beispielhafte Akzeptanzkriterien für User Story 1 von Epic 1:

  • Sobald ein Jira Issue von „To Do“ auf „in Progress“ gestellt wird, soll die Automation erfolgen.
  • Bitbucket soll bei der Erstellung des Branches den Product Owner mittels E-Mail informieren.

Best Practices zu Akzeptanzkriterien:

  • Die Akzeptanzkriterien decken die funktionalen und nicht-funktionalen Anforderungen ab. Sie liefern auch die Informationen, die erforderlich sind, um sicherzustellen, dass eine Story adäquat implementiert wird.
  • Akzeptanzkriterien müssen testfähig verfasst werden.
  • Nicht zu tief ins Detail gehen. Effektive Akzeptanzkriterien definieren den vernünftigen Mindestumfang an Funktionalität, den Sie liefern können.
  • Effektive Akzeptanzkriterien müssen den Arbeitsumfang umreißen, damit die Entwickler ihren Aufwand richtig planen und einschätzen können.
  • Im Sinne von Acceptance Test Driven Development sollten Sie daran denken, die Akzeptanzkriterien vor dem Start eines Entwicklungsprozesses festzulegen.
  • Sollen ein gemeinsames Verständnis und gegenseitiges Einvernehmen aller Projektteilnehmer über die Kriterien schaffen.

Abgrenzung Akzeptanzkriterien zur Definition of Done (DoD):

  • Die Definition of Done ist eine Checkliste mit Qualitätskriterien, die User Stories erfüllen müssen, um als erledigt bezeichnet werden können.
  • Diese Definition of Done gilt für alle Backlog Elemente, während Akzeptanzkriterien immer spezifisch für eine bestimmte User Story definiert sind.

Wie auch bei einem typischen Software-Entwicklungsprojekt, ist die Administration und das Management über Jira problemlos möglich. Es wurde aufgezeigt, dass mittels Epics und Akzeptanzkriterien, die man aus dem Atlassian Tool Jira und aus Scrum kennt, eine gemeinsame Basis geschaffen werden konnte, anhand der eine Kollaboration ermöglicht wird. In Zukunft sollten Infrastruktur-Themen stärker in Vordergrund treten, da diese entscheidend für die weiteren Schritte einer Wertschöpfungskette sind. IT-Infrastrukturen, die vollautomatisiert und an mehreren Stellen angebunden sind (keine Datensilos oder Systeminseln), sind einfacher in der Administration. Können diese dann auch mit agilen Methoden, wie in der IT-Entwicklung üblich ist, realisiert werden, ist es eine Win-Win Situation und der DevOps-Teamgeist wird gefördert.

Weitere Fragen?

Dann sind wir als Atlassian Platinum Partner für Sie da. Tragen Sie jetzt alle noch offen gebliebenen Fragen und Wünsche zum Thema der neuen JIRA-Produktfamilie an uns heran. Wir freuen uns darauf, gemeinsam mit Ihnen herauszufinden, wie Sie die Werkzeuge von Atlassian optimal nutzen können.

  • Hier findest Du ausführlichere Informationen zu unseren Atlassian-Leistungen.
  • Du hast Interesse an einer Demo von Jira-Produkten, wollen mehr über das Thema erfahren oder ein individuelles Angebot erhalten? Wende dich dafür über das Kontaktformular an uns.
  • Unser Portfolio rund um das Scaled Agile Framework findest du hier