Scope-Kontrolle: neue Features von Release Blockers trennen

Ein gesperrter Feature Scope schützt das Spiel, das Clowdr genehmigt hat. Er entschuldigt keinen defekten kritischen Pfad, fehlende Credits oder Assets unterhalb der Quality Baseline. Solche Probleme können Release Blockers werden, selbst wenn alle geplanten Tickets abgeschlossen sind.

Entscheidend ist die Wirkung einer Änderung: Eine neue Fähigkeit für Spieler erweitert das Spiel; ein Release Blocker macht das bereits genehmigte Spiel veröffentlichbar. Dieser Leitfaden wendet die Unterscheidung aus Clowdrs Produktionsprozess und ADR 0005 an.

Einen Wunsch prüfen, bevor daraus eine Aufgabe wird

Beantwortet für jede vorgeschlagene Änderung fünf Fragen:

1. Welcher genehmigten Fähigkeit oder welchem Player Promise dient sie?
2. Was scheitert ohne sie, und wo ist das sichtbar?
3. Repariert sie das genehmigte Erlebnis oder fügt sie eine neue Fähigkeit hinzu?
4. Welche Integrations- und Prüfaufgaben entstehen dadurch?
5. Wer entscheidet, verantwortet die Arbeit und hält das Ergebnis fest?

Ein hypothetischer Fehler in der Controller-Navigation, der den Start des genehmigten Spiels verhindert, ist ein Blocker. Ein zweiter Kampfmodus ist ein neues Feature. Ihn „Polish“ zu nennen, ändert seinen Umfang nicht.

Fachliche Qualitätsprobleme brauchen dieselbe Sorgfalt. Unlesbares Feedback zu korrigieren kann nötig sein, um die genehmigte Baseline zu erreichen. Ein neues System für visuelle Anpassungen darf nicht über diese Korrektur in den Umfang gelangen.

Gestrichene Features außerhalb der aktuellen Zusage halten

Sammelt abgelehnte Ergänzungen in einer separaten Liste für spätere Pitches. Haltet jeweils einen kurzen Grund und das Entscheidungsdatum fest. So bleibt die Idee verfügbar, ohne Contributors eine versteckte Zusage zu machen.

In der Slice Phase bleibt übernehmbare Arbeit auf den Vertical Slice beschränkt. Erst nach Genehmigung der Quality Baseline öffnet sich der übrige genehmigte Feature Scope für die Production. Keine dieser Freigaben erlaubt eine stille Erweiterung, weil eine einzelne Aufgabe leicht aussah.

Wenn der genehmigte Umfang nicht mehr zur Kapazität passt, bringt den Konflikt zum Lead und zu Clowdr. Dokumentiert jede genehmigte Änderung und ihre Wirkung auf den Player Promise. Lasst keinen versprochenen Teil des Erlebnisses still entfallen.

Ein Termin hebt den Standard nicht auf

Prüft zum geplanten Veröffentlichungstermin den integrierten Build und offene Blocker. Streicht zuerst nicht genehmigte Ergänzungen. Erledigt die Arbeit, die der genehmigte Umfang braucht, und reicht einen Release Candidate ein, sobald das Projekt Done ist.

Der Lead kann die Veröffentlichung nicht erklären, um einen Kalendertermin einzuhalten. Clowdr prüft in der Publication Review die Five Proofs of Release und kann Überarbeitung verlangen oder die Veröffentlichung ablehnen.

Der Vertical-Slice-Leitfaden erklärt die Baseline; How We Ship beschreibt den Veröffentlichungsweg. Dieser Entscheidungstest hilft bei der Einordnung von Arbeit. Er garantiert keinen Projektabschluss.