shinescrum.com

只通过Specification来传递需求。 活动把每个小组（4-5个人）中的2人留在屋子里，其他人到屋子外面等待。在屋子里的人，会得到一张A4纸，上面画着几个比较简单的图形，比如一个十字，2个套着的圆，一个淡蓝色的六边形，等等。要求，留在屋子里的人不能用绘画的方法，只能用文字，描述这些图形的形状、位置、大小、颜色，并写在纸上。写好后转交给等在屋外的对此还一无所知的人，屋外的人在不许有任何语言交流、肢体动作的情况下，根据屋内人所写Specification，画出原来的所有图形。而整个过程被限定在10分钟内完成。 结果是：在参与活动的3个小组中，没有一个小组能画出全部图形，即使画出部分图形，要么位置不对，要么大小不对。 展示了各组的结果后，大家总结经验教训，想想在哪些地方需要改进，之后进行第二轮。当然，图形跟第一轮完全不同，而且又稍微复杂一些。即使大家吸取了前一轮的教训，改进了方法，但结果还不如第一轮的情况。 这个活动其实在让我们感受一个事实：只用文档（或Specification）来传递需求信息，是非常不准确的和容易被误解的。SCRUM（包括其它敏捷方法）提倡用面对面的交流，而不是通过文档交接正是基于此事实。

回顾会议（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百万）。这是一个双赢的局面。有人经常会说：如果甲方不敏捷，我们怎么能敏捷。我想当甲方理解知道敏捷可以给他带来收益或节约成本后，他是乐于签署敏捷合同的。