Open Discussion on Project Planning

• 语言: 英语
• 格式: .docx
• 来源: github.com/Agile4Defense

摘要

文档讨论了在敏捷环境中进行项目规划的关键要点，强调规划应关注近期目标，避免过度规划未来不可预见的情况。文档指出，敏捷方法不强制要求在项目初期确定完整的范围、需求和设计，但需要保持长期视角，关注未来六个月内发布的功能。通过使用史诗和用户故事来定义系统功能，确保相关方对所需功能有清晰理解。文档还提到，规划不应是一次性活动，而应持续进行，并通过更频繁的设计审查来展示功能和项目进展。系统工程师需与开发人员、测试人员、用户和其他相关方协作，确保架构的持续完善。此外，文档还探讨了在敏捷环境中成本估计的挑战，强调根据预算进行项目结构的重要性。

AI总结

### 文档总结

#### 敏捷环境下的规划要点
1. **短期聚焦**：规划应重点关注近期目标，避免为未发生的情况制定详细计划。
2. **消除浪费**：简化流程，快速交付功能，避免过度规划。
3. **动态调整**：敏捷方法不强制在项目初期明确全部范围、需求和设计，但需保持长期视角，关注未来6个月的发布。

#### 规划的“做”与“不做”
- **DO**：
- 制定高层次计划，关注团队未来几个版本的开发能力。
- 使用史诗（Epic）和用户故事（User Stories）定义系统功能，确保各利益相关方对需求达成一致理解。
- 进行持续规划，避免一次性规划。
- **DON'T**：
- 不要制定过于详细且难以控制的长期计划。
- 不要将规划视为一次性前置活动。

#### 文档替代与流程优化
- 用**需求定义包（RDPs）**替代全面的需求文档，用于捕捉部分需求。
- 用**能力下降文档（CDs）**处理小型项目，如应用程序。
- 用**增量设计审查**替代传统的初步设计审查（PDR）和关键设计审查（CDR），聚焦于每个发布的内容及其与企业架构的对齐。

#### 系统工程角色
- 系统工程师需与开发、测试、用户和其他利益相关方紧密合作，避免孤立的 ivory tower（象牙塔）式工作。
- 虽然敏捷方法更灵活，但不等于降低严格性。通过更频繁的非正式审查，使决策者和利益相关方更熟悉敏捷环境，促进协作。

#### 成本估算
- **挑战**：国防部通常要求明确需求后才分配预算，这在敏捷环境中可能难以实现。
- **优势**：一旦预算确定，敏捷方法允许“按预算构建”，即根据预算决定交付的版本数量和总需求。
- **细化**：在执行阶段，通过细化的发布和冲刺级别估算，逐步提高成本估算的准确性。

#### 图片说明
- 对比了传统瀑布模型与敏捷方法的成本估算方式：
- **传统瀑布**：需求固定，成本估算基于明确的需求。
- **敏捷**：需求可变，成本估算逐步细化，基于实际开发进展。

### 总结
在敏捷环境中，规划应注重短期目标和持续调整，避免过度规划和浪费。通过使用史诗和用户故事、持续规划、优化审查流程，以及动态调整成本估算，团队可以在保持灵活性的同时，确保项目高效推进。