Omsæt et resultat til et initiativ

Beskriv resultatet før trinnene

Den fiktive udstyrstjeneste kræver selvbetjening for medarbejdere. En nyttig anmodning beskriver resultatet: »En autentificeret medarbejder kan oprette en anmodning og kun se sine egne anmodninger.«

Forklar, hvorfor det betyder noget: Ledere registrerer i dag anmodninger for medarbejdere. Definér omfanget: oprettelse af anmodning, statusvisning, adgangskontroller og dokumentation for denne adfærd. Udelad automatiske indkøb og ændringer af lederens godkendelsesregel.

Foreskriv ikke filændringer, før repositoryet er undersøgt. Initiativet indfanger hensigten; detaljeret planlægning omsætter den til implementeringstrin.

Gennemgå anmodningens resultat

Taiga bruger anmodningen og produktkonteksten til at skabe et initiativ eller et ordnet sæt initiativer. Nyt arbejde lander i Backlog. En større anmodning kan kræve flere ændringer, der kan gennemgås uafhængigt.

Læs den genererede sluttilstand, Why og Scope. Kontrollér, at den krævede adfærd er bevaret, og undtagelserne er respekteret. Hvis et eksisterende initiativ allerede dækker anmodningen, kan Taiga pege på det frem for at skabe en dublet.

En anmodning blokeret af en publiceret politik kræver den beslutningsvej, politikken definerer. Læs forklaringen, og løs konflikten ad den vej. Omskriv ikke anmodningen blot for at skjule den forbudte handling.

Betragt tavlen som en udførelsesrækkefølge

Taiga arbejder på ét initiativ ad gangen pr. produkt, inklusive planlægning. Det næste initiativ i køen starter, når den aktuelle pull request merges. Taiga flytter ikke automatisk elementer fra Backlog eller Todo til Queue.

Køplacering betyder noget. Den tilsidesætter ventetid på ufærdige afhængigheder. Bekræft, at identitetsfundamentet findes, eller at det valgte omfang etablerer det korrekt, før selvbetjening for medarbejdere sættes i kø.

Undersøg den detaljerede plan

Planlæggeren læser repository, produktdokumenter, politikker, instruktioner og udrulningskontekst. Kontrollér planen mod det faktiske brugerresultat og miljø.

Verificér tre adgangstilfælde for udstyrstjenesten. En medarbejder ser sin anmodning. En anden medarbejder kan ikke se den. En leder beholder den tilsigtede reviewadgang. Medtag datamigrering og driftseffekter, hvis implementeringen ændrer dem.

Hvis Build on its own by default er slået fra, venter den færdige plan på din beslutning. Approve starter buildet som den godkendende person og med dennes tilladelser. Reject bruger din feedback til at planlægge igen. Et initiativ kan have sin egen indstilling.

Brug den rette registrering til næste beslutning

Planer er versionerede. En kørsel registrerer, hvilken plan den udførte. Hvis den tilsigtede tilgang ændres, skal initiativet og den relevante handling til ny planlægning gennemgås. Brug kørslen til at undersøge det tidligere forsøg.

Et build, en merget pull request og en produktionsrelease er forskellige tilstande. Hold acceptdokumentation og udrulningsansvar synlige, mens arbejdet skrider frem. Fortsæt med autonomiindstillinger.