组织会出于多种原因而采用敏捷方法。一些组织希望能提高生产率和缩短产品上市时间，另一些组织希望能够获得更成功的产品，还有一些组织希望能增强开发人员与业务人员间的协作，以提升质量或提高团队成员的工作满意度。
当然，还有许多组织采用敏捷是希望能同时实现这些好处的组合。
但是，为了能从敏捷中尽可能多地获得好处，组织似乎也存在很多误解。在本文中，我想谈谈关于敏捷产品开发的六个误解。
误解1：敏捷不是仅适用于软件开发吗？
这个误解很有趣，因为作为最古老的敏捷方法，Scrum起源于实体产品的开发。最初的Scrum项目是复印机、本田汽车和照相机。
如今，敏捷已广泛应用于各种形式的产品开发，从实体产品到基于云的软件即服务（SaaS）。
但除了产品开发（包括硬件和软件）外，敏捷已被成功应用于：
- 营销团队用来进行活动策划与执行
- 律师用来管理案件和工作负荷
- 组织转型（尤其敏捷转型）中的事务管理
- 高层领导团队管理其组织
- 家庭用来改进共处时光
- 夫妻策划婚礼
当然，还有更多。任何比较独特（您之前从未做过十次）且复杂的事项都非常适合于敏捷。如果您因敏捷宣言中采用“软件”一词而感到困扰，只需用“产品”这个词代替即可。例如，可以将“可用的软件”更改为“可用的产品”，然后再重新阅读：[我们倡导]“可用的产品”胜过“完备的文档”。非常适合。为什么？因为敏捷可用于所有类型的产品——软件只是其中之一。
误解2：在敏捷中真的不存在经理角色吗？
我认为这一误解依然存在，因为太多的经理花了大量时间去做他们不该做的事情，而罔顾敏捷与否。
例如，经理经常将工作分解到个人任务级别。当得知在敏捷中这并非其工作时，他们会感到自己的工作被剥夺了。
事实并非如此，并未完全取消这项工作。
首先，诸如分配任务之类的琐事，本来就不该成为工作的一部分。
经理们应当专注于打造团队蓬勃发展所需的环境和文化。他们的时间不应该消耗在诸如谁该干哪个任务的琐事上。
彼得·德鲁克（Peter Drucker）或许是20世纪的领军管理理论家。他以目标管理思想和为设置目标而创建的SMART首字母缩写（目标必须是具体、可衡量、可达成、相关和有时限的）而闻名。德鲁克说过，经理们有五项工作：
- 设定目标
- 组织人和工作
- 激励与沟通
- 衡量
- 培养人
当然，在某些组织中，其中某些责任可能会消弱。但是另一些职责——例如培养人，会变得更加重要。
在我实施敏捷以及与敏捷组织合作的这些年，没有人会决定要解雇所有经理。是的，虽然有些经理已经转换为工作更加聚焦的Scrum Master或产品负责人角色，但是在敏捷中依然存在经理角色。
误解3：干系人不是能随时发起变更吗？
毫不奇怪，最普遍相信这一误解（干系人能随时发起变更）的人群是干系人自身。
开发团队成员们都理解，在错误的时间引入变更是需要花费代价的。
设想一个在餐厅点餐的场景。你告诉服务员你要份鸡肉，随后又立即说：“不，请改为三文鱼。”
这种变更是没有成本的。
但是，如果您后来才改变主意，就要付出代价。如果在厨房开始煮鸡肉后，你告诉服务员将您的饭菜从鸡肉改三文鱼，就会出现食物浪费成本（餐厅可能会向您收费）。
如果在告诉服务员您想换三文鱼前，您已经吃了一半鸡肉，那花费会更加明显。
干系人把变更引入到迭代，就像吃饭者把鸡肉换成三文鱼一样。如果在正确的时间进行更改，成本可能很小甚至没有。但如果在错误的时间引入，则要付出代价的。
敏捷并不能消除所有干系人引入变更的成本。但是，无论在何时引入变更，优秀的敏捷团队都能降低变更成本。常用的方法是：
- 短迭代
- 短小的产品待办项
- 经常性最小化并行工作数量，以尽可能快地完成每个产品待办项
但这并不是说团队不应该欢迎适当的变更。某些干系人需要的变更可能非常重要。但是，变更成本并不总是零，对于每个变更都应该对照其变更成本评估收益。
误解4：不是敏捷团队中的每个人都应该成为通才吗？
出于某种原因，有个关于敏捷的误解非常流行，即每位团队成员都需要能做所有的工作。
这个误解意味着，如果您聘请了世上最棒的Oracle数据库管理员，您还希望这个数据库管理员同时也是名出色的JavaScript开发人员。并且，如果在一个迭代中不需要太多JavaScript开发工作，那么您出色的JavaScript开发人员还应该完全精通安全性测试。
这是完全错误的。
敏捷团队需要的不是每个人都掌握所有技能，而是重视任何确实具备多种专业技能的团队成员。
为了理解这一误解的错误之处，设想有一家运营良好的高档餐厅。从所看的电视烹饪节目中，我了解到这样的餐厅可能有糕点师。糕点师擅长制作糕点、甜点、面包和其他烘焙食品。
这听起来像是一个技艺高超而又专业化的角色。厨房里的另一个特殊角色可能是酱料师，他负责准备酱料、炖菜和其他类似食品。
在这个运作良好的厨房中，如果糕点师能帮助酱料师，例如在突如其来的洋葱短缺情况下时帮忙切一些洋葱，就已经很好了。但无论糕点师或酱料师，都不能期望其能完全胜任对方的工作。
在如今复杂的技术世界中，期望团队成员完全精通团队的所有技能是不现实的。取而代之的是，优秀的敏捷团队要学会重视掌握多种技能的团队成员。
拥有几名具备多种技能的团队成员，会有助于管理工作类型的平衡。比如说，有时团队需要更多的测试职位，如果有一两个团队成员能转做测试工作，就能极大地提供帮助。
但是，大多数团队即使有少数团队成员是真正的专家并且只擅长一门学科，也能做到这一点（即拥有几名具备多种技能的团队成员）。
误解5：我听说敏捷团队不做计划。
大多数优秀的敏捷团队都会做计划。只是，与传统项目相比，这种计划通常不太明显，因为敏捷团队没有一个早期计划阶段。
取而代之的是，优秀的敏捷团队将计划作为一系列小而重复的活动来实施，以确保其计划始终反映当前的实际情况。
这样，通过持续检视和调整，团队就能以开发产品的方式来做计划。
对于任何敏捷团队来说，其计划程度都应只限于重大决策的需要，而不应过于深入到未来。
但大多数组织和团队都会有一个计划，以在某种程度上估计接下来要完成什么以及何时完成。
事实上，尽管存在这种误解，由于能尽早洞察其开发软件的速率，敏捷团队能更容易地制定出可信的计划。
设想一个具有分析、设计、编码和测试阶段的传统团队。如果足够幸运，团队或许能将计划的提交时间推迟到设计阶段结束时。但就算到那时，团队仍不知道他们在编码和测试上能有多快——他们还没有开展过任何此类活动。
相反，敏捷团队每个迭代都会运转整个开发过程。每个迭代都会包含一些分析、设计、编码和测试活动。这就使敏捷团队能尽早地洞察到，其能以多快的速度将想法转化为新特性。
误解6：敏捷团队不是不做架构规划就开发产品吗？
终于到破除最后一个误解的时候了——关于敏捷团队不做架构和产品设计的误解。
敏捷团队肯定会设计他们的产品。敏捷团队以同样的方式，增量地进行计划、架构和设计。
这使得他们能够持续检视和调整其体系结构和设计，从而使其成为最佳方案。
这就意味着不存在前期的、决策所有体系结构的阶段。取而代之的是，产品架构会随着时间而浮现出来。
技术团队成员会首先关注产品中他们认为存有风险的任何方面。例如，如果要交付的产品在所需吞吐量上存在挑战，那么团队和产品负责人就会选择在早期研究如何达到目的，以降低该风险。
同样，敏捷产品的浮现式架构设计也是刻意的。架构不是一天就出现的。它是在技术团队的刻意引导下逐渐浮现的。
这意味着敏捷产品确实拥有基础架构。但是，有关该架构的决策是在项目过程中根据需要而作出的，而不是在项目开始时就完全作出的。
还有其他什么需要破除的敏捷误解吗？
我已经破除了围绕敏捷产品开发的六个误解。您在组织中还遇到了哪些其他误解？请在下面的评论中分享您的想法。
作者：Mike Cohn
译者：李洁（Jerry Li）
原文链接：
https://www.mountaingoatsoftware.com/blog/six-agile-product-development-myths-busted
