敏捷项目管理的十大误区

许秀影，PhD、OPM3、CSPO、PMI-ACP、LLP Educator。

本文的观点均来自笔者亲身的经验或亲自辅导的心得，并不是针对某个人的观点或某家公司的流程做评价，如有雷同，纯属巧合。若您的看法与做法列在文中，意味着根据国际的敏捷趋势、知识与笔者个人的经验判断，它可能会导致失败，应该引以为戒。

敏捷就是在快速变化的这个“互联网+”时代，所有知识工作者必备的DNA。对于敏捷的认识最主要的就是要能够像任正非所讲的“你的笑脸要面对客户，你的屁股要面对老板”。如果你一天到晚巴结你的领导，然后你的领导又巴结他的领导，然后大家一心一意所想的所看的都是领导高不高兴，那么这个组织通常不太敏捷。你所想的应该是我们怎么样能够对客户最好，怎么样能够为客户创造最高价值。这样的话才是敏捷。

敏捷是时代演进的必然结果，传统的项目管理是从工业时代遵循泰勒的科学化管理方式而来的，演进到PMI以及后面一系列的项目管理标准，敏捷项目管理是从彼得·德鲁克的人性化管理演进而来的。敏捷项目管理提供了以人为本和科学管理有机融合的项目管理方式，敏捷团队以协同合作、自我组织的方式工作，努力的成果是为了要达成项目愿景，帮助客户创造最高价值。在我的著作《敏捷项目管理：基础知识与应用实务》（中国电力出版社出版，2016）一书中，我提出敏捷项目管理的架构APMF，这个架构就是用中国的《易经》阴阳平衡的理论，基于一个自然界运行的方法。

全世界优秀成功的信息公司几乎都采用敏捷，尤其是Scrum，如谷歌、诺基亚、奥多比、苹果、微软等。采用敏捷可以实现几个主要的商业目标。第一，持续创新。因为新的点子是来自自我组织的团队，不是由上而下的下命令。第二，产品比较有弹性，可以根据客户现在跟未来的需求进行调整。第三，可以加快上市时间，就是用比较小的迭代，然后赶快上市，赶快回收所花成本，提高投资回报率。第四，人员跟过程有弹性。第五，产出可靠的成果，支持业务的成长及提升获利的能力。

误区1 敏捷是将大瀑布变成几个小瀑布？

我发现大部分导入敏捷失败，问题都是出在团队虽然用了敏捷的流程，但是没有用敏捷的思维，而是用传统的脑袋和思维在做事情。那也就是会导致“有形无意”。空有敏捷的流程外观，没有把握敏捷的精神，做事情的方法都跟以前一样，这些团队只是把一些大瀑布分割成为小瀑布，要求团队用更少的时间来完成，这样不是敏捷。

导入敏捷项目管理是一种组织的价值观跟文化的变革。项目团队不是只有如期如质如预算地完成项目而已，是要达成项目愿景。敏捷解决了长久以来无法让用户满意的主要原因——“缺乏使用者参与”跟“需求不明确”。敏捷把客户纳入到敏捷团队，然后在过程当中频繁跟开发团队进行互动，并且逐步地细化需求，让团队能够做出符合客户需求，为客户创造最高价值的成果。

误区2 敏捷只适合在IT产业？

根据我的实践经验，除了已经广泛应用的IT产业，敏捷适用于各行各业，包括嵌入式的系统、公关、数字媒体等，同时也适用于我们的工作和生活。在《敏捷项目管理：基础知识与应用实务》一书里，我提到的一些范例可供大家参考。但是，并不是所有的项目都一定要用敏捷。如果需求和技术都非常明确，用传统的项目管理就可以；如果需求不是很明确，就是大方向确定，小的细节可能修改，那就比较适合用敏捷。

误区3 敏捷只适用在小型的项目？

其实敏捷适用于各种类型的项目，包括小型的项目，也包括大型的项目，在我的敏捷一书里提到，有非常多上百人的团队也都是采用敏捷的方式。虽然是在不同的项目，可以有不同的适用敏捷或者传统项目管理的方式，但是无论是哪一种项目，如果能够运用敏捷的心态和敏捷的一些实践，不管是任何形态的项目管理都会有更好的成果。

误区4 敏捷不需要文档？

我对企业进行辅导的时候，企业里的领导有时候会要求我在辅导时跟团队强调，敏捷不是不要文档。原来自从他们去外面上了敏捷的课程回来之后，所有的软件开发的人员都不写文档了，其实这是错误的概念。敏捷的精神应该是追求科学化与人性化管理的平衡。所以，敏捷修炼的秘诀就是维持平衡，而每一家企业根据状况的不同，维持平衡点也不一定在中间，这是我在书里面特别提出来，认为敏捷不是偏左，也不是偏右，而是要维持平衡。

误区5 敏捷就是“无法管”？

敏捷强调仆人式领导，鼓励团队成员以“自我组织”（Self-Organizing）的方式执行与管理项目，不是用“命令-控制”（Command-Control）方式，并不表示敏捷项目管理等同“无法管”。

用仆人式领导的方式，意味着不要告诉团队怎么做，而是要告诉他们愿景在哪里，要做什么，然后协助团队自发性地发挥他们的创造力，完成项目。所以，敏捷强调让客户代表、开发团队更多地协同合作。导入敏捷之后其实是比以前更有规矩，而由谁来维持这个规矩呢？就是敏捷教练。所以，敏捷不是没办法管，敏捷团队是自己管自己，管得比以前别人来管他、盯着他推着他来得好。

误区6 敏捷是需求跟目标都不明确？

敏捷并不是在需求目标范围都完全不明确的情况之下执行项目，敏捷适用于目标明确、需求大方向明确、细节不明确的项目，而不是完全不明确的状态。这在我书里也提到，项目启动的时候要有明确的愿景、目标，过程当中不是不断地变更范围，而是紧盯愿景，计划细节可以变，但是项目范围不可以变。只是渐进明细地在适当的时间点根据更细化的需求做适当精度的计划，项目愿景跟范围不变，为达成项目愿景，有时候计划必须要根据内部外部环境而变。如果说是新创公司，或者新产品的开发项目，那需求跟目标都不明确的时候光用敏捷是不够的，还要配合商业模式图跟客户开发，也就是《敏捷项目管理：基础知识与应用实务》书中介绍的“LLP敏捷创新创业”方法。

误区7 敏捷在每个迭代都提出新的需求？

每个迭代都提出新的需求，会不会做了一些东西都不在我们项目的范围里面，而造成范围的蔓延呢？其实不会。敏捷项目管理是把客户代表作为产品负责人纳入敏捷团队，而产品负责人的主要任务是让团队的努力为客户创造最高价值。所以，产品负责人也就是这个客户代表，最主要的工作就是跟团队讨论后，排定产品待办列表的顺序。团队成员所做的所有工作都是从产品待办列表最上方拿自己擅长的工作来做。每一次发布，每一次迭代，都是把需求更细化，而且可以在不改变合同的情况之下改变工作的先后顺序。

敏捷使用的“用户故事“，与传统项目管理用的规格书不同，因为规格书无法充分表达需求。项目执行过程中，用户将原来的需求表达得更清楚，但跟原来规格书不一样，从传统的项目管理视角认为是改变需求。敏捷团队在合同范围内，欢迎改变需求，因为每次发布、每次迭代，用户代表就会把需求表达得更明确，可能会跟原来的描述或条件不同，其实只是按部就班地将需求细化，不是乱改乱提需求。

误区8 导入敏捷之后就不需要计划？

因为需求一直在变，计划一直在变，所以不需要计划。事实上这也是错误的概念，敏捷是紧盯愿景，而不像传统项目管理紧盯计划。所以，敏捷需要计划，通常来讲它需要五个层次的计划，计划是渐进明晰，而不是没有计划，详细的内容也请参考《敏捷项目管理：基础知识与应用实务》一书。

误区9 敏捷是在每一个迭代重新审查需求？

敏捷并不是重新审查需求，而是在适当的时间点才把需求逐步细化。所以，在项目启动的时候，我们会把需求展开为大的用户故事。进一步发布计划的时候再把大的用户故事切分为小的用户故事，并且讨论跟记录用户故事的验收条件。在迭代计划的时候讨论跟记录验收的用例，并把这个用户故事再分解为工作。

误区10 敏捷不能抛弃传统的项目管理方法？

认为要使用敏捷项目管理，一定要先学会传统项目管理，这也是不对的。敏捷工作者不一定要先学传统的项目管理，也可以采用单一敏捷，敏捷跟传统混合，敏捷跟敏捷混合的方式。如果是新创公司，没有以前的包袱，为什么一定要先用传统再变敏捷呢？可以直接采用敏捷项目管理的方式来进行项目的管理。