今天部门大佬让我去设计并且开发一个为游戏中的AI精灵小助手的数据提供接口，强调了是敏捷开发原则。由于不太明确敏捷开发原则是什么，就去设计了一个AI精灵小助手中问题的后台管理页面，以及DB中表的设计。然后设计了一个很完善但是开发时间略长的实施方案。然后汇报工作的时候就被嫌弃太麻烦，可以简单实现，下个版本在完善。

敏捷开发原型

简单设计，快速实现，根据客户需求迭代，需要高效沟通

1. 需求评审，用story的形式去描述需求
2. 根据story描述的去划分需求
3. 概要设计
4. 详细设计
5. 开发
6. 自测
7. 联调
8. 灰度上线(灰度发布也称金丝雀发布，让一部分人去使用新版本，剩余部分的人去使用老版本，逐渐扩大范围直至全面上线)
9. 全面上线

优点

注重沟通、客户写作、需求变化快、快速适应、建造模型

缺点

无法适用于大型项目，沟通需求大，造成成本大

瀑布开发原型

将功能实现和需求设计分开。将软件生命周期划分为：

1. 制定计划
2. 需求分析
3. 软件设计
4. 程序实现
5. 测试
6. 运维

优点

为项目提供了按阶段划分的检查点、只需要关心当前和下游功能实现、一般多嵌套于其他开发模式上

缺点

①各阶段间的联系较少，极少有互相反馈②只能在项目后期才能看到成品③根据设计文档的时间点跟踪项目的各个阶段④对需求的变更的适应力差

迭代开发原型

从某种角度上，迭代开发是一次完整经过所有流程，类似于小瀑布模式的开发流程，每次迭代都有一个成品，它也是最终成品的一部分（子集）

优点

①降低了一个功能增量的风险 ②需求变更可以在迭代的版本中实现③加快开发的进度④对新需求或者需求的变更的适应能力强

缺点

快速成型的软件可能会导致产品质量低

快速原型模式

快速建造原型，根据原型去细化需求，确认好需求的时候就可以抛弃原型，进行重新架构和开发。