很多刚刚接触敏捷的项目经理经常会有的一个困惑是：敏捷和传统的项目到底有什么本质的不同？当然关于本质不同各有各的说法，我们先看看大家一般都是怎么对比传统的项目管理与敏捷。
观点
【关于敏捷一般会这么说】
敏捷强调应对变化，关注“价值-客户/用户-团队”之间的协调和适应，有方法论和框架，也特别注重实践。但凡看过一些敏捷资料的人都能说出个几点，比如迭代、冲刺、用户故事、测试驱动等等，看上去很美，听起来很简单。
仔细分析会发现，我们的项目经理或管理者们，很多都是从传统项目管理或实践中开始了解敏捷或在进行转型的，但敏捷和传统项目管理却有着很大的不一样。这些不同，不是表面上的框架和方法论，也不仅是工具和技术的应用，更为关键的是思维方式不一样!
敏捷需要实践，敏捷中很多知识和实践甚至是反直觉的 -- 所谓直觉：就是因为“常识”带来的偏见，却未见得是正确的。
传统的项目管理，通常强调严格和完善的计划、遵循计划进行执行和监控，有复杂的流程进行变更控制。
看完上面这段文字，你可能抓住了两个关键词，一个是“注重实践”，另一个是“思维方式”。但是我们平时做项目难道不注重实践了么？我们平时做项目难道不灵活应变么？还真没有见过谁把PMBOK上规定的全部过程在实践中全盘拿过来用的，大家都是根据实际情况进行调整和适应。传统项目的方法和工具也是由实践总结而来的，所以传统项目也很注重实践。
要解答这些疑问，单纯的对比传统项目和敏捷之间的所谓工具、方法、流程、原则似乎是回答不清楚的。所以海哲准备另辟蹊径，希望能够从更高的层次上来回答这个问题，也就是回归到我们看待世界方法上来研究这个问题。那么我们接下来讨论一下传统项目管理和敏捷是如何看待世界和项目的。
知识是人类对世界的认识。知识的来源之一是直觉经验，也就是人类在生活的过程中与世界发生互动产生的经验。这种经验知识可以解决一些生活中的问题，但是这种知识受时间、地域、作用对象的限制比较多。例如你某次肚子疼，喝了一点热水肚子就不疼了，于是你把这个当作经验知识。每次肚子疼的时候就喝点热水，你甚至建议别人也这么做。这就是经验知识，是人类认知能力自然的体现。
但是并不是所有的肚子疼都可以用喝热水来解决，于是就有人研究人为什么会肚子疼，肚子疼分几种类型，不同的肚子疼表现如何以及在不同的情况下如何应对肚子疼。这种通过分析、推理、实践等环节得来的知识被称为经典知识。经典的知识适应性广，大家都可以用来学习和使用，不需要人人都去体验一遍才能知道。经典知识便利了知识的传播与继承，很好的促进了社会的发展。
需要注意的是，世界是变化的，人类对任何一个领域都不可能做到认识其全部的知识，所以经典知识在运用的时候也未必能解决所有的问题。但并不是人人都能看到这一点，人们在运用经典知识的时候，往往错误的认为他所掌握的知识已经是世界的全部。凡是与经典不符的就是异端，就是邪说。人类历史上不知道发生过多少次因为捍卫自己对世界的认识而引发的迫害、运动甚至战争。
我们学项目管理的也会犯这种错误，项目管理最经典的知识体系是PMBOK，要想成为一个称职的项目经理，除了天赋、经验之外，最重要的就是要掌握PMBOK中的经典知识。但是因人在某种程度上的不自知和不自主,也就是说无法做到“知行合一”，错误的认为自己所学的知识就是项目管理的全部，这在实践中不免就会遇到各种各样的问题。当遇到问题时又不能很好的反思总结丰富自己的项目管理知识体系，结果要么认为自己学的是假知识，要么固执的坚持认为别人的做法是错误的。
敏捷提出“注重实践”其立意深远，相当于一开始就表明了，敏捷不是什么经典，不会固步自封，敏捷是开放的知识体系，大家通过实践获取知识，通过反思提炼知识，通过实践应用知识，通过交流（敏捷社区）传播知识。其实这应该是我们学习所有的知识都应该遵循的法则，但是往往简单的道理是最难认识的道理。
不能把“注重实践”错误地理解为凡事都要亲自去体验过才叫知识，不相信任何前人总结好的经典知识，一切凭经验主义，自己没有经历过的就不相信、不实践、不调整。敏捷的知识体系正处于一个快速发展的阶段，各种理论和各种实践不断的被增加到这个体系中，用不了多久，敏捷也会变成经典。知识本身并没有错误，错误的只有人们学习和应用知识的态度。
项目是为创造独特的产品、服务或成果而进行的临时性工作。这是PMBOK给出的关于项目的经典定义。这句话看似简短实则含义丰富，只有深谙世界变化之道理才能体悟到这句话的高明之处。根据这个定义，我们可以了解项目的两个基本特征：独特性和临时性。简单来讲，项目就是大家临时聚在一起完成一个（些）事，事情做完了，大家就各回各家，各找各妈。
项目实际上就是我们对于要做的事以及如何把事做好的一种认识，基于实践总结了一套完成这些事的知识体系。那么传统上（或经典上）我们是如何看待“找一些人来完成一件事”的呢？
传统的项目过程大概可以这么简单的描述：有个事很好，跟以前不一样（独特性）做完了可以有好处（交付成果）；既然要做事，总得找一些人来做（启动），为了把事情做好，咱么需要仔细合计合计（计划），人算不如天算，不怕一万就怕万一，真做的时候还得看着点（执行&监控），好不容易做完了，咱们还得说道说道、论功行赏，以后能不能干的更好（收尾总结），事情做完了，下次什么时候再搞一次，还不知道，大家就先各回各家，有事的时候再叫你们（收尾解散资源）。
所以传统上我们看待项目是这样的，先有事，再找人，事情做完了，人解散。也就是先有坑，再种萝卜。从项目的角度来看重在做事而非养人，既然事情做完了，那么人也就应该解散。养人的工作由组织来承担。
咱们做项目的目的，说的高大上一点是创造价值，通俗一点是为了赚钱。为了赚钱你就得考虑成本，降低成本的常用方法就是提高效率。提高效率的方法最好是一个人能干两个人的活。一个人干两个人的活太不容易实现，因为毕竟工资低，能力高的牛人很难找。但是通过团队的高效配合可以实现一加一大于二的效率，这就是高绩效团队。
敏捷认为，高绩效团队来之不易，这就像军队上的尖刀班、突击连是经过实战检验的、能攻坚克难的队伍。不能因为项目结束了就解散，那样对组织来说是最大的浪费。虽然说项目没钱养人，但是这个钱项目不出，组织也要出，从总体上讲，养团队的成本是省不了的。而且现在项目工作已经变成了企业的常态，企业不可能像过去一个产品吃上几十年，产品的生命周期越来越短，IT企业尤其如此。所以传统的基于分工的职能部门组织方式太落伍了，现在应该建设全职能的团队。
在敏捷中很少会特别提到项目，而只提团队，这并不是说采用敏捷之后，传统上的项目概念就消失了（其实消失了也没什么，“项目”本来就是人发明的概念而已），其实这是用心良苦，敏捷希望这样提醒人们，敏捷团队来之不易，传统上事毕人散，为了继续发挥团队的绩效，敏捷是“人存事续”，也就是团队在相当长一段时间内不解散，而由企业不断地为其找事情做，反正企业中也不会缺少事情。
那么这个高绩效的、自组织的团队就变成了价值生产单位，可以持续不断地、高效地为企业创造价值。敏捷不是只有团队没有项目，而是修改了项目定义。
项目实际上是不太关心事情是怎么来的，主要关心如何把事情做好。虽然在现代企业中，每天都在忙着做各种各样的项目，似乎企业本来就是这样。但是看一下项目的发展史就可以了解，企业或者组织一开始做事的形态并不是项目，而是基于职能分工的运营，也就主要应对重复性的工作。对于那些创新性的工作，大家发明了“项目”来应对，因为这种新鲜事不常有，所以项目往往是一个一个的做，不像运营是持续的做。随着社会的发展，对于某些行业（尤其是IT行业），项目工作变成了常态，而原来基于职能分工的组织方式发展起来的项目管理方法，渐渐无法适应新的需要，如此才有敏捷的应用而生。
敏捷并不是没有项目的概念，而是对项目的概念进行了发展和补充，由传统的“因事设人、事毕人散”，发展成为“因人设事、人存事续”。之所以出现这样的变化也是基于软件行业的特点而提出来的，这是对项目管理知识体系的发展与完善。我们可喜地发现，即将启用的PMBOK第6版已经把敏捷纳入其中，而且 PMI也在不遗余力的推广敏捷项目管理的知识，虽然没有形成所谓的知识体系，但是ACP（Agile Certified Practitioner）的推广已经初见成效。
联系客服
