01/24 (2) : XP VS Scrum

 

 

Scrum中有四个很标致性也很核心的词:backlog , sprint、迭代、反馈。

backlog：是为条目(具体是不是不清楚，但我明白那是干嘛用的。相当于简洁”说明书”一样，但又不同于说明书)

spint：我就把它理解为运动会中每次比赛的准备工作或扫尾工作吧。

迭代：指产品的开发过程中，一个完整的开发活动周而复始的进行，产品的功能、性能、可用性在周期活动的叠加中不断得到更新和加强。

反馈：指在产品开发任何时期，代表项目业务（Business）的利益干系人（Stakeholder）都要参与到产品的需求分析，设计，以及其他活动的决策制定中来。

Backlog的作用：它是由需求，特性等组成。按照重要性进行排序。其中包括：客户想知道的内容，而且这个内容是用客户能够理解的术语进行描述。

sprint：就是sprint会议，就是开会！

 

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

Scrum的基本假设是：

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

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

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

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

图1

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

图2

三、Scrum模型

1、有关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小时。

2、实施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。

整个过程如下图所示：

图3

 

 

极限编程的12个实践是极限编程者总结的实践经典，是体现极限编程管理的原则，对极限编程具有指导性的意义，但并非一定要完全遵守12个实践，主要看它给软件过程管理带来的价值。

1、小版本
为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。

2、规划游戏
就是客户需求，以客户故事的形式，由客户负责编写。极限编程不讲求统一的客户需求收集，也不是由开发人员整理，而是采取让客户编写，开发人员进行分析，设定优先级别，并进行技术实现。当然游戏规则可进行多次，每次迭代完毕后再行修改。客户故事是开发人员与客户沟通的焦点，也是版本设计的依据，所以其管理一定是有效的、沟通顺畅的。

3、现场客户
极限编程要求客户参与开发工作，客户需求就是客户负责编写的，所以要求客户在开发现场一起工作，并为每次迭代提供反馈。

4、隐喻
隐喻是让项目参与人员都必须对一些抽象的概念理解一致，也就是我们常说的行业术语，因为业务本身的术语开发人员不熟悉，软件开发的术语客户不理解，因此开始要先明确双方使用的隐喻，避免歧异。

5、简单设计
极限编程体现跟踪客户的需求变化，既然需求是变化的，所以对于目前的需求就不必过多地考虑扩展性的开发，讲求简单设计，实现目前需求即可。简单设计的本身也为短期迭代提供了方便，若开发者考虑“通用”因素较多，增加了软件的复杂度，开发的迭代周期就会加长。简单设计包括四方面含义：（1）通过测试。（2）避免重复代码。（3）明确表达每步编码的目的，代码可读性强。（4）尽可能少的对象类和方法。由于采用简单设计，所以极限编程没有复杂的设计文档要求。

6、重构
重构是极限编程先测试后编码的必然需求，为了整体软件可以先进行测试，对于一些软件要开发的模块先简单模拟，让编译通过，到达测试的目的。然后再对模块具体“优化”，所以重构包括模块代码的优化与具体代码的开发。重构是使用了“物理学”的一个概念，是在不影响物体外部特性的前提下，重新优化其内部的机构。这里的外部特性就是保证测试的通过。

7、测试驱动开发
极限编程是以测试开始的，为了可以展示客户需求的实现，测试程序优先设计，测试是从客户实用的角度出发，客户实际使用的软件界面着想，测试是客户需求的直接表现，是客户对软件过程的理解。测试驱动开发，也就是客户的需求驱动软件的开发。

8、持续集成
集成的理解就是提交软件的展现，由于采用测试驱动开发、小版本的方式，所以不断集成(整体测试)是与客户沟通的依据，也是让客户提出反馈意见的参照。持续集成也是完成阶段开发任务的标志。

9、结对编程
这是极限编程最有争议的实践。就是两个程序员合用一台计算机编程，一个编码，一个检查，增加专人审计是为了提供软件编码的质量。两个人的角色经常变换，保持开发者的工作热情。这种编程方式对培养新人或开发难度较大的软件都有非常好的效果。

10、代码共有
在极限编程里没有严格文档管理，代码为开发团队共有，这样有利于开发人员的流动管理，因为所有的人都熟悉所有的编码。

11、编码标准
编码是开发团队里每个人的工作，又没有详细的文档，代码的可读性是很重要的，所以规定统一的标准和习惯是必要的，有些象编码人员的隐喻。

12、每周40小时工作
极限编程认为编程是愉快的工作，不轻易加班，今天的工作今天做，小版本的设计也为了单位时间可以完成的工作安排。

 

 

极限编程又称xp方法，是敏捷开发的软件过程模型。

极限编程的4条准则：沟通，简单，反馈和勇气（修复缺陷，集中攻关和放弃原有的代码）。

基本原则：快速反馈，假设简单，递增更改，提倡更改，优质工作。

开发软件的4项基本工作：编码，测试，倾听和设计

首先使用计划游戏，根据功能的优先级和实际进程来决定游戏的玩法，并只是制定下一阶段的计划，希望程序员主动的接受责任，并对预期实现的时间进行估计。不断发布小版本（小但是有价值）。使用隐喻，用有关整个系统如何运行的简单、众所周知的故事来指导所有的开发。使用的是简单的设计。通过测试来增强运行程序的信心，测试包括程序员进行的单元测试和客户方进行的功能测试，程序员们编写的每个测试都必须是独立的、自动化的。通过重构来简化程序并提高程序的柔性。采用结对编程，结对编程是xp方法的实践过程。代码归集体所有，防治复杂的代码进入系统，系统中不能包含重复的代码（有且仅有一次），系统拥有尽可能少的类，拥有尽可能少的方法。持续的集成，每次集成都要完成一项任务。规定每周工作时间是 40个小时。要求有现场客户，要求使用统一的编码标准。分阶段的交付产品，进行迅速而具体的反馈，清晰的参赛系统的业务要求和为特殊任务配备的专家。

在xp中，团队负责体系结构。Xp不注重体系结构，但有几点机制可以确保它的实现：探究、隐喻、第一次迭代、小版本、重构和团队实践。

Xp方法一天的开发流程是：

1. 确定问题和解决问题的人。

2. 配对－快速设计会议。在战略上选择伙伴，战术上考虑选择输入编码的人。并周期性的交换角色。

3. Test，Q&A。在编码之前验证测试失败，测试可能出错的地方，如果不明确答案是什么就询问客户。

4. Refactor。找出“代码的味道”（感觉不对的地方）应用重构，验证单元测试，并使其依然通过。采用小幅度改动，每次行动后都要做单元测试。

5. 集成或丢弃代码。将集成的代码生成系统，运行所有的测试，测试必须全部通过。如果不容易集成到过去的代码中，就丢弃它，明天重试。

结对编程，有利于团队成员间的互相学习。结对编程的伙伴不仅要求人在现场，而且更重要的是对任务做出承诺。伙伴能帮助保证团队的价值观不被忽略。伙伴允许你做必须做的事，这也许意味着丢弃代码，保持学习，并从头开始。结对编程弥补了键入代码和大脑高质量思考的矛盾。因此而导致了高质量代码的快速产出。国外的结对编程经验表明追求完美的开发人员与多产的开发人员结对的效果最好。

Xp的方法提倡为了胜利而比赛。人们喜欢胜利，喜欢学习，喜欢与别人交流，喜欢成为团队的一部分，喜欢将事情控制在自己的手中，喜欢受到信任。喜欢出色的完成任务。喜欢使自己制作出的软件发挥作用。

Xp方法的好处：

1. 有利于团队的整体进步。

2. 不会因为一两个人的离队而使项目停滞不前。

3. 开发过程带给程序员快乐和趣味。

4. 开发出来的项目有质量的保证。

经过自己使用xp管理团队管理的一年的实践过程中发现，Xp方法不适用具有一下特点的团队：

1. 还没有任何编出一个项目的团队。

2. 团队中多数人并不理解xp的方法。

3. 团体中的编程人员不愿意交流。或有些编程人员希望自己独立写代码。

4. 设计未动，开发先行的团队。

5. 团队中多数人并没有学习必要的软件工程知识。或不重视团队的重要性。

6. 成员没有掌握足够的技能来评估自己的代码，或做必要的测试。

7. 成员中没有人能知道自己要实现的功能将会花费多少时间。

8. 没有充足编程时间的团队。

同时也发现xp方法不适用的项目：

1． 没有客户方积极参与的项目.

2． 复杂而庞大的项目.

3． 有“高科技”攻关的项目.

4． 项目组不熟悉的项目类型.