【ShineScrum分享】敏捷是一场关于适者生存的进化合作伙伴认证资质关注我们

        Ken Schwaber作为Scrum的缔造者之一，与Jeff Sutherland一起倾情撰写的敏捷图书《30天软件开发——告别瀑布拥抱敏捷》，现已由ShineScrum成功翻译出版，并在各大网站出售。近日，ShineScrum又邀请Ken Schwaber参加了图灵社区的访问，下面请见详细访谈内容及Ken Schwaber的精彩回答。

Scrum创始人Ken Schwaber访谈录

图灵社区：你建立Scrum的最初动机是什么？

Schwaber：因为Srum管用。当时我的公司正在忙于交付一个高级产品，这个产品的市场正火，需要有经常性的改动。如果我们采用长开发周期，我的公司就会破产。所以我们设计了Scrum，它让我们涅槃重生。

图灵社区：你觉得在中国推广Scrum有文化障碍吗？

Schwaber：不会比其他文化更困难。一种文化是否能接纳并利用Scrum的关键点在于对可预测性的相信程度。在文化中更理解和接纳可预测性的人会相信他们可以预测未来。他们工作的目的就是通过利用人力和资源让未来变成真正的现实。使用Scrum的人们都曾有这样的看法，像软件开发这样充满复杂性和创造性的工作是毫无预测性可言的。这样的结果很可怕：糟糕的软件，赶不上的进度，浪费的金钱，泄气的工作者。所以他们知道最重要的就是预测什么才是真正的需求，让员工们都认识到这点，然后竭尽所能帮助人们实现这个目标。Scrum之道的核心在于“有可为”，利用机会，避开障碍，敏捷起来。

图灵社区：经常有人会抱怨舍弃瀑布模型的困难重重，你认为有必要把敏捷和瀑布模型结合起来吗？为什么？如果可行的话，如何做到？

Schwaber：这两个模型分别适合于两种极端不同的情况。对于瀑布模型，我们预测我们要建的是什么，怎么制作，建立计划，然后按照进度完成。所有事情的关键都在于界定想要什么的准确性，以及直到产品最终成型前的有效沟通的准确性。如果沟通环节完美无缺，没有改变的需要，这么做是可行的。Scrum的假设是沟通是有缺陷的，而改变才是永远不变的。在不超过30天的短周期中，人们建立起他们认为最终想要的东西。这在周期的最后会被检查。根据结果与需求的和谐程度，要做出下一个周期的计划。这是一个一直在改变的持续反馈环，根据检查结果和需求变化做出改变。有人曾尝试结合两种方法，结果让人失望，毫无意义。还不如分开的好。

图灵社区：一家公司如何知道Scrum是否适合他们的企业以及他们产品？

Schwaber：Scrum几乎从来不会和某些软件公司的企业文化契合，这些公司因为不适当的瀑布模型而压力山大，他们在过去30年中一直都使用毫无新意的技术。Scrum确实适合某些企业文化，为了年度预测而模仿销售周期，然后年度预测变成了月度预测，然后检查结果，并作出合适的变化。多数公司对给他们开发软件的部门都不甚满意，因为浪费、失败、糟糕的质量屡见不鲜。那些极度绝望或者有真知灼见的人们会努力转移到Scrum上，这是一种更加适宜的方法，它可以反映出这家公司其余部门运作的方式。

图灵社区：在现实开发中，有些公司执着于死板的方法，而不会调整这些方法以适用于他们自身的环境，你对这些公司怎么看？你对他们有什么建议吗？

Schwaber：软件发展之迅速，已经成为了公司是否能存活的关键，这不仅关乎公司运转的方式，也关乎已经被嵌入到他们产品中的软件。那些不进化的企业，不在软件和产品开发中应用敏捷方法的企业，就无法有效竞争并存活下来。我的建议就是，敏捷是一场关于适者生存的进化。

图灵社区： Product owner有很大的责任，有时候，他们会成为整个团队的瓶颈，如何解决这个问题？

Schwaber：这个问题确实存在。所以我们要解决它。要解决这个问题有很多方法，包括为团队增加更多的领域知识。如果团队没有领域知识的话，product owner就不存在，那么我猜测整个开发就会慢下来，直到问题解决。否则就要等发布糟糕产品，丢人现眼之后再解决了。

图灵社区：番茄工作法是提高个体效率的方法，可以在Scrum中使用番茄工作法吗？

Schwaber：如果你愿意的话，Scrum是一种可以内嵌番茄工作法的框架。但是，不加调整地盲目应用任何技术都是有害的。

图灵社区：如何控制和管理技术负债？

Schwaber：在你写每条功能的时候，都要假设你后半辈子要一直维护和提升这个功能。就算你要上手一条烂到骨子里的老程序的时候，也要这么做。否则，那部分用来维护和支持老产品的开发预算就会吞噬所有要花在新工作上的费用。

图灵社区：你认为敏捷方法过分强调YAGNI（你不会需要它）吗？这样会造成忽视远期目标吗？

Schwaber：敏捷方法并不包含 YAGNI。但是敏捷确实需要清理不需要的东西。比如，为什么要在有记录文档的情况下和别人沟通，而不是直接和他们交谈？无论如何，维护一个产品所需要的文档应该在每个周期都有发展。做有用且需要的事，剔除所有其他。

图灵社区：有人认为敏捷方法现在在走下坡路，你认为为什么会有这样的声音？你的看法呢？

Schwaber：我曾听见有人问，敏捷是一种潮流吗？我认为敏捷是一系列的价值观和原则。而Scrum建立在敏捷之上，Scrum也建立在聚焦，勇气，开放，承诺，和尊重这些价值观之上。价值观不是潮流。在我的想法中，在这些价值观和原则下工作的人们会成为潮流，他们的方法远远超过其他的方法，或潮流。

图灵社区：你怎么看敏捷的派别之争？你认为他们之间有冲突和矛盾吗？他们的不同来自哪里？

Schwaber：敏捷和Scrum是非常非常简单的方法。不同和冲突来自想通过制造工具、方法，以及创造基于敏捷理念的新方法而赚钱的机构。一旦金钱进入了等式的一端，冲突就会发生。这些冲突并不是非发生不可的。用你的眼睛选择对你来说有用的方法。试验，并持续改进。

世界级Scrum认证大师

Jens Ostergaard秦风3月来华授课

客户证言

这两天参加Jens’s CSM认证班，感受挺多。资深讲师Jens Ostergaard经验丰富，活泼风趣。虽然我感觉内容还是比较基础，对于已经有几年Scrum实施经验的人来讲，较为浅显，但在授课中间穿插的一些练习活动，感觉还是挺有收获的。下面举2个例子。

1. 只通过Specification来传递需求。

活动把每个小组（4-5个人）中的2人留在屋子里，其他人到屋子外面等待。在屋子里的人，会得到一张A4纸，上面画着几个比较简单的图形，比如一个十字，2个套着的圆，一个淡蓝色的六边形，等等。要求，留在屋子里的人不能用绘画的方法，只能用文字，描述这些图形的形状、位置、大小、颜色，并写在纸上。写好后转交给等在屋外的对此还一无所知的人，屋外的人在不许有任何语言交流、肢体动作的情况下，根据屋内人所写Specification，画出原来的所有图形。而整个过程被限定在10分钟内完成。

结果是：在参与活动的3个小组中，没有一个小组能画出全部图形，即使画出部分图形，要么位置不对，要么大小不对。

展示了各组的结果后，大家总结经验教训，想想在哪些地方需要改进，之后进行第二轮。当然，图形跟第一轮完全不同，而且又稍微复杂一些。即使大家吸取了前一轮的教训，改进了方法，但结果还不如第一轮的情况。

这个活动其实在让我们感受一个事实：只用文档（或Specification）来传递需求信息，是非常不准确的和容易被误解的。Scrum（包括其它敏捷方法）提倡用面对面的交流，而不是通过文档交接正是基于此事实。

2. 回顾会议（Retrospective meeting）

今天是培训的第二天，早上一开始，就讲到Sprint Retrospective Meeting，作为一个练习活动，所有的组被要求回顾昨天一天的培训中，哪些地方做得好，哪些不太好可以更好一点，可以试着做哪些改进，哪些事情正在恶化而无法控制。我想说说我们组的情况，我们组5个人中有一个韩国人，她不懂中文，只能用英文交流。同时我们组中还有一个人，英语听说又不是太好。所以在昨天的培训中，我们大部分的时间，大部分的讨论交流，都是用中文，所以忽略和冷落了那位韩国女士，这是我们组公认做得不太好的地方，也正是可是试着改进的地方。

使我感受最深的事情发生我们做了这些回顾之后，讲师Jens走到我们组的桌子前，问我们：“你们准备如何改进？”，我说：“我们可以尽量使用英语交流，我们3个英语还可以的人可以为他们做翻译。”Jens又问所有人：“还有其它办法么？”忽然有个人说，那个英语不太好的人可以换一个组。Jens马上问那个人：“你是否愿意换一个组？”，那个人说是。于是他换到了另一个组。

从这个事情我感受到，Scrum回顾会议的实用性，它使团队认识到我们有哪些不足，有哪些可改进的地方，并立即可以采取行动。这就是活脱脱一个现实的Scrum，语言障碍正减低着我们的生产率（Velocity），用翻译的方法是一种改进，但它仍然较低效。但那人换组之后，我们的团队生产率马上得到了大幅提高（在后面做练习活动时全体组员可以全部用一种语言交流，没有人被落下，也没有翻译的冗赘环节），而且那个人换到另一组，在活动时可以完全用中文交流，对他来说也是种“解脱”。通过此例也可以看出（对于认识Scrum很重要的一点）：Scrum不一定能解决所有问题，但它可以通过持续改进，使我们可以做得越来越好。

另外，Jens在讲到敏捷合同的时候，举了个对比传统合同和敏捷合同的例子，我觉得不错，可能对那些没有使用敏捷合同但使用敏捷方法开发的公司有用。例子是这样的：

对于很多传统合同的签署，情况往往是这样的：客户给出的价格是固定的，比如是5百万，但随着不断地改变需求，造成项目的代价是8百万，而且还可能要不断地修复Bug和完成那些之前并没有真正完成的功能，最终成本是1千万。

而敏捷合同的类似这样的：

– 乙方保证交付高质量的、真正完成的功能给甲方。

– 增加2个规则以适应变化：

1. 优先级的改变免费。

2. 可以免费增加新功能，如果等量的其它工作被同时移除。

– 甲方可是随时终止（Abort）合同，终止时，乙方从剩下合同额中返还一部分给甲方。

这样的合同体现了2件事情：即Change for Free和Money for Nothing。

Change for Free：当总量不变，增减需求是免费的，这对客户是个好事情。

Money for Nothing：当客户在任何时刻认为，所有优先级相对较高的功能都开发完成，剩下的那些没有价值或价值较小的功能不再需要时，可以终止合同。终止时客户可以拿回部分（比如80%）剩下的钱（现有使用传统合同的企业，要先从IT公司拿回钱简直是天方夜谭），同时提供产品的甲方也可以拿到另外的20%，而没有任何成本，即所谓的Money for Nothing。比如：总合同额为1千5百万，当投资回报率（ROI）降到1/3时终止（也就是用掉5百万后），甲方可以拿回剩下1千万的80%（也就是8百万），乙方可以也可以拿到20%（即2百万）。这是一个双赢的局面。有人经常会说：如果甲方不敏捷，我们怎么能敏捷。我想当甲方理解知道敏捷可以给他带来收益或节约成本后，他是乐于签署敏捷合同的。