Unterstützen der Einführung durch digitale Innovationen

Der ultimative Test der Innovation ist die Reaktion des Kunden auf Ihre Erfindung. Hat sich die Hypothese als wahr erwiesen? Verwenden Kunden die Lösung? Wird sie den Anforderungen des gewünschten Prozentsatzes von Benutzern gerecht? Das Wichtigste: Kommen sie wieder? Alle diese Fragen können erst nach der Bereitstellung der MVP-Lösung (Minimum Viable Product) gestellt werden.

In diesem Artikel konzentrieren wir uns auf die Unterstützung der Einführung von Tools für Continuous Integration und Continuous Delivery (CI/CD) von Pipelines. Continuous Integration ist die mehrmals täglich durchgeführte Automatisierung von Code, um über ein aktualisiertes einzelnes Projekt zu verfügen. Continuous Deployment ist die automatische Bereitstellung dieser Funktionen im Laufe des Tages.

Verringern von CI/CD-Reibungen, die sich auf die Einführung auswirken

Einige Hindernisse bei der Einführung können durch eine Kombination aus Technologie und Prozessen minimiert werden. Lesern, die sich mit CI/CD- oder DevOps-Prozessen auskennen, werden die folgenden CI/CD-Pipelineprozesse vertraut sein. Dieser Artikel schafft einen Ausgangspunkt für Cloudeinführungsteams, der Innovation und Feedbackschleifen anregt. Auf der Grundlage dieses Ausgangspunkts könnten sich stabilere CI/CD- oder DevOps-Ansätze entwickeln, wenn die Produkte und Teams ausgereift sind.

Wie unter Messen der Auswirkungen für Kunden beschrieben, erfordert die positive Validierung jeder Hypothese Iterationen und Entschlossenheit. Dieser Artikel zu Continuous Integration und Continuous Delivery (CI/CD) zielt darauf ab, die technischen Spitzen zu minimieren, die die Innovation bremsen, aber dennoch sicherzustellen, dass Sie bewährte Methoden anwenden. Auf diese Weise kann das Team Entwürfe für einen zukünftigen Erfolg entwickeln und dabei die aktuellen Anforderungen der Kunden erfüllen.

Fördern von Einführung und digitaler Innovation: Das Reifemodell

Das Hauptziel der Innovationsmethodik ist das Schaffen von Kundenpartnerschaften und Beschleunigen von Feedbackschleifen, was zu Marktinnovationen führen wird. In der folgenden Abbildung und den folgenden Abschnitten werden die anfänglichen Implementierungen beschrieben, die diese Methodik unterstützen.

• Freigegebene Lösung: Richten Sie ein zentrales Repository für alle Aspekte der Lösung ein.
• Feedbackschleifen: Stellen Sie sicher, dass Feedbackschleifen durch Iterationen konsistent verwaltet werden können.
• Continuous Integration: Erstellen und konsolidieren Sie die Lösung regelmäßig.
• Zuverlässiges Testen: Überprüfen Sie die Lösungsqualität und die erwarteten Änderungen, um die Zuverlässigkeit ihrer Testmetriken sicherzustellen.
• Lösungsbereitstellung: Stellen Sie Lösungen bereit, damit das Team Änderungen schnell für Kunden freigeben kann.
• Integrierte Messung: Fügen Sie der Feedbackschleife Lernmetriken für eine klare Analyse durch das gesamte Team hinzu.

Um technische Spitzen zu minimieren, setzen Sie voraus, dass die Reife in diesen Prinzipien anfänglich niedrig ist. Planen Sie durch Orientierung an Tools und Prozessen voraus, die sich präziser werdenden Hypothesen anpassen können. In Azure ermöglichen GitHub und Azure DevOps kleinen Teams, mit geringen Reibungsverlusten zu beginnen. Diese Teams könnten wachsen und Tausende von Entwicklern einbeziehen, die gemeinsam an skalierten Lösungen arbeiten und Hunderte von Kundenhypothesen testen. Im restlichen Teil dieses Artikels wird der Ansatz „Groß planen, klein beginnen“ zur Unterstützung der Einführung zu diesen Prinzipien veranschaulicht.

Freigegebene Lösung

Wie unter Messen der Auswirkungen für Kunden beschrieben, erfordert die positive Validierung jeder Hypothese Iterationen und Entschlossenheit. Während eines beliebigen Innovationszyklus werden Sie weit mehr Niederlagen als Siege erleben. Dies entspricht dem erwarteten Verhalten. Wenn jedoch Kundenanforderung, Hypothese und Lösung bedarfsabhängig ausgerichtet werden, ändert sich die Welt rasch.

Zum Skalieren von digitalen Innovationen gibt es kein wertvolleres Tool als eine freigegebene Codebasis für die Lösung. Leider gibt es keine zuverlässige Möglichkeit, vorherzusagen, mit welcher Iteration oder welchem MVP die gewinnende Kombination erzielt wird. Daher ist es nie zu früh, eine freigegebene Codebasis oder ein Repository einzurichten. Dies ist die einzige technische Spitze, die nicht verzögert werden sollte. Wenn das Team verschiedene MVP-Lösungen durchläuft, ermöglicht ein freigegebenes Repository mühelose Zusammenarbeit und beschleunigte Entwicklung. Wenn Änderungen der Lösung Lernmetriken beeinträchtigen, können Sie mit der Versionskontrolle ein Rollback auf eine frühere, effektivere Version der Lösung durchführen.

Das gängigste CI/CD-Tool für die Verwaltung von Coderepositorys ist GitHub. Damit lässt sich in wenigen Schritten ein gemeinsam genutztes Coderepository erstellen. Außerdem kann das Feature Azure Repos von Azure DevOps zum Erstellen eines Git- oder TFVC-Repositorys verwendet werden.

Feedbackschleifen

Den Kunden zu einem Teil der Lösung zu machen, ist der Schlüssel zum Aufbau von Kundenpartnerschaften während Innovationszyklen. Dies wird teilweise durch Messen der Auswirkungen für Kunden erreicht. Der Dialog und direkte Tests mit dem Kunden sind erforderlich. Beides generiert Feedback, das effektiv verwaltet werden muss.

Jeder Feedbackpunkt ist eine potenzielle Lösung für die Kundenanforderung. Noch wichtiger ist, dass jedes direkte Feedback eines Kunden eine Chance zur Verbesserung der Partnerschaft ist. Wenn Feedback es in eine MVP-Lösung schafft, stoßen Sie mit dem Kunden darauf an. Selbst wenn manches Feedback nicht umsetzbar ist, signalisiert schon das Eingestehen der Entscheidung, dem Feedback keine Priorität einzuräumen, eine Wachstumsmentalität und einen Schwerpunkt auf fortlaufendem Lernen.

Azure DevOps bietet Möglichkeiten, Feedback anzufordern, bereitzustellen und zu verwalten. Diese Tools zentralisieren Feedback, sodass das Team Feedback umsetzen und Folgeaktivitäten im Dienste einer transparenten Feedbackschleife leisten kann.

Continuous Integration

Continuous Integration ist die mehrmals täglich durchgeführte Automatisierung von Code, um über ein aktualisiertes einzelnes Projekt zu verfügen. Wenn Einführungen skaliert werden und eine Hypothese sich bedarfsabhängig einer echten Innovation annähert, wächst die Anzahl der zu testenden kleineren Hypothesen schnell. Für präzise Feedbackschleifen und reibungslose Einführungsprozesse ist wichtig, dass diese Hypothesen integriert werden und die primäre Hypothese hinter der Innovation unterstützen. Dies erfordert, das Sie auch schnell agieren müssen, um innovativ zu sein und zu wachsen, was voraussetzt, dass mehrere Entwickler Varianten der Kernhypothese testen. Für Entwicklungsaktivitäten in einer späteren Phase benötigen Sie möglicherweise mehrere Teams von Entwicklern, die jeweils auf eine gemeinsam genutzte Lösung hin arbeiten. Continuous Integration ist der erste Schritt hin zur Verwaltung aller sich bewegenden Teile.

In Continuous Integration werden Codeänderungen häufig in den Hauptbranch zusammengeführt. Automatisierte Build- und Testprozesse stellen sicher, dass der Code im Hauptbranch immer Produktionsqualität aufweist. Dies garantiert, dass Entwickler zusammenarbeiten, um gemeinsam genutzte Lösungen zu entwickeln, die exakte und zuverlässige Feedbackschleifen bieten.

Azure DevOps und Azure Pipelines bieten mit nur wenigen Schritten Continuous Integration-Funktionen für GitHub oder andere Repositorys. Weitere Informationen finden Sie unter Was ist Continuous Integration? oder im Praxislab zu Continuous Integration. Lösungsarchitekturen sind verfügbar, die die Erstellung Ihrer CI/CD-Pipelines über Azure DevOps beschleunigen können.

Zuverlässiges Testen

Fehler in einer Lösung können falsch positive oder falsch negative Ergebnisse erzeugen. Unerwartete Fehler können leicht zur Fehlinterpretation von Benutzerakzeptanzmetriken führen. Sie können auch zu negativem Feedback von Kunden führen, das den Test ihrer Hypothese nicht richtig wiedergibt.

Während der frühen Iterationen einer MVP-Lösung sind Fehler zu erwarten. Early Adopters verzeihen sie vielleicht sogar gern. In frühen Releases finden in der Regel keine Akzeptanztests statt. Ein Aspekt des Entwickelns von Lösungen mit Blick auf die Kundenanforderungen ist jedoch die Validierung von Anforderung und Hypothese. Beides kann mit Komponententests auf Codeebene und manuellen Akzeptanztests vor der Bereitstellung durchgeführt werden. Zusammen tragen sie zur Zuverlässigkeit des Testens bei. Sie sollten versuchen, eine klar definierte Reihe von Build-, Komponenten- und Akzeptanztests zu automatisieren. Diese stellen zuverlässige Metriken im Zusammenhang mit präziseren Anpassungen an die Hypothese und die resultierende Lösung sicher.

Das Feature Azure Test Plans bietet Tools zum Entwickeln und Einsetzen von Testplänen während der manuellen oder automatisierten Testausführung.

Bereitstellung von Lösungen

Der wichtigste Aspekt bei der Unterstützung der Einführung ist Ihre Möglichkeit, die Freigabe einer Lösung für Kunden zu steuern. Durch Bereitstellen einer Self-Service- oder automatisierten Pipeline zum Freigeben einer Lösung für Kunden beschleunigen Sie die Feedbackschleife. Indem Sie Kunden ermöglichen, schnell mit Änderungen in der Lösung zu interagieren, laden Sie sie ein, am Prozess teilzunehmen. Dieser Ansatz löst auch schnelleres Testen von Hypothesen aus, was Annahmen und potenzielle Überarbeitungen reduziert.

Es gibt mehrere Methoden zum Bereitstellen von Lösungen. Die drei häufigsten sind:

• Continuous Deployment ist der fortgeschrittenste Ansatz, weil er automatisch Codeänderungen in der Produktionsumgebung bereitstellt. Für ausgereifte Teams, die ausgereifte Hypothesen testen, kann Continuous Deployment äußerst wertvoll sein.
• In den frühen Phasen der Entwicklung könnte Continuous Delivery besser geeignet sein. Bei Continuous Delivery werden Codeänderungen automatisch in einer produktionsähnlichen Umgebung bereitgestellt. Entwickler, Geschäftsentscheidungsträger und andere Teammitglieder können diese Umgebung verwenden, um zu überprüfen, ob ihre Arbeit produktionsbereit ist. Sie können mit dieser Methode auch eine Hypothese mit Kunden ohne Auswirkung auf die laufenden Geschäftsaktivitäten testen.
• Die manuelle Bereitstellung ist der am wenigsten ausgereifte Ansatz für die Releaseverwaltung. Wie der Name schon sagt, stellt ein Teammitglied die neuesten Codeänderungen manuell bereit. Dieser Ansatz ist fehleranfällig, unzuverlässig und wird von den meisten erfahrenen Technikern als Antimuster betrachtet.

Während der ersten Iteration einer MVP-Lösung ist die manuelle Bereitstellung trotz der vorherigen Bewertung üblich. Wenn die Lösung sehr vage und das Kundenfeedback unbekannt ist, besteht ein erhebliches Risiko, dass die gesamte Lösung (oder sogar die Kernhypothese) zurückgesetzt wird. Hier ist die allgemeine Regel für die manuelle Bereitstellung: keine Kundenprüfung, keine Automatisierung der Bereitstellung.

Eine frühe Investition kann zu Zeitverlust führen. Noch wichtiger ist, dass sie zu Abhängigkeiten von der Releasepipeline führen kann, die das Team gegen eine frühe Wende resistenter machen. Nach den ersten Iterationen, oder wenn Kundenfeedback einen potenziellen Erfolg suggeriert, sollte schnell ein fortgeschritteneres Bereitstellungsmodell eingeführt werden.

In jeder Phase der Hypothesenvalidierung bieten Azure DevOps und Azure Pipelines Continuous Delivery- und Continuous Deployment-Funktionen. Erfahren Sie mehr über Continuous Delivery, oder sehen Sie sich die praktische Übung an. Lösungsarchitekturen können die Erstellung Ihrer CI/CD-Pipelines über Azure DevOps auch beschleunigen.

Integrierte Messungen

Beim Messen der Auswirkungen für Kunden ist es wichtig, dass Sie verstehen, wie Kunden auf Änderungen in der Lösung reagieren. Diese als Telemetriedaten bezeichneten Daten bieten Einblicke in die Aktionen, die ein Benutzer (oder eine Kohorte von Benutzern) beim Arbeiten mit der Lösung durchführte. Aus diesen Daten kann einfach eine quantitative Validierung der Hypothese gewonnen werden. Diese Metriken können dann verwendet werden, um die Lösung anzupassen und differenziertere Hypothesen zu generieren. Diese subtileren Änderungen tragen dazu bei, die anfängliche Lösung in späteren Iterationen ausreifen zu lassen, sodass die Einführung schließlich bedarfsabhängig wiederholt wird.

In Azure bietet Azure Monitor die Tools und die Schnittstelle zum Erfassen und Überprüfen der Daten aus den Kundenerfahrungen. Sie können diese Beobachtungen und Einblicke verwenden, um den Rückstand mithilfe von Azure Boards zu verbessern.

Nächste Schritte

Wenn Sie sich mit den Tools und Prozessen der CI/CD-Pipeline vertraut gemacht haben, die zur Unterstützung der Einführung erforderlich sind, ist es an der Zeit, eine erweiterte Innovationsdisziplin kennenzulernen: Interagieren mit Geräten. Diese Disziplin kann die Barrieren zwischen physischer und digitaler Umgebung reduzieren, sodass Ihre Lösung noch einfacher angenommen werden kann.