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 计划会议上要依次完成以下的内容:
- 团队决定在接下来的的 sprint 中要完成的用户需求,如过对需求存在疑问,团队应和 PO 进行澄清和确认。团队必须按照 PO 设定的 product backlog 的优先级别,从高到低选择,如因实现上的依赖关系,要调整需求选择的顺序,也需要和 PO 进行确认,以确保团队始终工作在最有价值的需求上。关于承诺多少需求,也并非取决于团队或专家的主观判断,而是根据 product backlog 中对每一个需求的大小估计,以及团队过去的实际开发速率(velocity),承诺相匹配数量的需求。
- 针对所选择需求的实现,进行简单和必要的沟通、分析。以确保第三步可以顺利的进行。
- 分别将每一个需求,分解成设计、开发和测试等任务。并估计每一个任务所需的工作量(通常以小时计)。
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 ”
感谢张凯峰对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。
评论