Scrum 框架讨论

Scrum是应用最广泛的敏捷开发方法。同时，它的失败率却非常高，其创始人之一KenSchwaber估计75%尝试Scrum的组织无法获取他们预期的效果（http://www.agilecollab.com/interview-with-ken-schwaber）。对此，通常的解释是“对Scrum框架的错误应用，和对其原则的错误把握。”KenScheaber在“ScrumGuide”一文中对这两方面都提供了权威的阐述。本文的目的是在此基础上，提供更加明确的操作性的指导和检查工具。

第一部分：Scrum的框架

Scrum并不是一个特定产品开发的流程或技术，而是一个容纳其它流程和技术的框架。作为一个迭代和增量的产品开发框架，Scrum本身十分简单和明确。下面的一段伪代码，是对Scrum框架的完整表述。

void run_scrum() {
    const int 	Sprint_Length = 10;    
    int 		velocity = get_past_performance();  		

    // Scrum 中的三个角色
    Role team, product_owner, ScrumMaster;

    // Scrum 中的制品
    Product_Backlog 	product_backlog;
    Sprint_Backlog 	sprint_backlog;
    Burndown_Chart	sprint_burndown_chart, release_burndown_chart;

    Product_Increment 	product_increment;

    //开始项目的三个准备条件
    setup_team(team);
    define_Definition_of_Done(team, product_owner);
    initial_project(&product_backlog );  //标红的为输出参数，将带回值，下同

    //每一次while 循环为一次迭代
    while (!is_empty(product_backlog)) {
        run_sprint_planning_meeting(product_backlog, velocity, &sprint_backlog);

    	//每一次for循环为一个工作日
        for(num_of_day = 1; num_of_day <=  Sprint_Length; num_of_day ++){
            run_daily_scrum_meeting(&sprint_burndown_chart);
            do_development_activity(sprint_backlog, &product_increment);
        }

        run_sprint_review_meeting(product_backlog, product_increment);
        run_retrospective_meeting();

        update_product_backlog(&product_backlog, &release_burndown_chart);
        update_velocity(&velocity);
    }  
}

这就是Scrum的完整框架，只有这些，很简单，我们下面将逐行解释。

constintSprint_Length=10;

intvelocity=get_past_performance();

Scrum是一个迭代开发模型。每一个迭代周期，团队完成一部分产品需求，交付可工作的软件。在Scrum中，迭代被称为sprint(本意为冲刺跑，一般不作翻译)，典型的sprint长度是1到4周。值得强调的是，对于同一团队，sprint的长度是固定不变的。

Sprint_Length--Sprint长度：这里以10个工作日（两周）为例，const常量修饰符，强调了其不可变性。

Velocity--团队开发速率：也即每个sprint团队能完成多少量的用户需求，它是Scrum中计划和承诺的最重要依据。开发速率来源自过去实际产出结果，并在产品开发过程中不断修正。

Roleteam,product_owner,ScrumMaster;

以上的实体定义是Scrum中的三个关键角色，在Scrum框架中也仅仅定义了这三个角色。

Team--团队：团队负责产品交付，规模一般为5～9人，Scrum强调团队的多功能（crossfunctional）和自组织。多功能指的是，团队应该整体具备各个职能所需的技能，如系统，开发和测试技能，同时也具备各个组件的技能如数据库设计、协议开发和UI设计等。团队的多功能是短迭代开发的基础，只有做到这一点，独立的团队才可能在一个sprint中交付对用户有意义的产品增量。自组织指，在目标清晰的前提下由团队自主决定完成目标的具体方法。

ProductOwner–产品负责人:多直接称为PO。PO负责把握产品的方向，包括需求的收集、定义，优先级设定等。PO通过这些活动以及和团队的合作，最终确保产品ROI（returnofinvestment,投资回报）的最大化。

ScrumMaster:一般不作中文翻译，ScrumMaster并不直接负责产品交付，它向团队负责，确保团队按照Scrum的框架工作，具备良好的外部和内部工作环境，顺畅地交付产品，并不断的改进，提升交付的效率和质量。与传统意义上的管理者不同，ScrumMaster更多是起服务、协调和引领的作用。如果注意观察会发现，在这段程序中，ScrumMaster是一个定义，但从未使用的变量，这也正反映了ScrumMaster的协调和支持的作用。

Product_Backlogproduct_backlog;

Sprint_Backlogsprint_backlog;

Burndown_Chartsprint_burndown_chart,release_burndown_chart;

Product_Incrementproduct_increment;

上面的结构变量是Scrum中的核心制品，它们贯穿整个Scrum操作过程，分别是：

Productbacklog--产品待办事项：很多时候直接用英文表示，简称PB，是一份用户需求列表。其中的每一项都是一个具体的端到端的用户需求，如“用户可以完成登录”等等。Scrum产品开发过程就是，通过一系列的sprint，每个sprint完成一部分“产品待办事项”，交付包含这些需求实现的产品增量，直至完成所有“产品待办事项”。Productbacklog的责任人是ProductOwner，它在产品开发的初期生成，并在开发过程中不断更新完善。

Sprintbacklog--sprint待办事项：是一个sprint中要完成的任务列表。其中的项目是为完成特定用户需求而要进行的设计、开发、集成、测试等具体任务，如“为模块A添加外部接口”等。完成sprintbacklog中的所有任务，也意味着sprint开发任务的完成，对应的用户需求可以交付。Sprintbacklog，在spirnt计划会议上生成，在开发过程中，可能会有所调整。

Sprintburndownchart–sprint燃尽图：以坐标图表示团队在一个sprint中工作进展情况，横坐标是sprint已进行的实际天数，纵坐标是还剩余的任务需要的时间的总和。它直观的反应了sprint实际执行与计划的比较，以及团队离sprint的目标完成的距离。

Releaseburndownchart–发布燃尽图：以坐标图表示当前版本的需求完成进展情况，横坐标是已经进行的sprint的个数，纵坐标是待完成的用户需求的多少。它直观的反应了产品需求的完成情况，以及团队离完成版本完全发布的距离。

Productincrement--产品增量：Scrum要求每一个sprint结束都产生用户可用的软件，也被称着“潜在可交付的产品增量”（Potentialshippableproductincrement,PSPI），事实上交付与否还要受用户习惯的约束。能否每个sprint生成满足质量定义的PSPI是Scrum执行效果的试金石。

setup_team(Team);

define_Definition_of_Done(team,product_owner);

initial_project(&product_backlog);

上面代码中的三步操作是Scrum执行开始的准备条件。

SetupTeam–创建团队：创立和建设适合的团队是Scrum实施的第一步工作，团队应该满足上面定义的Scrum团队的基本属性，并形成自己的目标和愿景，理解Scrum工作模式。

DefineDefinitionofDone–定义完成标准：完成标准，是指一个用户需求完成应该满足什么样的标准。它是ProductOwner和团队之间的一个约定，有了这个约定，当团队说，这个需求完成了的时候，ProductOwner将明确知道这意味着什么，比如是否包含了针对这个需求的性能测试，或是否包含相应的用户使用手册等。在实际运用中，由于条件限制，团队在一开始可能无法做到sprint结果可交付，而会剩余一部分工作在交付前完成，如性能测试等，这一部分工作被称为“undone”的工作。完成标准在特定时间是固定的，但随着团队成熟度提高，团队应逐步扩展自己的完成标准，使其逼近向客户交付的条件，undone的部分越来越少。

InitialProject–启动项目：项目启动，是项目进入开发阶段前的一系列准备工作，如：项目目标的设定，项目初始需求的定义和澄清，工作量的估计，风险的识别，关键设计决策的产生，开发基础设施的选择和构建等。一般由客户（如果可能），PO，团队以及相关干系人共同参与项目启动。项目启动最重要的是输出一个初始productbacklog，它应该包含对其中条目的大小的估计和优先级别的设定。

上面三个操作的结果是，有了合适的Scrum团队，团队和PO之间就需求完成的标准达成一致的定义，并生成了一份初始的productbacklog。有了这三个条件便可以正式进入迭代开发了。

While(!is_empty(product_backlog)){

run_sprint_planning_meeting(product_backlog,velocity,&sprint_backlog);

……

每一次while循环代表一个sprint周期，直至productbacklog中所有的需求被开发完成。

Runsprintplanningmeeting–进行sprint计划会议：sprint规划会议规划这个sprint目标和具体任务安排，它标志着一个sprint的开始。在sprint计划会议上要依次完成以下的内容：

1.团队决定在接下来的的sprint中要完成的用户需求，如过对需求存在疑问，团队应和PO进行澄清和确认。团队必须按照PO设定的productbacklog的优先级别，从高到低选择，如因实现上的依赖关系，要调整需求选择的顺序，也需要和PO进行确认，以确保团队始终工作在最有价值的需求上。关于承诺多少需求，也并非取决于团队或专家的主观判断，而是根据productbacklog中对每一个需求的大小估计，以及团队过去的实际开发速率（velocity），承诺相匹配数量的需求。

2.针对所选择需求的实现，进行简单和必要的沟通、分析。以确保第三步可以顺利的进行。

3.分别将每一个需求，分解成设计、开发和测试等任务。并估计每一个任务所需的工作量（通常以小时计）。

Sprint计划会议由团队主导，但需要PO的贡献，特别是上面的第一条，需要PO的现场参与。其它条目，即使PO不在场，也应该随时可以提供远程的咨询。

作为sprint计划会议的结果，团队选择并承诺了接下来sprint中要完成的productbacklog中的用户需求，并且，将每一个需求分解成具体的多个开发任务。这些开发任务的列表被称为sprintbacklog，它是sprint计划会议的最重要输出，接下来的工作，就是完成这些开发任务，交付对应的用户需求。

for(num_of_day=1;num_of_day<=Sprint_Length;num_of_day++){

run_daily_scrum_meeting();

update_burndown_chart();

do_development_activity(sprint_backlog,&product_increment);

}

在这里，每一次for循环代表一个工作日，循环的次数也即sprint的时间长度。

Rundailyscrummeeting–进行每日Scrum会议：Scrum团队每天都会进行一次同步--Scrum会议。Scrum会议被限定在15分钟之内结束，每一天在同样的时间，同样的地点举行，旨在沟通同步项目开发状态，建立团队对项目的整体认识，并发现项目中的问题。会议上，每一个人都向团队回答三个问题：我昨天做了什么？我今天计划做什么？在前进的道路上有什么障碍?Scrum会议结束后，要更新sprint燃尽图以反映团队的工作进度，和离sprint目标的距离。

Dodevelopmentactivity–进行开发工作：Scrum强调团队成员间的紧密协作，原则上任务应该由团队成员主动认领，而非被分配。为此，团队需要形成相应的规则，如：在同一时刻，不应该并行开始过多用户需求开发，这样可以确保团队有明确的工作重点，也可以避免在sprint结束时所有的需求都只是部分完成，而交付不了任何有价值的软件增量。随着开发进程的不断进展，软件增量得以生成、扩展和验证。

run_sprint_review_meeting(product_backlog,product_increment);

run_retrospective_meeting();

Runsprintreviewmeeting–进行sprint评审会议：Sprint评审会议又称为sprint演示会议，一个sprint结束，团队构建了包含新的用户需求的产品增量，团队在这个会议上展示过去的一个sprint所构建的产品。sprint评审会议是开放的，应尽可能邀请相关人员参加，ScrumMaster、团队、PO、市场人员、客户、管理人员、维护人员、领域专家以及关联团队等。在会议上团队对照productbacklog依次演示刚刚构建的用户需求，获取参与者的反馈，这些反馈将成为未来的产品设计和规划调整的依据，以使产品更好的满足客户的需求，更好的服务于组织的业务目标。

Runretrospectivemeeting–进行sprint团队回顾会议：在评审会议之后，团队进行回顾会议，评审会议是对产品的检查和调整，而回顾会议是团队对自身的检查和调整。Scrum强调通过经验性的过程，逐步检查和调整团队的协作和工作模式，持续改善。回顾会议是Scrum运行的十分重要的一环，其有效性是Scrum实施成功的保障。除非团队决定邀请额外人员，回顾会议一般只有团队参加，在回顾会议上，团队回顾刚刚过去的一个sprint，团队在哪些方面做得好，应该坚持；哪些方面有待改进，并挖掘其本质原因，定义具体的改进计划，以在下一个sprint去切实实施。为保证回顾会议的有效，组织和团队都应该承诺愿意做出适应性的改变。

update_product_backlog(&product_backlog,&release_burndown_chart);

update_velocity(&velocity);

Updateproductbacklog--更新产品待办事项：sprint结束，产品待办事项内的一部分需求被交付，应该更新其状态。此外，由于PO和团队获取了更准确和详细的产品信息，productbacklog也应该相应更新，例如在sprint回顾会议激发了用户对优先级新的认识，在同PO确认后，productbacklog的优先级定义就需要做出相应的调整。更新产品待办事项的同时，发布燃尽图也需要相应更改，以反映最新的需求完成情况。

Updatevelocity–更新团队开发速率：前面提到，团队承诺多少需求的依据是团队过去的开发速率。每个sprint结束，团队的参考发速率都需要根据实际情况做修正，这将有助于更好地把握开发节奏，合理地计划未来的工作。

至此，一个sprint结束，潜在可交付的产品增量得以交付或演示，团队和PO获取了有意义的反馈，productbacklog得到了调整，团队对工作进行了反思并定义了改进方案。这时就可以进入下一个sprint，直至交付整个产品。

总结

Scrum框架为团队敏捷实施定义了一个简单和明确的边界。在边界之内，团队探索和完善相关的管理和技术实践。我们一般建议，开始尝试Scrum的组织最初应严格遵循框架的定义，这时常会引起过于教条和形式主义的争议，团队会提出“应该抓住Scrum的实质，而不是强调形式”。问题是，只有通过严格的基本实践的学习和应用，我们才可能掌握其原则，区分哪些是实质，哪些是可以调整的形式。KenSchwaber对此的描述是，“对Scrum规则的修改，只有在ScrumMaster确信团队足够深入的掌握了Scrum的运行原理，有足够的技能和思维来修改规则时才可以进行”。

我们建议，那些准备实施Scrum或者已经实施但还处于探索中的团队，可以打印出这段伪代码，对照自身的实际操作，任何与这段伪代码不符的地方，团队都应该认真思考其合理性。我们更加建议，团队在实施Scrum的过程中，深入理解和思考Scrum框架背后的价值观和原则，Scrum为什么可以和将怎样改进产品开发，为此我们需要做出哪些改变。对原则的理解和思考，有助于我们对实践的更好掌握，更快的从Scrum中受益。