3. 迭代就是敏捷，UP属于敏捷。
看到这么多人都把UP归入敏捷，我都开始怀疑是不是自己搞错了。但是在我的印象中：
UP是重型的过程，虽然引入了迭代，但是其原则和价值观与敏捷是不同的。敏捷注重的是反馈，迭代周期尽量的短，重在客户的参与，通过客户的参与，获取持续的反馈，不断调整使整个项目走在正确的方向上。同时也给客户一个感受和思考的机会，因为对于大多数客户而言，目标是明确的(不排除有些客户目标也不明确)，但是具体怎么做，开始时是没有想法的，只有看到具体的东西的时候，才知道“噢，原来可以这样，那我想把这里调整一下”。
4. 敏捷是彻底革命的。
敏捷，特别是XP，让人有耳目一新的感觉，觉得以前的所有软件工程理论，设计方法都可以抛弃掉了，推翻一切，从头再来。抱着这种想法实施敏捷，那就错了，敏捷不是“石头里蹦出个孙大圣”，以前的软件过程中也有敏捷的影子，只是没有像敏捷一样上升到价值观和原则的高度，比如快速原型法。敏捷是在对已有的软件过程方法的改进，抛弃的是传统软件工程低效的外表，以往的软件过程中很多技巧都是很实用的。实施敏捷应该以现有的软件过程为基础，从敏捷宣言和原则出发，利用敏捷的方法来改善过程。
5. 敏捷是反文档的。
文档只是为了达成目标的一种手段，如果这种手段是低效的，那就换一种手段。可是完全抛弃了文档，怎样解决沟通的问题?难道你想每次沟通都完全用手比划，用嘴说，跟不同的人重复表述同样的想法，那样更是低效的。
应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识，知识具备两种形态，显性的和隐性的，传统的观念是尽量把隐性知识显性化，即文档化，而忽略了这其中的代价(特别是更新同步文档的代价)。
因此，在实施敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的最佳效率。
文档不是目的，有效沟通才是目的。
6. 为了敏捷而敏捷
“嗯，敏捷这么好，我们也敏捷吧”，可能很多人会有这种想法。忘了以前是在哪儿看的大师采访录：
Q：“我们现有的过程很好，不知道怎么用敏捷改进?”
A：“既然很好，那就不要用敏捷”。
做什么事情都要有明确目标的，敏捷虽好，得看你需不需要，能不能解决你现在头疼的问题，如果不是，那就不要给自己找麻烦了。
7. 敏捷是CMM的反义词
在桂林会议的讨论中，很多人把CMM作为敏捷的反义词，我觉得这不是很合适。CMM只是一种衡量软件成熟度的标准，并非过程，和敏捷不是一类概念。如果要给敏捷找一个反义词，我觉得传统的瀑布式开发应该更合适一些。
并且，我认为，如果CMM还能继续流行下去的话，应该会有公司可以用敏捷改善的过程通过CMM认证。
8. 敏捷是自由的，无约束的。
敏捷强调的是自组织团队，发挥人的能动性，以动力代替压力，让人有绝对自由的错觉。但是应该清楚，凡是都是要讲究一个平衡，人也是两面的，消极的一面和积极的一面同时并存，绝对的自由会放纵人消极的一面。敏捷并非是绝对自由，无约束的。作为管理者，有一个职责，就是引导团队成员用自己积极的一面去压制消极的一面，不能放任团队中出现搭便车的现象，否则将打击整个团队的士气。如果实在无效，那就只能将其排除出团队了，这个惩罚够有约束力吧?
9. 重做就是重构
重做不等于重构，很多场合这两个概念是混淆的。但是在敏捷中，重构的一个特征是必须可控的。当对系统结构进行大的调整时，如果没有测试驱动辅助的话，那么可控性就会很差，这不能叫做重构。
文章来源于领测软件测试网 https://www.ltesting.net/
