成果をinitiativeにする

手順の前に結果を説明する

架空の備品サービスには、従業員自身による申請が必要です。有用な要求は、成果を示します。「認証された従業員が申請を作成し、自分の申請だけを閲覧できる」と記載します。

重要な理由を説明します。現在は、マネージャーが従業員の代わりに申請を入力しています。範囲として、申請の作成、状態の表示、アクセスチェック、それらの振る舞いの証拠を定義します。自動購入と、マネージャーの承認ルールの変更は除外します。

リポジトリを調べる前に、ファイルの編集方法を指定しないでください。Initiativeは意図を記録します。詳細な計画が、その意図を実装手順に変えます。

要求から作られた内容をレビューする

Taigaは要求とproductのコンテキストを使い、一つのinitiative、または順序付けられた複数のinitiativeを作成します。新しい作業はBacklogに入ります。大きな要求には、独立してレビューできる複数の変更が必要になる場合があります。

生成された最終状態、Why、Scopeを読みます。必要な振る舞いが残り、除外項目が守られていることを確認します。既存のinitiativeがすでに要求を扱っている場合、Taigaは重複を作る代わりに、それを示すことがあります。

公開済みポリシーに阻まれる要求には、そのポリシーが定める判断経路が必要です。説明を読み、その経路を通じて競合を解消します。禁止された操作を隠すためだけに、要求を書き換えないでください。

ボードを実行順序として扱う

Taigaは、計画を含めて、productごとに一度に一つのinitiativeに取り組みます。現在のpull requestがマージされると、Queueの次のinitiativeを開始します。BacklogやTodoからQueueへ、項目を自動では移しません。

Queueへの配置は重要です。未完了の依存作業の完了待ちを上書きします。従業員自身による申請をQueueに入れる前に、ID基盤が存在するか、選択した範囲でそれを正しく構築することを確認してください。

詳細な計画を確認する

Plannerは、リポジトリ、product文書、ポリシー、指示、デプロイのコンテキストを読みます。実際にユーザーが必要とする成果と環境に照らして、計画を確認します。

備品サービスでは、三つのアクセスケースを検証します。従業員が自分の申請を見られること。別の従業員はそれを見られないこと。マネージャーが意図したレビュー用アクセスを維持することです。実装がデータ移行や運用に影響する場合は、それらも含めます。

Build on its own by defaultがオフの場合、完成した計画は判断を待ちます。Approveは、承認者の権限に従い、その人を実行主体としてbuildを開始します。Rejectは、フィードバックを使って再計画します。Initiativeには、個別の設定を持たせることもできます。

次の判断に適した記録を使う

計画はバージョン管理されます。Runは、どの計画を実行したかを記録します。意図する方針が変わった場合は、initiativeと、適切な再計画操作を確認します。前の試行を調べるには、runを使います。

Build、マージ済みのpull request、本番リリースは、それぞれ異なる状態です。作業が進んでも、受け入れの証拠とデプロイの責任を明確に保ってください。続いて、自律動作の設定を学んでください。