本文是英文blog玩转翻译的第一篇，后续会间歇进行这类优质英文blog的玩转翻译活动，纯玩转，个人发挥，请持续关注，多多支持。
对Scrum不熟悉的小伙伴，建议先去阅读我写的 按图索骥，探视Scrum框架 一文，了解一些基础的背景知识，然后再来阅读本文，否则肯定不知所云。英文bolg原文链接如下：
Five Questions Scrum Master Should Be Able to Answer
Scrum指南告诉我们实践敏捷应该做什么但却没有指明具体原因。而且，Scrum指南没有告诉我们实践敏捷不应该做什么。作为敏捷教练，Scrum团队和项目相关方会经常问我们一些颇具挑战性的问题。如果我们只是简单地依照Scrum指南，进行泛泛地解释说明，可能根本无法满足提问者的关切，也显得缺乏独立深刻的思考。本文选取Scrum实践过程中5个常见且具挑战性的问题进行深入分析，以期抛砖引玉，得到更多有深度和广度的创造性见解。
1. 为什么我们所有人要参加冲刺规划会？
这个问题问的好，很有道理。传统的瀑布式项目管理，一般都是项目经理先征求关键项目相关方和开发团队骨干的意见，然后独自去制定项目计划。那么问题来了，为什么之前1个人做的事情现在我们需要10个人去做哪？这难道不是人员浪费吗？我们参照Scrum指南对冲刺规划会的时长限制，一个月的冲刺最多8个小时。我们假设团队有8个开发工程师，那么每个月花在冲刺规划会的额外投入就是64个人时，这64个人时本来是可以用于完成实际的编码和测试工作的。
我之前的Scrum团队最初也是觉得冲刺规划会存粹是浪费时间，不如用来写代码更有价值。所以每次的冲刺规划会，我和产品负责人都是尽可能快地过我们的产品列表条目，尽量压缩规划会的时长。几周之后，在我们的冲刺回顾会上，开发团队向我反馈，他们希望在写代码之前能够投入更多的时间去更好地理解用户故事，了解需求细节。我立即对冲刺规划会做出部分改进，恢复规划会的合理时长，和产品负责人讨论如何更清晰地、细致地介绍每个用户故事，鼓励开发团队提问以便我们更好的去讨论、澄清用户故事的unclear点。实践证明，认真对待冲刺规划会不但不会浪费编码时间，反而可以提高冲刺速率。
我之前团队所采取的改进方法是有理论支撑的。Scrum指南就明确指出，Scrum团队可以利用冲刺规划会去澄清和精炼待办的产品列表条目，从而增加对用户故事的理解，增强完成任务的信心。
我们要求Scrum团队全员参加冲刺规划会，还有一个更深层次地考虑，那就是冲刺规划会可以帮助Scrum团队了解他们为什么要去实现这个用户故事，这个用户故事有什么价值和意义。相比被动地被告知要实现什么需求，冲刺规划会有助于Scrum团队参与需求讨论，方案设计，搞清楚用户故事的前世今生和来龙去脉，这将极大地激励团队，增强团队的自主性和主动性。每次的冲刺规划会，我们的首要任务是确定冲刺目标。Jeff Sutherland在他2014年出版的新书 SCRUM-The Art of Doing Twice the Work in Half the Time 中指出，卓越的Scrum团队都谋求达成共同目标，而且一旦达成，就会自发地遵守团队目标高于个人目标的基本准绳。他还指出当团队达成共同目标之后，这个看起来很小的团队，就会变得充满魔力。这是质的飞跃，效率会提高，质量会提升，协作会更流畅，工作满意度也会更高。之前更多的项目情况是编码任务被外包或分配给几个开发工程师，而这些工程师根本不清楚他们要开发什么，为什么开发，他们带着太多的困惑去猜测着写代码。这种团队的结果输出可想而知，跟卓越Scrum团队的成果输出比起来绝对相差十万八千里。我们冲刺规划会设定的冲刺目标就是用来回答为什么要开发的问题，这个冲刺目标对Scrum团队有极大的鼓舞和鞭策作用。
2. 为什么我们要组织冲刺回顾会？
跟对冲刺规划会的看法类似，不少开发工程师认为3个小时的冲刺回顾会意义不大，用来编码和测试更好。
二战之后，日本的持续改善思想 Kaizen 在制造业被广泛应用，取得良好的实践效果。这种理论提倡对企业当前已有的流程进行小的、连续的、渐进的改进来提高产品的交付质量和生产率，而不是设计新的流程和规范。
Kaizen思想对敏捷的原则和实践有深刻的影响。敏捷宣言 中有一句话是这样描述的,"团队定期地反思如何能提高成效，并依此调整自身的行为表现"。
Scrum的三大支柱是透明、检视和适应。因此，Scrum团队应该对所做之事保持开放和坦诚的态度。经常去讨论和反思如何改进，如何能做的更好，并采取具体措施去优化流程和实践。这么做，其实就是在实践冲刺回顾。
在我作为传统项目经理的时候，每到项目收尾阶段，我都会非常勤勉地组织项目团队进行经验教训总结。我们非常认真地收集和汇总50来条改进措施。我们确信这些措施能让我们在新的项目中少走弯路，但遗憾的是，这些经验教训总结被归档到指定资料库后就再无重见天日的机会。坦诚的说，当我要负责一个新项目时，我从来没有去查阅过项目资料库，去看看之前的项目经验教训总结。这个事情，我想都没想过，更别提去做了。
冲刺回顾的性质跟经验教训总结类似，只不过冲刺回顾贯穿整个项目周期，在每个冲刺结束时都会进行，它的有效性碾压经验教训总结会。冲刺回顾会的改进措施会被放入下次的冲刺列表以便采取切实行动改进产品构建过程。
我之前所在的Scrum团队对于组织冲刺回顾会的积极性不高，但是慢慢当他们发现自己的声音被听到，自己所关注的痛点问题也被逐渐解决，他们的态度和看法转变了。有时候我忘记安排回顾会的时候，他们开始主动提醒我。
3. 为什么每个冲刺结束我们都要交付一个潜在可发布产品增量？
你是否遇到过这种场景，在我们进入下一个冲刺的时候，我们却只是继续去完成上个冲刺的未完成任务，而且有时候这些未完成任何很多，导致我们没时间和精力去完成新的用户故事。这种现象在实施敏捷的团队中并不少见，它不仅违背Scrum指南精神，也会导致很多其它问题。
- 速率是每个冲刺完成的工作量。如果某个冲刺什么都没有完成，速率就是0，这对于下个冲刺规划肯定会有负面影响。
- Scrum指南指出，每个冲刺都有好的目标，是一个单独的小项目。
- 团队要在即将到来的截止时间前交付有价值的产品增强，这种目标感对团队有激励作用。
- 在接近发布日期的时候，团队比较有动力，充满能量。如果在冲刺结束的时候没有输出任何价值，士气就会受挫，而且项目风险会增加，进而转向传统的瀑布式开发模式。
每个冲刺结束都交付一个潜在可发布产品增量有几个目的。正如前面提到的，可以激励团队，获得成就感。相关方每次都能体验到实实在在的交付价值，他们也会对项目和团队变得越来越有信心。对于Scrum团队是个学习成长的经历。如果交付的产品增量跟相关方的实际需求有偏差，团队可以在项目早期就做修复和改进工作。避免和减少理解偏差，有助于相关方对后续需求进行更合理的定义和澄清。
4. 为什么产品负责人不同于商业分析师？
这也是一个很好的问题。产品负责人和商业分析师都需要掌握很多关键技能。要对产品功能有较强的理解，知晓产品交付给用户提供的价值，负责需求的收集、整理和实例化，以及识别需求的依赖和矛盾关系。不过二者也有区别，商业分析师更多是一个倾听者的角色，而产品负责人更多是一个决策者的角色。Scrum指南指出“为保证产品负责人取得成功，整个组织必须尊重他们的决定”
根据我的经验，很少有组织给予产品负责人充分的授权去做决策。产品负责人在Scrum团队中的角色大部分情况下还是与商业分析师类似。这种实际情况会导致很多问题，例如在Refinement会和规划会上提出的需求细节问题，产品负责人可能无法做出决策，因为他们没有被授权做类似决策，他们需要会后跟相关方去沟通，然后获得答案。因为产品负责人没被授权，导致几分钟能做出决定的问题可能要花费数天时间才能有最终的结论。
产品负责人的角色对于Scrum的成功实施至关重要。任何做敏捷转型的组织都要给予足够重视，审慎对待。
5. 为什么我们不能提前规划每个冲刺的需求范围？
乍一看，提前规划冲刺内容是可以的而且确实有很多所谓的敏捷团队也是这么做的。 在交付日期前完成固定范围需求的想法是值得高度警惕的，这种计划会对管理团队、终端用户、管理高层和其它关联项目产生一定影响，甚至导致改变。Scrum指南中没有明令禁止这种进度和范围都固定的规划，但也没有说明可以这么做。Scrum指南只是定义了冲刺规划会是一个冲刺中的第一个事件。这个规划事件是针对即将到来的一个冲刺而不是更远的未来冲刺。
提前定义未来冲刺的需求范围会导致问题。这些提前的规划结论会被当作Scrum团队的承诺，进而慢慢作为截止时间并生成一系列交付里程碑。这样我们的所谓敏捷迭代开发就实质上变成了传统的瀑布式开发。
其次，敏捷项目的一大好处在于它能快速响应商业模型、市场和技术的变化。这个快速响应对于项目的范围也同样适用。正如敏捷软件开发宣言里说的，“欢迎需求变更，即便是在开发阶段的后期依然如此”。对于敏捷项目而言，我们更关注的是相关方能验收满足当前需求的产品，而不是一年前或者一年后需求的产品。
因此，如果我们对未来的冲刺进行规划并对相关方做出承诺，会导致什么后果哪？一旦需求发生变化，我们必须要走正式的需求变更流程去评估变更影响和成本。我们无疑又是在实施瀑布式开发而不是敏捷。
毫无疑问，真正的敏捷冲刺应该是一次只规划一个冲刺的开发任务。除此之外的其他多余操作都会消弱团队的敏捷性，把我们带回瀑布式开发方法。
对于团队成员和相关方，我一直心怀感激。感谢他们对我提出挑战，提出困难的问题让我回答。我坚信正是这些问题为我们提供源源不断的动力去深入思考敏捷框架，探索更优的实践方案和措施。
