Transformați un rezultat într-o inițiativă

Descrieți rezultatul înaintea pașilor

Serviciul fictiv de echipamente necesită autoservirea angajaților. O cerere utilă precizează rezultatul: „Un angajat autentificat poate crea o cerere și vedea numai propriile cereri.”

Explicați de ce contează: în prezent, managerii introduc cererile pentru angajați. Definiți domeniul: crearea cererii, afișarea stării, verificările de acces și dovezile acestor comportamente. Excludeți achiziționarea automată și modificările regulii de aprobare a managerului.

Nu prescrieți editări de fișiere înainte de inspectarea depozitului de cod. Inițiativa consemnează intenția; planificarea detaliată o transformă în pași de implementare.

Verificați ce a produs cererea

Taiga folosește cererea și contextul produsului pentru a crea o inițiativă sau un set ordonat de inițiative. Lucrul nou ajunge în Backlog. O cerere mai amplă poate necesita mai multe modificări verificabile independent.

Citiți starea finală generată, Why și Scope. Verificați dacă s-a păstrat comportamentul necesar și s-au respectat excluderile. Dacă o inițiativă existentă acoperă deja cererea, Taiga o poate numi în loc să creeze un duplicat.

O cerere blocată de o politică publicată necesită traseul de decizie definit de acea politică. Citiți explicația și rezolvați conflictul prin acel traseu. Nu rescrieți cererea doar pentru a ascunde acțiunea interzisă.

Tratați panoul ca secvență de execuție

Taiga lucrează la o singură inițiativă o dată pentru fiecare produs, inclusiv planificarea. Începe următoarea inițiativă din coadă după merge-ul pull request-ului curent. Nu mută automat elemente din Backlog sau Todo în Queue.

Plasarea în Queue contează. Anulează așteptarea dependențelor neterminate. Înainte de a pune în coadă autoservirea angajaților, confirmați că baza identității există sau că domeniul ales o stabilește corect.

Inspectați planul detaliat

Planificatorul citește depozitul de cod, documentele produsului, politicile, instrucțiunile și contextul instalării. Verificați planul în raport cu rezultatul efectiv pentru utilizator și cu mediul.

Pentru serviciul de echipamente, verificați trei cazuri de acces. Un angajat își vede cererea. Alt angajat nu o poate vedea. Un manager păstrează accesul de verificare intenționat. Includeți migrarea datelor și efectele operaționale dacă implementarea le schimbă.

Dacă Build on its own by default este dezactivat, planul terminat așteaptă decizia dumneavoastră. Approve începe execuția planului în numele persoanei care aprobă, în limitele permisiunilor sale. Reject folosește feedbackul pentru a planifica din nou. O inițiativă poate avea propria setare.

Folosiți consemnarea potrivită pentru următoarea decizie

Planurile au versiuni. O execuție consemnează planul executat. Dacă se schimbă abordarea intenționată, verificați inițiativa și acțiunea adecvată de replanificare. Folosiți execuția pentru a inspecta încercarea anterioară.

Execuția planului, un pull request integrat prin merge și o lansare în producție sunt stări diferite. Păstrați vizibile dovezile de acceptare și responsabilitatea instalării pe măsură ce lucrul avansează. Continuați cu setările de autonomie.