Convertiu un resultat en una iniciativa

Descriviu el resultat abans dels passos

El servei fictici d’equipament necessita autoservei per als empleats. Una petició útil indica el resultat: «Un empleat autenticat pot crear una sol·licitud i veure només les seves pròpies sol·licituds.»

Expliqueu per què és important: actualment els responsables introdueixen les sol·licituds dels empleats. Definiu l’abast: creació de sol·licituds, visualització de l’estat, comprovacions d’accés i evidències d’aquests comportaments. Excloeu les compres automàtiques i els canvis a la regla d’aprovació dels responsables.

No prescriviu edicions de fitxers abans d’examinar el repositori. La iniciativa recull la intenció; la planificació detallada converteix aquesta intenció en passos d’implementació.

Reviseu què ha produït la petició

Taiga fa servir la petició i el context del producte per crear una iniciativa o un conjunt ordenat d’iniciatives. La feina nova arriba a Backlog. Una petició més gran pot necessitar diversos canvis que es puguin revisar de manera independent.

Llegiu l’estat final generat, Why i Scope. Comproveu que s’hagi mantingut el comportament requerit i que s’hagin respectat les exclusions. Si una iniciativa existent ja cobreix la petició, Taiga pot identificar-la en lloc de crear-ne una de duplicada.

Una petició bloquejada per una política publicada necessita la via de decisió que defineix aquella política. Llegiu l’explicació i resoleu el conflicte per aquesta via. No reescriviu la petició només per amagar l’acció prohibida.

Tracteu el tauler com una seqüència d’execució

Taiga treballa en una iniciativa alhora per producte, inclosa la planificació. Inicia la següent iniciativa de la cua després que es fusioni la pull request actual. No mou automàticament elements de Backlog o Todo a Queue.

La col·locació a Queue és important. Anul·la l’espera de dependències inacabades. Abans de posar l’autoservei dels empleats a la cua, confirmeu que els fonaments d’identitat existeixen o que l’abast triat els estableix correctament.

Examineu el pla detallat

El planificador llegeix el repositori, els documents del producte, les polítiques, les instruccions i el context de desplegament. Comproveu el pla respecte del resultat real de l’usuari i de l’entorn.

Per al servei d’equipament, verifiqueu tres casos d’accés. Un empleat veu la seva sol·licitud. Un altre empleat no la pot veure. Un responsable conserva l’accés de revisió previst. Incloeu la migració de dades i els efectes operatius si la implementació els canvia.

Si Build on its own by default està desactivat, el pla acabat espera la vostra decisió. Approve inicia la construcció amb la identitat de la persona que aprova, subjecta als seus permisos. Reject fa servir els vostres comentaris per tornar a planificar. Una iniciativa pot tenir el seu propi paràmetre.

Feu servir el registre adequat per a la decisió següent

Els plans estan versionats. Una execució registra quin pla ha executat. Si canvia l’enfocament previst, reviseu la iniciativa i l’acció de replanificació adequada. Feu servir l’execució per examinar l’intent anterior.

Una construcció, una pull request fusionada i una publicació en producció són estats diferents. Manteniu visibles les evidències d’acceptació i la responsabilitat del desplegament mentre avança la feina. Continueu amb els paràmetres d’autonomia.