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中受益。

相关推荐