聊我所理解的敏捷(Agile)——外一篇

那些众所周知的敏捷宣言，敏捷方法，敏捷教科书，敏捷大神，我就不提了。只是聊聊，我所理解的敏捷的本质。

敏捷的本质，是承认软件开发的复杂性。而且承认，这种复杂性，达到了这样一种程度：“无法通过足够充分的前期准备，而消除后续的风险。甚至于，前期准备得越是充分，后续的风险越大。”

往往有很多人，将建造大楼与软件开发做简单的类比，以说明前期设计的重要性。但事实上，我们无法想象，一幢大楼，在接近完工的时候，有新需求出来，要求整个设计从从一幢四边形的楼，变成一幢六边形的楼。

但是，在软件开发领域，就是会出现这样的需求，而且，这种需求虽然会被所有的开发人员痛骂，但却“实际上具有其合理性”。

如何理解需求的复杂性、易变性？

软件的出现，还不到100年。建筑的历史，则至少有5~6千年了吧。人类对于建筑的需求，已经足够稳定（相对于软件而言）。另一方面，软件的可能性，又实在是太强大了，至少重力因素软件可以毫不考虑。

软件开发这个领域，还太年轻，大家都没有足够的经验。年轻到了，甚至现在去急于总结经验，都是错误的！

来源于Christopher Alexander《A Pattern Language: Towns, Buildings, Construction》曾经给予Gang of Four以巨大的启发，所以他们写出了著名的《Design Patterns: Elements of Reusable Object-Oriented Software》。

但是，现在看来，设计模式的流毒真的不少...

所谓敏捷方法，不过是一种需求发现与谈判策略

过去的思路，认为需要尽可能发现所有的需求，并且做好设计，然后再开始开发。现在大家已经意识到，一边做，一边确认，一边发现，一边纠正。从总体成本上衡量，反而会更加低。

但是，在实际施行敏捷的过程中，“一边做，一边确认，一边发现，一边纠正”，也同样可能存在巨大的浪费。而且，因为披上了敏捷的外衣，反而变得无可指责了。

本质上，这是一种对于开发方，而非需求方，更加有利的谈判策略。

总结陈词

我们现在还缺少一系列量化的手段，去衡量需求的复杂度，开发的效率以及各种流程方法的优劣。（不要跟我提Function Point Estimation，那种教授坐在书桌边发明的方法~~）

因为缺乏这种量化，所以大师满天飞，却让人无所适从。

外一篇：“设计模式的荼毒”体现在何处？

可以从两个角度来谈这个问题：

1. 建筑里的结构工程师，如何设计结构？

我们都知道，建筑设计中的结构工程师，非常重要，而且，他们必须非常深入的了解数学这门学问。

在结构设计出来之后，他们还需要做一些模拟与演算，以确保他们设计的结构，能够承载整个建筑。

再进一步，一个敢于设计结构的结构工程师，有很长的一个学习阶段，以了解前辈大师的经典结构与数学模型。

可以说，建筑结构学，是一门科学，是一门以数学模型和科学实验为基础的严谨的科学。

2. 中医如何看病

中医，也有一套理论：阴阳呀、五行呀、相生相克呀，等等等等。在这套理论的基础上，也有上千年的经验积累，什么药吃了能治什么病，大概是什么计量。

但是，说到底，这是一门「经验科学」，或者直白一点说：「这不是一门科学」。

声明一下：我不是中医黑，虽然我也不是中医粉，至少中医的确有大师，他们真的治好了很多病人，这个我绝不会否认。

毕竟：疗效的好坏，还是很难伪造的。

3. 软件架构师，如何设计架构？

架构师，看起来很像结构工程师，但是：他们没有科学基础，只有一些「设计模式」和「架构模式」。

那些「模式」的有效性与适用范围，并无严谨的证明，只有一些模模糊糊的「实践案例」。

「听说设计模式是好东西」，就像「听说人参大补元气」一样。真正的中医，尚且不敢给病人乱开人参，但是架构师，他们真敢把所有的「设计模式」都用上。

中医再怎么不靠谱，真是把病人给治死了，医生也会吃不了兜着走。但是，我们什么时候听说过一个项目的失败，是因为架构师不合格呢？

还有个更大的罪魁祸首「需求变动」顶在前面呢。

4. 总结陈词

一种「理论」却没有严谨的理论支撑，一门「手艺」却难以客观的评价手艺高低，随便看两本模式的书，就敢开整。没有流毒，就怪了。