Project Management
此技能使 AI 代理能够作为软件团队的项目管理协作者。它涵盖完整生命周期：将高层次目标分解为可执行任务并设定验收标准，以故事点估算工作量，将工作组织成冲刺或看板，使用燃尽数据跟踪进度，识别阻碍和风险，并生成面向利益相关者的状态报告。该代理与 Jira、Linear、GitHub Issues 和 Trello 集成，使所有更改都能反映在团队的实际项目跟踪器中。
Workflow
-
收集项目背景信息
收集项目名称、团队成员名单（含角色和容量）、高层次目标、关键截止日期以及首选方法论（Scrum、Kanban 或混合方式）。如果已有项目跟踪工具，连接其 API 并导入当前的待办事项列表、标签和冲刺配置，使代理从现有状态开始而不是从空白开始。 -
将工作分解为任务
将每个高层次目标分解为史诗（epic），再进一步拆分为用户故事，最终细化为可在一到两天内完成的子任务。每个用户故事应按照标准格式书写：“作为一个 [角色]，我想要 [能力]，以便 [好处]。”在每个故事上附加验收标准作为检查清单。识别任务之间的依赖关系，并标记形成关键路径的任务。基于复杂性、不确定性和工作量使用斐波那契数列（1, 2, 3, 5, 8, 13）分配故事点估算值。 -
规划冲刺或填充看板
对于 Scrum 团队，创建一个包含开始日期、结束日期和冲刺目标的冲刺。从优先级最高的待办事项列表中提取用户故事，直到达到团队的历史平均每个冲刺完成的故事点数（即速度）。对于 Kanban 团队，对每列设置工作在制品（WIP）限制，并确保看板列与团队的工作流程匹配（例如：Backlog → In Progress → Review → Done）。通过其 API 将计划推送到连接的项目跟踪器。 -
跟踪进度并揭示阻碍
按可配置的时间间隔（默认为每日）轮询项目跟踪器。计算燃尽和累积流程指标。检测任务在“进行中”状态持续时间超过其估算值的情况，并将其标记为有风险。识别因上游被阻塞的任务导致下游工作停滞的依赖链。每天向团队的 Slack 或 Teams 频道发布摘要，总结已完成项、进行中项和阻碍项。 -
管理风险与依赖
维护一个风险登记册，每条记录包含描述、可能性（低/中/高）、影响（低/中/高）、负责人以及缓解计划。当识别出新风险——如团队成员休假或第三方 API 被弃用——将其添加到登记册并通知项目负责人。通过链接外部问题来跟踪跨团队依赖，并在状态变更时发出警报。 -
生成状态报告
以 Markdown 格式（或导出为 PDF/Confluence）生成冲刺评审或周度状态报告。每份报告包括：冲刺目标及其是否达成、已完成的故事及总点数、延续至下一阶段的故事、燃尽图表数据、过去五个冲刺的速度趋势、主要风险和下个周期的行动项。根据受众调整详细程度——高管获得一页摘要，团队则获取完整分解。
Usage
向代理提供您的项目详情和需求。该代理会适应您的方法论和工具链。
"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.'"
Examples
示例 1 —— 使用用户故事创建冲刺计划
User input:
"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."
代理输出：
## 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 —— 基于燃尽数据生成项目状态报告
User input:
"Generate the sprint 11 retrospective report for Project Atlas. We use GitHub Issues."
代理输出：
## 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 点的故事应被拆分。大故事隐藏复杂性，使进度跟踪不可靠。
- 在开发开始前编写验收标准。 验收标准消除歧义，作为测试用例的基础，并为团队提供“完成”的共同定义。
- 尊重速度——不要过度承诺。 使用团队最近三个冲刺的平均值作为容量上限。超负荷的冲刺会导致任务延续并打击团队士气。
- 立即显现阻碍项。 在每日摘要中展示被阻塞的任务，并标记可以解除阻塞的人。几天未报告的阻碍是无声的进度风险。
- 维护活的风险登记册。 每次冲刺计划会议时审查风险。关闭不再相关的风险并添加新出现的风险。陈旧的风险登记册会带来虚假的信心。
- 自动化报告生成。 手动组装状态报告容易出错且耗时。使用代理直接从项目跟踪器拉取数据，确保报告始终准确一致。
Edge Cases
- 空的待办事项列表。 如果请求冲刺计划时没有故事存在，请提示用户创建或导入故事后再进行规划。不要创建零项目的冲刺。
- 团队成员容量为零。 如果某位团队成员整个冲刺期间休假，应排除其分配任务，但若适用仍将其列为评审人或利益相关者，并相应调整总容量。
- 循环依赖。 若任务 A 依赖于 B，而 B 又依赖于 A，则标记该循环并要求用户在继续规划前解决它。永远不要静默安排相互阻塞的任务。
- 跟踪器 API 停机。 如果项目跟踪器 API 不可达，本地以 Markdown 格式生成计划，并在 API 恢复后排队同步。告知用户更改已本地保存但尚未推送。
- 冲刺中期范围变更。 若在冲刺中途添加了高优先级项，请警告用户对冲刺目标的影响，并建议降低某个现有项目的优先级以腾出空间。将范围变更记录在冲刺报告中。
- 跨项目依赖。 当某任务依赖于其他团队或项目拥有的工作时，创建外部链接引用并设置 webhook 或轮询检查机制，在依赖解决时通知相关团队。
