敏捷软件开发模型--SCRUM

敏捷软件开发模型--SCRUM

一 什么是Scrum?

Scrum (英式橄榄球争球队), 软件开发模型是敏捷开发的一种，在最近的一两年内逐渐流行起来。

Scrum的基本假设是：

开发软件就像开发新产品，无法一开始就能定义软件产品最终的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证专案成功。Scrum 将软件开发团队比拟成橄榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。

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

二 Scrum较传统开发模型的优点

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


下图是Scrum模型和传统模型的对比：
       

三 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和其他相关的人员。一般该会议为４小时。

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

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

1) 将整个产品的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.

整个过程如下图所示：




The diagrams in this article are all from web site: http://www.controlchaos.com.  Thanks very much!

 

敏捷软件开发宣言

                 我们 正通过亲身实践 以及 帮助他人实践，揭示更好的软件开发方法

                              通过这项工作 ，我们认为：

                                                        人和交互              重于                 过程和工具

          可以工作的软件             重于                面面俱到的文档

                       客户合作               重于                 合同谈判

随时应对变化            重于                 遵循计划

虽然右项也有其价值，但我们认为左项更加重要。

原则

1.       我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。

2.       我们欢迎需求的变化，即使到了开发后期。敏捷过程能够驾驭变化，为客户创造竞争优势。

3.       经常交付可以工作的软件 ，从几个星期到 几个月，时间间隔越短越好。

4.       在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。

5.       围绕斗志昂扬的人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

6.       在团队内部，最有效率也最有效果的信息传达方式，就是面对面的交谈。

7.       可以工作的软件是 进度主要的度量标准。

8.       敏捷过程提倡可持续开发。出资人、开发者和用户应该总是保持稳定的开发速度。

9.       对卓越技术和良好设计的不断追求有助于提高敏捷性。

10.   简单——尽量减少工作量的艺术是至关重要的。

11.   最好的架构、需求和设计都源于自我组织的团队。

12.   每隔一定时间，团队都要总结如何更右效率，然后相应地调整自己的行为。

极限编程实践

   完整团队            用户故事            短交付周期       验收测试            结对编码            测试驱动开发 

   集体所有权       持续集成            可持续的开发速度        开放的工作空间             计划游戏

   简单设计            重构      隐喻

避免设计的臭味

·         僵化性 （rigidity） ——设计难以改变。

·         脆弱性（fragility）——设计易于遭到破坏。

·         顽固性（immobility）——设计难以重用。

·         粘滞性（viscosity）——难以做正确的事情。

·         不必要的复杂性（needless complexity）——过分设计。

·         不必要的重复（needless repetition）——滥用鼠标进行复制、黏贴。

·         晦涩性（opacity）——混乱的表达。

设计原则

·         单一职责原则（SRP）：一个类应该只有一个发生变化的原因。

·         开放封闭原则（OCP）：软件实体应该对扩展开放，对修改关闭。

·         Liskov替换原则（LSP）：子类型（subtype）必须能够替换掉它的基类型（base type）。

·         依赖倒置原则（DIP）：a. 高层模块不应该依赖于低层模块。二者都应该依赖于抽象。b.抽象不应该依赖于细节。细节应该依赖于抽象。

·         接口隔离原则（ISP）：不应该强迫客户程序依赖并未使用的方法。

·         DRY：Don’t repeat yourself Principle。通过抽取公共部分放置在一个地方避免代码重复。

·         封装变化 （Encapsulate what varies）。

·         面向接口编程而不是实现（Code to an interface rather than to an implementation）。

·         优先使用组合而非继承（Favour Composition Over Inheritance）。

包和组件的设计原则

• 重用-发布等价原则（Reuse-Release Equivalence Principle, REP）：重用的粒度就是发布的粒度。
• 共同重用原则（Common-Reuse Principle, CRP）：一个组件中的所有类应该是共同重用的。如果重用了组件中的一个类，那么就要重用组件中的所有类。
• 共同封闭原则（Common-Closure Principle, CCP）：组件中的所有类对于同一种性质的变化应该是共同封闭的。一个变化若对一个封闭的组件产生影响，则对该组件中的 所有类产生影响，二对于其他组件则不造成任何影响。
• 无环依赖原则（Acycle-Dependencies Principle, ADP）：在组件的依赖关系图中不允许存在环。
• 稳定依赖原则（Stable-Dependencies Principle, SDP）：朝着稳定的方向进行依赖。
• 稳定抽象原则（Stable-Abstraction Principle, SAP）：组件的抽象程度应该与其稳定程度一致。