Zet een resultaat om in een initiatief

Beschrijf het resultaat vóór de stappen

De fictieve materiaalservice heeft zelfbediening voor medewerkers nodig. Een bruikbaar verzoek benoemt het resultaat: ‘Een geauthenticeerde medewerker kan een aanvraag maken en alleen de eigen aanvragen zien.’

Leg uit waarom dat belangrijk is: managers voeren nu aanvragen voor medewerkers in. Definieer de scope: aanvragen maken, status tonen, toegangscontroles en bewijs voor dat gedrag. Sluit automatisch inkopen en wijzigingen in de goedkeuringsregel voor managers uit.

Schrijf geen bestandswijzigingen voor voordat de repository is bekeken. Het initiatief legt intentie vast; gedetailleerde planning zet die intentie om in implementatiestappen.

Review wat het verzoek opleverde

Taiga gebruikt het verzoek en de productcontext om een initiatief of een geordende reeks initiatieven te maken. Nieuw werk komt in Backlog. Een groter verzoek kan meerdere afzonderlijk reviewbare wijzigingen vereisen.

Lees de gegenereerde eindtoestand, Why en Scope. Controleer of vereist gedrag behouden bleef en uitsluitingen zijn gerespecteerd. Als een bestaand initiatief het verzoek al dekt, kan Taiga dat benoemen in plaats van een duplicaat te maken.

Een verzoek dat door gepubliceerd beleid wordt geblokkeerd, vereist de beslisroute uit dat beleid. Lees de uitleg en los het conflict via die route op. Herschrijf het verzoek niet alleen om de verboden actie te verbergen.

Behandel het bord als uitvoeringsvolgorde

Taiga werkt per product aan één initiatief tegelijk, inclusief planning. Het start het volgende initiatief uit Queue nadat de huidige pull request is gemergd. Het verplaatst items niet automatisch van Backlog of Todo naar Queue.

Plaatsing in Queue is belangrijk. Ze overschrijft het wachten op onafgeronde afhankelijkheden. Bevestig vóór het inplannen van zelfbediening dat het identiteitsfundament bestaat of dat de gekozen scope dat correct aanlegt.

Bekijk het gedetailleerde plan

De planner leest de repository, productdocumenten, beleidsregels, instructies en deploymentcontext. Controleer het plan tegen het echte gebruikersresultaat en de omgeving.

Controleer bij de materiaalservice drie toegangsgevallen. Een medewerker ziet de eigen aanvraag. Een andere medewerker kan die niet zien. Een manager behoudt de bedoelde reviewtoegang. Neem gegevensmigratie en gevolgen voor beheer mee als de implementatie die verandert.

Als Build on its own by default uit staat, wacht het afgeronde plan op uw beslissing. Approve start de build als de goedkeurende persoon, binnen diens rechten. Reject gebruikt uw feedback om opnieuw te plannen. Een initiatief kan een eigen instelling hebben.

Gebruik de juiste registratie voor de volgende beslissing

Plannen hebben versies. Een run legt vast welk plan die uitvoerde. Als de beoogde aanpak verandert, review dan het initiatief en de passende actie voor opnieuw plannen. Gebruik de run om de vorige poging te bekijken.

Een build, een gemergde pull request en een productierelease zijn verschillende toestanden. Houd acceptatiebewijs en deploymentverantwoordelijkheid zichtbaar terwijl werk vordert. Ga verder met autonomie-instellingen.