敏捷开发过程
敏捷过程模型
以人为核心、迭代、循序渐进的增量开发方法
小步快跑,及时反馈,以快速的增量和迭代方式进行软件开发
核心—迭代开发
- 每一次迭代都建立在稳定质量的基础上,并作为下一轮迭代的基线,整个系统功能随着迭代稳定增长不断完善
- 每次迭代邀请用户代表(外部或内部)验收,提供需求是否满足的反馈
- 迭代推荐采用固定的周期(一般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回顾会
- 冲刺结束后召开的关于自我持续改进的会议