312 lines
9.2 KiB
Markdown
312 lines
9.2 KiB
Markdown
<execution domain="project-management">
|
|
<process>
|
|
# Milestone管理流程
|
|
|
|
```mermaid
|
|
flowchart TD
|
|
A[产品愿景] --> B[Epic Milestone规划]
|
|
B --> C[Feature Milestone分解]
|
|
C --> D[Sprint目标对齐]
|
|
|
|
D --> E[Milestone执行]
|
|
E --> F[进度监控]
|
|
F --> G[风险评估]
|
|
G --> H{状态判断}
|
|
|
|
H -->|绿色| I[正常推进]
|
|
H -->|黄色| J[密切关注]
|
|
H -->|红色| K[立即调整]
|
|
|
|
I --> L[里程碑达成]
|
|
J --> L
|
|
K --> M[应急计划]
|
|
M --> L
|
|
|
|
L --> N[价值确认]
|
|
N --> O[经验总结]
|
|
```
|
|
|
|
## Milestone分层体系
|
|
|
|
```mermaid
|
|
mindmap
|
|
root((Milestone体系))
|
|
Epic级里程碑
|
|
战略价值节点
|
|
3-6个月周期
|
|
重大业务能力
|
|
市场发布节点
|
|
Feature级里程碑
|
|
功能完整性
|
|
4-8周周期
|
|
模块级交付
|
|
用户价值体现
|
|
Sprint级里程碑
|
|
迭代增量
|
|
1-2周周期
|
|
可演示功能
|
|
团队承诺
|
|
质量里程碑
|
|
代码完成
|
|
集成测试
|
|
用户验收
|
|
性能达标
|
|
```
|
|
</process>
|
|
|
|
<guideline>
|
|
### Milestone设定方法(SMART-M)
|
|
|
|
#### SMART-M原则应用
|
|
|
|
```markdown
|
|
Specific(具体的):
|
|
- 明确定义交付内容和范围边界
|
|
- 清晰的可交付物清单
|
|
- 避免模糊或抽象的描述
|
|
|
|
Measurable(可测量的):
|
|
- 定量的完成标准和质量指标
|
|
- 可验证的验收标准
|
|
- 明确的成功衡量方法
|
|
|
|
Achievable(可达成的):
|
|
- 基于团队能力的现实评估
|
|
- 考虑依赖和风险因素
|
|
- 合理的时间和资源分配
|
|
|
|
Relevant(相关的):
|
|
- 与业务目标和产品战略对齐
|
|
- 支持更高层级的里程碑
|
|
- 对利益相关者有明确价值
|
|
|
|
Time-bound(有时限的):
|
|
- 明确的完成日期
|
|
- 包含适当的时间缓冲
|
|
- 关键路径和依赖时间分析
|
|
|
|
Motivating(激励性的):
|
|
- 团队能看到价值和成就感
|
|
- 适度的挑战性
|
|
- 明确的庆祝和认可方式
|
|
```
|
|
|
|
#### Milestone模板结构
|
|
|
|
```markdown
|
|
## M{编号}: {里程碑名称}
|
|
|
|
**基本信息**:
|
|
- 类型: [业务/技术/交付/质量]
|
|
- 层级: [Epic/Feature/Sprint]
|
|
- 目标日期: [YYYY-MM-DD]
|
|
- 负责团队: [具体团队]
|
|
|
|
**里程碑目标**:
|
|
[一句话描述核心目标和价值]
|
|
|
|
**主要交付物**:
|
|
- [ ] 交付物1: 具体可验证的成果
|
|
- [ ] 交付物2: 具体可验证的成果
|
|
- [ ] 交付物3: 具体可验证的成果
|
|
|
|
**成功标准**:
|
|
- [ ] 定量指标1 (>=目标值)
|
|
- [ ] 质量要求2 (通过标准)
|
|
- [ ] 用户验证3 (满意度>=阈值)
|
|
|
|
**依赖关系**:
|
|
- 前置里程碑: [必须先完成的里程碑]
|
|
- 后续影响: [依赖本里程碑的后续工作]
|
|
- 外部依赖: [其他团队或外部条件]
|
|
|
|
**风险应对**:
|
|
- 主要风险: [描述] → [应对策略]
|
|
- 应急计划: [Plan B方案]
|
|
- 早期预警: [风险信号识别]
|
|
```
|
|
|
|
### Milestone分类管理
|
|
|
|
#### 按性质分类策略
|
|
|
|
| 类型 | 特征 | 周期 | 示例 |
|
|
|------|------|------|------|
|
|
| 业务里程碑 | 市场价值导向 | 季度级 | MVP发布、新功能上线 |
|
|
| 技术里程碑 | 技术能力建设 | 月度级 | 架构完成、性能达标 |
|
|
| 交付里程碑 | 阶段性成果 | 双周级 | Alpha版本、集成完成 |
|
|
| 质量里程碑 | 质量标准达成 | 持续 | 测试通过、审核认证 |
|
|
|
|
#### 按层级管理策略
|
|
|
|
```markdown
|
|
Epic Milestone (3-6个月):
|
|
- 每个Epic设置2-4个关键里程碑
|
|
- 重点关注业务价值和市场影响
|
|
- 跨团队协调和依赖管理
|
|
|
|
Feature Milestone (4-8周):
|
|
- 标记功能模块的完整性节点
|
|
- 用户可感知的价值交付
|
|
- 技术和业务目标平衡
|
|
|
|
Sprint Milestone (1-2周):
|
|
- 每个Sprint的具体承诺
|
|
- 可演示的功能增量
|
|
- 团队内部的节奏控制
|
|
```
|
|
|
|
### Milestone跟踪监控
|
|
|
|
#### 状态管理体系
|
|
|
|
```mermaid
|
|
stateDiagram-v2
|
|
[*] --> 计划中
|
|
计划中 --> 进行中: 开始执行
|
|
进行中 --> 风险中: 发现风险
|
|
进行中 --> 已完成: 达成目标
|
|
风险中 --> 进行中: 风险解决
|
|
风险中 --> 延迟: 确认延期
|
|
风险中 --> 已完成: 成功挽回
|
|
延迟 --> 已完成: 调整后完成
|
|
已完成 --> [*]
|
|
```
|
|
|
|
#### 监控指标体系
|
|
|
|
```markdown
|
|
进度指标:
|
|
- 里程碑完成率 = 已完成数 / 计划总数
|
|
- 按时完成率 = 按时完成数 / 已完成数
|
|
- 平均延迟天数 = 延迟总天数 / 延迟里程碑数
|
|
|
|
质量指标:
|
|
- 交付物完整度 = 实际交付 / 计划交付
|
|
- 一次通过率 = 一次验收通过 / 总里程碑数
|
|
- 返工率 = 需要返工数 / 已完成数
|
|
|
|
预测指标:
|
|
- 预计完成时间 (基于当前进度趋势)
|
|
- 资源消耗率 = 实际消耗 / 计划消耗
|
|
- 风险里程碑占比 = 风险状态数 / 总进行中数
|
|
```
|
|
|
|
#### 预警响应机制
|
|
|
|
| 预警级别 | 触发条件 | 响应行动 | 升级机制 |
|
|
|----------|----------|----------|----------|
|
|
| 🟢 绿色 | 进度正常，无重大风险 | 正常监控 | - |
|
|
| 🟡 黄色 | 轻微延期或存在风险 | 加强关注，调整资源 | 1周内升级 |
|
|
| 🔴 红色 | 严重延期或阻塞 | 立即干预，启动应急计划 | 立即升级 |
|
|
|
|
### Milestone与敏捷集成
|
|
|
|
#### 与Sprint的关系
|
|
|
|
```markdown
|
|
Sprint-Milestone映射策略:
|
|
|
|
1. 里程碑驱动Sprint Planning
|
|
- Sprint Goal与里程碑目标对齐
|
|
- 优先选择推进里程碑的Story
|
|
- 量化Sprint对里程碑的贡献度
|
|
|
|
2. Sprint Review中的里程碑检查
|
|
- 评估里程碑进展情况
|
|
- 识别里程碑风险和调整需求
|
|
- 基于里程碑调整Product Backlog
|
|
|
|
3. 里程碑贡献度跟踪
|
|
Sprint 1-2 → M1.1(试卷结构管理) 贡献40%
|
|
Sprint 3-4 → M1.1(试卷结构管理) 贡献60%
|
|
Sprint 5-6 → M1.2(内容管理) 贡献35%
|
|
```
|
|
|
|
#### 跨团队里程碑协调
|
|
|
|
```markdown
|
|
依赖里程碑管理:
|
|
|
|
1. 依赖识别和规划
|
|
- 建立跨团队里程碑依赖图
|
|
- 识别关键路径和瓶颈
|
|
- 设定依赖交付的缓冲时间
|
|
|
|
2. 协调同步机制
|
|
- 周度依赖状态同步
|
|
- 月度跨团队里程碑对齐
|
|
- 风险升级和决策流程
|
|
|
|
3. 共享里程碑管理
|
|
- 明确各团队责任分工
|
|
- 统一验收标准和流程
|
|
- 建立联合庆祝机制
|
|
```
|
|
</guideline>
|
|
|
|
<rule>
|
|
1. **里程碑设定强制要求**
|
|
- 每个Epic必须有2-4个关键里程碑
|
|
- 里程碑必须符合SMART-M原则
|
|
- 所有里程碑必须有明确责任人
|
|
- 里程碑间隔不超过3个月
|
|
|
|
2. **进度跟踪强制要求**
|
|
- 每周更新里程碑状态
|
|
- 风险里程碑必须有应对计划
|
|
- 延期里程碑必须重新规划
|
|
- 里程碑变更需要正式审批
|
|
|
|
3. **质量门禁强制要求**
|
|
- 里程碑完成必须通过质量验收
|
|
- 技术里程碑必须有量化指标
|
|
- 业务里程碑必须有用户验证
|
|
- 不达标里程碑不允许发布
|
|
|
|
4. **协调同步强制要求**
|
|
- 跨团队里程碑必须建立同步机制
|
|
- 依赖里程碑必须提前协调
|
|
- 共享里程碑必须明确分工
|
|
- 里程碑冲突必须升级决策
|
|
</rule>
|
|
|
|
<constraint>
|
|
1. **时间约束**
|
|
- 市场窗口时间限制
|
|
- 资源可用时间限制
|
|
- 依赖交付时间约束
|
|
- 法规合规时间要求
|
|
|
|
2. **资源约束**
|
|
- 团队人力资源限制
|
|
- 技术平台资源约束
|
|
- 预算和成本限制
|
|
- 外部供应商能力约束
|
|
|
|
3. **技术约束**
|
|
- 现有技术架构限制
|
|
- 技术债务影响
|
|
- 第三方系统依赖
|
|
- 性能和规模约束
|
|
|
|
4. **业务约束**
|
|
- 市场竞争压力
|
|
- 客户期望和承诺
|
|
- 合规和监管要求
|
|
- 商业模式限制
|
|
</constraint>
|
|
|
|
<criteria>
|
|
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|
|
|---------|---------|---------|-----------|
|
|
| 里程碑完成率 | >95%按时完成 | >80%按时完成 | <80%按时完成 |
|
|
| 价值交付质量 | 超出预期的价值 | 达到预期价值 | 价值交付不足 |
|
|
| 风险管控 | 风险前置有效预防 | 风险及时识别应对 | 风险管控不足 |
|
|
| 团队协调 | 跨团队协作顺畅 | 基本协调有效 | 协调困难频繁冲突 |
|
|
| 透明度 | 进度状态完全透明 | 基本信息透明 | 信息不透明 |
|
|
| 利益相关者满意度 | 高度满意获得认可 | 基本满意 | 不满意有抱怨 |
|
|
| 持续改进 | 里程碑执行不断优化 | 有基本改进 | 缺乏改进机制 |
|
|
| 庆祝文化 | 里程碑成就获得庆祝 | 有基本认可 | 缺乏成就感 |
|
|
</criteria>
|
|
</execution> |