Kennen Sie das auch?

Als Product Owner:in erkennen wir bei Kunden nicht das „große Ganze“ - ob und fachlich oder technisch. Doch fachlich sowie technisch hängt eben jene Product Roadmap zusammen, wir können als Product Owner: innen keine Prozesse digitalisieren ohne die technischen Voraussetzungen (Bsp: Umstieg auf Cloud & Microservices) zu gewährleisten.

 

Anders herum arbeiten Product Owner: innen an der Fachlichkeit und den Anforderungen in Rücksprache mit Fachbereichen, Kundenfeedback und klar der technischen Machbarkeit in der Entwicklung von Produkt-Roadmaps und deren Features. Hierbei spielen Product Owner: innen eine Schlüsselrolle, da sie mittels Schnittstellenkommunikation zu Partnern, Bereichen, Kunden hierbei maßgeblich ebenfalls die Unternehmens Roadmap maßgeblich beeinflussen. Wir helfen hier den Unternehmen die Sicht zu schärfen.

Bei Kundenaufträgen merken wir immer wieder, dass unzureichend oder gar falsch priorisiert wird. Fachbereiche kommen mit teilweise undefinierten Anforderungen, wo nur der Titel des Jira-Tickets Aufschluss geben soll, was sie implementiert haben möchten. Der Data-Analytics Bereich kommt mit der Bitte Google Tag Manager Pixel zu implementieren ohne wirklich sich Gedanken gemacht zu haben warum sie denn gerne diesen Pixel in der Buchungsstrecke implementiert sehen möchten.

​

Die IT möchte gerne mehr interne Code-Reviews durchführen, obwohl 4 hoch priorisierte Themen, die es zu implementieren gilt, im Backlog liegen.

 

Ein klarer Fall von Priorisierungs Problemen, worin wir gerne Kunden unterstützen, um hier für Klarheit, Transparenz und Messbarkeit der Anforderungen und Ergebnisse zu sorgen.

Kunden haben oft das Selbstverständnis, dass Product Owner auch Scrum Master zugleich sein können und natürlich auch die Projektleitung übernehmen und falls Zeit ist auch den Tester zu spielen. Eine klare Herausforderung im Bereich Verantwortlichkeiten. Klar ist es relativ „simpel“ Scrum Events als Product Owner:in zu führen, jedoch ist die Vor-und Nachbereitung für ein Review und für die Retro eine immense Last für Product Owner:innen, denn in der Zeit könnten sie eventuell im Backlog aufräumen, für Klarheit der Anforderungen aus dem Fachbereich sorgen oder doch weitere User Stories schreiben oder verfeinern?

 

Auch hier unterstützen unsere zertifizierten und agilen Digital-Experten für klare Abgrenzungen zu sorgen, damit Prozesse eben da sind wofür sie bestimmt sind – klare, einfache und verständliche Verantwortlichkeiten, die man innerhalb des Unternehmens und an die Kunden tragen kann.

Bei vielen unserer Kunden werden Updates manuell auf aktive Systeme aufgespielt und es werden bereits im Vorfeld Zeitpunkte festgelegt, an denen ein Update aufgespielt wird.

​

Viele Updates laufen im Hintergrund und beeinträchtigen die Verfügbarkeit des Systems nicht oder nur für kurze Augenblicke. Doch einige Updates erfordern es, das Systeme für einige Stunden heruntergefahren werden müssen.

​

Über die Beratung unserer DevOps Spezialisten kann die Implementierung von automatisierten Prozessen und der Verwendung von DevOps Tools behoben werden.

In Regelfall wird vor jedem Backup die Datenbank für kurze Zeit heruntergefahren, damit keine Fehler im Backup entstehen. Ein weiteres Problem, dass entstehen kann, ist dass beim Kopieren der Datenbank Daten verloren gehen. Wird dieses Backup anschließend das System aus diesem Backup wiederhergestellt ist oft ein Hochfahren nicht möglich und führt erneut zu Downtimes und schränkt die Verfügbarkeit weiter ein. 

​

Um dieses Problem zu vermeiden, werden automatische Backup Test auf Integrität getestet. Dabei werden Health Checks durchgeführt und das Backup auf Vollständigkeit getestet. Sind beide dieser Tests erfolgreich, wird das System wieder hochgefahren und für Benutzer:innen freigegeben.

​

Mit dieser Vorgehensweise schaffen wir eine doppelte Sicherheitsvorkehrung für das Rollback auf eine vorherige Version und erzielen eine höhere Verfügbarkeit der Produktivsysteme.

 Im SDLC Prozess werden verschiedene Systeme oftmals ohne Vorwarnung zur Entwicklung oder Testen benötigt. Diese Systeme bzw. IT-Infrastruktur wird ohne DevOps normalerweise manuell konfiguriert. Manuelle Konfigurationen benötigen jedoch meist viel Zeit und sind fehleranfälliger.

​

Durch eine automatische Infrastruktur-Provisionierung (mit IaC und DevOps) werden alle Teile der IT-Infrastruktur (z.B. Server, Datenbanken, Load-Balancer und Systeme) von Entwickler:innen nicht jedes Mal manuell in der GUI vom Cloud Provider konfiguriert oder verwaltet werden.

• Geringere Kosten

• Schnellere Deployments

• Weniger Fehler

• Bessere Infrastruktur Konsistenz

• Keine Konfiguration Abweichungen

• Beispiele für IaC-Tools (Ansible, Terraform, CloudFormation, Helm)

• IaC automatisiert nicht nur den Prozess, sondern dient auch als eine Art Dokumentation der korrekten Vorgehensweise bei Deployments der Infrastruktur

​

Für IaC können häufig bereits vorhanden Tools für die Server Automatisierung und das Konfigurationsmanagement genutzt werden. Zusätzlich gibt es hier auch Lösungen, die speziell für IaC entwickelt wurden.