risk-assessment

name	risk-assessment
phase	implement
description	项目风险预测助手：基于 Yunxiao MCP Server 预测性工具进行交付风险分析、容量规划和阻塞识别；触发: 风险, 预测, 交付, 容量, 阻塞, 迭代规划.

Risk-Assessment: 项目风险预测助手

适用范围

在需要预测项目交付风险、分析团队容量、识别关键路径阻塞时触发本技能。基于 Yunxiao MCP Server 的预测性风险评估工具，完成三件事：

1. 预测：分析历史速率、当前负载，预测版本能否按时交付
2. 诊断：识别阻塞链、长期挂起任务、过载成员
3. 建议：输出可执行的调整建议（砍范围、加人、解阻塞）

典型触发查询：

• "这个版本能按时发吗"
• "项目有什么风险"
• "谁在阻塞关键路径"
• "团队容量够吗"
• "预测下迭代能完成多少"

不适用场景：

• 需要修改任务状态、分配任务（当前 MCP Server 为只读）
• 非 Yunxiao 项目管理系统的风险分析
• 不涉及具体项目/版本的泛化讨论

---

核心原则

1. 只读分析，不越界操作

当前 MCP Server 是 read-only GA 边界。MUST NOT 尝试调用写操作工具。所有输出必须是：

• 风险预测报告
• 容量评估建议
• 阻塞解除方案
• 待人工确认的 action items

2. 数据驱动，不自作主张

MUST 基于实际拉取的数据做分析，不能凭记忆或假设。每次评估必须：

1. 确认 MCP 会话可用（mcpc connect @yunxiao）
2. 获取项目上下文（get_project_overview）
3. 拉取预测性数据（get_sprint_velocity、get_blocker_analysis 等）
4. 基于真实数据生成预测

3. 预测框架

风险评估采用三层模型：

层级	判断维度	参考标准
红色 / 高风险	历史完成率 < 50%、关键路径阻塞、成员过载	必须立即干预
黄色 / 中风险	历史完成率 50-80%、部分阻塞、容量紧张	需要关注，准备预案
绿色 / 低风险	历史完成率 > 80%、无阻塞、容量充裕	正常推进

4. 动态阈值

所有阈值基于实际历史数据，不写死：

• 团队速率 = 历史 sprint 平均完成数
• 容量上限 = 成员历史最大负载 × 1.2
• 阻塞容忍 = 历史平均解决时间 × 2

---

执行工作流

阶段 1：连接与数据采集

进入条件：用户请求风险评估或交付预测。

1.1 确认 MCP 会话可用

通过 mcpc 连接 @yunxiao session：

mcpc connect @yunxiao

1.2 获取项目与版本上下文

• 调用 get_project_overview 获取项目基本信息、迭代、版本
• 确认目标 projectId 和当前活跃版本/迭代

1.3 拉取预测性数据

必须拉取（按优先级）：

工具	用途	优先级
get_sprint_velocity	历史完成率趋势	P0
get_blocker_analysis	依赖阻塞全景	P0
get_member_workload_trend	成员负载分布	P1
get_project_risk_dashboard	逾期/高优先级/停滞任务	P1

按需拉取：

工具	用途
get_workitem_status_timeline	具体任务为何阻塞
get_project_member_task_status	成员详细任务状态

---

阶段 2：分析与预测

进入条件：已获得预测性数据。

2.1 交付预测

基于 get_sprint_velocity 数据：

历史平均完成率 = 最近 N 个 sprint 完成数 / 承诺数
预测完成时间 = 剩余任务数 / 历史平均速率
风险判断 = 预测完成时间 > 版本截止日期 ? 红色 : 绿色

趋势判断：

情形	信号	建议
完成率持续下降	团队速率在衰减	检查是否有外部干扰或技术债累积
完成率波动大	估算不准或需求变更频繁	建议缩小迭代范围，提高估算精度
完成率稳定 > 80%	团队节奏健康	可适当增加挑战

2.2 阻塞分析

基于 get_blocker_analysis 数据：

• 被阻塞任务数：有多少任务因依赖而无法推进
• 阻塞他人任务数：哪些任务卡住了整个链路
• 关键阻塞者：阻塞最多下游任务的前 N 个任务

阻塞风险判断：

阻塞类型	风险等级	建议
关键路径阻塞	红色	立即升级，协调资源解决
非关键路径阻塞	黄色	跟踪进度，准备绕过方案
无阻塞	绿色	正常推进

2.3 容量分析

基于 get_member_workload_trend 数据：

• 人均任务数：总任务 / 成员数
• 过载成员：任务数 > 人均 1.5 倍的成员
• 逾期分布：哪些成员逾期任务最多

容量风险判断：

情形	风险等级	建议
多成员过载	红色	重新分配任务或延期
个别成员过载	黄色	协助拆分任务或转移部分工作
负载均衡	绿色	维持当前分配

---

阶段 3：输出与建议

进入条件：分析完成。

3.1 输出格式

必须包含：

• 概览：项目/版本、当前迭代、剩余任务数
• 交付预测：历史速率、预测完成时间、风险颜色
• 阻塞分析：被阻塞任务数、关键阻塞者、建议动作
• 容量评估：人均负载、过载成员、建议调整
• Action Items：具体、可执行、带负责人（如已知）

可选增强：

• 具体阻塞任务的 get_workitem_status_timeline 分析
• 周报格式转换

3.2 交互式追问

报告输出后，SHOULD 提供下一步选项：

• "需要我深入分析某个具体阻塞任务吗？"
• "要生成这段时期的 Markdown 周报吗？"
• "需要我对比不同迭代的速率趋势吗？"
• "需要我分析特定成员的负载详情吗？"

---

运行参考

• references/yunxiao-risk-tools-cheatsheet.md：预测性工具快速参考
• references/risk-assessment-framework.md：风险评估框架与计算公式

---

反模式（避免）

反模式	正确做法
假设 MCP 会话一定可用	先执行 mcpc connect @yunxiao，失败时引导检查配置
凭记忆或假设做预测	每次必须重新拉取最新数据
推荐 AI"自动完成"某个任务	只读边界内，只输出建议和报告
忽略历史数据，只关注当前状态	必须结合 get_sprint_velocity 做趋势判断
把具体阈值（如 7 天/14 天）当硬规则	根据历史数据动态计算阈值
只分析单个维度（只看阻塞不看容量）	必须综合交付预测 + 阻塞 + 容量三个维度

---

质量自检清单

• @yunxiao MCP 会话已确认可连接
• 已获取项目真实数据，未假设项目状态
• 已拉取 get_sprint_velocity 历史速率数据
• 已拉取 get_blocker_analysis 阻塞数据
• 已拉取 get_member_workload_trend 容量数据
• 交付预测基于历史速率，非主观判断
• 阻塞分析包含关键路径识别
• 容量评估基于实际负载分布
• 风险等级使用红/黄/绿三层模型
• Action Items 具体、可执行
• 未尝试任何写操作（状态更新、评论、分配）