承接上篇。

       PMBOK的第5章《项目范围管理》提出了“敏捷方法特意在项目早期缩短定义和协商范围的时间，并为持续探索和明确范围而延长创建相应过程的时间。“指的就是SCRUM中的快速启动“QuickStart”和在多个Sprint中持续探索。“并通过多次发布版本来明确需求。这样一来，范围会在在整个项目期间被定义和再定义”，SCRUM要求每个Sprint都有可交付的产品增量，而Kanban通过持续的流式交付，渐渐完成整个目标范围。“在敏捷方法中，把需求列入未完项。”，SCRUM通过产品待办事项列表来收集需求条目，Kanban通过可视化和显式化规则将不同的工作输入定义成不同类型的工作项，需求是其中一种。

        PMBOK的第6章《项目进度管理》提出的“具有未完项的迭代型进度计划”描述的是SCRUM，“按需进度计划”描述的是Kanban。在“控制进度”方面列举了很多，与之对应的精益敏捷实践包括SCRUM中的Sprint 计划会议，每日Scrum站会，Sprint 评审会议，Sprint回顾会议，产品待办列表梳理；Kanban中的管理流动，建立反馈、持续改进实践。值得一提的是，在本章的小节“6.5.2.8 敏捷发布规划”，PMBOK较完整的描述了敏捷产品规划，说明PMBOK已经对精益敏捷方法大范围的应用于产品开发进行了考量，并从规划的角度去观察。

        PMBOK的第7章《项目成本管理》较简单，只是提出了“可以采用轻量级估算方法快速生成对项目人力成本的高层级预测，在出现变更时容易调整预测；而详细的估算适用于采用准时制的短期规划。”在精益敏捷中，一般对需求条目采用用户故事点数估算，对工作任务采取工时进行基础估算。当然，也有采用其他方式的。

       PMBOK的第8章《项目质量管理》提出了项目质量管理的新趋势有“客户满意”，敏捷价值观和精益思想均以客户满意，产生价值为终极目标，价值导向是精益敏捷方法的原生基因之一。对于新趋势“持续改进”，SCRUM的计划会议-每日站会-评审会议-回顾会议就是一个完整的PDCA循环，而“Kaizen”（持续改进）也是精益思想的支柱，可以说持续改进也是精益敏捷方法的原生基因之一。对于新趋势“与供应商的互利合作关系”，敏捷宣言就明确提出了“客户合作高于合同谈判”。

        PMBOK的第9章《项目资源管理》提出自组织团队和协作型团队，SCRUM追求自组织团队，Kanban追求工作流的顺畅流动，需要团队顺畅协作。

        PMBOK的第10章《项目资源管理》提出将相关方纳入项目评审范围，SCRUM的Sprint评审会议，Kanban里面的快速反馈都反映了这一点。PMBOK提出的“更频繁和快速的沟通”，敏捷宣言中的“个体与互动高于流程与工具”，Kanban中的可视化价值流、显式化规则、建立反馈都深刻体现了这一点。

       PMBOK的第11章《项目风险管理》提出“通过跨职能项目团队和经常审查增量式工作产品，来加快知识分享，确保对风险的认知和管理。在选择每个迭代期的工作内容时，应该考虑风险；在每个迭代期间应该识别、分析和管理风险。”，精益敏捷方法一直强调全过程进行风控，因为只有全过程风控，才能更好的适应未知性。

       PMBOK的第13章《项目相关方管理》提出了适应型团队会直接与相关方互动，为加快组织内部和组织之间的信息分享，敏捷型方法提倡高度透明，这些新的趋势与精益敏捷方法对团队的要求不谋而合。

       以上，我们列举了PMBOK各章节中“敏捷项目管理”相关内容与精益敏捷方法的对比。通过对比，我们能够看出新版PMBOK对“敏捷项目管理“还处在探索阶段，但是管中窥豹，我们仍然能够从这些点滴浅析出PMBOK对“敏捷项目管理”这一领域趋势化的特征：

1. “适应性”项目所要求具备的知识技能在项目经理自身知识技能的比重会越来越大。

2. 随着“适应性”项目的需求越来越多，作为业界权威的标准组织，“敏捷项目管理”方法论的构建是PMBOK的重点方向之一。

3. 在各章节中分别描述“敏捷项目管理”，说明PMBOK开始尝试用自己的项目管理体系结构来描述“敏捷项目管理”。

4. 各章节的“敏捷”描述，只是点滴，离知识体系的系统化还有很长的路要走。

当然路很长，必然也面临很多挑战和机遇，窃以为如下：

1. PMBOK吸取精益敏捷的方法来完善“敏捷项目管理”，怎样将精益敏捷方法中的“实践”转换成PMBOK的项目管理体系结构语言，或者说怎样将精益敏捷“实践”的独立性与项目管理“知识领域”的系统性应对好，是一个很大的挑战。

2. 现在的精益敏捷方法更多是从“工程“、“实践”的角度来构建的，如果PMBOK能够用现有的或者是独创的一套知识体系从“管理”的角度来构建清楚“敏捷项目管理”，那么，对于我们广大项目管理者将是一个福音。