开发背景
在软件开发阶段，需求常常难以在初期就确定，而且变化在所难免。面对这种情况，传统的瀑布模型逐渐暴露出诸多问题，于是，迭代开发、敏捷开发等新的开发模式便应运而生。
瀑布式之困
难以适应变化
项目启动阶段需明确需求，瀑布式开发模式要求逐步实施。若项目进行中需求变动，先前投入的大量工作可能需重新进行，耗费成本极高。以某大型管理系统项目为例，需求调整后，前半年的开发成果几乎全盘推翻，需重新开始。
风险相对集中
由于流程固定，初期需求失误往往要到项目后期才显现，这时更正的成本相当高昂。若对某金融交易系统的功能模块进行错误规划，后续的修改不仅费用巨大，而且会对整个系统的上线进度造成影响。
迭代式初探
小巧灵活开发
迭代开发将任务划分为几个短暂且稳定的阶段，比如每3周为一个周期。在这些小周期内，虽然实现的功能有限，但能迅速完成。比如制作一个移动应用，每周完成一个新功能，逐步将它们整合成一个完整的产品。
提前开启开发
即便需求尚未完全明确，我们也可以先行着手开发系统的一些关键功能和业务流程。在客户对某电商系统的具体界面布局尚不清晰的情况下，我们应优先完成核心交易功能的开发。
文档精简之理
过度文档弊端
文档数量庞大，开发者需花费大量时间进行维护，还需确保内容与代码同步更新，否则工作便失去价值。有项目组为应对检查而撰写了大量文档，但这却导致开发工作进度被延误。
文档服务宗旨
文档的用途在于为程序提供支持，应当力求简明扼要。只需记录核心需求和技术关键点，无需过多冗余的文字。
敏捷之优势
拥抱变化特性
敏捷开发以最简洁的方式应对各种变化，让客户自始至终参与到开发过程中。这样，开发团队能够快速收集反馈，迅速调整以适应变化。例如，某个医疗软件项目就借助敏捷开发模式，迅速应对了政策法规的变动。
以人为本理念
我们重视交流与协作，注重人的作用。在项目推进中，我们充分听取每位成员的建议和创意，增强团队向心力与工作效率，进而提升产品品质。
Scrum模式解读
角色分工明确
敏捷教练负责推动项目进展并消除交流中的阻碍；开发团队由5至10人组成，他们专注于软件产品的开发任务；例如，在一家互联网初创企业中，各个成员各自承担职责，确保项目能够顺利开展。
会议驱动工作
会议旨在确定每个迭代的工作任务；在迭代完成后，会议用于展示成果并收集意见。在游戏开发过程中，通过这两类会议来保证项目方向准确并持续改进。
