Porta una base di codice esistente in Taiga

Parti dal sistema che hai

Esiste già un servizio fittizio di richieste di attrezzature. Il team vuole mantenerlo con Taiga preservando le integrazioni funzionanti.

Scegli Import codebase alla creazione del prodotto. Collega il repository e avvia l’analisi. Questo percorso usa l’analisi del repository al posto della conversazione per un nuovo prodotto. Un prodotto creato da zero non aggiunge in seguito questo percorso di importazione.

Conferma l’accesso al repository e il branch su cui Taiga deve lavorare. Aggiungi i vincoli permanenti al livello di contesto appropriato. Nell’esempio, indica che l’integrazione esistente con l’identità dei dipendenti deve restare in uso.

Esamina prima la specifica dedotta

Taiga ricava i documenti del prodotto dal codice e include riferimenti al repository. I riferimenti aiutano a verificare l’interpretazione. Non dimostrano l’intento aziendale dietro ogni schema esistente.

Esamina tre aspetti nella specifica:

• Scopo: l’obiettivo descritto corrisponde al motivo per cui esiste il servizio?
• Vincoli: quali schemi sono requisiti intenzionali?
• Difetti noti: quali comportamenti attuali devono cambiare?

Il servizio di attrezzature contiene un modulo legacy di autorizzazione. Un documento può riportarne accuratamente l’uso. Non significa che il team debba estenderlo.

Apri un file citato e confronta il comportamento pertinente con l’affermazione. Registra ogni limite nelle prove disponibili, come configurazioni o comportamenti operativi fuori dal repository.

Scegli la correzione giusta

I documenti importati seguono il codice. Non trattarli come descrizioni di un sistema futuro mantenute manualmente. L’aggiornamento di un documento ricava di nuovo anche i documenti da cui dipende. Aggiornare un documento successivo può quindi richiedere più lavoro.

Per il modulo legacy, un’istruzione potrebbe dire: «Non aggiungere nuovi chiamanti al modulo legacy di autorizzazione. Usa l’interfaccia sostitutiva approvata per il nuovo lavoro». Verifica che l’interfaccia esista e indica la posizione effettiva nel repository.

Valuta le prime iniziative

Il flusso di importazione esegue anche scansioni del repository, valutazione rispetto alle policy pubblicate e pianificazione iniziale delle iniziative. Una fase priva del prerequisito può essere saltata con una spiegazione. La pianificazione usa i risultati e la valutazione delle policy disponibili.

Confronta le lacune proposte con il repository. Le iniziative iniziali affrontano capacità mancanti, fondamenta o problemi pertinenti e irrisolti delle dipendenze. Non sono un elenco di nuove funzionalità mai richieste.

Mantieni una capacità esistente utile. Respingi o correggi una proposta che la ricostruirebbe inutilmente. Aggiungi un’iniziativa separata per un nuovo requisito aziendale.

Conserva un punto di partenza basato sulle prove

Completa Discovery ed esamina le iniziative proposte. Conferma ambiente e responsabilità di consegna prima della pianificazione dettagliata. Mantieni coerenti importazioni, modifiche al codice e istruzioni del prodotto mentre il lavoro procede.

Il risultato è un punto di partenza compreso e un backlog modificabile. Non è una dichiarazione che ogni comportamento esistente sia corretto. Prosegui con la pianificazione delle iniziative.