Software-Agentur · Delivery
Softwareauslieferung und Kundenabnahme
Bringen Sie jeden Meilenstein von vereinbarten Anforderungen zu einer dokumentierten Abnahme durch den Kunden. Der Kunde bestätigt die Akzeptanzkriterien und nimmt über einen öffentlichen Link ab, und kein Build erreicht ihn, bevor QA und der Engineering Lead ihn freigeben.
- Dauer: 4 bis 8 Wochen
- Wie oft: Für jeden Meilenstein
- Schritte: 11 Schritte
- KI-Agenten: 2 KI-Agenten
- Freigaben: 3 Freigaben
Kostenloser Plan, keine Kreditkarte nötig.
Was sich mit dieser Vorlage ändert
Ohne Vorlage
Dem Kunden fällt in der Sprint-Demo ein unverzichtbares Feature ein.
Ein halb getesteter Build landet am Abend vor der Kundendemo auf Staging.
Die Abnahme ist ein Daumen hoch in einem Call, den einen Monat später niemand mehr findet.
QA schreibt jeden Testplan von Grund auf neu.
Mit der Vorlage
Der Kunde bestätigt die Akzeptanzkriterien vor Entwicklungsbeginn, sodass das Team gegen eine Liste entwickelt.
Der Kundentest bleibt gesperrt, bis QA und der Engineering Lead das Release freigeben.
Der Kunde nimmt in der Ausführung ab, mit abgehakten Prüfungen, Name und Zeitpunkt.
Ein KI-Agent entwirft den Testplan aus den Kriterien, und der QA Engineer prüft ihn.
Die Vorlage, Schritt für Schritt
Jeder Schritt zeigt, wer ihn erledigt: jemand aus Ihrem Team, ein KI-Agent oder der Kunde über einen öffentlichen Link. Eine Freigabe hält alle folgenden Schritte gesperrt, bis sie erteilt ist.
- Erledigt von Ihrem Team
- Erledigt von einem KI-Agenten
- Erledigt vom Kunden, über einen öffentlichen Link
Beginnt, wenn
Ein Meilenstein aus der Leistungsbeschreibung kann beginnen. Der Product Manager startet eine Ausführung mit Kundenname und Meilenstein.
- 1
Umfang und Akzeptanzkriterien schreiben
Woche 1Product Manager · Team
Übersetzen Sie den Meilenstein aus der Leistungsbeschreibung in User Stories mit testbaren Akzeptanzkriterien, notieren Sie die Fragen, die der Kunde noch beantworten muss, und mailen Sie beides mit den Designs an den Product Owner beim Kunden.
Checkliste
- Jede Story hat Akzeptanzkriterien
- Was nicht zum Umfang gehört, ist benannt
- Kriterien und Designs an den Kunden gesendet
Auszufüllende Felder
- Meilenstein (Pflichtfeld)
- Akzeptanzkriterien (Pflichtfeld)
- Fragen an den Kunden
- Link zu den Designs (Pflichtfeld)
- 2
Kunde bestätigt die Anforderungen
Woche 1Product Owner beim Kunden · Öffentlicher Link
Der Product Owner beim Kunden liest die Akzeptanzkriterien, Designs und Fragen, die der Product Manager gemailt hat, und beantwortet die Fragen und bestätigt den Umfang über den öffentlichen Link. Das Team entwickelt und testet gegen das, was hier bestätigt ist.
Checkliste
- Akzeptanzkriterien gelesen
- Designs angesehen
- Offene Fragen beantwortet
Auszufüllende Felder
- Antworten auf die offenen Fragen
- Link zu Geschäftsregeln oder Beispielen
- Ich bestätige die Akzeptanzkriterien (Pflichtfeld)
- 3
Testplan entwerfen
Woche 1Testplan-Autor · KI-Agent
Der Testplan-Autor macht aus jedem bestätigten Akzeptanzkriterium Testfälle mit Schritten und erwarteten Ergebnissen und ergänzt Regressionsprüfungen für die Funktionen, die der Meilenstein berührt.
Auszufüllende Felder
- Testplan-Entwurf (Pflichtfeld)
Geprüft von: Der QA Engineer prüft und vervollständigt den Testplan in Schritt 4.
- 4
Testplan prüfen
Im öffentlichen Link ausgeblendetWoche 2QA Engineer · Team
Prüfen Sie, ob jedes Akzeptanzkriterium einen Testfall hat, ergänzen Sie die Grenzfälle, die im Entwurf fehlen, und verlinken Sie den endgültigen Testplan.
Checkliste
- Jedes Kriterium hat einen Testfall
- Grenzfälle ergänzt
- Testdaten auf Staging bereit
Auszufüllende Felder
- Link zum endgültigen Testplan (Pflichtfeld)
- 5
In Sprints entwickeln und reviewen
Woche 2 bis 5Engineering Lead · Team
Entwickeln Sie die Stories in Sprints und reviewen Sie jede Änderung, bevor sie gemergt wird. Wartet das Team auf eine Antwort des Kunden, markieren Sie die Ausführung als blockiert und notieren Sie die Frage.
Checkliste
- Jede Änderung vor dem Merge reviewt
- Sprint-Demos mit dem Kunden gehalten
- Keine offenen Fragen an den Kunden
Auszufüllende Felder
- Geplantes Release-Datum (Pflichtfeld)
- Sprint-Notizen (Pflichtfeld)
- Link zu den gemergten Änderungen (Pflichtfeld)
- Worauf das Team wartet
- 6
Auf Staging gegen jedes Kriterium testen
Im öffentlichen Link ausgeblendetWoche 6QA Engineer · Team
Führen Sie den Testplan auf Staging aus, erfassen Sie Fehler im Issue-Tracker und testen Sie die Fixes erneut, bis kein kritischer oder schwerer Bug mehr offen ist.
Checkliste
- Jedes Kriterium getestet
- Regressionsprüfungen gelaufen
- Keine offenen kritischen oder schweren Bugs
- Bekannte kleine Probleme notiert
Auszufüllende Felder
- Link zum Testbericht (Pflichtfeld)
- Bekannte Probleme
Freigabe: Die Release-Freigabe bleibt gesperrt, bis der QA Engineer die Testergebnisse freigibt.
- 7
Release Notes entwerfen
Woche 6Release-Notes-Autor · KI-Agent
Der Release-Notes-Autor entwirft Release Notes für den Kunden aus den Akzeptanzkriterien, den Sprint-Notizen und den bekannten Problemen: was neu ist, was sich geändert hat und was noch offen ist.
Auszufüllende Felder
- Entwurf der Release Notes (Pflichtfeld)
Geprüft von: Der Engineering Lead korrigiert die Notes und gibt das Release in Schritt 8 frei.
- 8
Release für den Kundentest freigeben
Woche 6Engineering Lead · Team
Lesen Sie den Testbericht, korrigieren Sie die Release Notes und prüfen Sie, ob auf Staging der getestete Build läuft. Geben Sie ihn dann frei und mailen Sie dem Product Owner beim Kunden den Staging-Link und die Release Notes.
Checkliste
- Testbericht gelesen
- Release Notes korrigiert
- Auf Staging läuft der getestete Build
Auszufüllende Felder
- An den Kunden gesendeter Staging-Link (Pflichtfeld)
Freigabe: Der Kundentest bleibt gesperrt, bis der Engineering Lead das Release freigibt.
- 9
Kunde testet auf Staging und nimmt ab
Woche 7Product Owner beim Kunden · Öffentlicher Link
Der Product Owner beim Kunden testet den Build über den Link, den das Team gemailt hat, auf Staging gegen die Akzeptanzkriterien, hakt dann jede Prüfung ab und hält seine Entscheidung über den öffentlichen Link fest. Probleme gehören in das Feld darunter, mit Links zu Screenshots oder Aufzeichnungen.
Checkliste
- Jedes Akzeptanzkriterium getestet
- Release Notes gelesen
Auszufüllende Felder
- Entscheidung (Pflichtfeld)
- Gefundene Probleme
- Links zu Screenshots oder Aufzeichnungen
- 10
Über die Befunde des Kunden entscheiden
Woche 7Product Manager · Team
Gehen Sie die Entscheidung und jeden Befund mit dem Engineering Lead durch. Verhindert ein Befund die Abnahme, markieren Sie die Ausführung mit dem Grund als blockiert, bis der Fix verifiziert ist und der Kunde zustimmt, und geben Sie danach das Produktions-Release frei.
Checkliste
- Jeder Befund als blockierend oder nicht eingestuft
- Blockierende Befunde behoben und verifiziert
- Übrige Befunde für einen späteren Meilenstein geplant
Auszufüllende Felder
- In einen späteren Meilenstein verschobene Befunde
Freigabe: Das Produktions-Release bleibt gesperrt, bis der Product Manager es freigibt.
- 11
In Produktion ausrollen und den Meilenstein abschließen
Woche 7DevOps Engineer · Team
Rollen Sie den abgenommenen Build mit bereitliegendem Rollback-Plan aus, führen Sie die Smoke-Tests durch und notieren Sie die ausgerollte Version.
Checkliste
- Rollback-Plan bereit
- Smoke-Tests bestanden
- Monitoring nach dem Release geprüft
Auszufüllende Felder
- Ausgerollte Version (Pflichtfeld)
- Ausgerollt am (Pflichtfeld)
Fertig, wenn
Der Kunde hat den Meilenstein gegen die vereinbarten Kriterien abgenommen, und das Release ist live, mit Testbericht, Freigaben und Abnahme in der Ausführung.
Passen Sie sie an. Benennen Sie Schritte um, ändern Sie Verantwortliche und ergänzen Sie Checklistenpunkte, Felder oder Freigaben. Die Vorlage ist ein Ausgangspunkt für die Arbeitsweise Ihres Teams.
Die KI-Agenten in dieser Vorlage
Ein Agent arbeitet nur an seinen eigenen Schritten, und jemand aus Ihrem Team prüft, was er getan hat. Alles, was ein Agent in eine verbundene App schreibt, wartet auf Freigabe, sofern Sie es nicht ausdrücklich erlauben.
Testplan-Autor
Macht aus den bestätigten Akzeptanzkriterien einen Testplan-Entwurf.
Was er tut
- Liest die Akzeptanzkriterien und die Antworten des Kunden in der Ausführung
- Schreibt Testfälle mit Schritten und erwarteten Ergebnissen
- Ergänzt Regressionsprüfungen für die Funktionen, die der Meilenstein berührt
- Schließt seinen Schritt ab, damit der QA Engineer prüfen kann
Geprüft von: Der QA Engineer prüft und vervollständigt den Testplan in Schritt 4.
Release-Notes-Autor
Entwirft Release Notes für den Kunden zum Build, der in den Kundentest geht.
Was er tut
- Liest Akzeptanzkriterien, Sprint-Notizen und bekannte Probleme
- Schreibt, was neu ist, was sich geändert hat und was noch offen ist
- Hält die Notes für den Kunden verständlich
- Schließt seinen Schritt ab, damit die Release-Freigabe beginnen kann
Geprüft von: Der Engineering Lead korrigiert die Notes und gibt das Release in Schritt 8 frei.
Fragen, die diese Vorlage beantwortet
Lassen Sie gegen die Akzeptanzkriterien abnehmen, die der Kunde zu Beginn bestätigt hat, nicht gegen eine Demo. In Schritt 9 testet der Product Owner beim Kunden auf Staging, hakt dann jede Prüfung ab und hält seine Entscheidung über den öffentlichen Link fest, mit Name und Zeitpunkt in der Ausführung.
Vereinbaren Sie testbare Akzeptanzkriterien, bevor die Entwicklung beginnt, und lassen Sie den Kunden sie nachweisbar bestätigen. In Schritt 2 beantwortet der Product Owner beim Kunden die offenen Fragen und bestätigt die Kriterien über den öffentlichen Link, sodass das Team gegen eine vereinbarte Liste entwickelt und testet.
Machen Sie den Kundentest von freigegebenen Testergebnissen abhängig, nicht vom Demo-Termin. Schritt 6 und Schritt 8 sind Freigabeprüfungen: Der Kundentest bleibt gesperrt, bis der QA Engineer und der Engineering Lead das Release beide freigegeben haben.
Halten Sie Akzeptanzkriterien, Testergebnisse und die Entscheidung des Kunden an einer Stelle fest. Die Ausführung zeigt die in Schritt 2 bestätigten Kriterien, die Testergebnisse und Freigaben aus Schritt 6 und 8 und die Abnahme aus Schritt 9 mit Name und Zeitpunkt.
Lassen Sie KI den Testplan und die Release Notes aus dem entwerfen, was Ihr Team schon geschrieben hat, und lassen Sie die Prüfung bei Menschen. In Schritt 3 entwirft der Testplan-Autor Testfälle, die der QA Engineer in Schritt 4 prüft, und in Schritt 7 entwirft der Release-Notes-Autor Notes, die der Engineering Lead in Schritt 8 korrigiert.
Trennen Sie Bugs, die die Abnahme verhindern, von Punkten, die warten können, und lassen Sie einen Menschen entscheiden. In Schritt 10 stuft der Product Manager jeden Befund als blockierend oder nicht ein, hält die Ausführung blockiert, bis blockierende Fixes verifiziert sind, und gibt erst dann das Release frei.
Führen Sie diesen Workflow in OKiDO aus
Richten Sie Schritte, Verantwortliche und Freigaben einmal ein und starten Sie dann für jeden neuen Fall eine Ausführung.