项目管理是指跟踪个人和团队的绩效，提供反馈，解决问题和协调变更，以提高项目的绩效。其中不乏一些误解，那么在项目管理之中敏捷的误解有哪些呢?下面就跟随项目管理软件小编一起来了解下吧~
误解一：项目管理——敏捷好，其他方法不好
有些人一提到敏捷就大呼好，只要是敏捷的实践就什么都好，而提到CMMI等方法就大呼不好，不管是什么只要沾上边就哪里都不好，似乎敏捷和其他方法是完全对立的。牛顿说过，我是站在了巨人的肩膀上。敏捷同样也吸取了其他方法论的优点，也是站在了巨人的肩膀上，敏捷依然保持了很多历史悠久的实践和原则，只是表现方式不同罢了。
从另一个方面来看，方法本没有好环，好与坏取决于是否适合解决你的问题。每一种方法都有他最善于解决的问题和最佳的发挥环境，在需求稳定、软件复杂度相对不高的时代，瀑布模型也可以工作的很好，而敏捷恰好适用于变化快风险高的项目 - 这恰恰是现在很多项目的共性。
因此选择一个方法或过程，并不是根据它是否敏捷，而应根据它是否适合。而要了解一个东西是否适合，还是要尝试之后才知道，任何没有经过实践检验的东西都不可信。
误解二：项目管理——敏捷对人的要求很高
很多人在尝试实施敏捷时说：敏捷对人的要求太高了，我们没有这样的条件，我们没有这样的人，因此我们没法敏捷。可是，敏捷对人的要求真的那么高么?
软件归根到底还是一种创造性活动，开发人员的技术水平和个人能力对软件的质量还是起着决定性的作用，各种过程与方法只是帮助开发人员、测试人员等角色能够更好的合作，从而产生更高的生产力。不管用什么方法，开发人员的水平永远都是一个主要的因素。
从另一个角度来看：过程和方法究竟能帮开发人员多大忙?对于技术水平较低的开发人员，敏捷方法和传统方法对他的帮助是差不多的，因此看不到显著的效果，甚至有些时候还有反效果;而随着开发人员技术水平的提高，敏捷方法能够解开对人的束缚，鼓励创新，效果也会越来越显著。
敏捷对人的要求并不高，而且会帮助你培养各种所需的能力，当然前提是你处在真正敏捷的环境中。
误解三：项目管理——敏捷没有文档，也不做设计
这个误解从XP开始就没有停止过，XP鼓励“在非到必要且意义重大时不写文档”。这里面提到的“必要且意义重大”是一个判断标准，并不是所有的文档都不写。例如，用户手册是不是“必要且意义重大”?这取决于客户的要求，如果客户不需要，那就不用写,如果客户需要，就一定要写;再如，架构设计文档要不要写?复杂要写，不复杂不用写。通常架构设计只需要比较简单的文档，对于有些项目，一幅简单的UML图就够了。因此，写不写，怎么写，都要根据这个文档到底有多大意义，产出和投入的比例，以及项目的具体情况决定。实际操作时可以让项目组所有人员表决决定，尽量避免由某一个人(比如lead)来决定。
至于设计，XP奉行的是持续设计，并不是不设计。这实际上是将设计工作分摊到了每天的日常工作中，不断的设计、改善(重构)，使得设计一直保持灵活可靠。至于编码前的预先设计，Kent Beck等人确实实行着不做任何预先设计的开发方式，但是对于我们这些“非大师”级开发人员，必要的预先设计还是需要的，只是不要太多，不要太细，要有将来会彻底颠覆的准备。
误解四：项目管理——敏捷很好，因此我要制定标准，所有项目都要遵循着个标准
没有哪两个项目是一样的，客户是不一样的，人员是不一样的，需求是不一样的，甚至没有什么可能是一样的。不一样的环境和问题，用同样的方法解决，是不可能解决的好的。方法是为人服务的，应该为项目团队找到最适合他们的方法，而不是先确定方法，再让团队适应这个方法。因此也不存在适合所有项目的统一的方法。任何企图统一所有项目过程的方法都是不正确的。