[MELDEN] Von der Vision zum Code: Ein Leitfaden zur Ausrichtung der Geschäftsstrategie auf die Ziele der Softwareentwicklung ist veröffentlicht!
HOL ES DIR HIER

Definition von Fertig — Checkliste für User Story und für Sprint

readtime
Last updated on
February 18, 2025

A QUICK SUMMARY – FOR THE BUSY ONES

TABLE OF CONTENTS

Definition von Fertig — Checkliste für User Story und für Sprint

Einführung

Definition von Erledigt ist ein Dokument, das die Grundlage für die Arbeit im Scrum-Team bildet und in vielen Fällen ausreicht, um den optimalen Softwareentwicklungsprozess durchzuführen.

Aber warum brauchen wir eigentlich die DoD-Checkliste?

Das ist ganz einfach.

Jedes Teammitglied sollte verstehen, was „Erledigt“ wirklich bedeutet. Weil die Arbeit in agilen Teams weitgehend auf gegenseitigem Vertrauen zwischen den Teammitgliedern basiert. Jeder muss die gleiche Definition dieses Wortes haben und kann (ohne zusätzliche Überprüfung) sicher sein, dass, wenn ein bestimmter Bereich als Erledigt markiert wurde, nichts passiert, außer der Bestätigung durch den Seite des Produkteigentümers, was uns vom Einsatz abhält.

Checklisten für User Stories und Sprints hilf uns, produktiv zu bleiben. Jedes Mitglied muss über großartige Tools verfügen, um die Teamproduktivität zu steigern.

Natürlich ist auch das beste Dokument kein Ersatz für eine gute Kommunikation innerhalb des Teams. Wir sollten jedoch jede Möglichkeit nutzen, um unseren Prozess einfacher und transparenter zu gestalten, und die DoD-Checkliste ist eine der besten Möglichkeiten, dies zu tun.

Vorteile einer User Story und einer Sprint-Checkliste

  • Prozessstandardisierung und langfristig bessere Einschätzung der Aufgabendauer
  • Eine Steigerung der Softwarequalität
  • Weniger kleine Bugs/Bugfixes aufgrund gut getesteter Funktionen in jeder Version
  • Bessere Teamkommunikation — Jeder hat die gleiche Definition von erledigt und den Prozess, den es zu befolgen gilt

Ein Beispiel für DoD von Brainhub

Als wir beschlossen, das DoD in unserem Unternehmen einzurichten, haben wir gemeinsam eine kurze Liste von Bereichen erstellt, die wir kontrollieren sollten, um Software von höchster Qualität zu liefern. Wir haben erstellt zwei Checklisten, die uns bei der Überprüfung unserer Arbeit in zwei Phasen des Softwareentwicklungsprozesses helfen.

#1. Definition der Checkliste „Fertig“ für eine User Story

Die erste und grundlegendste Ebene ist eine einzelne User Story, in der wir die Einhaltung der ursprünglichen Annahmen eines einzelnen Backlog-Elements überprüfen, die darin beschrieben wurden.

In dieser Phase kontrollieren wir auch die Qualität des geschriebenen Codes und prüfen, ob alle notwendigen Elemente unseres Prozesses ausgeführt wurden (z. B. QA-Sitzung oder Tests in der Testumgebung).

  1. Produzierter Code für vermutete Funktionalitäten
  2. Produzierter Code für vermutete Funktionalitäten
  3. Annahmen von US Met
  4. Projekt wird ohne Fehler erstellt
  5. Geschriebene und bestandene Komponententests
  6. Das Projekt wurde in der Testumgebung bereitgestellt, die mit der Produktionsplattform identisch ist
  7. Tests auf Geräten/Browsern, die in den Projektannahmen aufgeführt sind, wurden bestanden
  8. QA-Sitzung (Qualitätssicherung) durchgeführt
  9. Probleme aus der QA-Sitzung wurden behoben
  10. Refactoring abgeschlossen
  11. Alle dokumentierten Änderungen an der Konfiguration oder am Build
  12. Dokumentation aktualisiert (falls vorhanden)
  13. PCR (Peer Code Review) durchgeführt

Drucken Sie Ihr eigenes KOSTENLOSE Checkliste für User Storys finden Sie hier.

#2. Definition der Checkliste „Fertig“ für den Sprint

Die zweite Phase, für die wir uns entschieden haben, ist Sprint, in der wir den größten Teil unserer Arbeit überprüfen. Hier können wir sehen, ob alle implementierten Funktionen ihre ursprünglichen Annahmen erfüllen und ob alle erforderlichen Bedingungen für den Produktionseinsatz erfüllt wurden.

  1. Das Verteidigungsministerium der USs traf sich für jeden einzelnen US, der im Sprint enthalten war
  2. Alle „zu erledigenden Aufgaben“ im Code sind abgeschlossen
  3. Alle Komponententests bestanden
  4. Produkt-Backlog aktualisiert
  5. Das Projekt wurde in der Testumgebung bereitgestellt, die mit der Produktionsplattform identisch ist
  6. Die Tests auf den in der Dokumentation aufgeführten Geräten/Browsern wurden bestanden
  7. Tests der Abwärtskompatibilität bestanden
  8. Die Leistungstests wurden bestanden
  9. Alle Bugs behoben
  10. Sprint, der vom Product Owner als bereit für den Produktionseinsatz markiert wurde

Drucken Sie Ihr eigenes KOSTENLOSE Sprint-Checkliste hier.

Schlüsse

Gut vorbereitet Die Definition der Checkliste „Erledigt“ kann die tägliche Arbeit erleichtern und beschleunigen eines Softwareentwicklungsteams. Präzise definierte Kriterien zur Überprüfung der geleisteten Arbeit ermöglichen es, viele Konflikte zu vermeiden, die sich aus Missverständnissen zwischen Teammitgliedern und daraus resultierenden Verzögerungen ergeben können.

Seien Sie jedoch vorsichtig. Eine zu detaillierte DoD-Checkliste kann dazu führen, dass viel Zeit verschwendet wird keine unnötigen Formalitäten. Wir dürfen auch nicht vergessen, dass dieses Dokument nicht alle Probleme löst.

Es kann weder eine gute Teamkommunikation noch präzise Funktionsanforderungen ersetzen. Aber wenn es Teil eines gut funktionierenden Prozesses ist, könnte es viele Probleme lösen und helfen, etwas Zeit für etwas Angenehmes als Überstunden zu sparen.

Frequently Asked Questions

No items found.

Our promise

Every year, Brainhub helps 750,000+ founders, leaders and software engineers make smart tech decisions. We earn that trust by openly sharing our insights based on practical software engineering experience.

Authors

Matt Warcholinski
github
Chief Growth Officer

Ein Serienunternehmer, leidenschaftlicher Forschungs- und Entwicklungsingenieur mit 15 Jahren Erfahrung in der Technologiebranche. Teilt sein Expertenwissen über Technologie, Startups, Geschäftsentwicklung und Marktanalysen.

Matt Warcholinski
github
Chief Growth Officer

Ein Serienunternehmer, leidenschaftlicher Forschungs- und Entwicklungsingenieur mit 15 Jahren Erfahrung in der Technologiebranche. Teilt sein Expertenwissen über Technologie, Startups, Geschäftsentwicklung und Marktanalysen.

Read next

No items found...

previous article in this collection

It's the first one.

next article in this collection

It's the last one.