3 敏捷软件开发
敏捷方法是增量式开发方法，每个增量一般较小，通常两到三周会提供新版本给用户使用
3.1 敏捷方法
敏捷方法的基本原则
| 原则 | 描述 |
|---|---|
| 客户参与 | 客户在开发过程中始终紧密参与。作用是提供新系统的需求、对需求进行排序，并评估系统的迭代 |
| 增量式交付 | 软件以增量方式开发，客户指定在每个增量的内容 |
| 人非过程 | 开发团队的技术应得到承认和发扬，团队成员应保持自己的工作风格 |
| 接受变更 | 预料系统需求的变更，设计系统使其适应变更 |
| 保持简单性 | 致力于所开发软件和开发过程的简单性 |
3.2 计划驱动开发和敏捷开发
计划驱动开发和敏捷开发的对比
| 区别 | 计划驱动开发 | 敏捷开发 |
|---|---|---|
| 过程 | 需求工程->需求描述->设计和实现，阶段之间用正式文件沟通 | 需求工程->设计和实现 |
| 开始实现之前，详细和描述和设计很重要 | 是 | 否 |
| 软件交付并快速取得反馈可行 | 否 | 是 |
| 开发系统的规模 | 大的开发团队，大型系统 | 小的、处于同一地点的开发团队 |
| 开发系统的类型 | 实施之前需要大量分析和设计 | —— |
| 预期的系统寿命 | 长寿命，需要更多设计文档 | 文档更新不及时，且长期维护不需要 |
| 支持系统开发的技术 | 使用 IDE，且没有好的可视化编程和开发工具 | 依赖好的工具以跟踪设计进化 |
| 组织开发团队 | 分散或外包，需要文档进行沟通 | —— |
| 设计和编码人员的能力 | 水平较低，需要更好的设计人员 | 需要更高的技术水平 |
3.3 极限编程
| 实践或原则 | 描述 |
|---|---|
| 增量式规划 | 需求记录在脚本/场景/情景卡片，包含在版本中的故事情节可以决定可用的时间和相对优先级。开发者将脚本分解成任务 |
| 小版本发布 | 先开发能提供业务价值的一个最小有用集合。增量式地王第一个版本添加新功能 |
| 简单设计 | 只进行有限的能满足当前需求的设计，不追求太多 |
| 测试优先的开发 | 实现功能钱，采用一个自动单元测试框架编写对新功能的测试 |
| 重构 | 期待所有开发人员连续地重构代码，只要有能改善的代码就做，保持代码的简单性和可维护性 |
| 结对编程 | 开发人员成对工作，检查彼此的工作并提供支持 |
| 集体所有 | 配对的开发人员参与系统的所有方面的工作，共享代码。任何人可以修改任何代码 |
| 连续集成 | 任务一完成，将它继承到大系统。每次集成后，必须通过系统所有的单元测试 |
| 可持续的节奏 | 大量超时不能接受，因为这通常会降低代码质量和平均生产率 |
| 在场客户 | 系统最终用户的代表(客户)应全程配合 XP 团队。客户有责任将系统需求带给开发团队 |
3.4 敏捷项目管理
Scrum 方法是一个通用的敏捷方法，主要是注重迭代开发的管理。
| 序号 | 阶段 | 描述 |
|---|---|---|
| 1 | 规划纲要 | 建立大致的项目目标，设计软件体系结构 |
| 2 | 冲刺循环 | 每个循环开发一个系统增量 |
| 3 | 项目结束 | 总结项目，完善需要的文档(如系统帮助和用户手册)，总结经验 |
冲刺循环的流程：评估，特征的选择和开发，软件实现。特点包括
- 冲刺长度固定：一般是 2~4 周对应一个版本
- 规划起点：积压的任务，即项目中要完成的工作清单 2.1 评估阶段审查这些积压的任务，进行优先级排序并进行风险的指派 2.2 在此过程中，用户在每个循环开始时提出新的需求或任务的建议
- 选择阶段：项目团队的人员都参加，和用户角色相同
- 软件开发：每天，团队成员参加短时会议，回顾开发过程，科能会重新安排工作
- 冲刺循环结束：对已做工作复查并交付用户。开始下一个循环
3.5 可扩展的敏捷方法
将敏捷的一些重要内涵应用域大型工程：弹性计划、频繁发布、持续集成、测试驱动开发、良好的团队沟通