Ta en eksisterende kodebase inn i Taiga

Start med systemet dere har

En fiktiv tjeneste for utstyrsforespørsler finnes allerede. Teamet vil vedlikeholde den med Taiga og bevare integrasjonene som virker.

Velg Import codebase når produktet opprettes. Koble til repositoryet, og start analysen. Denne veien bruker repository-analyse i stedet for samtalen for et nytt produkt. Et produkt opprettet fra bunnen av får ikke denne importveien lagt til senere.

Bekreft repository-tilgangen og branchen Taiga skal arbeide mot. Legg til stående begrensninger på riktig kontekstnivå. I dette eksemplet oppgir dere at den eksisterende identitetsintegrasjonen for ansatte skal beholdes.

Gjennomgå den utledede spesifikasjonen først

Taiga utleder produktdokumenter fra koden og tar med repository-referanser. Referansene hjelper dere å kontrollere tolkningen. De fastslår ikke forretningshensikten bak hvert eksisterende mønster.

Undersøk tre ting i spesifikasjonen:

• Formål: Stemmer det beskrevne målet med hvorfor tjenesten finnes?
• Begrensninger: Hvilke mønstre er bevisste krav?
• Kjente feil: Hvilken oppførsel bør endres?

Utstyrstjenesten inneholder en eldre autorisasjonsmodul. Et dokument kan rapportere riktig om bruken. Det betyr ikke at teamet bør utvide den.

Åpne en referert fil, og sammenlign den relevante oppførselen med påstanden. Registrer begrensninger i de tilgjengelige bevisene, for eksempel konfigurasjon eller driftsoppførsel utenfor repositoryet.

Velg riktig retting

Importerte dokumenter følger koden. Ikke behandle dem som manuelt vedlikeholdte beskrivelser av et fremtidig system. En dokumentoppdatering utleder også dokumentene den avhenger av, på nytt. Oppdatering av et senere dokument kan derfor kreve mer arbeid.

For den eldre modulen kan en instruksjon si: «Ikke legg til nye kallere til den eldre autorisasjonsmodulen. Bruk det godkjente erstatningsgrensesnittet for nytt arbeid.» Verifiser at grensesnittet finnes, og oppgi den faktiske plasseringen i repositoryet.

Vurder de første initiativene

Importarbeidsflyten kjører også repository-skanninger, vurdering mot publiserte policyer og innledende initiativplanlegging. Et trinn som mangler forutsetningen sin, kan hoppes over med en forklaring. Planleggingen bruker funnene og policyvurderingen som er tilgjengelige.

Vurder de foreslåtte gapene mot repositoryet. De første initiativene håndterer manglende funksjoner, grunnlag eller relevante uavklarte avhengighetsproblemer. De er ikke en liste over nye funksjoner ingen har bedt om.

Behold nyttig eksisterende funksjonalitet. Avvis eller rett et forslag som ville bygget den opp igjen unødvendig. Legg til et separat initiativ for et nytt forretningskrav.

Bevar et bevisbasert utgangspunkt

Fullfør Discovery, og gjennomgå initiativforslagene. Bekreft miljøet og leveranseansvaret før detaljert planlegging. Hold import, kodeendringer og produktinstruksjoner konsistente mens arbeidet fortsetter.

Resultatet er et forstått utgangspunkt og en backlog som kan redigeres. Det er ikke en erklæring om at all eksisterende oppførsel er riktig. Fortsett med initiativplanlegging.