Co-Entwicklungs-Governance

Das Einrichten eines effektiven Co-Entwicklungs-Governance-Frameworks ist ein wichtiger Teil zur Sicherstellung der Konsistenz und Wiederholbarkeit in herstellerdefinierten Projekten und Fusion Teams. Dieser Artikel beschreibt einen Ansatz zum Definieren eines Governance-Flussdiagramms.

Den End-to-End-Prozess definieren

Sie können den folgenden Prozess als Beispiel verwenden und ihn an die bewährten Methoden Ihrer Organisation anpassen. Es ist nicht notwendig, jeden einzelnen Schritt durchzuführen, solange Sie das gewünschte Ergebnis erzielen.

Funktionen zum Backlog hinzufügen

Mit Backlogs können Sie Ihr Projekt planen, indem Sie Funktionen hinzufügen, die das Gesamterlebnis vorantreiben. Das Backlog stellt auch die allgemeine Roadmap bereit, die das Team zu liefern beabsichtigt.

Beim Hinzufügen einer neuen Funktion zum Backlog besteht das Ziel darin, den allgemeinen Umfang zu beschreiben. Jede Funktion definiert dann den Geschäftswert, entwirft Story-Titel, Umfang und Datenmodelländerungen, die die Codeentwicklungsbemühungen vorantreiben.

Darüber hinaus wird Ihnen beim Hinzufügen einer geschäftskritischen Funktion empfohlen, alle kritischen Szenarien zu identifizieren, um Ihre Tests zu automatisieren. Nachdem Sie Ihre Funktionen hinzugefügt haben, können Sie Ihr Scope-Alignment-Meeting planen.

Scope-Alignment-Meeting

Der Fokus dieses Meetings sollte darauf beschränkt sein, jede vorgeschlagene neue Funktion zu überprüfen und dann nach vorhandenen Apps, Szenarien oder Datenmodellen zu suchen, die diese Funktionalität bereits bieten, um Doppelarbeit zu vermeiden. Dieses Meeting bietet auch die Möglichkeit, die Auswirkungen auf andere Apps zu diskutieren. Schließlich sollten Sie überprüfen, ob diese Funktion eine Erfahrungsbewertung erfordert.

Geschichten und Storyboards zum Backlog hinzufügen

Nach dem Scope-Alignment-Meeting können beliebige User-Story-Titelentwürfe unter der Funktion hinzugefügt werden. An dieser Stelle sind keine Details erforderlich, und der Status der User Story ist „Neu“. Sie können Storys entweder in der Backlog- oder in der Board-Ansicht anzeigen.

Die folgende Abbildung zeigt eine beispielhafte User Story, die einem Backlog hinzugefügt wurde.

An diesem Punkt ist es wichtig, die Qualität aufrechtzuerhalten, indem die Arbeit nach Arbeitsstream und Anwendung organisiert wird. Dieser Ansatz trägt dazu bei, verwandte Arbeitselemente zusammenzuhalten, und ermöglicht es Experten in jedem Arbeitsstream, ein tiefes Verständnis der Funktionalität und Datennutzung in jeder App zu entwickeln und aufrechtzuerhalten.

Entwicklungsbewertung

Erfahrungsbewertungen sollten sich auf die Endbenutzererfahrung konzentrieren und sicherstellen, dass Ihr Team die bewährten Methoden der Organisation befolgt. Diese Konsistenz stellt sicher, dass alle Ihre Apps Endbenutzern und Supportteams ein zuverlässiges und wiederholbares Erlebnis bieten.

Story-Details hinzufügen

Das Hinzufügen einer typischen User Story kann die folgenden Informationen enthalten:

1. Titel : Als ein <persona> kann ich <do something>, sodass <impact/priority/value>
2. Beschreibung: Die Beschreibung enthält (obwohl sie nicht darauf beschränkt ist) bestimmte Schlüsseldetails, wie zum Beispiel:
   • Kurze Beschreibung des Szenarios, die das gewünschte Ergebnis zusammenfasst
   • Narrative – beschreibt die Aktionen, die Benutzer unternehmen, um durch das Szenario zu navigieren und es durchzuführen
   • Alternative Narrative – beschreibt andere Möglichkeiten, wie Benutzer dasselbe Ergebnis erzielen können
   • Designnotizen – zeichnet die mit der User Story verknüpften Entitäten, Felder, Ansichten, Mockup-Bildschirme und Geschäftsregeln auf
   • Betroffene Sicherheitsrollen – listet alle Sicherheitsrollen auf, die betroffen sind oder die für die User Story relevant sind.

Nachdem Sie all diese Details hinzugefügt haben, würden Sie den Status der User Story in „Bereit für Bewertung“ ändern. In den meisten Fällen überprüfen das Feature Team und das Business Team (falls zutreffend) die User Stories.

Story-Bewertung

Story-Bewertungen finden normalerweise innerhalb des Fusions Teams statt, um sicherzustellen, dass alle Details in der Story genannt werden und dass es keine Zweideutigkeiten gibt. Nach Abschluss aller Bewertungen empfiehlt es sich, die User Story einem Teammitglied zuzuweisen. Um Ihre Gesamtziele zu erreichen, müssen Sie sicherstellen, dass Ihr Team während des Entwicklungsprozesses ausgerichtet bleibt.

Aufgaben und Testfälle hinzufügen

Nachdem die Storys überprüft wurden, erstellen die Teammitglieder Aufgaben in Azure DevOps. Der Gesamtprozess zum Hinzufügen von Aufgaben und Testfällen ist wie folgt:

1. Öffnen Sie ein Sprint-Backlog. Alternativ erstellen Sie einen neuen Sprint.
2. Fügen Sie dem Sprint vorhandene Arbeitselemente hinzu. Wenn Sie bereits Arbeitselemente hinzugefügt haben, die nicht im Sprint erscheinen, sollten Sie deren Bereich und Iterationspfade überprüfen. Denken Sie daran, alle nicht übergeordneten Aufgaben den relevanten Arbeitselementen zuzuweisen.
3. Fügen Sie Aufgaben zu Backlog-Elementen hinzu. Wenn Sie Ihrem Sprint keine Backlog-Elemente zugewiesen haben, tun Sie dies jetzt. Legen Sie auch die Start- und Enddaten für den Sprint fest.
4. Füllen Sie das Aufgabenformular aus. Als Faustregel gilt, dass Aufgaben nicht länger als einen Tag dauern sollten. Aufgaben, die diesen Zeitraum überschreiten, sollten aufgeteilt werden.
5. Verfolgen oder integrieren Sie alle nicht übergeordneten Aufgaben. Sie können nicht übergeordnete Aufgaben wie andere Aufgaben verfolgen oder sie auf ein vorhandenes Backlog-Element ziehen, um sie als übergeordnet zuzuweisen.

Nachdem Sie Aufgaben und Testfälle hinzugefügt haben, können Sie mit der Festlegung der Sprintkapazität fortfahren.

Weitere Informationen zum Hinzufügen von Aufgaben finden Sie unter den Elementen Aufgaben zum Backlog hinzufügen zur Unterstützung der Sprintplanung.

Lösung vorbereiten

Ein wichtiger Aspekt für eine erfolgreiche gemeinsame Entwicklung ist ein strukturierter Releasemanagement-Prozess. Lösungen sind der Mechanismus zur Implementierung des Application Lifecycle Management (ALM). Sie verwenden die Lösung, um Komponenten durch Export- und Importaktivitäten über Umgebungen zu verteilen. Eine Komponente steht für ein Artefakt, das in Ihrer Anwendung verwendet wird und Sie eventuell anpassen können. Alles, was in eine Lösung aufgenommen werden kann, ist eine Komponente, z. B. Tabellen, Spalten, Canvas und modellgesteuerte Apps, Power Automate Flows, Chatbots, Diagramme und Plug-Ins.

Bereitstellungen

Komponenten können je nach Komplexität und Teamgeschwindigkeit mehrere Sprints in Anspruch nehmen. Komponenten sollten einer Lösung in einer Entwicklungsumgebung hinzugefügt werden, wenn Aufgaben erledigt werden. Lösungen werden dann in eine Produktionsumgebung importiert, nachdem sie getestet wurden. Wir empfehlen, dass Sie auch eine Testumgebung unterhalten, um Ende-zu-Ende-Tests durchzuführen und die Lösungsbereitstellung auszuprobieren, bevor Sie in die Produktion gehen.

Power Platform-Umgebungen

Umgebungen sind ein Raum zur Speicherung, Verwaltung und gemeinsamen Nutzung von Geschäftsdaten, Apps und Geschäftsprozessen Ihres Unternehmens. Sie dienen auch als Container zur Trennung von Apps, die unterschiedliche Rollen, Sicherheitsanforderungen oder Zielgruppen haben können.

Wenn Ihre Organisation über eine Fusion-Einrichtung für mehrere Teams verfügt, in der jedes Team seine eigenen Lösungen entwickelt, ist es wichtig, die Dauer von Sprints und Veröffentlichungen zu koordinieren. Sprints müssen entlang einer Projektzeitskala nicht von gleicher Länge sein und können je nach den Vorlieben der einzelnen Gruppen in der Dauer zwischen den Teams variieren. Die Veröffentlichungskadenz darf jedoch nicht geringer als die kürzeste Sprintdauer aller Teams sein.

Quellenkontrolle

Denken Sie über die Einführung eines Quellcodeverwaltungssystems wie Azure DevOps nach. Azure DevOps bietet Entwicklerdienste für Supportteams, um die Arbeit zu planen, bei der Codeentwicklung zusammenzuarbeiten und Anwendungen zu erstellen und bereitzustellen.

Eine Lösung aus Ihrer Entwicklungsumgebung exportieren, die Ihre Apps und Anpassungen enthält, Ihre Lösung entpacken und die Komponenten in Ihrem Versionsverwaltungssystem speichern.

Erweitertes Thema: Pull-Anforderung(PR)-Bewertungen

Sie sollten nur PRs für Stories erstellen, die aktiv sind und deren Funktionen überprüft und genehmigt wurden. Sie sollten sicherstellen, dass die Verwaltung der Lösungsversion korrekt ist, indem Sie die Sprint- und Entwicklungsrichtlinien befolgen, die in Implementieren der Scrum-Praktiken für Ihr Team in Azure Boards festgelegt sind. Testergebnisse aus der PR können Screenshots oder Videos sein, die die zu erstellende Funktionalität darstellen.

Die Automatisierung des PR-Governance-Prozesses trägt dazu bei, die Codequalität sicherzustellen, ohne dass grundlegende Überprüfungen wie Lösungsversionen manuell überprüft werden müssen.

Vorlagen und Standardisierung

Vorlagen und Standardisierung sorgen für Effizienz, indem sie dazu beitragen, die Konsistenz innerhalb des Teams zu fördern. Alle Aspekte des Betriebs eines Teams – ob Onboarding-Aufgaben, Präsentationen der Story-Bewertung oder Vorlagen für Arbeitselemente die helfen, Zeit zu sparen und Teams bei der Definition von User Stories, Funktionen, Fehlern oder Aufgaben zu unterstützen – profitieren von Standardisierung und Vereinfachung.

Implementieren eines effektiven Support-Modells

Ein effektives Support-Modell ist für den langfristigen Erfolg einer Anwendung nach ihrer Bereitstellung unerlässlich, wie im vorherigen Abschnitt über das Erstellen einer Support-Matrix hervorgehoben wurde. Fehler und Ausfälle sind unvermeidlich, daher ist es wichtig, dass das Team einen strukturierten Ansatz für den Umgang mit diesen Vorkommnissen hat und die Support-Matrix den notwendigen Rahmen bietet.

Erstellen der Vereinbarungen zum Servicelevel

Ein Schlüsselfaktor in jedem Support-Modell ist die Definition des Vereinbarungen zum Servicelevel (SLA). Die SLA sollte ein formelles Dokument sein, das vom Team erstellt wird und Abschnitte enthält, die die folgenden Punkte abdecken:

• Ausfälle – welches Maß an Dienstausfall ist akzeptabel, wer ist zu informieren, welche Maßnahmen sind zu ergreifen, Bestätigung der Wiederaufnahme des Dienstes und Maßnahmen, um eine Wiederholung zu verhindern. Alle automatisierten Testverfahren, die das Team verwendet, müssen mit der erwarteten Ausfalltoleranz und der anwendbaren SLA übereinstimmen.
• Fehler – wer kann benachrichtigen, Zuordnung von Schweregraden, Klassifizierung, Maßnahmen bei Erkennung, wer ist für die Lösung und Freigabe verantwortlich?
• Eskalationen – Eskalationsstufen, Zuordnung von Mitarbeitern zu Stufen, Verantwortlichkeiten auf jeder Stufe, Verteilerlisten für jede Stufe usw.

Die SLA sollte im Dokumentationsportal des Teams gespeichert und bei Bedarf aktualisiert werden.

Bereitstellen von Anwendungssupport

Der beste Ansatz für die Bereitstellung des im SLA angegebenen Anwendungssupports besteht darin, dass das Team, das die Lösung erstellt hat, auch für den Support verantwortlich ist. Die Vorteile dieses Systems sind:

1. Es fördert eine qualitativ bessere Entwicklung, denn diejenigen, die die App erstellt haben, wissen, dass sie sie unterstützen müssen.
2. Die Ersteller können Fehler schneller finden und beheben als ein Drittanbieterteam, einfach weil sie die App besser kennen.
3. Das Delegieren der Reparatur potenziell geschäftskritischer Software an eine andere Gruppe kann für diese Gruppe demoralisierend und zeitaufwändig sein. Wie in anderen Phasen der Anwendungserstellung, -entwicklung und -bereitstellung sollte das Fusion Team bei Bedarf mit der IT zusammenarbeiten, um Unterstützung zu erhalten.

Überwachung der Anwendungszufriedenheit und Benutzerfreundlichkeit

Der letzte Teil der Support-Bemühungen besteht in der Überwachung und Bewertung der Zufriedenheit und Benutzerfreundlichkeit der bereitgestellten App. Hier sind Metriken nützlich, zusammen mit traditionelleren Methoden wie Umfragen und Fragebögen. Weitere Informationen zum Überwachen der App-Nutzung finden Sie unter Admin-Analytics für Power Apps.

Wenn Kunden eine veröffentlichte App nicht verwenden, erfüllt diese App letzten Endes nicht ihren Zweck. Regelmäßige Bewertungs-Meetings können diese Metriken für Zufriedenheit und Nutzung überprüfen, um eine positive Feedback-Schleife zu schaffen, die Storys zum Backlog ändern oder hinzufügen kann, um eine aktualisierte Version der App zu generieren und dann bereitzustellen.

Übersicht

Die Entwicklung von No-Code- und Low-Code-Tools wie Power Apps bietet erweiterte Optionen für Geschäfts-Technologen oder Hersteller zum Erstellen, Entwickeln und Bereitstellen von Apps. Diese Entwicklung funktioniert am besten in einer Fusion Team-Umgebung, die aus einem Produktbesitzer, einem Domänenexperten, einem professionellen Entwickler und einem Administrator besteht, wobei dieses Team nach Bedarf andere Ressourcen einbringt.

Die Integration agiler und Scrum-Entwicklungsansätze innerhalb von Fusion Teams führt zu einer schnelleren App-Entwicklung und einer höheren Wahrscheinlichkeit einer erfolgreichen Bereitstellung mit einem Funktionsumfang, der einen erheblichen Unterschied für das Unternehmen ausmacht. Durch die Anwendung dieser bewährten Methoden, Richtlinien und Empfehlungen wird Ihr Fusion Team in der Lage sein, Power Apps zu verwenden, um die Herausforderungen der digitalen Transformation Ihres Unternehmens anzugehen.