敏捷开发过程

敏捷过程模型

以人为核心、迭代、循序渐进的增量开发方法
小步快跑,及时反馈,以快速的增量和迭代方式进行软件开发

核心—迭代开发

  • 每一次迭代都建立在稳定质量的基础上,并作为下一轮迭代的基线,整个系统功能随着迭代稳定增长不断完善
  • 每次迭代邀请用户代表(外部或内部)验收,提供需求是否满足的反馈
  • 迭代推荐采用固定的周期(一般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回顾会

    • 冲刺结束后召开的关于自我持续改进的会议