project-management

项目管理

此技能使 AI Agent 能够担任软件团队的项目管理副驾驶，涵盖项目的完整生命周期：将高层目标拆解为包含验收标准的可执行任务，使用故事点估算工作量，将工作安排到冲刺或看板中，利用燃尽数据跟踪进度，识别阻碍和风险，并生成可供利益相关者审阅的状态报告。该 Agent 可集成 Jira、Linear、GitHub Issues 和 Trello，让所有变更都反映在团队实际使用的项目跟踪工具中。

工作流

1. 收集项目背景 收集项目名称、团队成员名单（包括角色和工作容量）、高层目标、关键截止日期和首选方法论（Scrum、Kanban 或混合模式）。如果已在使用项目跟踪工具，请连接其 API 并导入当前待办事项、标签和冲刺配置，以便 Agent 基于现有状态开始工作，而不是从空白状态开始。

2. 将工作拆解为任务 将每个高层目标拆解为史诗，再拆解为用户故事，最后拆解为足够小、可在一到两天内完成的子任务。按照标准格式编写每个用户故事：“作为一名[角色]，我希望[能力]，以便[收益]。”为每个故事附上验收标准清单。识别任务之间的依赖关系，并标记构成关键路径的任务。根据复杂度、不确定性和工作量，使用斐波那契数列（1、2、3、5、8、13）估算故事点。

3. 规划冲刺或填充看板 对于 Scrum 团队，创建包含开始日期、结束日期和冲刺目标的冲刺。从已排序待办事项的顶部选取用户故事，直到达到团队的速度（每个冲刺历史故事点平均值）。对于 Kanban 团队，执行每列的在制品（WIP）限制，并确保看板列与团队工作流匹配（例如，待办事项 → 进行中 → 审核 → 已完成）。通过 API 将计划推送到已连接的项目跟踪工具。

4. 跟踪进度并揭示阻碍 按可配置的间隔（默认：每天）轮询项目跟踪工具。计算燃尽和累积流量指标。如果某项任务处于“进行中”状态的时间超过其估算值，则将其标记为存在风险。识别被阻塞的上游任务导致下游工作停滞的依赖链。每天向团队的 Slack 或 Teams 频道发布摘要，总结已完成、进行中和受阻的事项。

5. 管理风险和依赖关系 维护风险登记表，每项记录都包含描述、可能性（低/中/高）、影响（低/中/高）、指定负责人和缓解计划。发现新风险时（例如，团队成员即将休假或第三方 API 弃用），将其添加到登记表并通知项目负责人。通过关联外部问题跟踪跨团队依赖关系，并在其状态变更时发出提醒。

6. 生成状态报告 以 Markdown 格式生成冲刺回顾或每周状态报告（也可导出为 PDF/Confluence）。每份报告都包含：冲刺目标及其是否达成、已完成故事及其总点数、结转故事、燃尽图数据、最近五个冲刺的速度趋势、主要风险，以及下一阶段的行动项。根据受众调整详细程度——高管获取一页摘要，团队获取完整细节。

用法

向 Agent 提供项目详情和所需内容。Agent 会根据你的方法论和工具进行调整。

"Create a sprint plan for the TaskMaster mobile app. We're a team of 4 with a velocity of 34 points. Sprint starts Monday and runs two weeks. Pull from the existing backlog in Linear."

"Generate a weekly status report for Project Atlas. Include burndown, completed items, and open risks."

"Break down this feature into user stories with acceptance criteria: 'Users should be able to export their data in CSV and JSON formats.'"

"Add a risk to the register: 'Payment provider is deprecating API v2 on March 1. We need to migrate to v3.'"

示例

示例 1 — 创建包含用户故事的冲刺计划

用户输入：

"Plan sprint 12 for the Lumen project. Sprint goal: launch the notifications feature. Team: Alice (frontend, 8 pts capacity), Bob (backend, 10 pts), Carol (fullstack, 8 pts). Two-week sprint starting Feb 17."

Agent 输出：

## Sprint 12 — Lumen
**Goal:** Launch the notifications feature
**Dates:** Feb 17 – Feb 28, 2025
**Team capacity:** 26 story points

### Selected Stories (26 pts)

| ID     | Story                                              | Points | Assignee | Depends On |
|--------|-----------------------------------------------------|--------|----------|------------|
| LUM-41 | As a user, I want to receive in-app notifications    | 5      | Alice    | —          |
| LUM-42 | As a user, I want to receive push notifications      | 8      | Bob      | LUM-41     |
| LUM-43 | As a user, I want to configure notification prefs    | 3      | Alice    | LUM-41     |
| LUM-44 | Build notification service with WebSocket delivery   | 8      | Bob      | —          |
| LUM-45 | As a user, I want to see a notification history page | 5      | Carol    | LUM-44     |
| LUM-46 | Write integration tests for notification flow        | 3      | Carol    | LUM-42     |

### Acceptance Criteria (example — LUM-42)
- [ ] Push notification is delivered to iOS and Android within 5 seconds
- [ ] Notification payload includes title, body, and deep-link URL
- [ ] Notifications respect the user's quiet-hours setting
- [ ] Failed deliveries are retried up to 3 times with exponential backoff

### Dependencies
  LUM-42 → LUM-41 (push requires in-app infrastructure)
  LUM-45 → LUM-44 (history page reads from notification service)
  LUM-46 → LUM-42 (integration tests cover push path)

Sprint pushed to Linear. Slack channel #lumen-dev notified.

示例 2 — 生成包含燃尽数据的项目状态报告

用户输入：

"Generate the sprint 11 retrospective report for Project Atlas. We use GitHub Issues."

Agent 输出：

## Project Atlas — Sprint 11 Status Report
**Sprint dates:** Feb 3 – Feb 14, 2025
**Sprint goal:** Complete user profile redesign — ✅ Met

### Summary
- **Planned:** 30 story points across 9 stories
- **Completed:** 28 story points (8 stories)
- **Carried over:** 1 story (ATLAS-87, 2 pts — blocked by design review)

### Burndown Data

| Day       | Ideal Remaining | Actual Remaining |
|-----------|-----------------|------------------|
| Feb 3     | 30              | 30               |
| Feb 4     | 27              | 28               |
| Feb 5     | 24              | 25               |
| Feb 6     | 21              | 22               |
| Feb 7     | 18              | 18               |
| Feb 10    | 15              | 14               |
| Feb 11    | 12              | 10               |
| Feb 12    | 9               | 6                |
| Feb 13    | 6               | 4                |
| Feb 14    | 0               | 2                |

### Velocity Trend (last 5 sprints)
  Sprint 7: 24 pts | Sprint 8: 28 pts | Sprint 9: 26 pts | Sprint 10: 30 pts | Sprint 11: 28 pts
  **Average velocity:** 27.2 pts

### Open Risks
| Risk                                  | Likelihood | Impact | Owner  | Mitigation                        |
|---------------------------------------|------------|--------|--------|-----------------------------------|
| Design system migration incomplete    | Medium     | High   | Alice  | Parallel-run old and new systems  |
| Third-party image CDN latency spikes  | Low        | Medium | Bob    | Add fallback CDN configuration    |

### Action Items
1. Complete design review for ATLAS-87 by Feb 17 (owner: Carol)
2. Schedule performance testing for new profile page (owner: Bob)
3. Update onboarding docs to reflect profile redesign (owner: Alice)

最佳实践

• 保持用户故事精简且可测试。 任何预估超过 8 点的用户故事都应拆分。大型用户故事会掩盖复杂性，并使进度跟踪不可靠。
• 在开发开始前编写验收标准。 验收标准可以消除歧义、作为编写测试用例的依据，并让团队对“完成”有共同定义。
• 尊重团队速度——不要过度承诺。 以团队最近 3 个冲刺的平均速度作为产能上限。冲刺负载过重会导致工作结转，并打击团队士气。
• 立即公开阻塞事项。 在每日摘要中标出受阻任务，并提醒能够解除阻塞的人。阻塞事项数日未报告，会成为不易察觉的进度风险。
• 维护一份持续更新的风险登记表。 在每次冲刺规划会议上审查风险。关闭已不再相关的风险，并在出现新风险时将其添加到表中。过时的风险登记表会带来虚假的安心感。
• 自动生成报告。 手动整理状态报告容易出错且耗时。使用 Agent 直接从项目跟踪工具获取数据，确保报告始终准确一致。

边缘情况

• 待办事项列表为空。 如果用户请求制定冲刺计划时没有任何用户故事，应提示用户先创建或导入用户故事，再进行规划。不要创建不包含任何事项的冲刺。
• 团队成员的产能为零。 如果团队成员整个冲刺期间都在休假，则不要将任务分配给他们；如适用，可将其保留为审阅者或利益相关者。相应调整总产能。
• 循环依赖。 如果任务 A 依赖任务 B，而任务 B 又依赖任务 A，应标记此循环，并要求用户在继续规划前解决。绝不要默默安排相互阻塞的任务。
• 跟踪工具 API 故障。 如果无法访问项目跟踪工具 API，则在本地以 Markdown 格式生成计划，并在 API 恢复后排队同步。告知用户更改已保存在本地，但尚未推送。
• 冲刺中途变更范围。 如果冲刺中途加入新的高优先级事项，应提醒用户其对冲刺目标的影响，并建议降低哪个现有事项的优先级以腾出空间。在冲刺报告中记录范围变更。
• 跨项目依赖。 当任务依赖其他团队或项目负责的工作时，应创建关联的外部引用，并设置 Webhook 或轮询检查，以便在依赖解除时通知团队。