タスク、プラン、スプリント、およびレーン

Coroidには4種類の作業単位が存在します。これらは入れ子構造になっており、適切な単位を選ぶかどうかは、作業の規模や同時に実行すべき量によって決まります。

タスク#

最も基本的な単位です。1つのタスクは1つのpull requestを生成する作業単位であり、実際に実行される対象でもあります。計画やスプリント、レーンはすべてタスクを整理するための仕組みです。

結果を1段落で説明でき、レビュアーが一度に内容を確認できる場合、それがタスクです。

計画#

特定の順序で複数の変更が必要な場合、それが計画となります。これは段階に分けてグループ化されたタスクの順序付けられた集合であり、コードを記述する前に承認を受けます。

以下の場合に計画を使用します：

• 後続のステップが先行するステップに依存する場合
• いずれかのステップを実行する前に全体のアプローチを確認したい場合
• 作業内容が単なる変更ではなく機能である場合

計画を承認するのはシステム内で最もコストが低い介入ポイントです。ここでアプローチを却下するコストは1分程度ですが、3つのタスクが実行された後に却下すると3回分の実行コストがかかります。

計画がリポジトリに到達するまでの流れ#

計画のタスクはそれぞれ別のpull requestを作成しません。各タスクは独自のブランチで作業し、共通のレーンブランチにマージされ、そのブランチがベースブランチに対して1つのプルリクエストとして昇格します。

こうすることで、未完成の段階ごとに承認するのではなく、完成した機能全体を一度にレビューできます。

例外として、複数のプロジェクトにまたがる作業の場合、レーンとは異なるプロジェクトに属するタスクは個別に処理されるため、クロスプロジェクトの計画ではリポジトリごとにpull requestが生成されます。これは避けられない仕様であり、pull requestは2つのリポジトリにまたがることはできません。

スプリント#

時間制限付きの作業コンテナであり、独自の指標とタイムラインを持ちます。スプリントは「この期間に何を実施し、その結果はどうだったか」を問うものであり、「この機能がどのように構築されるか」を問うものではありません。

チームの作業を一定期間調整する場合はスプリントを、1つの機能を分解する場合は計画を使用します。両者は代替関係にあるわけではなく、スプリント内に複数の計画に属するタスクが含まれることもあります。

レーン#

レーンは計画の並列作業が統合される場所です。タスクはベースブランチではなくレーンのブランチを対象とするため、複数のエージェントが同時に作業しても競合せず、条件を満たした時点で1つのpull requestとして昇格します。

計画が重視するのは順序一方、レーンが重視するのは並列性と統合です。複数のエージェントを活用でき、厳密に直列化する必要のない作業がある場合、レーンを利用すれば同時に実行しつつ、1つのレビュー可能な変更としてまとめることができます。

選択方法#

重要なのはプルリクエストの数ではありません。タスクも計画もどちらも1つとして到達します。重要なのは、結果をレビューする価値があると判断するまでにどれだけの作業が必要かという点です。

1. レビュアーが一度に読めるような1回の変更か？はい → タスク。
2. 全体として意味をなすためには、複数の順序付けられた変更が必要か？はい → 計画。そのレーンを利用して、可能な範囲で並列に作業を実行します。

スプリントはこれらすべてと並列に位置づけられる計画・報告レイヤーです。

リリースの役割#

「リリースは統合後の配信記録であり、別のタスクや計画、スプリント、レーンではありません。リポジトリ内のコミットを特定し、そのコミットに計画された作業が含まれているかを確認し、各環境でのデプロイ試行を追跡します。1つのリリースには複数のスプリントで作成された作業が含まれる場合もあり、1つのスプリントで複数のリリースが生成されることもあります。レーンの昇格処理でpull requestが作成されますが、それ自体が検証済みの出荷物を生成するわけではありません。

同時に実行可能な処理量を制限する要因#

構造ではなく、処理能力が決定要因です。並列処理に対応するタスクが10件ある計画でも、エージェントスロットが1つしかなければ順番に処理されます。詳細は処理能力とエージェントスロット。

関連項目#

• 仕様書
• 品質チェック
• リリース