[知乎专栏–思考IT]聊我所理解的敏捷(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. 总结陈词

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

发表评论

电子邮件地址不会被公开。