依赖专家但要谨慎
一个普遍的误解是Scrum 团队的每个成员都必须是通才而不是专才——在技术和纪律性上具有同等的水
准。这是不对的。我对之感到吃惊的是世界上每个三明治商店都已经知道如何对待专家，而在软件行业的
我们还在为这个问题苦苦挣扎。
我喜爱的三明治商店是位于加利福利亚Folsom 的Beach Hut Deli。我在那里吃过非常多次午餐才注意到他
们有三种类型的雇员：订餐员（order taker）、三明治厨师（sandwich maker）和流动工（floater）。订餐员
在柜台上工作，写好每个三明治订单然后传递给后台的厨师。厨师在订餐员后面工作，接到订单后就准备
三明治。订餐员和厨师是熟食餐厅的专家。流动工则是多面手——能干两种工作，不过可能没有专家那么
好。这并不是说他们的三明治难吃，而是指他们可能做的比较慢。当我在一家快餐馆做义务工时，我是一
个流动工。我做墨西哥卷饼和夹饼不像厨师Mark 那样快。还有不论什么时候收银机需要新的一卷纸，我
都只得求助经理Nikki，因为我从不记得怎样做。但是，不像Mark 和Nikki，我两项工作都能做。
我怀疑世界上几乎每个三明治店都有一些专家——有人只做烹饪，有人只做柜台。但这些企业也了解拥有
通才的价值。多面手能在午餐拥挤时段帮助三明治店做好平衡：一些人写订单，一些人做三明治。
这对Scrum 团队的启示是我们总要尝试拥有一些多面手。正是多面手让专家们显得更专业。总有这样的团
队，它们需要硬件核心设备驱动程序员、精通Windows 内核的C++程序员、人工智能程序员、性能测试工
程师、生物信息科学家、美工等等。但每次给团队加入一名专家等同于给自己的熟食店加入一名三明治厨
师。在团队中加入太多的专家使得这种可能性提高了：某个人可能要花费太多的时间等待工作传递给自已。
所有工作都一小块一小块的做
习惯于顺序式开发流程的团队习惯于将工作在专职人员之间交接。分析员把工作交给设计者，然后设计者
交给程序员，程序员又交给测试人员。每次这些工作间的传递都包含了一些开销，这些交接的形式包括开
会、读文档、签字等。部分地因为这种开销，工作的交接往往包括了大量的功能。在最纯粹的瀑布式开发
流程中，整个应用程序经常从一个小组交接给另外一个小组。
刚开始接触Scrum 的团队在消除这些交接上往往做的很不够。他们常常做出假设，即程序员在把产品
backlog 的任务转交给测试人员前应该完成了编程。这导致在sprint 开始阶段就有了很长的延误，因为测试
人员在等待第一个产品backlog 的任务交付给他们。在Scrum 项目中，在不同主体间的交付单元应该小于
产品backlog 中的单个项。就是说，尽管总是会有一些工作任务的交接（ 不可能每个人都可以把所有的事
情从头做到尾），但从一个人到下一个人的交接量一般要尽可能的少。
例如，假如团队在开发一个新的电子商务程序。他们选择了做这个用户故事：“作为一个购物者，我可以
根据运输的实际成本选择货物的运输方式，以便于我可以做出最佳决定。”接下来，对此有兴趣的人或者
将参与该功能开发的那些人将展开讨论。假设参与人有产品负责人、业务分析员、测试人员和程序员。最
初的讨论是围绕着隐含于该功能中的常规需求进行——如要支持哪些快递公司（FedEx？DHL？等等），要
支持隔夜运输，还是两天，三天运输等等。
在这些讨论进行过程中，参与的个体就自然地来思考如何开始工作。传统项目中，每个人不管他或她怎么
想的也都能开始（工作交接完后）。但在Scrum 团队中，如何开始是需要在参与该功能开发的人员之间共
同商讨的。例如程序员认为因为某种原因从FedEx 开始更简单。测试人员表示同意。分析员表达了调查
DHL 和了解影响DHL 运输费用因素的打算。分析员的目标是等到程序员和测试人员完成FedEx 任务时能
弄清楚这些信息。
当程序员知道了足够多的东西，并且可以开始编码时，她就开始做了。产品负责人、分析员和测试人员讨
论高层测试。（网站要运送像滑雪板那样任何特殊尺寸的物品吗？）经过讨论，测试人员把高层测试清单
变成一个具体的测试（把这种特殊尺寸、重量的盒子运送到目的地）。测试人员创建测试数据和将测试自
动化。没有程序员的临时交付代码，有些自动化也可能完成。不过完整的自动化测试是需要从程序员那里
拿到早期代码版本的。当测试人员打算写具体的测试时，他应该告知程序员任何她在写代码时可能考虑不
到的测试案例。当程序员和测试人员完成工作时，他们在当前构建版本中加入对计算FedEx 运输费用的支
持，完成自动化测试。这可以用图11.1 来描述。
图11.1 四个团队成员在一个产品backlog任务上一起紧密协作，而不是各干各的。
接下来，程序员和测试人员会合业务分析员，后者希望了解更多的关于计算DHL 运输费用的信息。流程
就被重复，当编程和测试完成时，对DHL 运费计算的支持也加入到了程序。图11.1 的关键因素是团队学
会了在同一时间段什么都做一点的工作方式。而不是先有一个分析阶段（没有程序员和测试人员），接着
是编程阶段、测试阶段。
鼓励团队学习
如果你的团队已经拥抱了团队承诺的理念，减少了对专家的依赖，能够保持一小块一小块的做事情，那么
你的团队已经在团队协作上有了很大的进步。这时多数团队会有一种满足感。请不要这样，仍然还有改善
的机会。要成为一个真正的高效团队，并领会Scrum 带来的所有好处，那么，你的团队一定要主动寻求学
习和分享知识的新方法。
有些学习很自然地就发生了——例如用户告诉产品负责人她期望某个功能应该是怎样的，或者程序员发现
使用某种具体技术不能满足扩展性需求等。有些学习则需要主动的进行。这是我们现在感兴趣的学习。最
高效的团队和他们的领导者在改善学习效率和意义上起着非常积极的作用，而不是被动的等待学习。
确保学习环境
把积极的追求团队学习作为项目的目标，要使团队学习能够发生，以下五个条件是必不可少的：
作者:Mike Cohn
