正文
组织采用敏捷方法有很多原因。一些希望能够激发生产力同时缩短投放市场的时间。其他一些希望获得更成功的产品。还有一些希望采用Scrum来增加开发和业务人员之间的合作，提高质量，或者增加团队成员的工作舒适度。当然，很多组织应用Scrum 是为了达到上面所有的事情。但是，正如运行Scrum能给团队带来的好处类似，这里也会有很多谬论，在这篇文章中，我想梳理关于Scrum的5个误区。
-
误区一：职能经理在Scrum中真的没有用了吗？
我认为这个误区存在是因为太多的经理花了很多时间来做他们不应该做的事情，不管这些是不是与敏捷相关。例如，管理人员经常在将任务分配给个人的级别上工作。 当他们得知这不是他们应该在Scrum中进行的工作时，他们会觉得自己的工作已经被剥夺了。事实上没有任何工作被剥夺，像任务分配之类的工作本来就不应该成为工作的一部分。管理人员应专注于创造团队需要蓬勃发展的环境和文化。 他们的时间不应该花在这些细节上，例如谁将负责哪个任务。
彼得.德鲁克(Peter Drucker)是20世纪著名的管理理论家之一。他以创建目标管理方法而为名，用SMART这5个字母缩写用来指导如何设定目标包括：特定的(Specific)，可度量的(Measurable)，可接受的(Acceptable)，现实的(Realistic)，时间限制的(Time-bound)。德鲁克告诉经理们有5个工作可以作：- 设定目标
- 组织人和工作
- 激励和沟通
- 度量
- 拓展人员潜能
是的，在一些组织中上面一些工作可能被减弱了，但是其他一些像拓展人员潜能变得更加重要。在这些年我在与Scrum和敏捷组织的一起合作中，没有一个决定解雇所有职能经理。确实有一些经理将重心转移到ScrumMaster或者ProductOwner角色上，但是在Scrum中仍然有一些管理的角色。
-
误区二：干系人不能再任何时候提出他想要的变更吗？
不足为奇的是，干系人自己最常相信的是干系人可以在任何他们想要的时候引入变更。开发团队成员明白，在错误的时间引入变更是有代价的。想一下在餐厅你正在考虑晚餐吃什么，你告诉服务员，你想吃鸡肉，接着你马上说，“不，还是来一条鲑鱼吧”。这个时候改变没有任何成本。然而如果你之后改变注意那就有成本了。如果你在厨房开始制作鸡肉的之后告诉服务员你要把鸡肉换成鲑鱼，那就会有浪费服务的成本(餐厅可能还会要你付费)。如果你先吃了一半的鸡肉，然后告诉服务员你要改吃鲑鱼，那么你的花费就更明显了。干系人将变更引入迭代中，就像吃饭的时候从鸡肉变成鲑鱼一样。 如果在正确的时间进行更改，则成本可能很小或没有。 但是，在错误的时间引入，这就有代价了。
应用敏捷不能够消除所有干系人引入变更的成本，然而好的Scrum 团队能够降低这种变更成本无论何时发生变更，通用的做法一般如下：- 短迭代
- 小的产品待办列表
- 尽可能快地完成每个产品待办事项列表项，通常是通过最小化正在同时处理的项的数量。
这并不是说团队不应该欢迎适当的更改。一些干系人要求的变更可能非常重要。但是进行每次更改的好处需要与更改的成本进行评估，而更改的成本并不总是零。
-
误区三：在Scrum团队中任何人都需要成为通才吗？
由于某些原因，在Scrum里面最为广泛的一个误区是每一个团队成员需要能够做任何工作。这种陷阱意味着，如果您聘请了世界上最伟大的Oracle数据库管理员，那么您希望该DBA同时也是出色的JavaScript开发人员。如果在一次迭代中没有太多的JavaScript任务，那么您的JavaScript开发人员应该完全精通安全测试。这是完全错误。Scrum团队不需要每个人都拥有每种技能。相反，Scrum团队需要的是重视那些拥有多种技能的人。
要理解这个误区的问题，可以考虑一家经营良好的高档餐厅作为例子。我在看了很多电视烹饪节目之后明白，这样的餐厅可能会有一个糕点师，他擅长制作糕点、甜点、面包和其他烘焙食品。这听起来像是一个高技能但很专业的角色。厨房里的另一个专业角色是调味师，负责准备酱汁、炖菜和其他类似的东西。在一个运转良好的厨房里，如果糕点师能帮助制作酱料就好了，比如在洋葱突然短缺的时候切一些洋葱。但是糕点师和酱师傅都不能完全胜任对方的工作。
在当今复杂技术的世界中，期望团队成员完全精通团队的所有技能是不现实的。相反，好的Scrum团队学会重视拥有多种技能的团队成员。拥有一些拥有多种技能的团队成员有助于管理工作类型的平衡。也就是说，有时候团队需要更多的测试能力。例如有一两个团队成员，他们可以轮换彼此的工作内容，这是非常有帮助的。你要相信即使只有少数团队成员是真正的专家，并且只擅长一种学科的团队中依然可以实现。 -
误区四：我曾经听说Scrum 团队不能或者不应该有计划？
大多数优秀的Scrum团队都有计划。但是这种计划通常不像传统项目那么明显，因为Scrum团队没有预先计划阶段。相反，好的Scrum团队将计划作为一系列较小的、重复的活动来执行，以确保他们的计划始终反映当前的现实情况。通过这种方式，团队设计计划的方式与开发产品的方式相同:通过检查和调整。对于任何Scrum团队来说，他们的计划都不应该考虑未来，除非是做重要决策的必要条件。但大多数组织和团队都有一个计划，在某种程度上估计接下来会发生什么以及什么时候会发生。事实上，尽管存在这种误解，但Scrum团队更容易制定可靠的计划，因为Scrum团队更早地了解到他们生产软件的速度有多快。
考虑一个具有分析、设计、编码和测试阶段的传统团队。如果幸运的话，该团队可能会将对计划的承诺推迟到设计阶段的末尾。但在那时，这个团队并不知道他们编码和测试的速度有多快——他们还没有做任何这些活动。相比之下，Scrum团队在每次迭代时都要处理整个开发过程。每个迭代都包含一些分析、设计、编码和测试。这让Scrum团队更早地了解到可以多快地将想法转化为新特性。 -
误区五：Scrum团队一直在创建没有架构设计的产品吗？
是时候打破我们的最后一个误区了:Scrum团队不会架构或设计他们的产品。Scrum团队肯定会设计他们的产品。但是，Scrum团队的架构和设计也是和团队计划同样的增量方式进行的。这允许他们检查和调整他们的架构和设计，使其成为最好的。这意味着不存在做出所有架构决策的前期阶段。相反，产品的架构会随着时间的推移而出现。
这种情况发生在技术团队成员首先关注他们认为有风险的产品的任何方面。例如，如果交付一个具有所需吞吐量的产品是具有挑战性的，那么团队和产品所有者将选择在降低风险的早期致力于功能。在敏捷开发中，Scrum产品的架构是逐步涌现出来的，这个架构不是一天就出现的，而是在技术团队成员的不断尝试下逐渐出现的。这意味着使用Scrum构建的产品确实拥有一个底层架构，但是关于架构的决策是在项目过程中根据需要做出的，而不是在项目开始时完全预先做出的。
您肯定遇到了比这更多的误区，当您在组织中努力引入或优化Scrum时，您无疑会遇到人们对Scrum的其他误解或错误信念。希望我在这里打破的误区能给您在组织中克服Scrum误区的一个开端。
译者观点
综合上面的译文，结合我自己的实际工作经验说一下我自己的看法：
职能经理尽量不要在scrum团队中，因为本身带有光环效应，团队员工肯定会有所顾忌，无法公开透明的合作，无法体现敏捷价值观，影响团队合作。但不在团队内并不代表没有工作要做，转变以往思维方式，给团队提供服务和资源，帮助团队更好成长将会是职能经理的新定位。
敏捷宣言中提到“客户合作高于合同谈判”，“响应变化高于遵循计划”，从这两点能够看到，敏捷的思想注重合作共赢，注重价值优先；同时敏捷不否认变化，在当今VUCA时代下，变化是唯一不变的，不可能拒绝变化，那我们就勇敢的面对它，和客户(干系人)一起合作找出价值最大化的最优的选择，通过快速反馈找到最优的解决路径。
全栈团队(Feature Team)是Scrum框架里面推荐的一种最优团队形态。因为这样就能形成团队间解耦，团队内部高内聚的效果。全栈并不意味着每个团队成员都是通才，团队成员的技术组成覆盖面越广才是全栈团队需要关注的。
传统项目管理计划和敏捷项目管理方式的不同，需要我们从思想观念层面转变。Scrum本身是基于经验的过程持续改进。也就是不期待一次性计划完备，而期望通过快速反馈调整来逐步修正计划并最终达成目标。
和项目管理思想类似，传统架构设计本身就是一种假设的工作，尽可能把后续的修改、灵活性处理，好的架构期望能够应对将来任何变化，但事实往往无法如愿。因为所有设计都是基于假设，而假设只有经历过之后才知道是否成立，所以Scrum团队并不是不需要架构设计，而是设计够用的之后通过迭代持续改进，最终形成一个合理的架构。
