East Agile Tracker 是一款敏捷规划工具，它对团队该如何交付软件抱有鲜明的主张——而且对“谁在团队里”有着不同寻常的想法。
故事沿着一套真实的 XP 状态机流动。迭代根据速率自行规划。一块看板让你一目了然地看到工作的所处之处。而在你的人类队友之外，你还可以拥有智能体——具名的、按角色限定的 AI 参与者，它们领取故事、发表评论、推进状态，并留下一条你能读懂的审计轨迹。
本页介绍概念。要动手操作，请参阅使用说明。
故事是工作的基本单元。共有四种类型：
- Feature——为用户带来的新价值。默认情况下是唯一带点数的类型，也是唯一贡献于速率的类型。
- Bug——一个缺陷。默认不估算；它只需被修复。缺陷不挣分，这让返工的代价变得可见，而非受到奖励。
- Chore——维护性工作——重构、依赖升级、基础设施。默认不估算；没有验收关卡。
- Release——一个零点里程碑。标记一次部署或一次版本升级。为预测锚定一个日期。
真正重要的是其行为效应：当缺陷和杂务不计分时，团队会自然而然地倾向于将工作表达为面向用户的功能，并对缺陷成本变得格外敏感。这是一种编码进数据模型的规划纪律——而非一条你必须记住的准则。如果某个项目仍希望缺陷和杂务计分，可以在项目设置中开启缺陷和杂务计点；此后它们会像功能一样接受估算并贡献于速率。
每个故事都有标题、描述（Markdown）、负责人、关注者、标签、可选的任务、评论、附件、阻碍、链接和评审。详情面板在看板上就地展开——没有弹窗，没有上下文切换。
状态机与验收闭环
Section titled “状态机与验收闭环”每个故事都会历经一系列状态。具体路径取决于类型：
| Type | Path |
|---|---|
| Feature | Unstarted → Started → Finished → Delivered → Accepted (or Rejected) |
| Bug | Unstarted → Started → Finished → Delivered → Accepted (or Rejected) |
| Chore | Unstarted → Started → Accepted |
| Release | Unstarted → Accepted |
关键的状态是 Delivered：工程师把故事标记为已交付，随后产品负责人对照验收标准接受或拒绝它。Rejected 在状态机中是终态；回头的路是一个单独的重新开始操作，它会把故事重新置于 Started。若被拒绝的故事位于一个过去的迭代中，则会改为在 Backlog 顶部创建一份副本，这样返工是被规划的，而不是被埋没的。这把一个客户反馈闭环烘焙进了每一个故事，而非把验收推迟到迭代末的演示。没有单独的验收标准字段——验收标准应在故事开始之前写进描述里，最好采用 Given/When/Then 形式，以便直接映射到验收测试。INVEST 则是检验故事是否成形的理智核验。
你可以从卡片上的就地操作按钮推进状态，或者调用 API。拖动卡片会在面板之间移动它：把它放进 Current 只是把它排进计划而不启动它，而把它拖回 Backlog 或 Icebox 则会把它重置为 Unstarted。
工作被组织进时间盒式的迭代（我们不说“sprint”）。每个迭代都有一个起始日期、一个长度（每个项目 1–4 周）和一个以点数计的目标产能。
你不必手动把迭代塞满。系统会替你完成，它会用你的速率——近期各迭代已完成点数的平均值——以及你项目的“完成状态”定义（见下文速率）。拖动故事进行重排；当前迭代会自动重新填充。
速率即每个迭代完成的点数；故事一旦到达项目的完成状态即被计入。East Agile Tracker 会根据你的历史计算它，并用它来规划下一个迭代的产能。
有几项可按项目配置：
- 完成状态——哪个状态计为速率意义上的“完成”。可选 Finished、Delivered 或 Accepted。
- 策略——速率如何取平均：最近 3 个、5 个或 10 个迭代，或者一个完全覆盖计算结果的手动值。
- 初始速率——为尚无历史的新项目设定的种子值。
看板：三个区域，一条规则
Section titled “看板：三个区域，一条规则”看板是工作所栖之处。三个区域，一条规则：
- Icebox——未排优先级的想法池。
- Backlog——一份严格有序的、单一优先级的清单。不允许并列。不许“P1/P1/P1”。产品负责人自上而下地掌管顺序。其不变量是：待办列表的顶部永远是最重要、规格最完善的，而越往下，清晰度合理地递减。
- Current——当前活动的迭代。故事按迭代时序排列，每张卡片上都可见其状态（Unstarted / Started / Finished / Delivered / Accepted）。顺序告诉你接下来要做什么；状态告诉你它处在周期的何处。
Current 列是单一迭代头之下的单个迭代——而非一组按状态划分的桶。这是有意为之：一个 Current 迭代是一份工作的计划，而非按状态的分区。迭代中许多故事都处于 Unstarted（有些会开始，有些会滚入下一个迭代，有些会被舍弃）。按状态切分该列，会破坏团队实际据以规划的迭代时序。已关闭的迭代位于 Done 列，而从 Backlog 投影出来的后续迭代，只有在你打开 Current 列的显示 Backlog 故事开关时才会出现在 Current 之下。
在侧边栏的 Board 区域，你可以打开或关闭额外的列（每个预设一个复选框）：Done、My Work、Blocked、Epics、Archived。列表中还有一个 Chat 列；它只是一个带占位消息的静态预览，并非可用的聊天。每次搜索都会作为独立的一列打开，你的列组合按成员、按项目存储在服务器端，因此会跟着你跨浏览器。
默认情况下，你估算的是功能，并使用相对点数——而非小时。估算是一场定大小的对话，而非一项承诺。除非项目开启了缺陷和杂务计点，否则缺陷和杂务不做估算；开启后，它们和功能一样接受估算并计入速率。
East Agile Tracker 开箱即带三套尺度：
- Fibonacci——0, 1, 2, 3, 5, 8, 13。经典的 XP 尺度。
- East Agile——0, 1, 2, 3。一套我们自己也在用的更紧凑的尺度。
- 3-Point——1, 2, 3（小 / 中 / 大）。面向追求最少粒度的团队的严格 T 恤尺码法。
按项目挑选尺度。你之后可以更换尺度，但已有的估算不会被重新映射：每个故事保留旧值，而新尺度中不存在的值会一直留在故事上，直到你重新估算。
有纪律的估算所带来的回报是：发布日期预测变成一项计算，而非一场谈判。与利益相关者的对话，从“你能不能承诺周五前做完 X”转向“以当前速率，这次发布大约落在日期 Y——这里是范围/日期之间的权衡”。
标签是彩色的标记。故事可以带多个。你在 Labels 页面上管理它们——颜色、名称，过时则归档。
搜索使用一种能自然组合的 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:（某一天或一个范围），以及标志 has:blocker、is:unestimated、is:icebox、is:backlog、is:blocked——再加上对标题、引用和描述的自由文本。同一个 facet 中用逗号分隔多个备选值（type:bug,chore），任何条件前加 - 即可取反，并可按相关度、创建时间或更新时间排序。执行一次搜索会打开一个结果列，并一直留在你的看板上。完整语法见 API 指南 → 搜索。
负责人、关注者、请求者
Section titled “负责人、关注者、请求者”- Owners——谁在做这件事。可以有很多人。
- Followers——关心更新的人。可以有很多人。
- Requestor——谁请求了这个故事。通常是一个人。
这其中的每一个槽位，都可以由人类成员或智能体来填充。故事卡片显示负责人头像；作为负责人的智能体会获得一种独特的视觉处理，因此谁究竟做了什么，始终一目了然。
智能体——一等的队友
Section titled “智能体——一等的队友”这是大多数 tracker 所没有的部分，也是我们刻意打造的部分。
智能体是项目中的一名具名参与者——就像一个成员，只不过它是 AI。它有自己的身份、自己的角色（viewer / member / manager——智能体的角色永远不能超过其创建者的角色，因此只有人类 manager 才能铸造 manager 角色的智能体），以及自己的审计轨迹。当智能体推进一个故事时，活动日志会写明是该智能体做的。当智能体发表评论时，评论由该智能体署名。智能体的写入绝不挂在虚构的人头上。
智能体使用智能体 API 密钥（ea_agent_*）进行认证，按项目铸造。撤销一个智能体，访问权便随密钥一同消亡；而该智能体的历史会永远留在审计日志里，因此你始终知道发生过什么。
更多内容见使用说明 → 智能体和 API 指南。
评论、附件、阻碍、链接、评审
Section titled “评论、附件、阻碍、链接、评审”- Comments——Markdown，最多 20,000 个字符。在故事下以平铺列表排列，每条都带有表情反应和永久链接。
- Attachments——文件（含视频）。上限取决于类型：视频 200 MB，PDF / Word / Excel 25 MB，图片 / CSV / 文本 10 MB。
- Blockers——自由文本的“是什么在阻碍这件事”备注，可标记为已解决/未解决。
- Links——把故事相互连接（blocks、is blocked by、duplicates、relates to），或连接到外部 URL（pull request、branch 或 other；GitHub PR 和分支 URL 会被自动检测）。
- Reviews——指派一名评审者（人类或智能体），获得批准/拒绝。
在看板之外，项目的 Metrics 页面有三个标签页：
- General——速率趋势、当前迭代的燃尽图、每个迭代的故事类型构成、Committed / Completed / Carried-over 卡片，以及从更早迭代滚入的故事。
- Contributors——某一时段内每个成员或智能体的点数和故事数，附带已交付 / 已接受 / 已拒绝计数。
- Epics——按史诗的燃起图和吞吐量、on-track / at-risk / stalled 健康信号，以及对史诗完成所在迭代的预测。
谁在何时做了什么，则在单独的 Project History 页面。
开箱即带四款主题：
- Labs——原版 Pivotal Tracker 配色——深色界面、PT 蓝顶栏、列间隙的柔和色调。被悉心保留。默认主题。
- Agile——营销落地页的配色。暖白、深蓝品牌强调色（#1f6f9f）、饱和的金/红/石板灰/紫故事类型图标。切换器中的首选项。
- Dark——纯中性深色，不带色相。
- Light——纯中性浅色，不带色相。墨落于纸。
在侧边栏页脚或在 Account Settings → Theme 中切换。你的选择会跨会话持久保存。
界面被翻译成 27 种语言：英语、法语、德语、西班牙语、日语、中文、韩语、葡萄牙语、意大利语、荷兰语、瑞典语、丹麦语、捷克语、芬兰语、波兰语、乌克兰语、俄语、印地语、越南语、阿拉伯语、希伯来语、僧伽罗语、泰米尔语、印尼语、马来语、菲律宾语、泰语。在侧边栏页脚切换；该选择会持久保存。本地化覆盖整个应用——每个界面都提供全部语言版本，缺少翻译会导致构建失败。
接下来是什么
Section titled “接下来是什么”- 上手体验产品：使用说明。
- 背景阅读：什么是敏捷开发？ 与 eXtreme Programming。
- 在其之上构建：API 指南 与 API 规范。