【外文摘译】流言粉碎——6个有关敏捷产品开发的谬见
流言粉碎——6个有关敏捷产品开发的谬见
组织采用敏捷方法的原因很多。
有些是希望获得更高的生产力或者缩短产品上市时间。
另外一些是为了产品更加成功。
还有一些采用敏捷是为了增强开发团队和业务人员的合作，提升质量，或者提升团队成员的职业满意度。
当然，大多数组织采取敏捷是为了获得以上所有的好处。
然而，我们期待敏捷模式能带来多少效益，其中就存有多少对敏捷认识上的谬见。这篇文章，旨在破解其中6个有关敏捷开发模式的谬见。
谬见 #1：敏捷仅仅适用于软件开发？
这个谬见非常值得一提。Scrum是最早出现的敏捷方法之一，然而它最初其实是来源于实物产品研发（非虚拟的软件产品研发）。最早的Scrum项目是应用于复印机、本田汽车，还有照相机的生产。
这些年敏捷曾应用于所有形式的产品研发，囊括了从实物产品到（虚拟的）云上的Saas产品。
然而，除去产品研发（硬件和软件），敏捷还成功的应用于如下的领域：
营销团队用来计划和执行市场营销活动
律师团队用于管理案例和工作量
组织转型协作，特别是敏捷转型
高层管理团队用来进行组织层面管理
家庭成员用来提高共处时光的质量
夫妻用来计划婚礼
当然，还有很多很多。任何一个独特性高（你并未重复做过10次以上的项目都称为独特性高）并且复杂性高的项目，都是非常适合用敏捷模式的。如果你发现在阅读一些有关敏捷的文稿（比如敏捷宣言）的时候，常常被其中“软件”这个字眼带到坑里，只需要把“软件”改成“产品”就会清晰很多了。
比如，把可“工作的软件”改成“工作的产品”，再来读一读：可工作的产品高于详尽的文档。
非常完美。
为什么？因为敏捷适用于所有产品——软件只是其中之一。
谬见 #2：敏捷里面没有经理这个角色存在？
这个谬见之所以一直存在，因为太多经理花了太多时间做他们并不应该做的事情，不论是不是在敏捷模式下。
比如，经理们常常向下越级做任务分配的工作。
当他们认识到在敏捷中他们不应该做这些事情的时候，他们感觉自己的一部分工作被剥夺了。
否：经理们的部分工作并未被剥夺。
分配任务的工作从一开始就不应该是他们的工作。
经理们应该专注于建立团队得以繁荣兴旺的环境和文化。他们宝贵的时间和精力不应该花在谁该做什么任务上面。
彼得·德鲁克（Peter Drucher）也许算得上是20世纪管理理论先驱。他因为他的目标管理理念被人们熟知。他提出的目标设定SMART原则，就是将目标描述成：
Specific 具体化的
Measurable 可量化的
Acceptable 有合格标准的
Realistic 现实可实施的
Time-bound 有期限的
德鲁克曾提到过经理的5大工作范围：
1、设定目标
2、组织员工和工作
3、激励和沟通
4、度量
5、培养人才
的确在有些组织，以上职责也许会被削弱。但是，其中某些——像培养人才——将越来越重要。
我在敏捷过程和敏捷组织上进行工作这么多年来，从没有过任何一个组织或个人决定要拿经理们开刀。是的，有些经理们转移到了职责更加聚焦的岗位上，比如Scrum Master或者Product Owner，然而Agility组织中仍然需要其他管理者的角色。
谬见 #3： 重要干系人不能随时引入变更吗？
不足为奇，这个谬见是重要干系人们一直认为理所当然的：他们随时可以根据他们的需要引入变更。(这里重要干系人可以理解为重要客户、老板、股东......)
研发团队很清楚，在错误的时候引入变更带来的巨大代价。
试想在餐厅点餐。你告诉服务生你想要一份鸡肉。然后马上又说：“哦，不，换成沙拉。” 对于这样的改变没有代价。 可是，如果你过一会儿改变主意，成本就会产生。如果当厨房已经开始煮鸡肉的时候，你才告诉服务生把鸡肉换成沙拉。如果餐馆同意换，那就会产生浪费。
重要干系人在一个迭代中引入改变就类似于将鸡肉变成沙拉。如果改变在合适的时候引入，代价会很小或者没有成本浪费。如果改变在错误的时机引入，代价一定存在。 做敏捷不能消除所有重要干系人所引入的变化。但是，好的敏捷团队可以减少变化所带来的代价，不论这个变化何时发生。
通常有这几种做法：
缩短迭代周期
细分Product backlog项
每一个product backlog都尽可能快的完成，一般使用同时进行的PB数量尽量减少的方式来快速完成一个PB
这并不是说团队不应该欢迎适当的变化。有些时候重要干系人要求的改变对于项目成败非常重要。但是，做改变所带来利益需要对比改变所造成的代价并进行评估，并认识到无论如何代价一定存在。
谬见 #4： 敏捷团队每个人都需要是多面手？
由于某种原因，一个最普遍的有关敏捷的谬见就是，每个团队成员需要有能力做任何事。（全栈工程师）
这个谬见意味着，如果你有幸招到了世界上最牛的Oracle DBA，你还需要他同时还是一个厉害的JavaScript开发人员。并且，你那厉害的JavaScript开发人员在没有太多JavaScript开发工作的迭代，应该完全精通于安全测试。 这是完全错误的。 敏捷团队不需要每个人都会所有的技能。
但是呢，敏捷团队应该重视那些拥有多项技能的个体。
充分理解并去伪存真，细想一个运作得非常好的昂贵餐厅。我在电视节目上曾经看到过这样一个餐厅，他们有一个糕点师。这个糕点师在酥皮糕点、甜品、面包和其他类烘烤类产品都非常在行。 听起来是专业化很强的一个角色。另一个专业化角色是调味师，他负责准备酱汁、炖菜和其他相关菜品。 一个运行良好的厨房，如果他们的糕点师恰巧可以帮忙做酱汁，也许还能在洋葱紧缺的情况下帮忙切洋葱。但是不论是糕点师还是酱汁师，都不应该是被期待全职做另一个工作的那个人。 在当今复杂技术的世界里，期待团队成员都在所有专业领域成为专家是不切实际的。
但是呢，好的敏捷团队要重视那些拥有多项技能的成员们。
如果一个团队拥有好几个多技能成员，那将有助于协调和平衡进度，灵活的调整队形并保持前进。举例，如果当团队需要更多的测试资源的时候，有一两个成员能够快速跟进将大大提升团队效率。 不过呢，即使只有少数团队成员是真正的专家，并且只精通一种技术的团队仍然可以做到敏捷。
谬见 #5：我听说敏捷团队不做计划。
大多数好的敏捷团队是要做计划的。只是那些计划看起来不像传统项目那么明显，因为敏捷团队没有提前设置好的计划阶段。 但是呢，好的敏捷团队实施计划的方式是以一系列规模更小，重复的活动来保证他们的计划与当前的实际情况保持一致。 敏捷团队用研发产品相同的方法进行研发计划：检查和调整。
不断的通过检查，来确定目标是否偏离。
不断的通过调整，来适应拥抱变化。
对于任何一个敏捷团队，不能对太过遥远的未来做计划，而是关注于当下的每一个重要决策。但是大多数的组织和团队对下一步要做什么和什么时候做会有一个粗略的估计。
事实上，尽管这是个谬见，敏捷团队仍然可以轻松的创建一个可靠的计划，因为敏捷团队对自己开发速率有一个清晰的洞见。
试想一个传统的团队，需要经历分析、设计、编码和测试等阶段。如果幸运的话，这个传统团队很可能会延迟计划直到设计结束。在没开始编码之前，团队都无从知晓他们到底能够以多快的速度进行编码和测试——他们没有做过这样的事情。 与之相反，一个敏捷团队将整个研发过程转化到每一个迭代中。每个迭代都包含少量的分析、设计、编码和测试。这将让敏捷团队更多更早的知道自己能够以多快的速度将想法转化为新功能。
谬见 #6：难道敏捷团队在构建产品的时候不做架构设计？
是时候粉碎最后一个谬见了：这个谬见是关于敏捷团队从来不对他们的产品做架构设计。
敏捷团队当然要设计他们的产品。与增量式的进行计划相同，敏捷团队进行增量式的架构和设计。这样他们可以不断的对他们架构和设计进行检查和调整以确保是最佳方案。 这代表着没有专门的阶段供所有架构思路完型。相反，产品的架构随着时间推移不断的涌现。 技术团队首先关注的部分是他们认为产品存在风险的部分。比如，如果实现一个特定吞吐量的产品是非常有挑战有难度的，这个团队和Product Owner将优先考虑先做这部分工作以降低风险。 在这种模式下，一个敏捷产品所涌现的架构设计通常也是有意而为的。这些架构并非突然就出现了。而是随着技术团队的意图逐渐涌现出来的。 这就意味着敏捷产品具有一个潜在的架构。形成这个架构决策的并非在项目一开始就定下来了，而是随着项目进行在项目末尾最终定型。
原文链接：
