Eine bestehende Codebasis in Taiga übernehmen

Beginnen Sie mit dem vorhandenen System

Ein fiktiver Dienst für Ausstattungsanfragen besteht bereits. Das Team möchte ihn mit Taiga warten und seine funktionierenden Integrationen erhalten.

Wählen Sie beim Anlegen des Produkts Import codebase. Verknüpfen Sie das Repository und starten Sie die Analyse. Dieser Weg nutzt eine Repository-Analyse anstelle des Gesprächs für neue Produkte. Ein von Grund auf angelegtes Produkt erhält diesen Importweg später nicht.

Bestätigen Sie den Repository-Zugriff und den Branch, mit dem Taiga arbeiten soll. Ergänzen Sie dauerhafte Grenzen auf der passenden Kontextebene. Halten Sie hier fest, dass die bestehende Integration für Mitarbeiteridentitäten weiter genutzt werden muss.

Prüfen Sie zuerst die abgeleitete Spezifikation

Taiga leitet Produktdokumente aus dem Code ab und ergänzt Repository-Belege. Diese Belege helfen, die Interpretation zu prüfen. Sie belegen nicht die geschäftliche Absicht hinter jedem bestehenden Muster.

Prüfen Sie drei Punkte in der Spezifikation:

• Zweck: Passt das beschriebene Ziel zum Grund, aus dem der Dienst besteht?
• Grenzen: Welche Muster sind bewusst vorgegebene Anforderungen?
• Bekannte Fehler: Welche aktuellen Verhaltensweisen sollen sich ändern?

Der Ausstattungsdienst enthält ein veraltetes Autorisierungsmodul. Ein Dokument kann dessen Nutzung korrekt beschreiben. Das bedeutet nicht, dass das Team es erweitern soll.

Öffnen Sie eine zitierte Datei und vergleichen Sie das relevante Verhalten mit der Aussage. Erfassen Sie Grenzen der verfügbaren Nachweise, etwa Konfiguration oder Betriebsverhalten außerhalb des Repositorys.

Wählen Sie die passende Korrektur

Importierte Dokumente folgen dem Code. Behandeln Sie sie nicht als manuell gepflegte Beschreibungen eines künftigen Systems. Eine Dokumentaktualisierung leitet auch die Dokumente neu ab, von denen das Dokument abhängt. Die Aktualisierung eines späteren Dokuments kann deshalb mehr Arbeit erfordern.

Für das veraltete Modul könnte eine Anweisung lauten: „Fügen Sie keine neuen Aufrufer des veralteten Autorisierungsmoduls hinzu. Nutzen Sie für neue Arbeit die freigegebene Ersatzschnittstelle.“ Prüfen Sie, ob diese Schnittstelle existiert, und benennen Sie ihren tatsächlichen Ort im Repository.

Bewerten Sie die ersten Initiatives

Der Importworkflow führt auch Repository-Scans, eine Bewertung anhand veröffentlichter Richtlinien und eine erste Initiative-Planung aus. Eine Phase ohne ihre Voraussetzung kann mit einer Erklärung übersprungen werden. Die Planung nutzt die verfügbaren Befunde und Richtlinienbewertungen.

Prüfen Sie die vorgeschlagenen Lücken anhand des Repositorys. Die ersten Initiatives behandeln fehlende Fähigkeiten, Grundlagen oder relevante ungelöste Abhängigkeitsprobleme. Sie sind keine Liste neuer Funktionen, die niemand angefordert hat.

Erhalten Sie eine nützliche bestehende Fähigkeit. Lehnen Sie einen Vorschlag ab oder korrigieren Sie ihn, wenn er sie unnötig neu bauen würde. Legen Sie für eine neue geschäftliche Anforderung eine eigene Initiative an.

Erhalten Sie einen nachweisgestützten Ausgangspunkt

Schließen Sie Discovery ab und prüfen Sie die Initiative-Vorschläge. Bestätigen Sie die Umgebung und Lieferverantwortlichkeiten vor der detaillierten Planung. Halten Sie Importe, Codeänderungen und Produktanweisungen im weiteren Verlauf konsistent.

Das Ergebnis ist ein verstandener Ausgangspunkt und ein bearbeitbarer Backlog. Es erklärt nicht jedes bestehende Verhalten für richtig. Fahren Sie mit der Initiative-Planung fort.