敏捷实施中的常见错误

　　一些评论员写下了敏捷实施中一些常见错误和反模式。他们贴出了“Top X”列表，列出了需要避免的事项和他们曾在各种组织实现敏捷时见过的错误。

Target Process的Michael Dubakov写了两篇博文：“10个敏捷实施中最常见的错误”（Part 1; Part 2 ）。他认为“许多公司在敏捷实施中再三犯同样的错误。”

他的常见错误列表如下：

1. 从一个工具开始
敏捷开发是不同的。一个工具不会立刻产生影响，不会由于这一工具的存在而解决多数的问题。而且，你由于需要为工具的实施投入精力， 这会 影响更重要的目标--敏捷实施。

2. 从一个过程开始
多数公司是从一个过程开始的。这错误不是很严重，但更常见。如果你读读Scrum相关资料，会觉得它看起来很容易启动。你实施所有的Scrum实践，在若干sprint后发现开发有 了 点改进，但 远没有达到预期。于是热情开始消退，过程开始退化。任何公司开始尝试任何敏捷过程前做的第一件事 应该 是，专注于敏捷价值，比如：沟通、协作、反馈、信任和热情。 如果你对这些价值中的任何一个做出妥协，就几乎不可能实施一个 良好地 开发过程。

3.开发实践就足够了
有趣的是，开发人员倾向于实施技术实践，像TDD、持续集成甚至是结对编程，但很少注意到沟通、整体团队、客户现场协作和回顾。

4. Scrum就足够了
真正的错误在于，完全依赖Scrum，认为它是能解决所有问题的过程。它能做到这点，但你要开放思想并愿意做各种尝试：从结对编程到BDD。最好的敏捷教练相信，Scrum的实施应该与XP技术实践紧密的结合起来。

5. CSM无所不知
认证的Scrum Master不是神。是的，他有一些关于Scrum的基础知识，但许多情况下也就仅此而已。

6. CST无所不知
认证的Scrum培训师不是上帝。是的，他知道不少，也有相当的经验。很有可能他有能力帮助敏捷的实施，但也仅仅是帮助。他也许对你所在领域、你独特的状况和你所在组织的根本问题一无所知。如果你完全依赖于CST，把敏捷实施完全委托给他，敏捷实施将会失败。

7. 职能部门应该幸存
完全没有理由保留职能部门和职能团队。只要可能，大家应作为一个团队共同工作。很明显，如果测试人员在美国而开发人员在印度，这几乎是不可能的。但如果每个人都在同一栋楼里，却没有跨职能的团队就很愚蠢了。

  8. 我们可以不要客户反馈

敏捷主要在于快速反馈。来自客户的反馈最为重要。如果用错误的方法建造了某样东西，这是不好的。但如果建造错了东西，那就太糟糕了。为什么？因为稍后你将不 得不把丢弃它。来自客户的定期（快速！）反馈就像是在遍布礁石的海湾中航行的指南。需要在风向和其他因素变化时不断调整航向。客户是最有价值的团队成员， 应该得到重视。

9. 自我组织很容易
纯粹 的自我组织认为会有领导者出现。这不常出现，许多情况下没有领导者，团队会失去生气、变得平庸。领导者设置一个目标，并推动团队朝着正确的方向前进。领导者使团队自信、有热情及自我反思。最终实现自我组织。
当领导者离开团队会发生什么？多数情况下团队会出现倒退或慢慢退化。这是个明确的信号：能够判断出团队是否实现了自我组织。真正的自我组织团队在没有领导者的情况下保持他们的价值和进步。

10. 错误的目标（如：客户要求我们是敏捷的）
如果你的客户坚持在他的项目中使用敏捷过程，你应该为此感谢上苍。利用这个机会作为转折点，开始实施敏捷。
不幸的是，为了得到合约，许多公司只是试着“模拟”敏捷实施。他们派人去上CSM课程、购买一个敏捷项目管理工具并浅薄地实施Scrum。他们这么做没有什么深层次的目标和文化上的变化。他们没有任何激情的在做这些。

　　Mike Griffiths 在博客 Leading Answers写了篇博文：“敏捷实施反模式”，并列出了他曾见过的五个常见错误：

1. 敏捷是银弹 - 是的，敏捷方法能节约时间、增加商业信任及创作出高质量的产品，但他们不是银弹.他们不会扭曲空间或是时间，让你在有限时间、预算和资源的限制下能交付更多工作。

2. 把敏捷作为无规范的借口 - 与他人的观念相左，敏捷方法不是抛弃规范，跳过规划和评估就直接开始编码。敏捷方法中包含了许多高度规范的活动和技术，比如：测试驱动开发、Wideband Delphi估算法，并且双周迭代规划及评估会议需要许多规范。

3. 敏捷不需解释 - 项目和团队不在真空里；他们会与 组织内 许多其他干系人交流。而首先在你的团队和你有更多影响力的领域实施敏捷也许会更容易些，但总有一天你要向其他人解释一下这些工作实践。

4. 浅反馈- 敏捷方法依赖于来自不断发展的系统的反馈，以确认理解正确并验收已完成工作。典型的新功能会演示给客户，并留下测试环境供他们实验并收集反馈。我们很容易 认为，收到很少或没有反馈意味着用户一定对我们开发的产品很满意。然而更可能的是，客户没有真正正确地去察看它、或没有用实际数据或场景测试它。

5.依恋敏捷过程 - 人们对敏捷方法抱有热情，这是件好事。但如果人们开始过于专注于过程，并牺牲商业价值的 交付 ，那就有问题了。通常，项目的建立和进行是为了实现一些商业改变或改进。我们不是要实践完美的方法，最终的目标是让我们的投资者和用户满意，而不是沉迷于过程或构建履历。

Craig Larman和Bas Vode写了篇名为“大型敏捷实施的十大组织障碍”的文章，这篇文章“询问了一群在大型公司内工作或与之合作的敏捷开发专家，什么是最具挑战性的组织障碍。”

他们的前十列表包括下面这些：

10. Jeff Sutherland， Scrum的共同创始人 ， 认为不能移除组织障碍是大型组织中的主要障碍。

9. Peter Alfvin，一名经验丰富的开发经理，他参与了在施乐引入精益原则，Petri Haapio是Reaktor Innovations公司敏捷培训部门的主管。他们两人都提到了，为追求成本‘节约’和‘协作’的部门集中化导致了本地优化，这成为了一个障碍。

8. Sami Lilja，诺西网络的敏捷开发活动全球协调官，注意到一些组织认为学习 是浪费时间和金钱。

7. Larry Cai，上海爱立信的专家，提到职能组织（单一职能团体）是最大的障碍之一。他们阻碍单位间的沟通，并助长了单位之间的指责。

6.Esther Derby，顾问、教练、协调专家并著有两本关于组织学习的书，认为促进本地优化胜过全球优化的系统是主要障碍。她给出了一些例子，包括目标管理（MBO）和预算系统。

5. Mike Bria，前西门子医疗系统敏捷教练，提到“自我进行改进”是个障碍。他强调了一个有问题的态度：人们 在 读了一两本书后认为“我们知道怎么做了”。

4. 某A.（按当事人要求匿名），某大型电子商务网站的一名Scrum培训师，提到个人绩效评估和奖励是个主要障碍。它们会使开发人员和经理们感到沮丧，妨碍团队绩效并促进里命令和控制式管理。

3. Lü Yi，诺西网络杭州的一名Scrum培训师及大型开发团队的部门经理，认为“承诺游戏”和不切实际的允诺是主要的组织障碍。这导致走捷径、持续救火及遗留代码。

2. Diana Larsen，协调专家、与Esther Derby合著<敏捷回顾>一书，简单地说道，“假设一切全都与开发人员有关。”

1. 几乎每个人都认为“认为敏捷是银弹和肤浅的敏捷实施”是主要障碍。

除此之外，Larman和Vode提到另外两个他们常见的阻碍：

Craig认为关键阻碍是每个工作者的文化而不是真实的团队和团队合作的文化。他拜访了许多表面上在应用Scrum的个人，并看到些症状，如：“Jill做Jill的任务，Raj做Raj的任务”等等，而不是“整个团队一起”的结对行动，在团体内多方学习。 

Bas认为管理人员和第一线的人员之间的分歧是关键障碍。经常是这样，管理层的变动对做真正有价值工作没什么影响（或者说，至少没有正面的影响）。同样地，第一线的开发人员做的决定通常与组织的方向不一致。

查看英文原文：

　　Common Mistakes in Agile Adoptions