Transformer un résultat souhaité en initiative

Décrire le résultat avant les étapes

Le service fictif d’équipement a besoin de libre-service salarié. Une demande utile indique le résultat : « Un salarié authentifié peut créer une demande et voir uniquement ses propres demandes. »

Expliquez l’utilité : les managers saisissent actuellement les demandes pour les salariés. Définissez le périmètre : création de demande, affichage du statut, contrôles d’accès et preuves de ces comportements. Excluez l’achat automatique et les modifications de la règle d’approbation des managers.

Ne prescrivez pas de modifications de fichiers avant l’examen du dépôt. L’initiative consigne l’intention ; la planification détaillée la transforme en étapes d’implémentation.

Examiner ce que la demande a produit

Taiga utilise la demande et le contexte produit pour créer une initiative ou un ensemble ordonné d’initiatives. Le nouveau travail arrive dans Backlog. Une demande plus large peut nécessiter plusieurs modifications vérifiables séparément.

Lisez l’état final généré, Why et Scope. Vérifiez que le comportement requis est conservé et que les exclusions sont respectées. Si une initiative existante couvre déjà la demande, Taiga peut la nommer plutôt que créer un doublon.

Une demande bloquée par une politique publiée nécessite le circuit de décision défini par cette politique. Lisez l’explication et résolvez le conflit par ce circuit. Ne réécrivez pas la demande simplement pour cacher l’action interdite.

Traiter le tableau comme une séquence d’exécution

Taiga travaille sur une seule initiative à la fois par produit, planification comprise. L’initiative suivante de la file commence après le merge de la pull request actuelle. Taiga ne déplace pas automatiquement les éléments de Backlog ou Todo vers Queue.

Le placement dans Queue compte. Il remplace l’attente des dépendances inachevées. Avant d’y placer le libre-service salarié, confirmez que les fondations d’identité existent ou que le périmètre choisi les établit correctement.

Examiner le plan détaillé

Le planificateur lit le dépôt, les documents produit, les politiques, les instructions et le contexte de déploiement. Vérifiez le plan au regard du résultat utilisateur réel et de l’environnement.

Pour le service d’équipement, vérifiez trois cas d’accès. Un salarié voit sa demande. Un autre salarié ne peut pas la voir. Un manager conserve l’accès de revue prévu. Incluez les effets de migration des données et d’exploitation si l’implémentation les modifie.

Si Build on its own by default est désactivé, le plan terminé attend votre décision. Approve lance la construction sous l’identité de la personne qui approuve, selon ses permissions. Reject utilise vos retours pour refaire le plan. Une initiative peut avoir son propre réglage.

Utiliser la bonne trace pour la décision suivante

Les plans sont versionnés. Une exécution consigne le plan qu’elle a utilisé. Si l’approche souhaitée change, examinez l’initiative et l’action appropriée de replanification. Utilisez l’exécution pour examiner la tentative précédente.

Une construction, une pull request mergée et une mise en production sont des états différents. Gardez visibles les preuves d’acceptation et la responsabilité du déploiement à mesure que le travail avance. Poursuivez avec les réglages d’autonomie.