纸面上的模型，焦油坑里的实践

任何软件领域的组织总在不断地寻求提升创造价值、获得收益的能力的途径，以期应对技术、社会变革加速带来的诸多不确定性。一般地，组织会从两方面尝试突破，一方面持续反思软件工程各环节中的实践，有时甚至需要从具体实践和工具中跳出来，以圈外人的身份思考需要应对的客户或社会问题的本质；另一方面开启想象力根据特定情景和特定目标创造有效的实践与工具。无论哪一种都需要在实践中落地，足够多的实践才能保证我们更容易窥见全貌。

01

—

布道与选择

大多数书籍都有一个有趣的现象，即在章节起始处往往引用名人言句，这样做的目的是什么？其实作者引用名人言句是缘于一种写到不能再写的感觉亦或是无法用逻辑去诠释实践的感觉，就如同“道可道，非常道”，更是作者希望传递给读者必须意识到的深意：我已然领悟。

再比如日常夫妻间的吵嘴，总能听到“你总是xxx”或者“你从来就是xxx”。看似简单的言语，诸如“总是”、“从来”，却流露出一方表达说到不能再说的含义，映衬出的是一方十足的坚强或无奈。

上面两种现象中，文字或语言传递的不光光是表面的意思，而是价值观的布道，更是作者心智模式的展现。在软件领域中，最富盛名价值观布道之一的恐怕就是“Python之禅”，它以一种彩蛋的形式向程序猿/媛们描绘了Python所希望弘扬的价值主张：

软件研发的方式、方法、模型万万千千，无论何种都应看作是先贤们留下的智慧，选择和使用的权利却留给我们，一旦我们做出了选择就意味着我们接受了其中的布道并进行实践，现在就要面临新的问题了：怎么用或怎么用得更好？

02

—

“瀑布”模型的例子

我们大多数人熟知的“瀑布”模型的定义通常是研发流程采取自上而下、相互衔接、固定次序，如同瀑布流水逐级下落。它给人的印象在需求变化的适应性和流程衔接的可逆性上缺乏足够的灵活。

其实“瀑布”模型只是一个形象的比喻，而非一个科学的表述。上世纪70年代，“瀑布”模型诞生在Dr Winston W. Royce所著的“Managing The Development Of Large Software Systems”（Royce 1970）一文中。十分有趣的是论文通篇未见“瀑布”字眼，然而不知从何时起“瀑布”一词在业界中得到了广泛地传播，并被不同的人不断地解构，在这一过程中概念出现了明显的“抽象泄漏”，这种泄漏逐渐含糊了作者表达，偏离了作者的初衷。作者的本意又是什么呢？

抽象泄漏——指任何试图减少或隐藏复杂性的抽象，并不能完全屏蔽细节，被屏蔽的复杂细节总可能泄漏出来

首先，来看看解读最广泛的模型图（以下图片均来自Royce所著论文）。

Royce在文中指出迭代需要在上下两个连续步骤之间进行并且又贴近现实地强调设计迭代永远不会局限于在连续的两个步骤之间进行。

Royce在基本模型中加入关键的5条必要特性用于应对大多数开发风险：

预先的程序设计——架构师参与设计；定义、设计、划分数据模块；写一个概要文件；

足够的文档

成本允许时，尽可能细化，验证每一小步（DO IT TWICE）

计划、控制、监控测试

客户参与

因此，Royce在论文中提出的模型实际是下面这样的，而不是我们所熟悉的“瀑布”。

03

—

思考

从上面的例子可以看到论文中的模型是如此的复杂和完整，但大多数人在执行时出现了退化，如果再遇上不恰当的裁剪和省略就容易跌入焦油坑，这就是理论和实践的矛盾。由此引申，单就每个项目而言，是否使用“瀑布”模型取决你是否能够理解客户的需求，以及在项目进程中是否能够理解需求的变化。“没有调查研究就没有发言权”，这是一个持续思考和实践的过程，两者缺一不可。

04

—

结语

世界是无一息不变的，模型总是存在于纸面而将模型付诸实践却会遭遇各种各样的问题，说不定会陷入令人头疼的焦油坑。

“条条大路通罗马”，在软件研发这条路上选择何种模式其实并不是最重要，关键是倾注你所有的相信（心智模式）接受你的选择，然后积极响应外界变化，积微成著，时刻保持成长性思维去看待和实践我们选择的方法、模型。