敏捷开发过程
敏捷过程模型
以人为核心、迭代、循序渐进的增量开发方法
小步快跑，及时反馈，以快速的增量和迭代方式进行软件开发
核心—迭代开发
- 每一次迭代都建立在稳定质量的基础上，并作为下一轮迭代的基线，整个系统功能随着迭代稳定增长不断完善
- 每次迭代邀请用户代表（外部或内部）验收，提供需求是否满足的反馈
- 迭代推荐采用固定的周期（一般2-4周），迭代内工作不能完成，应当缩减交付范围而不是延长周期
快速反馈
- 将项目分成若干个迭代周期，每个迭代周期结束都能立即反馈
- 通过不断的沟通，还能减少理解上的偏差，配合反馈，减少误解，从而降低修正错误的代价
- 每个迭代周期的结束都能接受验证，从而能快速的适应变化，及时的适应新的需求，保证产品的正确性
- 适应变化，利用多层次反馈不断调整以逼近目标
快速交付
- 在需求响应周期相同的情况下，批量（一次开发的需求量）越小，资源利用率更高
- 在资源利用率相同的情况下，批量越小，交付周期更短
- 减少批量不仅能缩短交付周期，而且还能提高质量，促进创新、降低管理成本、效率更高
极限编程XP
- XP是一种近螺旋式的开发方法，它将复杂的开发过 程分解为一个个相对比较简单的小周期；通过积极地交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚地发现进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开 发过程
- 极限编程是一个轻量级的、灵巧的软件开发方法
- 极限编程和传统方法学的本质不同在于它更强调可 适应性而不是可预测性
- 降低因需求变更而带来的成本
核心价值
- 沟通、简单、反馈、勇气、尊重
核心实践方法
计划阶段
- 倾听用户陈述，形成用户故事，描述其输出、特性、功能等
- 按照价值或风险排序，为用户故事指定优先级
- XP团队评估用户故事，为其指定成本
- 将若干用户故事指定为下一次发布的增量，确定发布日期
- 规划整体进度
- 用户可以在开发过程中扩展形式，去除原故事，改变优先级，拆分等
设计阶段
- 遵循KIS原则（Keep It Simple）
- 设计模型：面向对象方法，CRC卡片
- 遇到困难，创建原型
对设计方案不断重构
- 遵循用户故事的外特性要求
- 改善内部结构
- 消除bug
- 提高效率
- 提高易读性
编码与测试阶段
Coding
- 根据用户故事设计单元测试用例
- 结对编程，实时讨论，实时评审
- 测试驱动的开发，先写测试用例，再写代码
Testing
- 自动化单元测试
- 持续集成
- 持续进行回归测试
- 验收测试
Scrum
- 整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称 为一个Sprint（冲刺），每个Sprint的建议长度是2到4周
- 使用产品Backlog（任务列表或清单）来管理需求，是一个按照 商业价值排序的需求列表，列表条目的体现形式通常为用户故事
- 总是先开发对客户具有较高价值的需求
- 在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求 进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表(backlog)
- 在每个迭代结束时，Scrum团队提交潜在可交付的产品增量
四个重要阶段
- 找出完成产品需要做的事情
- 决定当前冲刺需要解决的事情
- 冲刺
- 每日站会
三个角色
- 产品负责人Product Owner
- 项目管理者Scrum Master
- Scrum团队
三个工作
产品列表Product Backlog
- 根据用户价值进行优先级排序的高层需求
冲刺列表Sprint Backlog
- 要在冲刺中完成的任务清单
产品增量Increment
- 最终交付给客户的内容
活动
sprint
- 冲刺，代表一个2-4周的迭代
产品待办列表梳理会
sprint计划会议
- 决定sprint中完成那些工作，如何完成
每日站会
sprint评审会
- 在冲刺结束前给产品负责人演示并接受评价的会议
sprint回顾会
- 冲刺结束后召开的关于自我持续改进的会议
