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

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

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

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

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

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

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

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

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

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

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