Kthejeni një rezultat në iniciativë

Përshkruani rezultatin para hapave

Shërbimi i trilluar i pajisjeve ka nevojë për vetëshërbimin e punonjësve. Një kërkesë e dobishme tregon rezultatin: “Një punonjës i autentikuar mund të krijojë një kërkesë dhe të shohë vetëm kërkesat e veta.”

Shpjegoni pse ka rëndësi: aktualisht menaxherët i regjistrojnë kërkesat për punonjësit. Përcaktoni shtrirjen: krijimi i kërkesave, shfaqja e gjendjes, kontrollet e aksesit dhe evidenca për këto sjellje. Përjashtoni blerjet automatike dhe ndryshimet në rregullin e miratimit nga menaxheri.

Mos përcaktoni redaktime skedarësh para se të jetë shqyrtuar depoja e kodit. Iniciativa regjistron synimin; planifikimi i hollësishëm e kthen atë synim në hapa zbatimi.

Shqyrtoni çfarë prodhoi kërkesa

Taiga përdor kërkesën dhe kontekstin e produktit për të krijuar një iniciativë ose një grup të renditur iniciativash. Puna e re mbërrin në Backlog. Një kërkesë më e madhe mund të ketë nevojë për disa ndryshime që mund të shqyrtohen në mënyrë të pavarur.

Lexoni gjendjen përfundimtare të gjeneruar, Why dhe Scope. Kontrolloni që sjellja e kërkuar është ruajtur dhe përjashtimet janë respektuar. Nëse një iniciativë ekzistuese tashmë e mbulon kërkesën, Taiga mund ta emërtojë atë në vend që të krijojë një kopje.

Një kërkesë e bllokuar nga një politikë e publikuar ka nevojë për rrugën e vendimmarrjes që përcakton ajo politikë. Lexoni shpjegimin dhe zgjidheni konfliktin përmes asaj rruge. Mos e rishkruani kërkesën vetëm për të fshehur veprimin e ndaluar.

Trajtojeni tabelën si rend ekzekutimi

Taiga punon me një iniciativë njëkohësisht për çdo produkt, përfshirë planifikimin. Nis iniciativën e radhës në pritje pasi pull request-i aktual bashkohet në kod. Nuk i zhvendos automatikisht elementet nga Backlog ose Todo në Queue.

Vendosja në Queue ka rëndësi. Ajo anashkalon pritjen për varësi të papërfunduara. Para se ta vendosni në radhë vetëshërbimin e punonjësve, konfirmoni se baza e identitetit ekziston ose se shtrirja e zgjedhur e krijon atë siç duhet.

Shqyrtoni planin e hollësishëm

Planifikuesi lexon depon e kodit, dokumentet e produktit, politikat, udhëzimet dhe kontekstin e vendosjes. Kontrollojeni planin kundrejt rezultatit real të përdoruesit dhe mjedisit konkret.

Për shërbimin e pajisjeve, verifikoni tre raste aksesi. Një punonjës e sheh kërkesën e vet. Një punonjës tjetër nuk mund ta shohë. Një menaxher ruan aksesin e synuar për shqyrtim. Përfshini migrimin e të dhënave dhe efektet operacionale nëse zbatimi i ndryshon ato.

Nëse Build on its own by default është i çaktivizuar, plani i përfunduar pret vendimin tuaj. Approve nis ndërtimin me identitetin e personit që miraton, brenda lejeve të tij. Reject përdor reagimin tuaj për të planifikuar përsëri. Një iniciativë mund të ketë cilësimin e vet.

Përdorni regjistrimin e duhur për vendimin e radhës

Planet kanë versione. Një ekzekutim regjistron cilin plan zbatoi. Nëse qasja e synuar ndryshon, shqyrtoni iniciativën dhe veprimin e duhur të riplanifikimit. Përdorni regjistrin e ekzekutimit për të shqyrtuar përpjekjen e mëparshme.

Një ndërtim, një pull request i bashkuar në kod dhe një publikim në prodhim janë gjendje të ndryshme. Mbajini të dukshme evidencën e pranimit dhe përgjegjësinë e vendosjes ndërsa puna përparon. Vazhdoni me cilësimet e autonomisë.