上一次我们聊了一下敏捷的本质（点击回顾《关于敏捷的慢思考（1）》，这一次我们将继续深入敏捷内部的知识。

没有任何一个词比“实践出真知”更加符合敏捷这门学科。

敏捷的各位至圣先贤给我们留下来的，只有敏捷软件开发宣言和配套的十二项原则。这宣言和原则我也就不再重复了，有需要的去这里查看。

挖坑小能手来了

上述的宣言和原则，就已经开始给大家留下了一些坑。

坑的第一部分是，宣言中的内容，没有一个明确的评判标准。比如“个体与互动 高于 流程和工具”。每个字我们都认识，但这里没有一个可测试的标准，这就导致了对这条的判断就会比较困难。

坑的第二部分是，十二项原则中都太过于简略，没有涉及到场景（包括了行业、公司企业文化、人员素质、项目特征等各种情况），完全就是一个大一统的说法。比如第一条原则“我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。”至少有三个词将会影响对这条的判断，分别是“持续不断”、“及早”、“客户满意”。什么样是持续不断？什么情况是及早？怎样才是客户满意？没有一个大一统的标准。

回归项目的本质

既然有坑，我们就要努力去解决这个问题，解决问题的最好办法，是回归到项目的本质来看。

这里我们以PMI-PMP中对项目的定义为准：

项目是为创造独特的产品，服务或成果而进行的临时性工作-PMOBK 第六版

这里我们提取到两个关键词——独特、临时性。

所谓独特，意味着事情是unique的，不会出现重复的情况。那么也就包含了项目目标、相关方、技术栈等相关内容。用比较正向的词来说就是“每个项目都是新鲜出炉”的。

所谓临时性，意味着项目开发过程是有一定时效性，一定时间后项目就会结束。也就是说，项目不会无限制存在。

听起来比较正常的两个概念，但是如果结合起来，就会有一个问题——“那一个项目中的经验和做法，是否可以拿到其他项目中直接照搬？”

答案比较悲催——可以借鉴，但不能照搬。也就是说，不同项目中，你的做法需要调整。

此时，你原来项目中总结出来的经验教训、包括但不限于“及早”、“客户满意”等标准，都需要废弃重新确定。

所以我们对敏捷有一个限定，敏捷的做法，即使再成功，也不能直接照搬，需要根据情况进行调整。

为什么PMP可以直接复用

同时这里也回答一个会被问到的问题：为什么PMP就可以复用？

其实PMP也不能复用，认为PMP可以复用的是一个误解。PMP本身是一个框架Framework，所以需要经过裁剪tailor才能进行使用。我们在对它裁剪的过程，本身就是一个重铸的过程，只是我们把这个过程当作太理所应当，所以没有深层次去思考裁剪到底是做了什么。

也一定会有人问：既然裁剪了，那为什么很多做法可以在不同项目中保持一致呢？这是另一个话题，这里先简单说一下：PMP中一些步骤之所以可以在不同项目中复用，因为在PMP中，研发人员是被当作资源resource，而不是人human being。所以对资源的做法，可以在不同项目中保持一致。

所以下次不要说用PMP框架可以无限复用了哦。

实践出真知

上面的内容证明了敏捷不可以直接复用，到底想说什么呢？

我想说的就是，敏捷由于其特殊性，使得很多做法不可以在项目中进行横向复制。这些特殊性包括以下几点：

敏捷足够灵活。

这个在第一部分说的比较清楚了，敏捷最底层的逻辑很松散，要求也比较宽松，很多内容没有办法一把尺子量下来。这需要我们不同场景不同分析。这里将直接导致了绝大多数所谓的“SOP”直接失效；

在敏捷中，研发人员恢复了Human Being的属性，不再是Resource，所以我们需要考虑这些研发人员的感受，并通过激发研发人员来完成项目；

不同相关方具有不同的要求，需要认真分析不同项目中相关方的诉求，这完全无法复制；

项目外部情况，包括但不限于合规性、合同要求等内容。

在上述几点中，1、2、3两点是所有困难的来源。在任何时候我们都需要记住一句话——除了人之外，所有的我们都可以计算。而人的特殊性以及人的善变性和不确定性，导致了我们需要不断的调整做法来适应当下的情况。而这，恰好是对敏捷专业人士最大的挑战。

在我这些年的工作经验中，这种挑战唯一的解法，就是“提前准备”+“灵活应对”。

提前准备的信息来源是我们过去的实践成果，它可以给我们一些指导性的意见。但我们也要明确知道，这些指导性的意见有可能是完全不可用的，我们要随时随地抛弃这些意见，因为过去的指导意见极有可能都是错的；而灵活应对则是对敏捷专业人士的临场应变提出了较高的要求，通过这些临场应变来实践项目过程中的各种未知情况，并且针对这些未知场景找到一个最符合当前情况下的解法，而这，就是实践的真谛。

到这里我相信大家对“实践”的重要意义有了一定的了解，也基本认同敏捷中实践的重要性了。

下一次我将带着大家聊一下现有的一些敏捷的误区，敬请期待。