Empfehlungen für die Formalisierung der Softwareentwicklung und -verwaltung

  • Artikel

Gilt für diese Checklistenempfehlung für Azure Well-Architected Framework Operational Excellence:

OE:03 Formalisieren von Softwareideen und Planungsprozessen. Greifen Sie auf etablierte Branchen- und Organisationsstandards zu. Verwenden Sie ein gemeinsames, priorisiertes Backlog und ausreichend detaillierte Spezifikationen. Führen Sie basierend auf den Ergebnissen kontinuierliche Verbesserungen in Ihrem Planungsprozess durch.

In diesem Leitfaden werden die Empfehlungen für die Verwaltung von Softwareentwicklungspraktiken gemäß den etablierten Standards beschrieben. Die Fähigkeit Ihres Teams, qualitativ hochwertige Software zu produzieren, basiert auf einem strukturierten, kollaborativen Ansatz für die Entwicklungsplanung. Produktbesitzer und Manager müssen in der Lage sein, die Arbeit, die Entwickler zu jeder Zeit in einem Entwicklungszyklus ausführen, klar zu verstehen und den Stakeholdern zu artikulieren. Umgekehrt müssen Entwickler die Ziele des Entwicklungszyklus über gut geschriebene Features, User Storys und Akzeptanzkriterien verstehen. Etablierte Standards definieren, wie Entwicklungsmethoden durchgeführt werden sollen, und ermöglichen es dem Workloadteam, effektiv zusammenzuarbeiten, wodurch das Risiko von Verwirrung bei Zielen und Erwartungen verringert wird.

Wichtige Entwurfsstrategien

Formalisieren Sie Ihre Softwareentwicklungsmethoden, um sicherzustellen, dass Produktbesitzer, Projektmanager und Entwickler die Ziele jedes Sprints verstehen und den Beteiligten konsistente Qualität bieten. Anleitungen zu Entwicklungsmethoden finden Sie im Leitfaden für continuous Integration.

Standards für die Entwicklungsplanung

  • Zusammenarbeit: Der Prozess der Definition der vorgeschlagenen Änderungen an der Workload sollte eine zusammenarbeitende Aufgabe sein. Die meisten Änderungen an der Workload wirken sich auf mehrere Funktionen und/oder Komponenten aus, sodass die Einbeziehung von so vielen Workload-Teammitgliedern wie möglich dazu beitragen kann, sicherzustellen, dass wichtige Überlegungen nicht übersehen werden und dass sich alle über die Auswirkungen auf ihre jeweilige Domäne bewusst sind. Die Zusammenarbeit hilft auch dabei, den Umfang einer Änderung klar zu definieren und die erforderlichen Aufgaben, die zur Durchführung der Änderung erforderlich sind, in klar definierte Arbeitselemente aufzuteilen, da eine größere Gruppe mit Fachwissen in allen Domänen in der Lage sein wird, erfahrungsbasierte Schätzungen für den erforderlichen Aufwand bereitzustellen.

  • Tools: Verwenden Sie etablierte, branchenerprobte Tools und Prozesse wie Agile, Scrum und Kanban Boards. Die Entwicklung eigener Tools und Prozesse ist ein wichtiges Unterfangen, das Zeit und Entwicklungszyklen in Anspruch nimmt, die andernfalls für Ihre Workload aufgewendet werden könnten. Die meisten erfahrenen DevOps-Ingenieure und Produktbesitzer sind mit diesen Arten von Tools und Prozessen vertraut, daher sollte die Lernkurve bei der Einführung minimal sein. Ebenso wird der Onboarding-Prozess für neue Mitarbeiter auch von der Verwendung von Standardtools und -prozessen profitieren, da sie wahrscheinlich bereits mit den gleichen Tools und Prozessen beschäftigt sind.

Kompromiss: Agile Methodik kann zu streng werden, wenn sie übermäßig vorgeschrieben ist. Streben Sie nach einer Balance zwischen klar definierten Standards und Innovation.

  • Bereitstellung: Planen Sie die Verwendung häufiger kleiner, iterativer Bereitstellungen anstelle von großen seltenen Bereitstellungen. Mit diesem Ansatz können Benutzergeschichten und Arbeitselemente vom Standpunkt des Projektmanagements aus verwaltbar bleiben und das Risiko von umfangreichen Problemen bei fehlschlagenden Bereitstellungen verringert werden.

  • Begriffe: Standardisieren Sie Ihre Definition der abgeschlossenen Entwicklungszyklen, um sicherzustellen, dass unterstützende Funktionen, einschließlich Tests, Dokumentation und Barrierefreiheitsfeatures, erfolgreich abgeschlossen werden.

  • Kommunikation: Definieren Sie die Standardprotokolle für Produktbesitzer und Projektmanager, um anstehende Releases intern und extern zu fördern. Sie können beispielsweise einen Standard für die Kommunikation mit externen Parteien über anstehende Releases einrichten. Der Standard kann vorschreiben, dass die Kommunikation zwei Wochen vor der Veröffentlichung gesendet und 24 Stunden vor der Veröffentlichung eine Erinnerung gesendet werden sollte.

  • Benutzergeschichten: Standardisieren Sie eine Vorlage für User Storys. Stellen Sie sicher, dass jeder Benutzerabschnitt eine separate Arbeitseinheit ist, die aus der Perspektive des Endbenutzers geschrieben wird. Gut geschriebene Benutzergeschichten sollten die folgenden Merkmale aufweisen:

    • Jede User Story sollte völlig unabhängig voneinander sein. Die Unabhängigkeit von Benutzergeschichten vermeidet Verwirrungen mit überlappenden Arbeiten und hilft dem Team zu verstehen, ob die Arbeit an einer bestimmten Benutzergeschichte von der Arbeit an anderen abhängig ist, was bei der Planung und Priorisierung hilfreich ist.

    • Jede Benutzergeschichte ist verhandelbar. Die Perspektiven von Endbenutzern und Workload-Teammitgliedern sind unerlässlich, um realistische Benutzergeschichten zu erfassen, die über einen kurzen Zeitraum erreicht werden können.

    • User Storys sind für den Endbenutzer wertvoll. Wenn Sie Benutzergeschichten aus der Perspektive des Endbenutzers schreiben, erfassen Sie die Änderungen, an denen sie interessiert sind, und die ihrer Erfahrung einen Mehrwert verleihen. Wenn Sie diesen Fokus beibehalten, während die Benutzergeschichte in Arbeitselemente unterteilt wird, können Sie sicherstellen, dass jede Bereitstellung eine verbesserte Benutzeroberfläche bietet.

    • Der Aufwand, der für eine User Story erforderlich ist, ist mit einem hohen Maß an Vertrauen abschätzbar. Ohne eine genaue Annäherung an die für eine bestimmte Benutzergeschichte erforderlichen Stunden zu haben, wird die Planung schwierig und das Potenzial für fehlende Termine steigt, was möglicherweise kaskadierende Auswirkungen auf andere geplante Arbeiten verursacht.

    • Gut geschriebene User Storys sind klein, sodass sie innerhalb weniger Wochen abgeschlossen werden können. Kleinere bereichsbezogene Geschichten tragen dazu bei, dass sie abschätzbar und verwaltbar bleiben und arbeitsbezogene Elemente ausgeführt werden können.

    • User Storys sollten testbar sein. Ohne testen zu können, dass ein Feature bereitgestellt wurde, kann der Endbenutzer nicht darauf vertrauen, dass das Ziel erreicht wurde. Auch wenn ein Test noch nicht für eine bestimmte Benutzergeschichte geschrieben wurde, sollte es ein klares Verständnis dafür geben, wie ein Test entwickelt werden kann, um die Bereitstellung des Features nachzuweisen.

  • Akzeptanzkriterien: Standardisieren Sie eine Vorlage für Akzeptanzkriterien. Stellen Sie sicher, dass sich die Akzeptanzkriterien speziell auf die User Story beziehen und anhand eines oder mehrerer Akzeptanztests eindeutig nachgewiesen werden können.

  • Ablaufverfolgung: Stellen Sie sicher, dass der Entwicklungsprozess nachverfolgt werden kann. Sie sollten den Zustand Ihrer Produktionsworkload und des zugehörigen Codes eindeutig auf Qualitätssicherungstests, Akzeptanzkriterien, User Stories und Features zurückverfolgen. Eine detaillierte Ablaufverfolgung kann in einigen Fällen auch eine gesetzliche Anforderung sein, z. B. im Gesundheitswesen.

  • Überprüfung: Führen Sie regelmäßig interne Audits Ihrer Entwicklungspraktiken über Entwicklungszyklus-Retrospektiven und Postmorteme durch. Prozessreflektion sollte schuldlos sein und sich auf das Lernen konzentrieren, das als Verbesserungen angewendet werden kann. Stellen Sie sicher, dass das Team die Effektivität der Benutzergeschichte und -aufgaben beim Definieren der erforderlichen Aufgaben und der Genauigkeit der Zeitschätzungen berücksichtigt.

  • Berichte: Standardisieren Sie Berichte für Stakeholder, die nützliche Metriken bereitstellen, die sich auf Änderungen konzentrieren. Wenn Sie sich auf Veränderungen konzentrieren, können Sie produktbeschleunigung und -verzögerung nachverfolgen. Hilfreiche Metriken können Änderungen in folgenden Enthalten:

    • Die monatliche Wachstumsrate der Einführung.

    • Leistung.

    • Trainingszeit.

    • Die Häufigkeit von Vorfällen.

    Die Berichterstellung sollte nicht als Tool zum Bewerten der Arbeit von Einzelpersonen verwendet werden, daher vermeiden Sie Metriken wie Storypunkte oder Codezeilen für jeden Techniker.

Azure-Erleichterung

Azure Boards ist ein webbasierter Dienst, mit dem Teams die Arbeit über den gesamten Entwicklungsprozess planen, nachverfolgen und diskutieren können. Es eignet sich gut für agile Entwicklungsmethoden.

GitHub Projects ist ein anpassbares Projektverwaltungstool, das Projekte organisieren und integrieren kann, indem Probleme und Pull Requests in GitHub verwendet werden.

Checkliste für operationale Exzellenz

Weitere Informationen finden Sie im vollständigen Satz von Empfehlungen.

Checkliste für operationale Exzellenz