Gjør et resultat til et initiativ

Beskriv resultatet før trinnene

Den fiktive utstyrstjenesten trenger selvbetjening for ansatte. En nyttig forespørsel oppgir resultatet: «En autentisert ansatt kan opprette en forespørsel og bare se sine egne forespørsler.»

Forklar hvorfor det er viktig: Ledere registrerer i dag forespørsler for ansatte. Definer omfanget: opprettelse av forespørsler, statusvisning, tilgangskontroller og bevis for denne oppførselen. Utelat automatiske innkjøp og endringer i regelen for ledergodkjenning.

Ikke foreskriv filredigeringer før repositoryet er undersøkt. Initiativet fanger hensikten; detaljert planlegging gjør den til implementasjonstrinn.

Gjennomgå det forespørselen produserte

Taiga bruker forespørselen og produktkonteksten til å opprette et initiativ eller et ordnet sett av initiativer. Nytt arbeid kommer til Backlog. En større forespørsel kan trenge flere endringer som kan gjennomgås uavhengig.

Les den genererte sluttilstanden, Why og Scope. Kontroller at nødvendig oppførsel er bevart, og at avgrensninger er respektert. Hvis et eksisterende initiativ allerede dekker forespørselen, kan Taiga navngi det i stedet for å opprette en kopi.

En forespørsel som blokkeres av en publisert policy, trenger beslutningsveien policyen definerer. Les forklaringen, og løs konflikten gjennom den veien. Ikke skriv om forespørselen bare for å skjule den forbudte handlingen.

Behandle tavlen som en utføringsrekkefølge

Taiga arbeider med ett initiativ om gangen per produkt, inkludert planlegging. Det starter neste initiativ i køen etter at den gjeldende pull requesten merges. Det flytter ikke automatisk elementer fra Backlog eller Todo til Queue.

Køplassering betyr noe. Den overstyrer venting på uferdige avhengigheter. Før selvbetjening for ansatte legges i køen, må du bekrefte at identitetsgrunnlaget finnes, eller at det valgte omfanget etablerer det riktig.

Undersøk den detaljerte planen

Planleggeren leser repositoryet, produktdokumenter, policyer, instruksjoner og utrullingskontekst. Kontroller planen mot det faktiske brukerresultatet og miljøet.

For utstyrstjenesten verifiserer du tre tilgangstilfeller. En ansatt ser sin forespørsel. En annen ansatt kan ikke se den. En leder beholder den tiltenkte tilgangen for gjennomgang. Ta med datamigrering og driftsvirkninger hvis implementasjonen endrer dem.

Hvis Build on its own by default er slått av, venter den ferdige planen på din beslutning. Approve starter bygget som personen som godkjenner, innenfor vedkommendes tillatelser. Reject bruker tilbakemeldingen din til å planlegge på nytt. Et initiativ kan ha sin egen innstilling.

Bruk riktig registrering for neste beslutning

Planer er versjonerte. En kjøring registrerer hvilken plan den utførte. Hvis den tiltenkte tilnærmingen endres, gjennomgår du initiativet og den riktige handlingen for ny planlegging. Bruk kjøringen til å undersøke det forrige forsøket.

Et bygg, en merget pull request og en produksjonsutgivelse er ulike tilstander. Hold akseptansebevis og utrullingsansvar synlige etter hvert som arbeidet går fremover. Fortsett med autonomiinnstillinger.