Co-Entwicklungs-Governance

Die Etablierung eines effektiven Rahmens für die Co-Development-Governance ist ein wichtiger Bestandteil der Sicherstellung von Konsistenz und Wiederholbarkeit in herstellerdefinierten Projekten und Fusionsteams. In diesem Artikel wird ein Ansatz zum Definieren eines Governance-Flussdiagramms beschrieben.

Festlegung des End-to-End-Prozesses

Sie können den folgenden Prozess als Beispiel verwenden und an die bewährten Methoden Ihrer Organisation anpassen. Es ist nicht erforderlich, jeden einzelnen Schritt abzuschließen, solange Sie das erforderliche Ergebnis erzielen.

Hinzufügen von Features zum Backlog

Mithilfe von Backlogs können Sie Ihr Projekt planen, indem Sie Features hinzufügen, die die Gesamterfahrung fördern. Der Backlog bietet auch die allgemeine Roadmap, die das Team liefern will.

Wenn Sie dem Backlog ein neues Feature hinzufügen, besteht das Ziel darin, den allgemeinen Umfang zu beschreiben. Jedes Feature definiert dann den Geschäftswert, den Entwurf von Geschichtentiteln, den Umfang und die Datenmodelländerungen, die die Bemühungen der Codeentwicklung leiten.

Darüber hinaus wird empfohlen, beim Hinzufügen eines unternehmenskritischen Features alle kritischen Szenarien zu identifizieren, um Ihre Tests zu automatisieren. Nachdem Sie Ihre Features hinzugefügt haben, können Sie Ihre Bereichsausrichtungsbesprechung planen.

Bereichsausrichtungsbesprechung

Der Fokus dieser Besprechung sollte darauf beschränkt sein, jedes vorgeschlagene neue Feature zu überprüfen und dann nach vorhandenen Apps, Szenarien oder Datenmodellen zu suchen, die diese Funktionalität bereits bereitstellen, um Doppelarbeit zu vermeiden. Diese Besprechung bietet auch die Möglichkeit, die Auswirkungen auf andere Apps zu besprechen. Schließlich sollten Sie überprüfen, ob für dieses Feature eine Erfahrungsprüfung erforderlich ist.

Geschichten und Storyboards zum Backlog hinzufügen

Nach dem Scope-Alignment-Meeting können alle Entwurfstitel von Benutzerstorys unter dem Feature angefügt werden. Zu diesem Zeitpunkt sind keine Details erforderlich, und der Status der Benutzer-Story ist "Neu". Sie können Stories entweder im Backlog oder in der Boardansicht anzeigen.

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

An diesem Punkt ist es wichtig, die Qualität aufrechtzuerhalten, indem Arbeit nach Arbeitsstrom und Anwendung organisiert wird. Dieser Ansatz trägt dazu bei, verwandte Aufgaben zusammenzuhalten und erlaubt Experten in jedem Arbeitsstream, die Funktionalität und die Datennutzung innerhalb jeder Anwendung zu entwickeln und zu pflegen.

Erfahrungsüberprüfung

Erfahrungsüberprüfungen sollten sich auf die Endbenutzererfahrung konzentrieren und sicherstellen, dass Ihr Team den bewährten Methoden der Organisation folgt. Diese Konsistenz stellt sicher, dass alle Ihre Apps eine zuverlässige und wiederholbare Erfahrung für Endbenutzer und Supportteams bieten.

Hinzufügen von Storydetails

Das Hinzufügen einer typischen Benutzererzählung kann die folgenden Informationen umfassen:

1. Titel: As a <persona>, I can <do something> so that <impact/priority/value>
2. Beschreibung: Die Beschreibung enthält (obwohl sie nicht beschränkt ist) bestimmte Wichtige Details, z. B.:
   • Kurze Beschreibung des Szenarios, das das gewünschte Ergebnis zusammenfasst
   • Narrativ – beschreibt die Aktionen, die Benutzer ausführen, um das Szenario zu navigieren und zu erreichen.
   • Alternative Erzählung – beschreibt andere Möglichkeiten, wie Benutzer dasselbe Ergebnis erreichen können
   • Entwurfsnotizen – erfasst die Entität, Felder, Ansichten, Mockup-Bildschirme und Geschäftsregeln, die der Benutzerstory zugeordnet sind.
   • Betroffene Sicherheitsrollen – listet alle betroffenen Sicherheitsrollen auf oder die für den Benutzerverlauf relevant sind.

Nachdem Sie alle diese Details hinzugefügt haben, ändern Sie den Status der Benutzergeschichte in "Bereit für die Überprüfung". In den meisten Fällen überprüfen das Featureteam und das Geschäftsteam (falls zutreffend) die Benutzergeschichten.

Story-Überprüfung

Story-Bewertungen finden normalerweise innerhalb des Fusionsteams statt, um sicherzustellen, dass alle Details in der Story genannt werden und dass es keine Zweideutigkeiten gibt. Nach Abschluss aller Rezensionen empfiehlt es sich, dem Teammitglied die Benutzergeschichte zuzuweisen. Die Sicherstellung, dass Ihr Team während des Entwicklungsprozesses ausgerichtet bleibt, ist entscheidend, um Ihre Gesamtziele zu erreichen.

Hinzufügen von Aufgaben und Testfällen

Nachdem Sie die Geschichten überprüft haben, erstellen Teammitglieder Aufgaben in Azure DevOps. Der allgemeine Prozess zum Hinzufügen von Aufgaben und Testfällen lautet wie folgt:

1. Öffnen Sie einen Sprint-Backlog. Alternativ können Sie einen neuen Sprint erstellen.
2. Fügen Sie dem Sprint vorhandene Arbeitsaufgaben hinzu. Wenn Sie bereits Arbeitsaufgaben hinzugefügt haben, die nicht im Sprint angezeigt werden, sollten Sie deren Bereichs- und Iterationspfade überprüfen. Denken Sie daran, alle nicht übergeordneten Aufgaben den relevanten Arbeitselementen zuzuweisen.
3. Fügen Sie Aufgaben zu Backlogelementen hinzu. Wenn Sie Ihrem Sprint keine Backlog-Elemente zugewiesen haben, tun Sie dies jetzt. Legen Sie außerdem die Start- und Enddaten des Sprints fest.
4. Füllen Sie das Aufgabenformular aus. Als Faustregel sollten Vorgänge nicht länger als einen Tag dauern. Vorgänge, die größer als diese Zeitskala sind, sollten aufgeschlüsselt 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 die Sprintkapazität festlegen.

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

Vorbereiten von Lösungen

Ein wichtiger Aspekt der erfolgreichen Co-Entwicklung ist ein strukturierter Release-Management-Prozess. Lösungen sind der Mechanismus für die Implementierung der Anwendungslebenszyklusverwaltung (APPLICATION Lifecycle Management , ALM); Sie verwenden Lösungen zum Verteilen von Komponenten über Umgebungen über Export- und Importaktivitäten. Eine Komponente stellt ein Artefakt dar, das in Ihrer Anwendung verwendet wird, und etwas, das Sie potenziell anpassen können. Alles, was in eine Lösung einbezogen werden kann, ist eine Komponente, z. B. Tabellen, Spalten, Canvas und modellgesteuerte Apps, Power Automate Flows, Chatbots, Diagramme und Plug-Ins.

Bereitstellungen

Die Fertigstellung von Komponenten kann je nach Komplexität und Arbeitsgeschwindigkeit des Teams mehrere Sprints in Anspruch nehmen. Komponenten sollten einer Lösung in einer Entwicklungsumgebung hinzugefügt werden, wenn Aufgaben abgeschlossen werden. Anschließend werden Lösungen nach dem Testen in eine Produktionsumgebung importiert. Es wird empfohlen, auch eine Testumgebung beizubehalten, um End-to-End-Tests durchzuführen und die Lösungsbereitstellung auszuprobieren, bevor Sie zur Produktion wechseln.

Power Platform-Umgebungen

Umgebungen sind ein Raum zum Speichern, Verwalten und Freigeben der Geschäftsdaten, Apps und Geschäftsprozesse Ihrer Organisation. Sie dienen auch als Container zum Trennen von Apps, die möglicherweise unterschiedliche Rollen, Sicherheitsanforderungen oder Zielgruppen aufweisen.

Wenn Ihre Organisation über ein Fusionssetup mit mehreren Teams verfügt, bei dem jedes Team eigene Lösungen entwickelt, ist es wichtig, die Dauer von Sprints und Releases zu koordinieren. Sprints müssen nicht über eine einheitliche Länge entlang einer Projektzeitachse verfügen und können je nach den Vorlieben jeder Gruppe in der Dauer zwischen Teams variieren. Die Veröffentlichungskadenz darf jedoch nicht geringer als die kürzeste Sprintdauer aller Teams sein.

Quellcodeverwaltung

Erwägen Sie die Einführung eines Quellcodeverwaltungssystems wie Azure DevOps. Azure DevOps stellt Entwicklerdienste für Supportteams bereit, um Arbeit zu planen, an 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-Request-(PR)-Reviews

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

Durch die Automatisierung des PR-Governanceprozesses wird die Codequalität sichergestellt, ohne dass eine manuelle Überprüfung grundlegender Prüfungen wie Lösungsversionen erforderlich ist.

Vorlagen und Standardisierung

Vorlagen und Standardisierung liefern Effizienz, indem sie die Konsistenz innerhalb des Teams 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 Supportmodells

Ein effektives Supportmodell ist für den langfristigen Erfolg einer Anwendung nach der Bereitstellung unerlässlich, wie im vorherigen Abschnitt zum Generieren einer Supportmatrix hervorgehoben. Fehler und Ausfälle sind unvermeidlich, daher ist es wichtig, dass das Team einen strukturierten Ansatz für den Umgang mit diesen Vorkommen hat, und die Supportmatrix stellt das erforderliche Framework bereit.

Erstellung des Service-Level-Agreements

Ein wichtiger Faktor für jedes Supportmodell ist die Definition des Service Level Agreement (SLA). Die SLA sollte ein formelles Dokument sein, das das Team erstellt, das Abschnitte enthält, die die folgenden Elemente abdecken:

• Ausfälle – welche Dienstausfallstufe akzeptabel ist, wer darüber informiert werden soll, welche Maßnahmen ergriffen werden sollen, die Wiederaufnahme des Diensts bestätigen und maßnahmen, um eine Wiederholung zu verhindern. Alle automatisierten Testverfahren, die das Team verwendet, müssen mit der erwarteten Ausfalltoleranz und der entsprechenden 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 , Zuweisung von Mitarbeitern zu Ebenen, Zuständigkeiten auf jeder Ebene, Verteilerlisten für jede Ebene usw.

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

Bereitstellen von Anwendungsunterstützung

Der beste Ansatz für die Bereitstellung der im SLA festgelegten Anwendungsunterstützung ist, dass das Team, das die Lösung erstellt hat, auch die Unterstützung übernimmt. Die Vorteile dieses Systems sind:

1. Es fördert eine bessere Qualitätsentwicklung, da 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 Fixierung potenziell unternehmenskritischer Software an eine andere Gruppe kann für diese Gruppe demoralisieren und zeitaufwändig sein. Wie bei anderen Phasen der Anwendungserstellung, Entwicklung und Bereitstellung sollte das Fusionsteam bei Bedarf mit der IT zusammenarbeiten.

Überwachen der Anwendungszufriedenheit und Benutzerfreundlichkeit

Der letzte Teil des Supportaufwands ist die Überwachung und Bewertung der Zufriedenheit und Nutzbarkeit der bereitgestellten App. Metriken sind hier hilfreich, zusammen mit herkömmlicheren Methoden wie Umfragen und Fragebogen. Weitere Informationen zur Überwachung der App-Nutzung finden Sie unter Admin Analytics für Power Apps.

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

Zusammenfassung

Die Entwicklung von No-Code- und Low-Code-Tools wie Power Apps verfügt über erweiterte Optionen für Unternehmenstechnologen oder -hersteller, um Apps zu erstellen, zu entwickeln und bereitzustellen. Diese Entwicklung funktioniert am besten in einer Fusionsteamumgebung, bestehend aus einem Produktbesitzer, einem Domänenexperten, einem Pro Dev und einem Administrator, mit diesem Team, das andere Ressourcen nach Bedarf einbringt.

Die Integration von Agile- und Scrum-Entwicklungsansätzen in Fusionsteams führt zu einer schnelleren App-Entwicklung und einer höheren Wahrscheinlichkeit einer erfolgreichen Bereitstellung mit einem Featuresatz, der einen erheblichen Unterschied zum Unternehmen macht. Durch die Anwendung dieser bewährten Methoden, Richtlinien und Empfehlungen kann Ihr Fusionsteam Power Apps verwenden, um die Herausforderungen der digitalen Transformation Ihrer Organisation zu beheben.