评估
从当前技术与业务状况开始
大多数值得做的软件工作都始于约束、继承系统、不清晰接口、截止期限和运维压力。第一轮要做的是理解现状、哪里脆弱、什么必须保留，以及什么在阻碍前进。
- 先澄清真正的交付问题，而不只是被提出的功能请求
- 梳理当前代码库、系统边界、依赖关系和发布路径
- 在提出建设计划之前先识别业务关键风险
方法论
面向继承系统、API 工作和真实交付压力的软件开发流程。
多数软件项目并不是从一张白纸开始。它们往往从继承代码、不清晰的 API、交付压力、后端约束，或一个已经超出当前设置的产品开始。这套方法就是从那里出发，按评估、稳定、实现和交付逐步推进。
最适合
- 已经带着技术包袱的软件项目
- 必须契合运维现实的 API 与集成工作
- 仍然需要诚实范围定义和交付结构的新建设
稳定
先降低脆弱性，再谈提速
继承系统往往需要先去掉风险，才能安全地加快新功能工作。这可能意味着清理脆弱区域、澄清接口、改进部署流程，并减少围绕在线系统的运维阻力。
- 分级处理继承代码，移除明显的发布阻塞点
- 修复那些持续制造阻力的接口与集成点
- 把系统整理到一个新工作不会继续制造不稳定的状态
构建
实施真正适合这个项目的软件工作
一旦系统被理解清楚、风险更明朗，实现路径就可以更诚实地被选择。这可能意味着新产品建设、后端服务、API 实现、集成工作、内部工具，或与系统其他部分相连的移动端交付。
- 围绕实际用例构建，而不是围绕预制套餐定义构建
- 让架构与实现始终和支持需求保持一致
- 使用直接且可验证的里程碑
交付
在商业和支持预期都清楚定义的前提下交付
工作并不会因为代码存在就算完成。交付还包括清楚说明建了什么、如何移交或支持、许可与所有权如何处理，以及后续工作或维护应当是什么样。
- 围绕具体合作本身定义项目定价和许可
- 记录支持预期、延续方式和移交边界
- 在运维清晰的前提下交付