书摘《敏捷帮你成功：使用 Scrum 开发软件》

Scrum 团队成员已经习惯于看到他们项目组中的两个新角色了——Scrum Master 和 Product Owner。但 Scrum 项目成员面临的改变远不只是这两个新角色。例如，Scrum 团队的自组织特性使其取消了技术主管这一角色，每个人都不能仅限于自己的术业专攻，而是要尽可能地帮助整个团队，尤其是要把写需求取代为讨论需求，到每个 sprint 末，团队都必须做出些实实在在的东西来。当采用 Scrum 时，有些调整会改变团队和组织内部的角色及其之间的关系，这常常会给组织带来一些直面的挑战。

本文将描述每个人从传统角色到 Scrum 转换过程中必须做的主要调整。重点会落在这些角色怎样转变，而不仅仅是对每个角色的介绍。例如，我不会介绍一个测试人员参与测试应用程序要做的每项工作。而我却会将重点放在测试人员在 Scrum 项目中工作需要怎么样的转变。我将讨论的角色有：分析师、项目经理、架构师、职能经理、程序员、数据库管理员、测试人员及用户体验设计师。

在阅读的过程中，请记住，任何参与开发产品或软件系统的团队成员首先是开发人员。当我使用像测试人员这样的术语时，我指的是拥有特殊技能或对测试有兴趣的开发人员。类似地，分析师是指倾向于从事分析工作的开发人员，但他也会从事团队所需要的任何其它高优先级的任务。

分析师

一些精通产品相关知识且擅长沟通的分析师会向 Product owner 的方向转变。这在那些大型项目中尤为普遍，而且这种项目中 Product owner 们还会有层次结构。 例如，有些人名片上写着是产品经理，其实可能是为整个产品充当首席 Product owner 的角色，花大量的精力关注在用户和市场上。换句话说，一个名片上印着分析师的人，也可能做的是各个团队的 Product owner，和首席 Product owner 一起把愿景转化为各团队的产品 backlog。

许多团队发现，在团队里有个分析师是有利于长远发展的，尽管分析师的工作方式可能要改变。在传统管理模式的项目中，分析师的职责貌似是尽可能超前于团队工作。在 Scrum 项目中，及时分析成为了目标。分析师的新目标是尽可能稍稍超前于团队工作，同时仍能够为团队当前以及近期所做的功能特性提供有用信息。

分析师能推动需求工作的重心转移，从而达到从写需求转化为讨论需求的目的。由于分析师不再像以前一样超前于团队，他们要开始习惯更多地以非正式方式更顺畅地和团队共享信息，而不再是通过大规模的文档。尽可能多的信息要通过口头讨论来传递，然而分析师仍然需要写一些需求文档，特别是和分布式团队一起工作时。但通常分析师写的东西将不那么正式了——常常是 wiki，而不是签了字的文档。

在传统项目中，分析师通常充当的是团队成员和 product owner 沟通的传话筒。而在 Scrum 项目中，分析师应当成为团队 VSproduct owner 讨论的催化剂，而不再是传话筒。团队成员和 product owner 要面对面沟通。优秀的敏捷分析师应该注重在团队和 product owner 会话的有效性和效率，而不只是简单地组织对话。也就是说，分析师要引导 product owner 和团队关注讨论一个用户故事而不是另外的，因为那样很可能会误入歧途。这也意味着分析师要在团队和 product owner 一起讨论细节之前，让团队对新功能点有一定的初步认识。

在传统项目中，分析师可能会对团队说，“我已经我我们的关键利害关系人谈过了，了解了他想要什么，具体细节都写着这份文档里了。”相比之下，在 Scrum 项目中，同样的分析师应该说，“我和我们的 product owner 聊了一下，试着摸索他所期望的东西。我写了这 6 个用户故事让你们先初步了解一下，并且我收集了一些进一步的问题要问 product owner。但是我希望讨论的时候你们几个可以和我一起去。”

有了以上这些关于分析师的讨论，让人很容易想到分析师工作要超前团队一个 sprint。但事实却不是这样。Gregory Topp，一个美国农业信贷服务行业的分析师，介绍了使用 Scrum 是怎样让他能够专注于当前 sprint 的经验：“用 Scrum 前，我不得不把重点放在那些近几周甚至几个月都不会被开发的需求上。而现在，我只要关注当前的 sprint（我们是两周），于是可以花更多时间在用户故事的细节完善、开发和测试上。”分析师的第一要务是达成当前 sprint 的目标。Scrum 团队中的分析师将协助测试，为要开发的功能解答问题（或找出解答问题的方法），完全参与到 sprint 的所有日常会议当中，等等。

不过，这些活动很可能并不能占据分析师所有的时间。那些当前 sprint 中剩余的时间可以用来做前瞻工作。但是，作为当前 sprint 的团队一员并花些时间在前瞻工作上，和超前团队一个 sprint 工作是不同的。Topp 解释了为什么太过超前实际上会让他落后：“我尝试过超前一两个 sprint 工作，定义一些用户故事的细节。我认识到这会伤及当前 sprint。我也发现很多时候用户故事的细节会在团队真正要实现它的发生变化。”

一个普遍的疑问是，分析师花在前瞻工作上的时间应不应该包含着 sprint backlog 里。我的建议是要在 sprint backlog 里包含那些在 sprint 计划阶段能够识别的具体分析工作。例如，假设团队在做一个批准或驳回贷款申请的应用程序。如果 product owner 和团队达成一致，要在下一个 sprint 包括计算申请人信用评分的功能，那么相关的准备分析任务就应该被识别、估算并包含在 sprint backlog 里。换句话说，如果下一个 sprint 的工作未知，也就没有什么和下一个 sprint 相关的具体任务要放到 sprint backlog 里了。

总而言之，许多分析师还是很喜欢在 Scrum 中的转变的，即使他们出让了作为客户期望唯一代言人的职责。采用 Scrum 两年后，Topp 谈到他和团队中其它人关系的变化。

因为我们都在一个团队，都在同一时间做着同一批用户故事，团队看起来更同心协力。在用 Scrum 之前，貌似每个职能角色（分析师、程序员、测试人员、数据库管理员）都各自为政。在那种状态下大家经常互相职责。现在用了 Scrum，团队都关注在一个个小的故事上。互相职责、推卸责任的想法已经被“一个团队”的理念摒除了。

项目经理

在采用瀑布开发过程的项目中，项目经理的艰巨任务是保证客户想要的产品就是正被开发的产品。要做到这点，项目经理必须面面俱到的管理项目，包括范围、成本、质量、人员、沟通、风险、采购等等。其中有些职责事实上属于其他人。例如，范围控制应当属于客户的管辖范畴。没人比他们更有资格对产品开发期间出现的状况做必要的决定，来权衡优先级、团队速度以及市场状况变化。排优先级不是一成不变的、一次性的、在一开始就能定义好并交给项目经理来管的活动。然而，瀑布开发过程的项目却要项目经理来做有理有据的推测，以发布正确的产品。

Scrum 项目中，我们认识到项目经理一职的不堪一击并将它去掉。但去掉这个角色并不意味着我们要对工作和职责置之不理。如你所料，既然自组织团队是 Scrum 的核心原则之一，处理原先那些项目经理肩上重担的最好方法就是将它们交给 Scrum 团队。例如，不需要项目经理分配任务给每个人，团队成员们担起了为他们自己选择任务的职责。还有些职责则转给了 ScrumMaster 或 product owner。

原先的项目经理则通常会承担起他们过去的某个角色——项目经理可能成为 ScrumMaster、product owner 或团队成员，这取决于经验、技能、知识水平和兴趣。

有些人做项目经理是因为他们觉得这是理想职业路线的下一步，而并非他们喜欢做项目经理。这些人错过了作为程序员、测试人员、数据库工程师、设计人员、分析师、架构师等可能遇到的技术挑战。 他们中的许多人将利用去掉项目经理这一角色的契机重新回到他们更满意的岗位上去。

另一些项目经理则习惯了充当相关行业及其客户知识专家的角色。这种情况下，项目经理可以利用这些知识成为 product owner。 这可能是个很棒的匹配，特别是对那些难以完全戒掉指挥别人的项目经理而言。作为角色的一部分，product owner 可以跟团队说一些“该做什么”，只要他们不插手告诉人家怎么做。这或许可以满足那些以前习惯于偶尔指使团队又很难戒掉的项目经理。

如果一个项目经理能够克服以前指使团队、为团队做决断的习惯，这样的项目经理可能可以成为一个不错的 ScrumMaster。在采用 Scrum 的组织中，这是项目经理们最常见的新角色。对于以前的项目经理而言，这个新角色一开始可能有点儿难，他要学着保持沉默，让团队学着怎样解决他们的问题和做决定。通常，新 ScrumMaster 都面临着挑战，他们要教团队的东西——敏捷，其实他们自己也不擅长。在这种情况下，对 ScrumMaster 来说最好的策略包括一下几点：

• 尽可能坚持按照书上的指导来实施 Scrum。开始先好好按着某本关于 Scrum 的书上的建议做。或者最好聘请一个现场培训师或教练，跟着人家的建议做。在有了真正的实战经验之后，再开始考虑定制过程。
• 尽可能多和其它 ScrumMaster 交流讨论。如果你的组织中有很多 ScrumMaster，和其它 ScrumMaster 组织一个实践社团来分享大家成功和失败的经验。在这些经验中提取共性的东西善加学习。如果你是组织中唯一的 ScrumMaster，找些外面的同行，和他们分享你的故事，比较你们的方法。
• 尽你所能学得越多越好，越快越好。阅读大量的书籍、文章、博客以及网页。找到本地的敏捷兴趣小组并加入他们的会议。尝试参加一个或更多主要关于敏捷或 Scrum 的会议。

Doris Ford，摩托罗拉公司的一个软件工程经理，是一个科班出身的项目经理，并且是项目管理专家（PMP）。但是，尽管在项目管理方面有传统背景，Doris 做事的方针就是去支持和帮助她的团队的方式。也正是因为这样，她很自如地完成了从项目经理到 ScrumMaster 的转变。她写下了 Scrum 给她的工作带来了怎样的变化。

经过多年敏捷开发管理，我学会了不在任务细节上浪费汗水。作为一个传统项目经理，我曾总是要了解谁在做什么任务，他们的依赖是什么，以及任务能否按时完成。我花了无数的时间，就一直在问这些问题，随后得到答案并试图努力满足范围 / 进度 / 预算 / 质量约束，再把进展情况（有时使用挣值）向上汇报。在敏捷环境中，我不得不学着信任团队成员，让他们来识别和执行完成每个 sprint 范围所需的任务。这一开始很困难，但我很快意识到团队能够胜任。 现在我的大部分时间都花在支持团队成员工作上，处理他们遇到的阻碍，置身事外提醒他们矫正工作重点。

为什么要变头衔？

对于项目经理而言，如果可以成为团队的 ScrumMaster 或是 product owner，我们又何必要改人家的头衔呢？我们来看看 _ScrumMaster_ 这个术语。多年以前，当我刚开始做 Scrum 项目时，根本没有 _ScrumMaster_ 这个术语，我也根本没有意识到除了项目经理还能叫这个角色什么。这没什么。但是，我要给这个角色招几个新人；我很清楚我期望这些新人该怎样和他们的团队合作。我没要那些刚愎自用型、命令－控制型的人。同时，这些新的项目经理向我汇报，也就允许我有更多的机会感染他们，让他们懂得如何和自己的团队相互配合。叫他们项目经理也还行。

随着我们公司不断的发展壮大，我们开始并购其它公司。在这些公司中，我得接管一些对项目经理一职有着非常传统认识的项目经理。我面临的是帮助他们转化理念以便和敏捷开发更协调。我发现这比雇佣有合作精神的、适合自组织团队的项目经理难多了。

多年后在和 Ken Schwaber 的一次交谈中，他帮我理解了为什么对有传统背景的项目经理的指导要比我想象中的更难。Schwaber 提醒我，允许项目经理保留他们的头衔，就意味着我允许他们认为改变可以打折扣。他在 1997 年创造 _ScrumMaster_ 这个词，在某种程度上说，就是为了要提醒每个人这个角色绝不只是个增减了几项额外职责的项目经理。Schwaber 告诉我，“这个词是 Scrum 的变种。这些词常常故意被造得很丑——burndown，backlog，ScrumMaster——因为它们在提醒我们，改变正在发生。”

尽管我这么建议，你也不一定就要排斥项目经理这个头衔。如果你或者你的组织对这个词情有独钟，就接着用它好了。但别忘了 Ken Schwaber 的忠告，还有我用这个旧词的经历，它可能会减缓或阻碍新方法的采用。保留旧的头衔阻碍用新的方式思考。更有甚者，如果大家连像旧头衔一样毫无意义的东西都不愿意放弃，他们很可能也不愿意做采用 Scrum 所需的更多更难的改变。

架构师

许多架构师工作了很多年才得到这个令人敬畏的头衔架构师。他们理应为他们能够对技术和行业挑战提出最佳解决方案的知识功底、经验和能力而骄傲。我发现，在面临采用 Scrum 时，架构师们提出的诸多担忧大致可以分为以下两类：

• 大家还会按着我告诉他们的架构执行吗？
• 要是没有事先的架构阶段，我怎么能够保证我们构建一个架构上完善的产品呢？

对第一个担忧的答案完全取决与架构师自身。许多架构师可能会发现他们的工作变化很小。很多架构师推荐的解决方案能够被实施是因为其他开发人员尊敬他们并知道他们的意见可能较好。例如，如果我的一个同事因为以前做过明智的架构决定而名声在外，我又注意到他在这个项目中做了不错的架构判断，在遇到架构问题时，我就会更倾向于去请教他。纵然我们在自组织团队中，我还是会那么做，没人逼我在我的决定上有第二种选择。

第二个担忧多半是庸人自扰。产品的架构需求和商业目标一起用于决定产品 backlog 里任务的优先级。这使得架构师可以把精力和时间更多的放在应用程序架构的变化上。对一个架构上结构复杂或有风险性的产品，架构师要和 product owner 紧密合作，告诉 product owner 产品 backlog 中的项目对架构的影响。所有的 product owner 都知道他们应该聆听来自市场部、用户或客户的声音，作为产品决策的输入。优秀的 product owner 同样懂得请教技术团队关于优先级的意见。尽管 product owner 是最终决策人，优秀的 product owner 在给工作排优先级时还是会考虑各方的意见。

AgileArchitect.org 的 Andrew Johnston 写到，“在敏捷开发中，当其他开发人员都在关注下一个发布时，架构师的主要职责是考虑变化和复杂性。”Sprint 中明智的工作顺序可以帮助团队更快获得关键知识，有足够的时间避免或发现风险并予以补救，从而实现开发的总成本最小化。

不编码的架构师

不编码的架构师可能会发现他们的工作变化最大。他们就是 Scott Ambler 口中“象牙塔里的架构师”。一点都不编码架构师的存在本身就是个臭名昭著的麻烦预兆；Scrum 项目很好地避免了这些。一些不编码的架构师把 Scrum 当成了一个契机，他们可以重拾在他们早期职业生涯中所热衷的编码。这样的架构师是受 Scrum 团队欢迎的有帮助的人。他们将因渊博的知识和丰富的经验、以及卷起袖子投身代码的热忱而受到尊敬。

要小心那些抵制角色转化、不想为项目做出贡献的架构师。很多情况下，不编码的架构师把他们的职业方向定做了一条从此洗手不编码的路。一个这样的架构师，Tom，让我第一次见到他的时候倍感困惑。他在谈论一个不错的游戏，听起来他对其中的技术都很在行。但是，他是我认识的第一个喜欢开会的开发人员。他总是希望安排更多的会议。随着我对 Tom 更加了解，我发现他对技术知识十分肤浅——他并不像我想象中那么优秀。我很快认识到他希望团队多花时间开会的原因： 在不必要的会议中，所有参与者的生产率和价值都是相等的。当团队成员回到自己的位子上开始做真正的工作时，开发人员之间的惊人差异就显而易见了。Tom 对不必要会议的热衷是一种自卫本能——团队在会议中花得时间越多，大家认识到 Tom 其实不够优秀所需要的时间就越长。

要成为一个有价值的贡献者，名片上印着架构师的人也不一定要全职编码。事实上，架构师在一两个 sprint 不产出任何代码也是很有可能的。我想说的是那些能编码的架构师和编码能力较弱的架构师之间的区别。软件架构师 Johannes Brodwall 说，“对与架构师这一角色来说，形式上最大的变化是，架构师再也没权力主宰技术解决方案了。取而代之地，架构师要成为一个指导老师和服务者。作为指导老师，我能够将提供建议这项工作做得更好。”

职能经理

在 Scrum 项目中，职能经理，像开发经理、QA 主管等，这些以前在矩阵组织结构下工作的人，将继续那样的工作方式。有些职能经理的权力可能会在转变后稍有减少，但这主要取决于转变前组织对这个角色的定义。

职能经理通常会保留分派人员到各项目的职责。他们被要求继续根据所有项目的竞争需要、项目地点、个人发展要求和职业志向等等做相应安排。在一些组织中，职能经理通常不仅安排人到项目中，还会涉及他们组内一些任务的安排。转变到 Scrum 后，他们就再也不能做这些了。自主选择工作是团队成员自组织的一个重要体现，必须留给团队。

职能经理的领导作用

职能经理总是领导。多年来广义的领导趋势已经影响了个人的风格。例如，在我的成长过程中，我父亲曾管理西尔斯商店。那个时代西尔斯是全球最大的零售商。我父亲的管理风格是非常自上而下、组织严密的那种。他会建立目标、定额及其他衡量标准；去和雇员们讨论；随后用这些目标去衡量每个雇员。那同样是一个以智慧为主流、优秀的经理可以管理一切的时代。我父亲大概可以用他管理零售商店的经验，以相同的技能去管理一个银行或者生产运营。我的父亲应该落在图表 8.1 中的左 - 下象限，这一图表源于 Jeffrey Liker 所著的 _The Toyota Way_ 。

不同的职能经理类型是视专业知识技能和领导风格的类型而定的。改编自 Jeffrey Liker 所著的 _The Toyota Way_，版权为 The McGraw-Hill Companies, Inc. 所有。

一个不同类型的经理，或者可能和我父亲工作在不同时代的经理，可能应用的是自底向上型的综合管理技能。这样的经理可能会落在图表 8.1 的左 - 上象限。在图表右下象限，我们看到的是一个对工作有深刻理解且自上而下型的经理。这种经理——在软件项目中很常见——能告诉同时他的团队做什么和怎么做。

在使用 Scrum 的组织中，职能经理应该落在右 - 上象限，他们具备了对工作的深刻理解和自底向上的风格。一个职能经理的职责是为团队成员提供指导和教导。ScrumMaster 和 product owner 也要提供指导和训练，但他们的视角仅限于单一的项目或产品。职能经理则有更广阔的视角，包括建立跨项目的标准以及为质量、维护性、重用性和很多其他特性或非功能性需求设定期望值的能力。

职能经理同样保留了团队成员建设的职责。根据预算和时间安排他们参加一些会议，用适当的项目给他们以挑战，以及鼓励他们参与或组织实践社团，都是职能经理的职责所在。

员工职责

多数组织中，职能经理将保留为他部门员工做定期考核的职责。尽管理想中职能经理总是参考每个员工的搭档以及客户的意见做考核，在 Scrum 环境中更需要这么做，因为员工可能无法在日常工作中和职能经理紧密合作。

在许多组织中，职能经理还保留了决定聘用或解雇的职责。在产品开发团队中，ScrumMaster 和 product owner 对个人都没有这个级别的权力。

在组织采用了 Scrum 后，多数职能经理都发现他们自己的可用时间比以前多了。这些时间通常会被用在和他们下属保持密切联系，来了解组内成员所服务的每个项目的更多情况（通过参加各式各样的 sprint 评审等），从而可以花更多精力在制订跨项目的标准和未来方向上。

程序员

在 Scrum 项目中，程序员做什么呢？他们编程。他们测试。他们分析。他们设计。他们做对团队完成 sprint 要提交的工作有帮助的任何事。尽管在 Scrum 团队中可以有专家，专家仍要在团队需要的时候做他专业以外的工作。也有例外。例如，一个游戏开发项目可能受益于人工智能编程的专家。由于他们产品的高度专业化的特性，这个专家可能对他专业外的工作一点都不做。但是，Scrum 项目的大多数程序员还是要乐于用多种方式来为项目出力，从而优化整个团队的生产能力。这就意味着他们要在需要的时候做测试，有时要用非熟练语言编程等。

在 Scrum 项目中，对程序员最显著的变化之一是他们再也不能做在自己的位子上，等着被告知具体要编写些什么了。他们要积极参与产品需求的理解。令人惊讶的是，有很多人就是想要别人告诉他该做什么。我听到的表达是“如果他们告诉我要做什么，我做了，于是我就不会被解雇了。”Scrum 团队的程序员——像团队中的其他角色一样——被期望担负起整个产品成功的责任。当充分体会到这份责任，承担一些常规工作以外的任务也就变得很平常了。

程序员也被期望参与与客户和用户的讨论中去。数量可以根据程序员、组织、其他团队成员的能力以及项目的性质做上下调整。程序员不需要发展合群的性格，也不用成为故作热情的销售员。但他们确实需要偶尔和用户或客户轻松地聊一下，哪怕只是通过电话。

相似地，程序员最好能多花点儿时间和同事合作。一个程序员不可能被允许 11 点上班，戴一天耳机直到晚上 7 点悄然离开。相反，程序员应该坐在一个团队的环境中，参与讨论，帮被人解围，还要参与结对编程。

对于许多因为想要在位子上独坐一天才入行的程序员（包括我自己）而言，这些变化足以让人不安了。在我的第一份编程工作之前，我成天工作在一个总共只有 6 英尺乘 4 英尺的小黑屋里处理照片。我只在规定好的休息和午餐时间才能出来；否则我就成天呆在黑暗中，独自享受。移到光明世界的位子上是一个巨大改变。从安静的位子移到充满活力的、健谈的文化中，是个更大的改变。Scrum 团队的程序员就被期望做这种转变。尽管幸运的是，对我们大多数人而言，这种转变并不太难。我们可能会喜欢孤独，但我们发现参与一个有组织的会话（像 Scrum 项目中的会议及决议讨论）会比参与一个无组织的、像在鸡尾酒会上的会话容易多了。

除了交流和合作的变化，程序员要几乎毫无疑问地经历他们如何做自己的工作的转变。技术实践如结对编程、测试驱动开发、还有需要特别强调的自动化单元测试，对与他们而言可能都是新东西。团队可能在最初不会选择采用所有这些实践（有些时候也许一直不），但我建议好好考虑一下这些实践，并且试着做一下。

数据库管理员

数据专家，不管他们的头衔是数据库管理员、数据库工程师或其他什么，可能是最排斥采用 Scrum 的一群人。在前面章节提到的对程序员的很多东西，对数据库管理员也适用。另外，数据专家还将面临学习怎样做增量式任务，这在传统意义上被认为是项目前期工作的一部分。

在数据库设计中，标准的意见是对系统的需求做全面分析，建立逻辑的或概念的数据库设计，随后在物理数据库设计时将概念对应到现实的数据库约束上。这一连串步骤的成功是建立在一个前期完全准确的分析的基础上的。对于传统数据专家的观点的最佳概括来自于我从芝加哥到萨克拉曼多的飞机上遇到的一个同路人。他是为一个大型的、与卫生保健相关的公司做数据库开发的第二负责人。他对这一领域的认识是“应用程序在变；但数据是永恒的。”

这种思维方式导致前期注重做全面分析的极端行为。这种理论上没问题，但当我们讨论做这个全面分析所需的时间时，世界早已不断前进了。用户的需求在变。竞争对手在发布他们的产品。数据库需要进化以支持建立在它之上的应用软件的进化。

在许多方面，用户体验设计、架构和数据库设计都是面临相同挑战的特殊例子：从事某些增量式的、需要全盘考虑的工作。DBA 的很多日常工作并不是惊天动地的改变，而是 DBA 怎样着手处理和计划那些工作，那些工作将是备受关注的改变，在书中本章的“在整个 Sprint 一起工作”部分有做讨论。

测试人员

多年以来，对测试的普遍方式都是基于 Philip Crosby 的质量定义：和需求一致。如果质量是和需求一致，那么需求最好要写下来。这使得许多测试人员过分热衷于弄一份完美的需求文档，这样他们就能根据它来验证系统的一致性。 然而，就算和需求一致再好，和用户的需要一致才是更好。用 Scrum，我们承认，完美地满足所有的用户需求是不可能的。

就像程序员永远不能说，“给我份完美的说明书；随后在我开发系统，来准确地满足你要求的东西时别来烦我，”测试人员也不能说，“给我份完美的需求文档，随后我会保证系统能做到里面的一切。”每种态度（而在传统形式管理的项目中，它们都很盛行）都会导致推卸责任。当这类的声明一出口，说这些的程序员或测试人员就是在放弃对项目最终成功的责任。“就告诉我做什么，我会去做，”每个人都会说。取而代之，每个人都应该考虑产品，对每个功能提提问，弄清楚在整个产品中它是怎样增加（或去掉）的。

由于 Scrum 团队将需求收集期间的重心从写转到了讨论，和 product owner 的会话成为了测试人员找出一个新功能应该如何呈现的主要途径。测试人员可能和 product owner 讨论关于一个功能如何工作，它的性能要多快，必须通过怎样的验收准则等等。测试人员也不仅仅限于从 product owner 那里获得信息。如果有合适的机会，测试人员也要和用户、客户及其他利害关系人做交流。

和程序员一样，在这样的交互环境中工作可能让那些转到 Scrum 来的测试人员有些不舒服。许多测试人员，像他们的同事一样，是怀着自己能坐在位子上、每天少和别人打交道的期许进入软件开发行业的。没别的。Scrum 团队的测试人员要对和自己的同事进行频繁的、有意义的会话习以为常，并且在很多情况下，还要和团队外部的人交流。

除了放弃可以预先写好完美的说明书这一神话，测试人员要面临的一个最大变化是学习怎样迭代式工作。概念上讲这不是什么难事。如果我们把每个 sprint 都当成是项目，针对每个项目 /sprint 的测试都会在每个 sprint 完成。这并不像看上去那么简单，好像每个 sprint 的最后一周应该是留作测试的。在每个 sprint 里做个微型瀑布模型是行不通的。在早期的几个 sprint 中，测试人员会面临巨大的挑战。在那期间程序员也在学习怎样迭代开发，也很可能并不擅长此道。团队可能过量使用一个 spirnt 要做的任务，而程序员可能直至接近 sprint 结束才全部完成每个计划的功能的编码工作。于是他们会试图在一个 20 天 sprint 的第 18 天才把代码交给测试人员。等每个角色都学会了如何用敏捷的方式工作，这种最后一刻的传递会消失。

对测试自动化的特别强调成了 Scrum 团队的一个特征。甚至那些已为在自动化测试上有所进步而奋斗多年的团队都发现，Scrum 的短周期 sprint 使自动化测试不可或缺。随着时间的推移，对手工测试人员的依赖在削减，现在只要读脚本，按下按钮，然后记录结果就好了。测试人员常常会被要求学习团队使用的一种或多种测试自动化工具。尽管有些自动化测试工具也要依赖于编码来建立测试，但不是所有的。我见过不只几个手工测试人员，他们没能成功转型，从而为团队的自动化测试工作做出有效的贡献。换句话说，我见到过很多害怕这种改变的人。时间、实践、培训和结对（包括和程序员的）应该足以克服这些恐惧了。

Lisa Crispin，与 Janet Gregory 合著的 _Agile Testing_ 一书的作者，回忆起她转到敏捷团队工作的时候，她提起的第一件事就是她需要积极主动。

别坐着等事情来找你。主动点！我们测试人员不能等测试任务来找我们。我们要站起来，参与进去，找出要做的事。和程序员合作对很多测试人员来说都是新的尝试。（尽管对我不是，我总是在每个项目开始时插上一脚，不管进度如何。）和客户合作对很多测试人员来说同样是新的尝试。对很多人来说，这是走出温室的一条路。程序员是大忙人，有时还有点恐怖。当我是一个有八名程序员的团队里的唯一的测试人员的时候，即使他们中的大多数都和我在另一家公司共事了好几年了，要提出帮助请求还是需要很大的勇气。

如果我和团队中的其他人工作太紧密，我会发展成‘程序员视角’，这使得我从他们的角度去看待每件事，而不是从测试人员的角度。 很难想象和程序员工作太过紧密会导致测试人员丧失立场从而再也无法测试软件。数据库专家和程序员一起共事多年，却也没被污染啊。十年间，测试人员提倡要同时做白盒测试（可以看到系统内部）和黑盒测试（看不到系统内部）。如果和程序员一起工作会导致发展成“程序员视角”貌似也有理由相信做白盒测试的测试人员也会相类似地失去立场，不能在做黑盒测试了。 值得庆幸的是，情况并非如此。

尽管 Scrum 带来的很多变化会在一开始让人不舒服，大多数测试人员还是在习惯了之后很享受他们的新工作方式。Jyri Partanen 是一个 Sulake 的 QA 经理，Sulake 的开发人员，一个平均每月有超过 8 百万不重复用户访问的虚拟世界。Partanen 描述了测试人员所要做的转变。

测试是在旧的习惯中排在最后的职业。就向敏捷的转变来说，抱着旧的做事方式可能会导致对敏捷精神不能彻底实施。通常测试工程师的苦恼是源于对工作保障的担心和敏捷转变的来临会给他们的日常工作带来的变化。然而，这是不必要的担心。基于我自己的经验和其他一些事实上已经完成到敏捷 QA 角色转变的人的经验，我可以很有信心地说这个转变无疑是明智之举。敏捷团队中的测试工程师在开发过程中更有影响力，而且对最终产品甚至更为重要。

用户体验设计师

用户体验设计师（UEDs）对采用 Scrum 通常有一个还算合情合理的担忧。尽管他们习惯于迭代式工作，他们还是倾向在项目其他阶段开始之前进行他们的迭代。但是，在 Scrum 项目中，我们不想在开始做其他开发活动之前先做完所有的 UED 工作。

我最推崇的关于敏捷设计师工作的描述出自 Toronto 的 Autodesk 公司。Lynn Miller 和 Desirée Sy 写文章介绍过关于他们将设计集成到敏捷过程中去的方法。我做过的很多项目中，团队和设计师们都接受了他们的建议。

据 Miller 和 Sy 所说，项目中的工作有两条平行的轨迹：一个是开发，另一个是配合的设计。图表 8.2 描绘了这两条轨迹和它们之间的交互。这里非常重要的理念就是，UED 的工作总是超前于开发工作至少一个 sprint。UED 可以从 sprint 0 开始做起，在 sprint 1 中开发团队做一些跟用户界面实现无关或者基本无关的功能，UED 就可以为下一个 sprint 做准备了。

这里提出的方法是可行的，但也带来了让用户体验设计师觉得自己各自为政的风险。Lynn Miller 起草了这个图表的第一版，也同意这并不意味着有单独的团队存在。

不论我在哪里讲述这个概念，我总是强调，设计师不能把自己当成分立的团队，紧密且频繁的交流是让这一概念生效的必要方法。这可能永远都是这个图表的缺陷，它看起来像是建议要各自独立，但那却不是我的本意。

UED 和项目开发可以并行进行。（引用自 Lynn Miller）

用户体验设计师把自己当成团队的成员是非常重要的。多职能团队的理念是 Scrum 的基本原则；团队要包含每个所需的人才，这样才能成功交付。怎么能够预防测试团队误入各自为政呢？图表 8.2 也显示了编码和测试的 sprint 平行轨迹

如果我在公司的走廊里碰到一个用户体验设计师，我问，“你在干嘛？”我可能会得到这样的回答：“我是个用户体验设计师。我的工作要比开发人员超前一个 sprint。我的工作是要确保当他们要开始一个 sprint 时，我能够给他们这个 sprint 要开发的东西的设计。”这个回答和图表 8.2 的一致，但这不是我喜欢的答案。其实我想听到，“我是个用户体验设计师。我在开发团队工作，我的主要工作是确保我们能为 sprint 交付完成所需的任何工作。但那占不了我的全部时间，所以我可以花很多时间在未来一两个 spirnt 我们要构建的东西上。于是我收集数据，仿制设计，做我所能做的一切，这样当我们开始未来一个 sprint 的功能开发时，我们就能在那个 sprint 里完成它了。”

上面两个假设论述都准确地描述了同样的工作。两种情况下，用户体验设计师都和团队一起工作，在 sprint 中解决当前 sprint 的问题，同时有为下个 sprint 做准备。但是，两个不同的答案体现了两种不同的工作态度。首要的，我想让用户体验设计师感到他是团队的一部分，他们最高优先级的任务是为当前 sprint 所要交付成果的发布。除此之外，他们的工作才是前瞻，就像 product owner 要预测到竞争者们在做什么，用户接下来想要什么等。

对于用户体验设计师来说，敏捷理念是完成 Scrum 转化的关键。持有这个观点的，并不是只有我一个。备受尊敬的可用性专家 Jakob Nielsen 表示赞同。

对于为敏捷团队服务的用户体验从业者而言，主要的转变是理念。拥有优秀的、全面的用户体验知识可以帮助你理解如何转变传统设计和评估方法从而满足敏捷团队的不同的关注点。但是最终，如果你想获得成果的话，就必须发自内心相信并接受敏捷开发的概念。如果你准备好了改变你的实践方式并承担责任，那里会有很多改进你的效率和你对所服务团队的影响力的绝好机会。

三个共同的主旨

在本文中，我涉及了分析师、项目经理、架构师、职能经理、程序员、数据库管理员、测试人员以及用户体验设计师这些角色的转变。在此，有三个主旨要重申

• 增量式工作。总是力求在 sprint 生产一个潜在可交付的产品增量。
• 迭代式工作。功能模块可以在后续的 sprint 中被重新考虑。
• 不拘泥于专业工作。为了在 sprint 末完成潜在可交付的东西，个人有时需要乐于不拘泥自己专业工作

当你不断前进，你会发现牢记这些主旨，把它们当作今后为 Scrum 团队工作的指南，将对你很有帮助。

作者简介

Mike Cohn 是 Mountain Goat 软件 (

http://www.mountaingoatsoftware.com ) 的创始人，那是他教授和指导 Scrum 和敏捷开发的平台。他还是《

Agile Estimating and Planning》，《

User Stories Applied for Agile Software Development》以及《

Succeeding with Agile: Software Development with Scrum》的作者。在 25 年多的工作生涯中，从起步到 Fortune 40，Mike 曾做过不同规模的公司的技术主管。作为 Scrum 联盟和敏捷联盟的创办会员，Mike 还是个活跃的杂志撰稿人和会议演讲者。可以通过他的站点

http://www.mountaingoatsoftware.com 联络他。

本文摘自 Mike Cohn 的新书《Succeeding with Agile: Software Development Using Scrum》，此书由 Addison-Wesley Professional 于 2009 年 11 月发行，编号为 ISBN 0321579364，版权所有 Mike Cohn。完整目录请见： www.informit.com/title/0321579364

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。