提到 XP 的关键实践，就不得不拿出下面这张图。看着眼熟不？是不是很多内容我们在上篇文章中其实都已经讲过了。没错，可能有些概念你很清楚，但有些概念你就完全没听说过了。
恭喜大家，当然也要一起恭喜我自己，又是一个大型的连载系列完成了。前前后后差不多也有半年时间，对比技术类的文章来说，项目管理这类理论学科的内容其实会更难写一些。一是篇幅不像技术类的文章好凑，贴几段代码文章就会显得很长；二呢也是需要参考很多的资料
在学习完风险、问题之后，我们再继续学习一个简单的内容，是和 QA 有关的缺陷、质量方面的内容。关于这一点，又要搬出 PMP 了。在 PMP 中，质量管理也是一个非常重要而且非常大的章节。是范围、成本、进度三大知识领域外最最重要的一个知识领域。还记得在开篇文章中我们讲过 PMP 有
风险，一般来说会是我们预估的，可能会发生的“问题”。而 问题 ，则是已经出现并且放在你面前的麻烦事。不管你做任何事，做任何项目，风险有可能发生，也有可能不会发生，但问题，你一定会遇到。有的问题在成为问题之前不一定会是风险，因为可能你都没有察觉到它，它就出现了。
在 PMP 中，风险是一个重要的章节，并且有许多的过程，比如说我们要识别风险、进行定性定量分析、应对风险等，工具方面也有决策树、敏捷性分析等，最后还有一个风险应对和机会应对（PMP认为风险和机会是对应的）。这些内容其实是相当有意思的，不过这并不是我们在敏捷中学习的重点。
在敏捷团队中，我们一直会说没有项目经理，而传统的项目经理这个角色，更多的会体现在敏捷教练这个角色中。对于传统的项目管理，项目经理要管理团队成员，管理项目计划。而在敏捷团队中的教练，则更多的是一种服务式的领导，很少有管理成分。当然，并不是说完全没有管理，只是我们认为领导力会更优于管理
在传统企业中，要想达到高绩效，往往是需要非常多的管理过程参与。也就是说，我们会制定许多的规则、制度以及奖惩措施，并通过各种激励手段来达到让团队努力冲冲冲的干劲。而在敏捷中，我们提倡的是自组织、自管理的团队，而且从头到尾，我们也一直强调 SM 要以领导的方式来带领团队，而不是管理。
前面讲了很多东西，是不是都感觉和 PO 有很大的关系。但其实 SM 也是一直贯穿其中的，当然，这也是敏捷中最重要的部分。因为我们要将有价值的内容给客户，那么如何识别价值，如何与相关方合作，如何进行敏捷规划都是决定一个项目产品的关键。剩下的还有什么呢？别忘了，敏捷中还有非常重要的一点，那就是“人”。
上篇文章用大量篇幅学习了敏捷中计划的概念以及用户故事的估算，毕竟都是新东西，所以大家还是要好好消化消化。今天我们主要学习的是敏捷计划的具体实施以及敏捷的适应问题。适应其实是针对于计划的变动、修改方面的相关内容。
我们已经准备好了用户故事，也了解到了用户故事的一些相关的知识。这个时候，就要开始敏捷计划的制定。我们将学习到一系列的概念和方法用于敏捷中计划的制定。或许他们和 PMP 中关于计划的概念和形式有很大的不同，但这也是敏捷和传统项目管理最典型的区别。
经过上一篇的学习，你对用户故事有了一个大概的了解了吗？用户故事这个东西，是需要多多练习的，并且最好是有经验的 Scrum Master 能够带着你一起学习并建立合适的用户故事应用到实际的项目开发中。对于用户故事来说，我们还有一个层次的概念以及用户故事地图的概念
一看到这个标题，是不是感觉马上就激动起来了，自从讲完敏捷框架之后，我估计大家最激动的地方就在今天这篇文章了。用户故事这个东西吧，现在已经是在敏捷中用来描述需求的通用工具了。但凡提敏捷，必须要问用户故事。之前我们学习过的 待办事项列表 ，迭代冲刺事项列表 之类的内容，记录的都是用户故事。
这篇文章的内容我觉得会比较有用，怎么说呢，我们即将学习到的都是可以在日常工作生活中应用到的，而且马上就可以尝试的内容。而且，从我工作这些年的经历来看，会说话，会沟通的人真的是自带光环属性加成的。
讨论完相关方参与和愿景规划之后，我们就来到了如何管理相关方参与。前面已经说过，用“管理”这个词在敏捷中是不恰当的，因此，我们用增强相关方的沟通和协作来说会更好一些。既然是沟通和协作，那么必然就要学习一些工具技术来帮助我们实现增强的目的。今天的文章主要来讲的就是这些工具和技术。
对于敏捷来说，相关方是可以包括任何与项目有关的人的。也就是说，不管是客户、用户、高层领导、甲方员工，只要是与我们要进行的项目有关联的人都是相关方。在 PMP 的十大知识领域中，有一个 管理相关方 ，但是从敏捷的角度来看，我们与相关方应该是相辅相成的，所以，用 “参与” 会更合适些。
在学习了评估价值和为需求排定价值优先级的一些方法之后，我们接下来就看看在迭代或者冲刺中应该注意些什么才能不枉费之前的努力。毕竟前期花了那么大的精力，但是迭代冲刺之后却提交了一个没什么价值的产品，那可不是所有人愿意看到的结果。
我们已经学习过了从财务的角度来说，一个产品的价值是如何体现在金钱利润上的。这件事本无可厚非，但是，在价值驱动交付的开篇，我们又说过，一个产品的价值也并不是完全的体现在钱这件事上。因此，矛盾也就产生了，那么除了财务维度外，我们还应该怎样衡量一个产品中各项任务的价值优先级呢？
前文已述，价值在商业项目中的体现最终会回归到赚钱这个事情上。而如何衡量赚钱这个事，那就和金融财务方面的许多计算扯上关系了。项目经理需要掌握这些东西吗？可以不需要，但如果你有这方面的知识那就最好了。如果没有的话，请发挥你的情商，跟公司的财务打好关系吧。
上一大篇的敏捷框架怎么样，有没有意犹未尽的感觉？敏捷框架只是敏捷的一部分，而且是偏实践的部分。所有的教材都喜欢把这些敏捷框架写在前面也是因为这部分非常吸引人。但是，真正的敏捷还有许多理论等着我们来探索，不要着急，在学习完后面的内容之后，再回来看敏捷框架，或许你会理解得更加深入。
总算来到了 Scrum 的最后一篇文章，前面的超长文章有没有吓到大家。如果你没记住它们也没关系，看完今天这篇简单的文章内容之后，我们再回去看它们就简单易懂了。当然，如果是要准备 PMI-ACP 考试的同学，那还是尽量回去好好记住它们吧。