Taigaで新しいproductを始める

明確な成果を一つ準備する

このシナリオでは、架空の備品申請サービスを使います。マネージャーが従業員の備品申請と判断を記録します。従業員自身による申請は、後の拡張です。学習には合成レコードを使ってください。このシナリオは、実際の人事データの利用を許可するものではありません。

Productを作成する前に、組織と関連する共有コンテキストが設定済みであることを確認します。サービスの成果に責任を持つ人と、稼働環境に責任を持つチームを特定します。

初期の範囲を書きます。最初のバージョンは、申請と判断を記録します。備品の発注、支出の自動承認、給与レコードの変更は行いません。

この新しいサービスには、Start from scratchを選びます。既存のリポジトリを出発点にする場合は、Import codebaseを使います。インポートはproductの作成時に選ぶため、意図して選択してください。

作成時には、TaigaがInfrastructure codeとCI/CD pipelinesを作るかも確認されます。これらは別々の責任です。プラットフォームチームがすでに一部を提供している場合は、その生成オプションをオフにし、現在の実施方法を説明します。

例えば、「当社のプラットフォームは、既存のリポジトリパイプラインを通じて、レビュー済みのコンテナーイメージをデプロイします。そのworkload identityと環境設定を使ってください」と記載します。この説明に依存する前に、正確であることを確認します。

Discoveryは、Contextから始まります。会話の前に、関連するproductの参考資料と継続的な指示を追加します。複数のproductで共有するルールは、組織またはfactoryのレベルに置きます。

備品サービスでは、従業員の本人確認方法、承認されたデータサービス、マネージャーのアクセスルールが有用なコンテキストです。未解決の問いを明示します。フォームを埋めるために、保持期間を作り上げないでください。

次に、会話でサービスを説明します。ユーザー、望ましい結果、制限、対象外の範囲を説明します。作業中、仕様は下書きとして保存されます。

実装を変える前提がないか、仕様を読みます。このシナリオでは、マネージャーがすべての従業員の申請を見られるのか、自分のチームの申請だけなのかを確認します。その違いは、権限、データフロー、テストに影響します。

後続の作業に適した内容になったら、仕様を公開します。下書きの変更は、再び公開するまで公開済みの版を置き換えません。必要な文書を順に進め、前提条件をレビューします。Discoveryのレッスンでは、依存関係と古くなった文書を説明します。

必須の八つの文書をすべて公開したら、Discoveryを完了し、initiativeを計画します。生成された順序は、確認して変更できる提案です。

Initiativeの詳細を計画する前に、リポジトリを接続します。計画の開始に環境は必須ではありませんが、予定する環境も同時に定義します。

環境の説明は、クラウドアクセスを与えません。デプロイは、自社のパイプラインが実行します。担当チームと、リポジトリのブランチ、ID、インフラの責任、必要な設定作業を確認してください。

このシナリオの有用な成果は、定義されたproductと、実際のデリバリー環境に基づくレビュー可能な作業です。Taigaワークフローのシミュレーションで、判断の順序を練習してください。