Wenn eine PHP-Initiative von anderen Teams, Services oder Geschäftsentscheidungen abhängt, reicht es nicht, die Arbeit in Aufgaben aufzuteilen. Ein Team kann viele Aufgaben abschließen – eine Tabelle erstellen, eine API vorbereiten oder eine Queue konfigurieren –, ohne dass jemand das Ergebnis nutzen oder bewerten kann. Entscheidend ist nicht, wie viel Arbeit in einen Sprint passt, sondern welche überprüfbare Änderung am Ende verfügbar sein wird und was sie dafür benötigt.
Bei der Planung kleiner Lieferungen in PHP-Projekten geht es darum, Unsicherheit durch Inkremente zu verringern, die überprüft, getestet und gegebenenfalls für Nutzerinnen und Nutzer freigegeben werden können. Das bedeutet nicht, alle Abhängigkeiten zu beseitigen oder vom ersten Tag an eine endgültige Architektur zu erzwingen. Es bedeutet, Abhängigkeiten sichtbar zu machen und jedes Inkrement so zu gestalten, dass sich etwas Konkretes daraus lernen lässt, ohne technischen Fortschritt mit geliefertem Mehrwert zu verwechseln.
Beginnt mit dem Wertstrom statt mit der Aufgabenliste
Beschreibt, welches Bedürfnis erfüllt werden soll, wer davon profitiert und wie der vollständige Ablauf vom Eingang bis zum Ergebnis aussieht. In einer PHP-Anwendung kann dieser Ablauf eine Benutzeroberfläche, Geschäftsregeln, Persistenz, eine externe API und eine Aktion eines anderen Teams umfassen. Eine einfache Übersicht sollte Folgendes zeigen:
- Die Schritte, die Nutzerinnen und Nutzer oder das auslösende System ausführen.
- Die PHP-Komponenten und Services, die Daten verarbeiten oder speichern.
- Integrationen, Daten oder Berechtigungen, die andere Teams bereitstellen.
- Offene Entscheidungen, die das erwartete Verhalten ändern könnten.
Notiert für jede Abhängigkeit, wer dafür zuständig ist, was genau benötigt wird, wann es verfügbar sein muss und welche Alternative es bei einer Verzögerung gibt. „Auf das Datenteam warten“ ist zu ungenau. „Die ID und den zulässigen Status erhalten, um Anfragen abzufragen“ ermöglicht ein Gespräch über einen konkreten Vertrag. Unterscheidet außerdem zwischen einer tatsächlichen Abhängigkeit und einer bloßen Präferenz: Vielleicht braucht das Team den endgültigen Service nicht, um den ersten Ablauf zu überprüfen.
Wählt ein erstes vertikales Inkrement, das sich bewerten lässt
Ein vertikales Inkrement durchläuft die erforderlichen Teile, um ein beobachtbares Ergebnis zu erzeugen, auch wenn sein Umfang begrenzt ist. Es kann beispielsweise eine einzige Anfrageart annehmen, eine begrenzte Auswahl an Regeln anwenden und den Status in einer internen Ansicht anzeigen. Es muss nicht alle Fälle abdecken, sollte aber einen durchgängigen Ablauf mit ausreichend repräsentativen Daten und Verhaltensweisen erproben.
Vergleicht mögliche Inkremente anhand von vier Fragen:
- Wer kann das Ergebnis bewerten? Bestimmt eine nutzende Person, eine verantwortliche Person aus dem Fachbereich oder ein konsumierendes System.
- Welche Entscheidung wird dadurch möglich? Zum Beispiel eine Regel bestätigen, einen API-Vertrag anpassen oder eine Hypothese verwerfen.
- Welche Abhängigkeiten sind unverzichtbar? Trennt die Abhängigkeiten, die zum Testen des Verhaltens nötig sind, von denen, die erst für die Skalierung oder Automatisierung gebraucht werden.
- Lässt sich das Inkrement sicher testen? Berücksichtigt Berechtigungen, Testdaten, externe Auswirkungen und Möglichkeiten, einen Vorgang rückgängig zu machen oder einzuschränken.
Bereitet das erste Inkrement lediglich eine Datenbank oder eine Integrationsschicht vor, kann das als vorbereitende Arbeit sinnvoll sein. Es sollte jedoch nicht als Lieferung bereits validierten Mehrwerts dargestellt werden. Gebt an, welches Risiko damit verringert wird und welche Nachweise entstehen. Eine technische Phase kann eine spätere Lieferung ermöglichen; für sich allein belegt sie nicht, dass der Ablauf für die Zielgruppe funktioniert.
Legt Nachweise und Akzeptanzkriterien vor der Umsetzung fest
Eine Lieferung lässt sich bewerten, wenn vereinbart ist, was beobachtet wird, um zu entscheiden, ob sie ihren Zweck erfüllt. Vermeidet Kriterien wie „Die API ist fertig“ oder „Der Prozess funktioniert“. Beschreibt das Verhalten, den Kontext und das erwartete Ergebnis: Wenn eine gültige Anfrageart vorliegt und sie übermittelt wird, wird sie registriert und ein abfragbarer Status angezeigt. Ergänzt relevante Grenzfälle, etwa unvollständige oder doppelte Daten sowie eine fehlgeschlagene Antwort des abhängigen Service.
Die Kriterien sollten auch die zugehörigen Nachweise umfassen. Das kann ein automatisierter Test, eine Demonstration mit kontrollierten Daten, ein Audit-Log oder eine Bestätigung durch einen Consumer sein. Legt bei einer PHP-Änderung außerdem die jeweils relevanten Betriebsbedingungen fest: erforderliche Konfiguration, Datenmigration, Berechtigungen, aussagekräftige Metriken oder Logs sowie ein Wiederherstellungsverfahren. Nicht jedes Inkrement muss Nutzern zugänglich gemacht werden, aber alle sollten sich auf eine vereinbarte Weise überprüfen lassen.
Unterscheidet zwischen Deployment und Release. Ein Deployment bedeutet, eine Version in einer Umgebung zu installieren; eine Funktion zu veröffentlichen oder zu aktivieren bedeutet, sie einer Zielgruppe oder einem Prozess verfügbar zu machen. Eine Funktion kann deployed werden, ohne aktiviert zu sein, etwa um die Kompatibilität zu prüfen. Wird ein schrittweiser Rollout eingesetzt, legt fest, wer Zugriff erhält, wie dieser begrenzt wird und welches Signal die Aktivierung stoppt oder zurücksetzt.
Stimmt Verträge und Integrationsfenster ab
Abhängigkeiten zwischen Teams lassen sich handhaben, wenn es ausdrückliche Integrationsvereinbarungen gibt. Legt für eine API Felder, Formate, Fehler, Authentifizierung, relevante Grenzwerte und Kompatibilität fest. Definiert bei Events oder Dateien Schema, Häufigkeit, Verantwortliche sowie den Umgang mit wiederholten oder verspäteten Nachrichten. Dokumentiert für PHP außerdem, welche Konfiguration die Anwendung benötigt und welches Verhalten erwartet wird, wenn der Service nicht antwortet.
Eine abgestimmte Schnittstelle setzt nicht voraus, dass beide Teams gleichzeitig fertig werden. Der Anbieter kann einen Vertrag und eine Testumgebung bereitstellen; der Consumer kann mit einem Test-Double arbeiten, das die erwarteten Antworten nachbildet. Test-Doubles ermöglichen den Fortschritt, ersetzen aber nicht die Validierung mit dem realen System. Reserviert ein Integrationsfenster, um Authentifizierung, Daten, Latenz und tatsächliche Fehler zu überprüfen.
Legt Prüftermine für den Vertrag und die Integration fest, nicht nur einen endgültigen Liefertermin. Ändert sich das Schema, haltet fest, wer die Auswirkungen bewertet und wie die Kompatibilität gewahrt wird. Vertragstests und automatische Prüfungen in der Continuous Integration können Abweichungen früh erkennen, lösen aber weder Meinungsverschiedenheiten über das Produkt noch Probleme in der externen Umgebung.
Geht mit Unsicherheit durch Optionen und Verantwortliche um
Eine unsichere Abhängigkeit sollte als Risiko mit einer verantwortlichen Person, einem Prüftermin und einer damit verbundenen Entscheidung erfasst werden. Notiert, was unbekannt ist, welche Nachweise zur Klärung beitragen und wie das Team vorgeht, wenn die Antwort nicht rechtzeitig kommt. Mögliche Optionen sind ein reduzierter Umfang, kontrollierte Daten, eine vorübergehend simulierte Antwort oder eine Änderung der Reihenfolge der Inkremente. Jede Alternative hat Grenzen: Eine Simulation eignet sich dazu, den lokalen Ablauf zu testen, validiert aber nicht die produktive Integration.
Versteckt offene Arbeit nicht hinter Begriffen wie „Integration“ oder „Abstimmung“. Kann eine Lieferung erst getestet werden, nachdem ein anderes Team Daten bereitgestellt hat, behandelt diese Bedingung als Teil des Plans und vereinbart einen Prüftermin. Betrifft die Unsicherheit Datenschutz, Sicherheit oder finanzielle Auswirkungen, löst sie nicht durch eine technische Annahme: Holt die zuständige Entscheidung ein, bevor ihr das Verhalten aktiviert.
Hypothetisches Beispiel: Eine Geschäftsanfrage automatisieren
Angenommen, eine Organisation möchte die Annahme und Klassifizierung interner Anfragen mit einer PHP-Anwendung automatisieren. Ein erstes Inkrement könnte eine Kategorie annehmen, Pflichtfelder validieren und das Ergebnis in einer Review-Ansicht anzeigen. Das Datenteam hat den endgültigen Katalog noch nicht bereitgestellt. Daher vereinbart das Produktteam einen kontrollierten Datensatz, um den Ablauf zu bewerten, und hält fest, dass die Klassifizierung noch nicht für alle Kategorien validiert ist.
Das nächste Inkrement integriert den abgestimmten Vertrag mit dem Datendienst, testet gültige Antworten und Fehler und protokolliert die verwendete Katalogversion. Anschließend kann eine Lieferung die automatische Zuweisung für eine begrenzte Gruppe aktivieren, mit menschlicher Prüfung und einer Möglichkeit, den Prozess anzuhalten. Jeder Schritt hat einen anderen Nachweis: einen funktionierenden Ablauf, eine geprüfte Integration und ein Betriebsverhalten unter klar begrenzten Bedingungen. Die Abfolge dient der Veranschaulichung; die tatsächliche Reihenfolge hängt von den Risiken und Entscheidungen der jeweiligen Organisation ab.
Prüfliste, bevor ihr das nächste Inkrement zusagt
- Ist klar, welche Person oder welcher Prozess das Ergebnis bewerten kann?
- Durchläuft das Inkrement einen nützlichen Ablauf, oder beschränkt sich sein Wert darauf, eine technische Schicht fertigzustellen?
- Sind die Abhängigkeiten, die dafür Verantwortlichen und der nächste Prüftermin bekannt?
- Gibt es beobachtbare Kriterien, Testdaten und eine Möglichkeit, Fehlerfälle zu überprüfen?
- Haben die Teams Verträge, Kompatibilität und ein Integrationsfenster vereinbart?
- Sind Konfiguration, Berechtigungen, Logs und Wiederherstellung festgelegt, sofern sie relevant sind?
- Wird zwischen Deployment und Aktivierung unterschieden, und lässt sich der Rollout kontrollieren?
- Ist klar, welche Entscheidung getroffen wird, wenn eine Abhängigkeit ausfällt oder die Nachweise der Hypothese widersprechen?
Wenn mehrere Antworten Nein lauten, besteht der nächste Schritt nicht immer darin, weitere Aufgaben hinzuzufügen. Vielleicht muss der Vertrag geklärt, eine Entscheidung eingeholt oder das Inkrement auf einen überprüfbaren Ablauf reduziert werden. Eine sinnvolle Planung macht sichtbar, was genutzt oder gelernt werden kann, was dafür noch fehlt und wer bei jeder Unsicherheit handelt. So verringern kleine Lieferungen Risiken, ohne gemeinsame Arbeit in ein vages Versprechen zu verwandeln.
