East Agile Tracker は、チームがどのようにソフトウェアをリリースすべきかについて確固たる考えを持つアジャイルプランニングツールであり、そして誰がチームに属するのかについて型破りな発想を持っています。
ストーリーは本物の XP 状態機械を流れます。イテレーションはベロシティから自ら計画されます。ボードは作業がどこにあるかを正確に示します。そして人間のチームメイトと並んで、エージェント を加えることができます。彼らは名前を持ち、ロールに応じた範囲で動く AI の参加者で、ストーリーを引き受け、コメントし、状態を遷移させ、あなたが読める監査証跡を残します。
このページでは概念を扱います。実際の操作については 操作手順 を参照してください。
ストーリーは作業の基本単位です。タイプは 4 つあります。
- Feature — ユーザーにとっての新しい価値。デフォルトでは、ポイントを持つ唯一のタイプであり、ベロシティに寄与する唯一のタイプです。
- Bug — 欠陥。デフォルトでは見積もりはなく、ただ修正されなければなりません。bug はクレジットを得ないため、手戻りのコストは報酬ではなく可視化されます。
- Chore — メンテナンス作業 — リファクタ、依存関係の更新、インフラ。デフォルトでは見積もりはなく、受け入れのゲートもありません。
- Release — ゼロポイントのマイルストーン。デプロイやバージョン更新を記します。予測のために日付を固定します。
重要なのは行動への影響です。bug と chore が得点しないとき、チームは自然と作業をユーザー志向の機能として表現しようとし、欠陥のコストを鋭く意識するようになります。これは覚えておかなければならないガイドラインではなく、データモデルに組み込まれたプランニングの規律です。それでも bug と chore を数えたいプロジェクトは、プロジェクト設定で Points for bugs and chores をオンにできます。すると feature と同様に見積もりを持ち、ベロシティに寄与するようになります。
すべてのストーリーには、タイトル、説明（Markdown）、オーナー、フォロワー、ラベル、任意のタスク、コメント、添付ファイル、ブロッカー、リンク、レビューがあります。詳細パネルはボード上にインラインで開きます。モーダルも、コンテキストの切り替えもありません。
状態機械と受け入れループ
Section titled “状態機械と受け入れループ”各ストーリーは複数の状態を移動します。正確な経路はタイプによって異なります。
| タイプ | 経路 |
|---|---|
| Feature | Unstarted → Started → Finished → Delivered → Accepted（または Rejected） |
| Bug | Unstarted → Started → Finished → Delivered → Accepted（または Rejected） |
| Chore | Unstarted → Started → Accepted |
| Release | Unstarted → Accepted |
決定的な状態は Delivered です。エンジニアがストーリーを delivered とマークし、プロダクトオーナーが受け入れ基準に照らして accept するか reject します。Rejected は状態機械における終端です。戻る道は別の Restart アクションで、ストーリーを再び Started に置きます。過去のイテレーションにあるストーリーを reject すると、代わりに Backlog の最上部にコピーが作られるため、手戻りは埋もれるのではなく計画されます。これは受け入れをスプリント末のデモまで先延ばしにするのではなく、すべてのストーリー 1 つ 1 つに顧客フィードバックループを組み込みます。独立した受け入れ基準フィールドはありません。基準はストーリーが開始される前に、理想的には受け入れテストに直接対応づけられるよう Given/When/Then の形式で、説明に記載されるべきです。INVEST は、ストーリーが適切に形成されているかどうかの健全性チェックです。
状態はカード上のインラインアクションボタンから進めるか、API を呼び出すことで進められます。カードのドラッグはパネル間の移動です。Current に落とすと開始しないまま計画に入るだけですが、Backlog や Icebox へドラッグして戻すと Unstarted にリセットされます。
イテレーション
Section titled “イテレーション”作業はタイムボックス化された イテレーション に整理されます（私たちは「スプリント」とは呼びません）。各イテレーションには開始日、長さ（プロジェクトごとに 1〜4 週間）、ポイントでの目標キャパシティがあります。
イテレーションを手動で詰め込む必要はありません。システムが、あなたの ベロシティ — 直近のイテレーションで完了したポイントの平均 — とプロジェクトの「完了状態」の定義を使って、それを代行します（後述の ベロシティ を参照）。ストーリーをドラッグして並べ替えれば、現在のイテレーションは自動的に再充填されます。
ベロシティは、イテレーションあたりに完了したポイント数です。ストーリーは、プロジェクトの完了状態に達した時点で数えられます。East Agile Tracker は履歴からそれを計算し、次のイテレーションのキャパシティを計画するために使用します。
いくつかの項目はプロジェクトごとに設定できます。
- 完了状態 — ベロシティにおいて「完了」とみなされる状態。選択肢は Finished、Delivered、Accepted です。
- 戦略 — ベロシティの平均の取り方: 直近 3、5、または 10 イテレーション、あるいは計算を完全に上書きする 手動 の値。
- 初期ベロシティ — まだ履歴のない新規プロジェクトのためのシード値。
ボード: 3 つのゾーン、1 つのルール
Section titled “ボード: 3 つのゾーン、1 つのルール”ボードは作業が存在する場所です。3 つのゾーン、1 つのルール。
- Icebox — 優先順位付けされていないアイデアの溜まり場。
- Backlog — 厳密に順序付けられた、単一の優先順位リスト。同順位はありません。「P1/P1/P1」もありません。プロダクトオーナーが上から下までの順序を所有します。不変条件: バックログの最上部は常に最も重要で最もよく仕様化されており、下に進むにつれて明確さが正当に減少していきます。
- Current — アクティブなイテレーション。ストーリーはイテレーションの時系列順に並び、各カードに状態（Unstarted / Started / Finished / Delivered / Accepted）が表示されます。順序が次に取り組むものを教え、状態がサイクルのどこにいるかを教えます。
Current 列は単一のヘッダーの下にある単一のイテレーションです。状態ごとのバケットの集合ではありません。これは意図的です。Current イテレーションは状態による区分ではなく、作業の 計画 だからです。イテレーション内の多くのストーリーは Unstarted です（一部は開始され、一部は次のイテレーションへ繰り越され、一部は破棄されます）。列を状態でスライスすると、チームが実際に計画するイテレーションの時系列が崩れてしまいます。閉じたイテレーションは Done 列にあり、Backlog から投影される今後のイテレーションは、Current の Show Backlog stories トグルをオンにしたときにだけ Current の下に表示されます。
サイドバーの Board セクションから、追加の列をオン/オフに切り替えられます（プリセットごとのチェックボックス）。Done、My Work、Blocked、Epics、Archived です。Chat 列も一覧にありますが、これはプレースホルダーのメッセージを表示する静的なプレビューであり、動作するチャットではありません。検索は専用の列として開きます。列の構成はプロジェクトごと・メンバーごとにサーバー側に保存されるので、ブラウザをまたいで引き継がれます。
デフォルトで見積もるのは feature で、時間ではなく 相対ポイント を使います。見積もりはサイジングのための会話であり、約束ではありません。bug と chore は、プロジェクトが Points for bugs and chores をオンにしない限り見積もりを持ちません。オンにすると、feature と同じように見積もりを持ち、ベロシティに数えられます。
East Agile Tracker は最初から 3 つのスケールを備えています。
- Fibonacci — 0, 1, 2, 3, 5, 8, 13。古典的な XP スケール。
- East Agile — 0, 1, 2, 3。私たち自身が使うより引き締まったスケール。
- 3-Point — 1, 2, 3（Small / Medium / Large）。最小限の粒度を望むチームのための厳格な T シャツサイジング。
スケールはプロジェクトごとに選びます。後でスケールを変更できますが、既存の見積もりは再マッピングされません。各ストーリーは古い値を保持し、新しいスケールにない値は、再見積もりするまでストーリーに残ります。
規律ある見積もりの見返り: リリース日の予測が交渉ではなく 計算 になります。ステークホルダーとの会話は「金曜日までに X をコミットできますか」から「現在のベロシティでは、このリリースは Y 日あたりに着地します — スコープ/日付のトレードオフはこうです」へと変わります。
ラベル は色付きのタグです。ストーリーは複数持てます。Labels ページで管理します — 色、名前、古くなったらアーカイブ。
検索とフィルター
Section titled “検索とフィルター”検索は、自然に組み合わせられる GitHub スタイルのフィルター構文を使います。
type:feature state:started label:mvp owner:claire修飾子: type:、state:、label:"with spaces"、epic:、priority:、points:（値または 1..5 のような範囲）、iteration:、人物の修飾子 owner:、requester:、follower:、reviewer:、commenter:、mention:（メンバーとエージェント。@me はあなた自身）、日付の修飾子 created:、updated:、started:、completed:、release:（1 日または範囲）、フラグ has:blocker、is:unestimated、is:icebox、is:backlog、is:blocked — 加えてタイトル、参照、説明に対するフリーテキスト。ファセット内の選択肢はカンマで区切り（type:bug,chore）、先頭に - を付ければ何でも否定でき、関連度、作成日、更新日で並べ替えられます。検索を実行すると結果の列が開き、ボード上に残ります。完全な文法は API ガイド → 検索 にあります。
オーナー、フォロワー、リクエスター
Section titled “オーナー、フォロワー、リクエスター”- オーナー — 作業を行う人。複数可。
- フォロワー — 更新を気にかける人々。複数可。
- リクエスター — そのストーリーを依頼した人。通常 1 人。
これらの枠はそれぞれ、人間のメンバー でも エージェント でも埋められます。ストーリーカードにはオーナーのアバターが表示され、エージェントのオーナーには独自の視覚的な表現が与えられるので、誰が実際に何をしたかが常に明確です。
エージェント — 一級のチームメイト
Section titled “エージェント — 一級のチームメイト”これはほとんどのトラッカーが持たない部分であり、私たちが意図的に作り上げた部分です。
エージェント はプロジェクトの名前を持つ参加者です。メンバーのようですが、AI です。独自のアイデンティティ、独自のロール（viewer / member / manager — エージェントのロールは作成者のロールを超えることができないため、manager ロールのエージェントを発行できるのは人間の manager だけです）、独自の監査証跡を持ちます。エージェントがストーリーを遷移させると、アクティビティログにはエージェントが行ったと記録されます。エージェントがコメントすると、そのコメントにはエージェントの署名が付きます。エージェントの書き込みに架空の人間が現れることはありません。
エージェントは エージェント API キー（ea_agent_*）で認証します。これはプロジェクトごとに発行されます。エージェントを取り消すと、アクセスはキーとともに消滅します。エージェントの履歴は監査ログに永遠に残るので、何が起きたかを常に把握できます。
詳しくは 操作手順 → エージェント と API ガイド を参照してください。
コメント、添付ファイル、ブロッカー、リンク、レビュー
Section titled “コメント、添付ファイル、ブロッカー、リンク、レビュー”- コメント — Markdown、最大 20,000 文字。ストーリーの下のフラットな一覧で、それぞれに絵文字リアクションとパーマリンクがあります。
- 添付ファイル — 動画を含むファイル。上限は種類によります: 動画 200 MB、PDF / Word / Excel 25 MB、画像 / CSV / テキスト 10 MB。
- ブロッカー — 「これを妨げているもの」を記すフリーテキストのメモ。解決済み/未解決でマークされます。
- リンク — ストーリー同士（blocks、is blocked by、duplicates、relates to）または外部 URL（pull request、branch、other。GitHub の PR とブランチの URL は自動検出）を接続します。
- レビュー — レビュアー（人間またはエージェント）を割り当て、承認/却下を得ます。
ボードを超えて、プロジェクトの Metrics ページには 3 つのタブがあります。
- General — ベロシティの推移、現在のイテレーションのバーンダウン、イテレーションごとのストーリータイプの構成比、Committed / Completed / Carried-over のカード、以前のイテレーションから繰り越されたストーリー。
- Contributors — 期間内のメンバーまたはエージェントごとのポイントとストーリー数、delivered / accepted / rejected の件数付き。
- Epics — エピックごとのバーンアップとスループット、on-track / at-risk / stalled の健全性シグナル、エピックが完了するイテレーションの予測。
誰が何を、いつ行ったかは、別の Project History ページにあります。
最初から 4 つのテーマを備えています。
- Labs — オリジナルの Pivotal Tracker パレット — ダークなクローム、PT ブルーのトップバー、パステルの列の隙間。愛情を込めて保存されています。デフォルトです。
- Agile — マーケティング用ランディングページのパレット。温かみのある白、深い青のブランドアクセント（#1f6f9f）、彩度の高いゴールド/レッド/スレート/パープルのストーリータイプアイコン。スイッチャーの筆頭オプション。
- Dark — 純粋でニュートラルなダーク、色相なし。
- Light — 純粋でニュートラルなライト、色相なし。紙の上のインク。
サイドバーのフッターか、Account Settings → Theme で切り替えます。選択はセッションをまたいで保持されます。
UI は 27 言語に翻訳されています: 英語、フランス語、ドイツ語、スペイン語、日本語、中国語、韓国語、ポルトガル語、イタリア語、オランダ語、スウェーデン語、デンマーク語、チェコ語、フィンランド語、ポーランド語、ウクライナ語、ロシア語、ヒンディー語、ベトナム語、アラビア語、ヘブライ語、シンハラ語、タミル語、インドネシア語、マレー語、フィリピン語、タイ語。サイドバーのフッターから切り替えられ、選択は保持されます。ローカライズはアプリ全体に及びます。すべての画面がすべての言語で提供され、翻訳が欠けているとビルドが失敗します。
- 製品に実際に触れる: 操作手順。
- 背景を読む: アジャイル開発とは？ と eXtreme Programming。
- その上に何かを作る: API ガイド と API 仕様。