6月
22
2011

ZZScrum框架及其背后的原则

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

第一部分: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的完整框架,只有这些,很简单,我们下面将逐行解释。

const int 	Sprint_Length = 10;
int 	velocity = get_past_performance();

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

Sprint_Length — Sprint长度:这里以10个工作日(两周)为例,const常量修饰符,强调了其不可变性。

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

Role team, product_owner, ScrumMaster;

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

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

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

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

Product_Backlog 	product_backlog;
Sprint_Backlog 		sprint_backlog;
Burndown_Chart		sprint_burndown_chart, release_burndown_chart;

Product_Increment 	product_increment;

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

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

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

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

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

Product increment — 产品增量:Scrum 要求每一个sprint结束都产生用户可用的软件,也被称着“潜在可交付的产品增量”(Potential shippable product increment, PSPI),事实上交付与否还要受用户习惯的约束。能否每个sprint生成满足质量定义的PSPI 是Scrum 执行效果的试金石。

setup_team(Team);
define_Definition_of_Done(team, product_owner);
initial_project(&product_backlog );

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

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

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

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

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

While (!is_empty(product_backlog)) {
    run_sprint_planning_meeting(product_backlog, velocity, &sprint_backlog);
    ……

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

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

  1. 团队决定在接下来的的sprint 中要完成的用户需求,如过对需求存在疑问,团队应和PO进行澄清和确认。团队必须按照PO设定的product backlog的优先级别,从高到低选择,如因实现上的依赖关系,要调整需求选择的顺序,也需要和PO进行确认,以确保团队始终工作在最有价值的需求上。关于承诺多少需求,也并非取决于团队或专家的主观判断,而是根据product backlog中对每一个需求的大小估计,以及团队过去的实际开发速率(velocity),承诺相匹配数量的需求。
  2. 针对所选择需求的实现,进行简单和必要的沟通、分析。以确保第三步可以顺利的进行。
  3. 分别将每一个需求,分解成设计、开发和测试等任务。并估计每一个任务所需的工作量(通常以小时计)。

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

作为sprint 计划会议的结果,团队选择并承诺了接下来sprint 中要完成的product backlog中的用户需求,并且,将每一个需求分解成具体的多个开发任务。这些开发任务的列表被称为sprint backlog,它是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 的时间长度。

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

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

run_sprint_review_meeting(product_backlog, product_increment);
run_retrospective_meeting();

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

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

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

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

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

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

总结

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

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

* 本文部分参考了“Scrum guide”和“Scrum Primer

图(一)是对该框架的总结。如此简单的框架如何能提升组织的能力?做到什么才能保障Scrum实施的成功,并从中受益?理解和贯彻Scrum框架背后的原则是关键。

图(一)Scrum 总体框架 PPT格式大图下载链接

为了说明这些原则与Scrum 框架的对应关系,在图(一)中我们以Scrum 框架为索引,列出了相对应的原则(见图中蓝色框),它们分别是:

  1. 产品开发过程相关的原则
    • 高度透明
    • 不断反馈调整
  2. 团队组织相关的原则
    • 多功能
    • 自组织
  3. 持续改进相关的原则
    • 将改进嵌入开发过程
    • 不断暴露和解决问题

以下我们将分别对这三个方面原则进行讨论,并就每个方面分析Scrum实施过程中的不良症状。

产品开发过程

Scrum 是一个经验性(empirical)的过程,透明(transparent)、检验(inspect)和调整(adapt)是它的三个支柱。Scrum的产品开发过程是高度透明和不断反馈调整的自适应过程。

需要特别强调的是,与传统开发过程相比,Scrum引入了一个根本性变化 —— 在每个固定长度的迭代周期(spirnt)产出潜在可交付的产品增量(potential shippable product incremental – PSPI。这是透明、检验和调整的基础,能否做到这一点是Scrum实施成功与否的试金石。

Scrum产品开发过程应该做到高度透明

透明是团队合作信任,以及对产品开发过程进行检验、调整的前提。为了做到真正的透明,Scrum开发过程中影响到最终结果的各个方面都应该是可见和可信的。在Scrum实施过程中要做到:

a) 遵循共同的框架

共同的迭代和增量开发框架为开发过程的透明提供了统一的基准,Scrum框架下的制品(Artifacts)是高度透明:

  • Product backlog反映了用户需求,以及它们的开发工作量、优先级和当前状态;
  • Sprint backlog反映了sprint的目标、工作任务和当前状态;
  • 发布燃尽图反映了项目的整体工作进展状态;
  • Sprint燃尽图反映了当前sprint的进展状态

Scrum的四个标准活动(event) —— sprint 计划会议、每日Scrum 会议、sprint评审和sprint回顾进一步促进了透明。

b) 信息真实可信

透明的信息为PO和团队提供了决策依据,信息可信与否直接影响决策质量的高低。敏捷开发的透明性内建于开发活动当中,保证了其真实可靠。这些信息,即时从版本层面、迭代层面和日常工作层面,反映项目的最新状态。

信息的可信还体现在,对相同信息的一致理解。例如,当声明一个需求已经完成时,PO的预期应该和团队的理解应该是一致的,这就是完成标准定义(Defintion of Done — DoD),它必须清晰明确,并被严格遵循。

c) 以最高效的方式及时沟通信息

良好的沟通促进透明。团队坐在一起,面对面的交流是最高效的沟通方式;有效的会议组织能改善计划、评审以及回顾活动的效果;一个良好的可视化工作空间(如白板墙等),可以促进信息的发布和交流,具体可参见《借助信息化工作空间实现高效的团队自我管理》。总之,采取一切可能的手段改善团队内部以及团队对外的沟通。

d) 持续交付带来最可靠的透明

向客户交付产品,可以让团队得到最直接和真实的反馈,可运行的软件不会撒谎。受产品特性和团队成熟度的限制,并不是所有的团队一开始就能做到每个 sprint向客户交付软件。但团队应努力让迭代的结果更接近交付的标准,并力争更频繁的实际交付,每一次交付都是对产品开发成果和团队过程能力的检验,。

Scrum开发过程中应该不断反馈调整

在传统开发过程中,团队根据目标制定计划,而后严格按照计划执行以达成目标,这是所谓定义性的开发过程。然而计划可能不合理,执行过程可能出现偏差,这都会使结果偏离预设的目标。即使计划被完美的执行,目标本身也会发生迁移,实际的业务目标和最初的设想总会有差距。如图(二)所示,定义性的开发过程对于软件开发这样复杂的活动并不适用。

图(二)定义性的开发过程

Scrum 倡导“经验性”的开发过程。如图(三)所示,在开发过程中团队不断检查和汲取反馈,调整下一步的行动,动态达成目标。经验性的开发过程让团队在复杂的市场和技术环境中更好的把握和实现业务目标,取得竞争优势。为实现有效的调整和反馈,组织要做到:

图(三)经验性的开发过程

a) 周期性的检验和调整

Scrum框架中包含多个检验和调整的反馈循环。每日Scrum会议上团队检验工作进展,和sprint目标进行比较,调整接下来的工作以更好地达成目标;Sprint评审会议上,团队演示软件,获取业务人员和客户的反馈,及时调整产品的方向以及开发计划。通过不断的检验和调整,团队和客户持续修正产品开发方向和计划,更好的实现商务目标。

b) 业务人员更紧密的参与开发过程

不管业务人员还是用户,都不可能在项目一开始就准确无误地把握产品方向和定义完整的需求,它们需要在开发过程中不断的被修订、调整和完善。如果,业务人员不参与到开发过程当中去,在项目结束时就可能会出现“团队开发的产品和业务人员的定义不符”,或者“团队开发的与当初业务人员所定义相符,但却不是业务人员和市场需要的产品了”。

业务人员参与开发过程,一方面团队能够及时获得对产品目标和需求的澄清和确认,确保双方的理解一致;另一方面,通过参与开发过程,业务人员更准确地理解客户需、把握产品目标,并做出及时的调整。

针对开发过程的不良症状分析

excel 版本下载

团队组织

通过Scrum开发过程的实施,组织更快的交付价值,更灵活的适应变化。同时,Scrum的实施对团队组织提出了新的要求。典型的Scrum 团队应该是多功能和自组织的。

团队应该是多功能的

多功能是指团队具备为客户提供端到端服务的全部技能,对于Scrum团队这意味着有能力完成从需求分析到交付产品的所有工作。如果团队为了完成一个工作要严重依赖其它部门,就无法实现真正的短迭代交付;同时,因为团队仅凭自身的努力无法获取期望的结果,就会缺乏对目标的认同和责无旁贷的责任感,也会缺乏改进的动力。为了做到团队的多功能,组织需要:

a) 创建跨职能和跨组件的团队

跨职能指团队具备承担系统分析、架构、设计、开发和测试等工作的全过程能力;跨组件指团队具备完成开发工作所需各个组件的知识,如UI,中间件,底层驱动等。

b) 拓展团队成员的知识技能

需要指出的是,多功能的团队并非指团队中的每一个人都具备所有技能,这在操作上是不实际的。Scrum对团队成员的技能要求倾向于通才型的专家(Generalizing specialist)。团队成员具备通用软件开发知识、业务领域知识、和自己的业务专长,同时应积极寻求拓展自己的技能。这有助于成员产生更全面的思考,促进团队的协作,以及消除开发过程资源的瓶颈和等待,增加开发过程中的灵活性等。

c) 团队应长期存在

一个团队从成立到高效运作需要一个过程,能力的拓展、团队的磨合、技术实践的优化、基础设施的完善都需要时间。通常建议Scrum 团队尽可能长期存在,而不是随着特定项目或开发版本成立和解散,长期存在的团队才有长期的承诺,形成对目标的认同和坚持,并激发不断改进的动力。

Scrum团队应该自组织的

自组织团队是指,由团队而不是管理者决定“怎么做”。Scrum团队被赋予并承诺组织目标,计划、执行和监控的职责则属于团队。因决策权力的充分下放,自组织团队能够对现状做出准确和及时的响应,并最大程度发挥团队成员能动性。但,简单地对一个团队说:“从今天开始,你们就自组织吧”,不会带来期望的结果。自组织的团队的形成需要:

a) 有意义和挑战的目标

有意义的目标可以协调团队成员努力方向,增加团队的凝聚力。一个通过努力可以达成的目标可以激发团队的激情和能动性。

b) 自主完成目标的潜在能力

团队有了目标,还要有与之匹配的潜在能力配置。多功能团队是自组织的前提,团队的长期性则保障了能力拓展和提升的可持续性。

c) 明确的边界

团队的自组织需要特定的边界。没有边界约束的自组织,很难确保其在执行上与组织目标的一致。Sprint周期是时间边界;Product Backlog是范围的边界;DoD是质量的边界。边界的存在让自组织更有序的发生,边界既是对团队的约束,也是对外界干扰的约束。有了边界的约束,可以建立外面的人对团队的信心和安全感;团队则在边界之内充分自主。

d) 良好的组织环境支持

组织环境之与团队,就像土壤之与种子。团队的自组织离不开良好组织环境的支持。面向团队而非个人的奖励和认可机制、面向结果而非过程的绩效体系、简单扁平的组织结构、以及充分的授权机制,都为团队自组织提供了良好的土壤。

针对团队组织的常见不良症状分析

持续改进

对开发过程本身的持续改进是Scrum的一部分,Scrum 实施能更好地暴露组织中存在的问题,解决这些问题是Scrum成功实施的保障,也是组织能力提升的关键。

via:infoQ.com

将改进融入开发过程

检验和调整针对的不仅是产品,团队还应经常对开发过程本身进行检验和调整,持续改进是Scrum框架的有机组成部分。如图(四)所示,下面的实线框内是对所开发产品的检验与调整,这一持续循环的目的是使最终的产品更好的符合实际目标;上面的虚线框内是对开发过程的检验与调整,其目的在于不断提高团队的过程能力,和长期交付的能力。

图(四)Scrum中的两个调整与检验循环

影响过程能力的要素很多,如团队协作方式、开发流程、技术实践、基础设施等。每个sprint的回顾会议都应对以上要素进行反思和调整,为保证sprint回顾及其后续活动的有效,团队要做到:

a) 让团队成员,积极参与改进的过程

retrospective prime directive” 是回顾会议的基本指导原则,它明确的指出,回顾是为了改进开发过程,而不是针对任何个人。一个被少数人主导的回顾会议,很难达到期望的效果,创造一个安全开放的氛围,让每一个人都积极参与改进过程,是确保其有效的前提。尝试不同的形式来组织回顾会议的进程,也有助于提高成员参与的积极性,Agile Retrospective一书提供了丰富的回顾会议的组织形式。

b) 每次聚焦有限的改进项目

一次改变太多的东西是不现实的,会导致分析不够深入彻底,执行的效果打折。每次聚焦一到两点,集中力量,积累小的改进成果。

c) 找到深层次的原因

就问题解决问题是不够的,多问几个为什么,挖掘问题背后的本质原因,这样的改进才是彻底和长久的。

d) 产生具体可执行的行动方案

光发现和分析问题还不行,要制定切实可行的方案。方案必须是具体和可执行的,可以落实到人,而不是仅停留在口头或纸面。

e) 检验改进效果

改进计划落实执行后,需要检查其效果,形成改进环。每次回顾会议的开头检查上次改进方案的执行结果,是一个比较好的做法。

f) 永远不要放弃改进的努力

Scrum的改进过程没有终结,持续改进是Scrum的一部分。

在Scrum实施中暴露并解决问题

Ken Schwaber曾经对Scrum做出一个非常好的类比,他说:“Scrum象丈母娘,她希望自己的女儿好,总是对女婿不满意,不断挑他的毛病,却从来不提供改正方案”。相似之处在于,Scrum暴露问题,却不提供解决方案,因为那是团队的责任。

Scrum没有告诉你怎么开发软件,甚至也不告诉你怎么协作,这些由团队自主决定,《敏捷开发艺术》的作者James Shore评论“Scrum是一个有意为之的半成品”。这恰恰是Scrum的生命力所在,维持了Scrum的简洁和包容性;这也是Scrum的陷阱所在,它可能误导使用者低估Scrum实施的难度,而事实上它却对组织和团队提出了很高的要求。通过Scrum实施暴露问题,然后解决它们,这是Scrum引领团队成功的不二法门,这需要团队的勇气和智慧。

a) 尽可能暴露问题,并解决这些问题

Scrum通过透明和检验使问题更易被发现。每个迭代产生潜在可交付的产品增量,暴露了过去深藏于长开发周期中的问题;团队的直接沟通,暴露了隐藏于复杂组织结构下的问题;更少并行开始的用户需求,暴露了隐藏于大量的半成品里的问题。因此选择更短的开发周期,更直接沟通,同一时间更少的并行需求开发,都有助于问题的暴露。

没有重大的改变,就不可能有重大的不同。问题暴露了,就要去解决,不管是组织的问题、团队合作的问题、工程实践的问题、还是研发基础设施的问题,都要去解决。在解决问题的过程中,团队完善自己、提高交付能力并从Scrum实施中真正获益。

b) 技术实践必须跟上

Scrum框架中并不包含任何技术实践,当然也不排除任何技术实践。问题是在实际操作中,技术实践很容易被忽略。James Shore在“The Decline and Fall of Agile ”中表达了对许多Scrum团队忽略技术实践的深深担忧,言辞激烈,但发人深思。Robert C. Martin 在 “The Land that Scrum Forgot”中也旗帜鲜明的指出离开技术实践的Scrum是无法长久的,他提出如果没有技术实践的支持,更快的交付软件就意味着更快的积累技术债务,这篇文章还列举了最应该被重视的技术实践,很有参考意义。

尽管,在Scrum的框架中,由团队自主决定技术实践的采用,团队在检验和调整过程中决定是否需要技术上的改变和怎样改变。但理论和实践都已经证明 Scrum的成功离不开敏捷技术实践的支持,很多团队都因技术实践未跟上而走向失败。既然这是一个必然且十分重要的选择,那么,在操作上单独去强调技术实践就十分必要。

针对持续改进的常见不良症状分析

总结

掌握自己的命运:Scrum对不同组织含义是不同的, 对一个重流程的官僚组织,它可能意味着拥抱变化、紧密的合作、充分的授权、和灵活的交付模式。而对于一个缺乏必要规范的组织,它可能意味着加强团队纪律,用明确的框架来规范和拓展当前的实践。作为一个强调经验性过程的框架,在Scrum框架的基础上,组织需要探索适合自身的实施过程,掌握自己的命运!

Scrum实施策略需要考虑所处阶段:不同阶段采用不同的策略1)初始实施时,严格遵照Scrum框架进行 2)在实施过程中加深对Scrum原则的理解,在此基础上考虑创新突破。3)当对这些原则把握自如时, Scrum的形式就不再重要了,当然这可能需要好几年的时间。Alistair Cockburn曾引用来自日本剑道的术语“守,破,离”来描述这三个阶段。

很痛苦,但非常值得:Scrum 框架非常简单,但简单不等于容易。Scrum一定会带来巨大的改变,你要做好准备,它意味着观念的转变,权力的重新分配,技术实践的配套,基础设施的优化等。改变是困难的,过程是痛苦的,但非常值得。

转自:http://b.zkjia.com/post/2011/05/24/Scrume6a186e69eb6e58f8ae585b6e8838ce5908ee79a84e58e9fe58899.aspx

关于作者:moface

博主

留下评论

博客剩余工作

6,优化前台(YSlow) 2,404页面 3,IE6下兼容性问题很大 1,标签小工具行高有点儿问题 4,微博聚合 5,推广工作 7,CDN(cloudflare

分类

访问统计