Ein Repository zu erhalten, bedeutet nicht, ein System zu übernehmen, das das Team warten kann. Damit eine Übergabe eines PHP-Projekts an ein internes Team erfolgreich ist, müssen die Übernehmenden die Anwendung ausführen, Änderungen bereitstellen, Vorfälle untersuchen und fundierte Entscheidungen unter Berücksichtigung der Grenzen des Systems treffen können.
Der Übergang sollte als Teil der Arbeit geplant werden und nicht als Besprechung zum Abschluss. Es empfiehlt sich, zu vereinbaren, welche Fähigkeiten übertragen werden, wer sie demonstriert und wie überprüft wird, ob das übernehmende Team sie ausüben kann. Ziel ist nicht, jede Unsicherheit zu beseitigen, sondern Risiken, offene Entscheidungen und Abhängigkeiten sichtbar zu machen, die weiterhin Abstimmung erfordern.
Definieren, was Betriebsbereitschaft bedeutet
Bevor ihr Dokumente zusammentragt, legt fest, was das interne Team ohne improvisierte Anweisungen des ausscheidenden Teams erledigen können muss. Je nach System kann dazu gehören, eine lokale Umgebung einzurichten, eine Version bereitzustellen, Protokolle zu prüfen, Daten wiederherzustellen oder auf den Ausfall einer Integration zu reagieren.
Übersetzt diese Erwartungen in überprüfbare Tests. Zum Beispiel könnte eine Person aus dem übernehmenden Team eine Änderung mit geringem Risiko anhand des verfügbaren Verfahrens bereitstellen oder erklären, wie eine problematische Migration erkannt und rückgängig gemacht wird. Der Test muss zu den Berechtigungen und zur tatsächlichen Umgebung passen: Es darf kein Vorfall in der Produktion ausgelöst werden, nur um zu zeigen, dass ein Wiederherstellungsplan existiert.
Grenzt außerdem ab, was nicht zum Umfang gehört. Bestimmte Vorgänge können von einem anderen Team, einem Anbieter oder einer Sicherheitsfreigabe abhängen. Haltet diese Abhängigkeit und den Eskalationsweg fest; stellt sie nicht als bereits übertragene Fähigkeit dar.
System und Abhängigkeiten erfassen
Das technische Inventar muss es ermöglichen, die für Entwicklung und Betrieb der Anwendung benötigten Komponenten und deren Verantwortliche zu finden. Nehmt mindestens Folgendes auf:
- Code und Automatisierung: Repositories, relevante Branches, Konfiguration der Continuous Integration, geplante Aufgaben und Betriebsskripte.
- Anwendung: erforderliche PHP-Version, Paketmanager und Abhängigkeitsdateien, Erweiterungen, Build-Befehle und Konfiguration je Umgebung.
- Infrastruktur und Umgebungen: wo die einzelnen Umgebungen ausgeführt werden, wie sie bereitgestellt werden und welche wichtigen Unterschiede zwischen Test und Produktion bestehen.
- Daten: verwendete Datenbanksysteme, Migrationen, Backups, Wiederherstellung, Aufbewahrung und zu schützende sensible Daten.
- Verbundene Dienste: APIs, E-Mail, Zahlungen, Speicher, Warteschlangen und Identitätsdienste einschließlich ihrer Verantwortlichen und bekannter Ausfallmodi.
Eine Liste von Technologien reicht nicht aus. Gebt für jede kritische Abhängigkeit an, wer sie verwaltet, welche Zugangsdaten oder Berechtigungen erforderlich sind, wie ein Ausfall erkannt wird und wie sich die Anwendung verhält, wenn der Dienst nicht mehr antwortet. Nehmt keine Geheimnisse in Dokumente oder Repositories auf; gebt stattdessen an, wo sie sicher verwahrt werden und wie der Zugriff beantragt werden kann.
Architektur, Entscheidungen und Grenzen dokumentieren
Nützliche Dokumentation beantwortet Fragen, die bei der Arbeit auftauchen: Welche Komponente verarbeitet eine Anfrage? Wo werden Daten validiert? Welcher Prozess aktualisiert diese Informationen? Welche Teile dürfen nicht ohne Abstimmung einer Migration geändert werden? Eine kurze Übersicht über Komponenten und kritische Abläufe ist oft praktischer als der Versuch, jede Datei zu beschreiben.
Haltet relevante Entscheidungen samt Kontext, erwogenen Alternativen und Konsequenzen fest. Wenn eine Integration Einschränkungen hat, eine wiederkehrende Aufgabe nicht idempotent ist oder für einen älteren Bereich Tests fehlen, macht dies ausdrücklich kenntlich. Trennt bestätigte Fakten von Annahmen und gebt an, wann die Informationen überprüft wurden.
Nehmt auch offene Entscheidungen auf: verfügbare Optionen, die Folgen eines Aufschubs, die für die Klärung verantwortliche Person und den Überprüfungstermin oder -auslöser. So bleibt die Entscheidungsfähigkeit des übernehmenden Teams erhalten, statt übernommene Entscheidungen in vermeintliche Verpflichtungen umzuwandeln.
Verfahren für Entwicklung und Betrieb übertragen
Dokumentiert die Abläufe, die das Team wiederholt ausführen muss, und testet sie gemeinsam mit den Teammitgliedern. Deckt als Grundlage ab, wie die lokale Umgebung vorbereitet, wie Tests ausgeführt, Schemaänderungen vorgenommen, Builds erstellt und bereitgestellt, Versionen überprüft und Rollbacks oder Wiederherstellungen durchgeführt werden.
Ein Verfahren muss Voraussetzungen, Berechtigungen, Befehle oder Schritte, erwartete Ergebnisse und Kriterien für einen Abbruch festlegen. Erfordert eine Bereitstellung eine inkompatible Migration oder einen manuellen Schritt, gebt die Reihenfolge und das Risiko an. Eine Wiederherstellungsoption zu beschreiben, beweist nicht, dass sie funktioniert: Testet sie, sofern dies sicher ist, in einer geeigneten Umgebung und dokumentiert das Ergebnis, die Einschränkungen und die Person, die ihren Einsatz genehmigt.
Ergänzt den Betrieb um Observability: wo Protokolle und Metriken eingesehen werden, welche Alerts es gibt, wer sie erhält und wie ein Signal mit einem Geschäftsprozess zusammenhängt. Gibt es für ein relevantes Risiko keinen Alert, haltet dies als Lücke fest; geht nicht davon aus, dass das neue Team das Problem rechtzeitig entdecken wird.
Zugriffsrechte, Eigentümerschaft und Verwahrung prüfen
Das übernehmende Team benötigt tatsächlich wirksame Berechtigungen für den Code und die erforderlichen Tools, nicht nur das Versprechen eines späteren Zugriffs. Prüft Repositories, Incident-Management, Deployment-Pipelines, Cloud-Umgebung, Domains, Zertifikate, Monitoring und Anbieter-Konten. Prüft, wer Benutzerkonten verwalten und den Zugriff wiederherstellen kann, falls jemand die Organisation verlässt.
Bestätigt außerdem Eigentümerschaft und Verwahrung der relevanten Assets, darunter Code, Dokumentation, Domains und Konfigurationen. Wendet das Prinzip der geringsten Berechtigung an: Autonomie bedeutet weder, persönliche Zugangsdaten zu teilen, noch uneingeschränkte Rechte zu gewähren. Verwendet persönliche Benutzerkonten oder genehmigte Verfahren und plant die Rotation oder den Entzug der Zugriffsrechte des ausscheidenden Teams gemäß den internen Richtlinien.
Gemeinsam arbeiten und den Abschluss überprüfen
Eine Einführungsbesprechung ist hilfreich, beweist aber nicht, dass Wissen übertragen wurde. Organisiert geführte Durchläufe anhand realer Aufgaben und wechselt dabei die Leitung: Zunächst erklärt das ausscheidende Team den Ablauf; anschließend führt eine Person aus dem übernehmenden Team denselben Ablauf aus und erläutert, was sie warum überprüft. Plant Zeit für Fragen ein und haltet offene Punkte fest, die weitere Untersuchungen erfordern.
Die Überprüfung sollte mehrere Fähigkeiten abdecken: eine Änderung entwickeln und testen, einen repräsentativen Fehler diagnostizieren, gemäß dem Verfahren ein Deployment durchführen und die Verantwortlichen einer kritischen Abhängigkeit finden. Wählt sichere und dem System angemessene Übungen. Schlägt eine Aufgabe fehl, unterscheidet zwischen einer Dokumentationslücke, fehlenden Berechtigungen, einer technischen Einschränkung und einem Schulungsbedarf; jede Ursache erfordert eine andere Maßnahme.
Schließt den Übergang mit einer Liste offener Punkte ab, die Beschreibung, Auswirkung, verantwortliche Person, Risikominderung und Überprüfungstermin enthält. Das übernehmende Team muss verbleibende Risiken bewusst akzeptieren. Die Akzeptanz löst eine Einschränkung nicht auf; sie hält fest, wer davon Kenntnis hat und wie damit umgegangen wird.
Checkliste für einen vollständigen Übergang
- Das übernehmende Team kann den Code finden, ausführen und die relevanten Tests durchführen.
- Umgebungen, Abhängigkeiten, geplante Prozesse und externe Dienste sind erfasst.
- Es gibt eine Übersicht über Architektur, kritische Abläufe, Entscheidungen und bekannte Grenzen; die Informationen lassen sich überprüfen.
- Die Verfahren für Bereitstellung, Überprüfung, Rollback und Wiederherstellung nennen Verantwortliche und Voraussetzungen.
- Die erforderlichen Zugriffe wurden getestet, die Eigentümerschaft ist geklärt und Geheimnisse werden sicher verwahrt.
- Das übernehmende Team hat praktische Aufgaben ausgeführt und nicht nur Erklärungen angehört.
- Für Risiken und offene Entscheidungen sind Verantwortliche, Maßnahmen zur Risikominderung und eine ausdrückliche Akzeptanz festgelegt.
- Für Fragen während des Übergangs gibt es einen vereinbarten Kanal und Zeitraum mit klaren Grenzen für den Umfang.
Die Übergabe ist abgeschlossen, wenn das interne Team die vereinbarten Fähigkeiten nachweisen und erkennen kann, wann es Unterstützung benötigt. Fehlen Tests, Zugriffsrechte oder Verantwortliche, ist die Übergabe trotz vollständig geteilter Dokumentation unvollständig. Dieses Kriterium macht den Abschluss zu einem überprüfbaren Übergang und erhält die Autonomie, das PHP-Projekt zu warten und weiterzuentwickeln.
