敏捷软件开发模型Scrum通俗讲义

前言

     之前或多或少都听过说有关敏捷开发模型的诸多东西，包括什么有它相关的书籍或培训。由于公司现在所采用的是Scrum开发流程--敏捷开发的一种，所以，特此作番学习与研究，我也力求文字通俗易懂，已不致让大家对它产生如参加会议一般的厌倦情绪。

一、什么是敏捷开发

    敏捷软件开发又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。

    在敏捷方法其独特之处以外，他和其他的方法也有很多共同之处，比如迭代开发，关注互动沟通，减少中介过程的无谓资源消耗。通常可以在以下方面衡量敏捷方法的适用性：从产品角度看，敏捷方法适用于需求萌动并且快速改变的情况，如系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合；从组织结构的角度看，组织结构的文化、人员、沟通则决定了敏捷方法是否适用。跟这些相关联的关键成功因素有：

• 组织文化必须支持谈判
• 人员彼此信任
• 人少但是精干
• 开发人员所作决定得到认可
• 环境设施满足成员间快速沟通之需要

    最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，20、40人或者更少。大规模的敏捷软件开发尚处于积极研究的领域。

    另外的问题是项目初期的大量假定或者快速收集需求可能导致项目走入误区，特别是客户对其自身需要毫无概念的情况下。与之类似，人之天性很容易造成某个人成为主导并将项目目标和设计引入错误方向的境况。开发者经常能把不恰当的方案授予客户，并且直到最后发现问题前都能获得客户认同。虽然理论上快速交互的过程可以限制这些错误的发生，但前提是有效的及时反馈，否则错误会迅速膨胀。

目前列入敏捷方法的有：

• 软件开发节奏，Software Development Rhythms
• 敏捷数据库技术，AD/Agile Database Techniques
• 敏捷建模，AM/Agile Modeling
• 自适应软件开发，ASD/Adaptive Software Development
• 水晶方法，Crystal
• 特性驱动开发，FDD/Feature Driven Development
• 动态系统开发方法，DSDM/Dynamic Systems Development Method
• 精益软件开发，Lean Software Development
• AUP（Agile Unified Process）
• Scrum（本文的主角）
• XBreed
• 极限编程，XP Extreme Programming
• 探索性测试

然后，请允许我引用邹欣老师的一篇博客有关敏捷的两张图片，如下：

问: 爱脚儿 - 敏捷到底是什么东东? 好像有很多名词, 缩写和传说…

答: 敏捷 (Agile) 是一股思潮, 它包括了好几种软件开发的方法论 (methodology); 这些方法论又是建立在许多业界证明行之有效的最佳实践方法 (best practices) 上面的。 如下图所示:

    ok，开头说了，由于目前公司采用的是Scrum开发流程，所以对Scrum作番学习和了解也是我的工作任务。所以，接下来，咱们来分析上述敏捷方法中的Scrum开发方法。

二、Scrum

    2.1、什么是Scrum       

    Scrum是一个轻量级的软件开发方法，它是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。通俗的讲，咱们现在制定了整个产品的开发周期，而这个开发周期是由各个小的迭代周期组成的，我们把每个小的迭代周期称为一个个Sprint，如Sprint1，Sprint2，Sprint3（我现在手头接触到的手头上的项目就是分为Sprint1~Sprint5），然后给每个Sprint2到4周的时间解决，分而治之，各个击破。

    在Scrum中，使用产品（Product）Backlog来管理产品或项目的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。在每个Sprint中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog 。  在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。

    如上图所示，Scrum 开发流程通常以 30 天(或者更短的一段时间)为一个阶段，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部分，开发团队必须尽力于 30 天后交付成果，团队每天用 15 分钟开会（daily meeting）检查每个成员的进度与计划，了解所遭遇的困难并设法排除。

  2.2、Scrum较传统开发模型的优点

    Scrum模型的一个显著特点就是响应变化，它能够尽快地响应变化。下面的图片使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就迅速降低。

    
    下图是Scrum模型和传统模型的对比（基本上每篇介绍Scrum都会引用的图）：

    
   2.3、 Scrum模型

    一) 有关Scrum的几个名词

    backlog: 可以预知的所有任务， 包括功能性的和非功能性的所有任务。

    sprint:一次跌代开发的时间周期，一般最多以30天为一个周期.在这段时间内，开发团队需要完成一个制定的backlog,并且最终成果是一个增量的，可以交付的产品。

    sprint backlog:一个sprint周期内所需要完成的任务。

    scrumMaster: 负责监督整个Scrum进程，修订计划的一个团队成员。

    time-box: 一个用于开会时间段。比如每个daily scrum meeting的time-box为15分钟。

    sprint planning meeting: 在启动每个sprint前召开。一般为一天时间（8小时）。该会议需要制定的任务是：产品Owner和团队成员将backlog分解成小的功能模块, 决定在即将进行的sprint里需要完成多少小功能模块，确定好这个Product Backlog的任务优先级。另外，该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。

    Daily Scrum meeting：开发团队成员召开，一般为15分钟。每个开发成员需要向ScrumMaster汇报三个项目：今天或昨天完成了什么？是否遇到了障碍？即将要做什么？（每天早晨，我们也是这么做的）通过该会议，团队成员可以相互了解项目进度。

    Sprint review meeting：在每个Sprint结束后，这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为4小时。

    Sprint retrospective meeting：对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为3小时。

    二）实施Scrum的过程简单介绍

1. 将整个产品（Product）的backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力物力条件可以完成的。
2. 召开sprint planning meeting，划分，确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的，并不是按人天计算。
3. 进入sprint开发周期，在这个周期内，每天需要召开Daily Scrum meeting。
4. 整个sprint周期结束，召开Sprint review meeting，将成果演示给Product Owner.
5. 团队成员最后召开Sprint retrospective meeting，总结问题和经验。
6. 这样周而复始，按照同样的步骤进行下一次Sprint.

    整个过程如下图所示
    

 

  本文参考：1、维基百科；2、邹欣的软件工程教学博客；3、酷勤网。完。