Démarrer un nouveau produit dans Taiga

Préparer un résultat clair

Ce scénario utilise un service fictif de demandes d’équipement. Un manager consigne la demande d’un salarié et la décision. Le libre-service salarié sera ajouté plus tard. Utilisez des enregistrements synthétiques pour apprendre. Le scénario n’autorise pas de vraies données du personnel.

Avant de créer le produit, confirmez que l’organisation et le contexte partagé pertinent sont configurés. Identifiez le responsable du résultat du service et l’équipe responsable de son environnement d’exploitation.

Définissez une limite initiale : la première version consigne les demandes et les décisions. Elle ne commande pas d’équipement, n’approuve pas automatiquement de dépenses et ne modifie pas la paie.

Choisir le point de départ du produit

Choisissez Start from scratch pour ce nouveau service. Utilisez Import codebase lorsqu’un dépôt existant doit définir le point de départ. L’import est un choix à la création du produit ; faites-le délibérément.

La création demande aussi si Taiga écrit Infrastructure code et CI/CD pipelines. Ce sont des responsabilités distinctes. Si votre équipe plateforme fournit déjà une partie, désactivez l’option de génération correspondante et décrivez comment le travail est fait aujourd’hui.

Par exemple : « Notre plateforme déploie les images de conteneur revues par le pipeline existant du dépôt. Utilisez son identité de workload et sa configuration d’environnement. » Confirmez l’exactitude de cette description avant de vous y fier.

Placer le contexte avant la conversation

Discovery commence par Context. Ajoutez les références produit et les instructions permanentes pertinentes avant la conversation. Placez les règles communes à plusieurs produits au niveau de l’organisation ou de la factory.

Pour le service d’équipement, le contexte utile inclut la méthode d’identité des salariés, les services de données approuvés et la règle d’accès des managers. Précisez les questions non résolues. N’inventez pas une durée de conservation pour compléter un formulaire.

Décrivez ensuite le service dans la conversation. Expliquez les utilisateurs, le résultat souhaité, les restrictions et ce qui est hors périmètre. La spécification est enregistrée comme brouillon pendant votre travail.

Examiner et publier l’intention

Lisez la spécification pour repérer les hypothèses qui changeraient l’implémentation. Dans ce scénario, vérifiez si un manager peut voir toutes les demandes des salariés ou seulement celles de son équipe. Cette différence touche les permissions, les flux de données et les tests.

Publiez la spécification lorsque son contenu convient aux travaux suivants. Les modifications du brouillon ne remplacent la version publiée que lorsque vous publiez de nouveau. Poursuivez les documents requis et examinez leurs hypothèses. La leçon Discovery explique les dépendances et les documents obsolètes.

Après publication des huit documents requis, terminez Discovery et planifiez les initiatives. La séquence générée est une proposition que vous pouvez examiner et modifier.

Relier la cible réelle de livraison

Connectez le dépôt avant la planification détaillée des initiatives. Définissez les environnements prévus en même temps, même si un environnement n’est pas obligatoire pour commencer la planification.

Une description d’environnement n’accorde pas d’accès cloud. Votre pipeline effectue le déploiement. Vérifiez la branche du dépôt, l’identité, la responsabilité de l’infrastructure et les tâches de configuration requises avec l’équipe responsable.

Le résultat utile de ce scénario est un produit défini et un travail vérifiable fondé sur son environnement réel de livraison. Entraînez-vous à suivre la séquence de décisions dans la simulation du parcours Taiga.