我曾经应聘过一个SCRUM Master的职位，面试官问我这样一个问题：“在一个Sprint进行中，如果用户想改变某个正在这个Sprint中实现的User Story，你觉得应不应该改变它？”SCRUM的规定在我脑海中明明白白的印着：“在Sprint里不许改变任何任务，团队在第一天承诺一系列工作，然后期望它们在整个Sprint保持不变。”
我照本宣科地叙述了SCRUM的这个规定，面试官跟着下一个问题来了：“你如果不改变，那么2周以后，当Sprint结束以后，你会发现你这些日子所做的工作完全是徒劳，因为用户有可能已经完全期望一种完全相反的结果。你怎么办？”这个问题问得我有些措手不及，我们原来公司，这种事情都由Product Owner来斟酌，我还真没有考虑过这样的情况。我于是敷衍着：“考虑到这样的风险，如果必要，我们也会考虑根据用户的要求而改变。”
随着这些未加深思熟虑的话脱口而出，面试官狡黠地抛出了他的第三个问题：“如果你改变了，当Sprint结束时，用户的需求又变回原样了，你怎么办？”
显然，我掉进了面试官设下的陷阱。应试者应该琢磨面试官的每一个问题背后深层的东西，想想他到底想考察你什么。说到面试的经验，觉得有点跑题了，让我们回到正题。这无疑又是一个SCRUM节外生枝的问题。尽管当时通过了这轮面试，但是这一系列问题深深地印在我的脑海里。事后我一直在思考这个问题，但也一直未得其解，尽管在Sprint里不允许有变，但是外部世界无时无刻不在发生着变化，我在“可变”和“不可变”之间不停游走。
从Mike Cohn的《Scrum敏捷软件开发》中，我找到了答案。他从另一个角度看待这个问题，我摘抄了其中一段话。
“我常常建议Scrum团队首先要对Sprint当中的变化采用强硬立场。这不是因为我反对改变团队的目标或我要机械地遵守某个Scrum规定，而是因为我想帮助团队外面的人认识到改变团队目标带来的成本。当然，有时候在Sprint中间改变团队的目标是必要的。但更多时候，团队目标的改变是因为它太容易变和因为有人事先考虑不周。在我看到企业不再考虑将每个新要求作为Sprint中间变化的要紧事之后，我会缓和这种强硬立场。”
以一种通俗一点的比喻，这段话的意思就是：对孩子要严格要求，从开始就不能惯着他的臭毛病，否则他会养成习惯，到时就不好管教了。团队外面的人不是天生出尔反尔，反复无常，是团队内的人的不坚定养成了他们这种毛病。
所以，有时候，当你深入某一问题不能自拔的时候，跳出来，从外部或者其它角度重新思考和审视它，也许会很快找到答案。
原文链接：http://www.cnblogs.com/wanghui9072229/archive/2011/03/02/1969348.html
