敏捷方法与过程
一. 敏捷过程模型
变化无处不在，难以预测变化何时发生，要在每一项开发活动中贯穿变化的意识
《敏捷软件开发宣言》
总结：小步快跑，及时反馈
本质：以快速的增量和迭代的方式进行软件开发
- 不强调文档而强调可运行软件片段
- 开发者与客户频繁沟通
- 快速开发，快速反馈，快速修改，增量交付
- 持续不断的短周期迭代
- 不看重形式和工具，看重人和内容，保持简洁
敏捷开发前期开发成本比传统开发过程高，而后期成本要比传统开发过程低
敏捷过程中最重要的因素：人
（这里的人应该指的是开发者和客户）
目前广泛使用敏捷开发方法论
略，包括极限编程和Scrum，XP是Scrum的基础
二. 极限编程（XP）
- 极限：把事情做到极致
- 了解客户需求
客户时时刻刻都在身边，时时了解需求 - 测试/单元测试提高质量
TDD（先写测试，测试驱动开发） - 代码复审找到错误
一开始就处于“复审状态”，即结对编程 - 变化块
频繁增量开发，重构和频繁发布
- 了解客户需求
1. XP Planning 计划阶段
用户故事、权值（价值和风险）、验收测试准则、迭代计划
- 用户故事：描述输出、特性、功能等
- 客户指定用户故事优先级：按照价值或风险评估
- XP团队指定用户故事成本（开发周数）：超过三周则拆分
- 指定下一次发布的增量的若干个用户故事
- 规划整体进度
- 开发过程增删改拆用户故事
2. XP Design 设计阶段
- KIS原则（Keep It Simple）
- CRC卡片（Class Responsibility Collaborator）
- Spike Solutions 原型（刺探性的解决方案，问题拿不准做实验尝试）
- 设计方案不断重构
3. XP Coding and Testing 编码与测试阶段
3.1 XP Coding
结对编程：两个人一起编程、实时讨论评审
TDD（测试驱动的开发）：先写测试用例（单元测试用例），再写代码；
3.2 XP Testing
自动化单元测试、集成测试、持续进行回归测试、验收测试（见10章）
验收与用户故事是否相符
4. Pair Programming 结对编程
驾驶员，领航员
双方只有水平上的差距，没有级别上的差异（平等的决策权）
质量取决于一对程序员中各方面水平较高的那一位
三. Scrum
Scrum的六项活动
- Product Owner：确定产品功能，维护Product Backlog、deadline、priority、ROI（投资回报率），验收结果
- Scrum Master（Strum Team Leader）：保证开发过程按计划进行；组织会议：每日站会、Sprint计划会议、完成工作后的Sprint评审会议和Sprint回顾会议；通过外在/内在协调，确保团队资源完全可被利用并且全部是高产出的
- Team（Scrum团队）：在每个Sprint中将Product Backlog中的条目转化成为潜在可交付的功能增量（可以认为是Sprint Backlog）；规模在4-7人；具备交付产品增量所需要的各种技能
每日站会
- 团队成员站着开会——短时间（15分钟。每人不超过三分钟）内高效讨论问题，保持注意力集中
- 每个人向同伴报告进度：我昨天做了什么、我今天要做什么、我碰到了哪些问题
- 简明图表展示项目进度
Sprint Burndown Chart 燃尽图
Task Board 任务墙（parking 表示任务堆积）
四. 与传统开发过程模型对比
五. 敏捷案例分析
客户对功能需求还不明确
需要快速推出抢占市场
适合敏捷过程的项目
敏捷方法希望快速交付可用的软件，实现软件的快速交付是通过迭代来完成
业务分析师？？？