软件开发与交通阻塞的相似之处

Ken Delong 解释了他认为软件开发“超级困难”的原因：

每个人都知道编写软件很难，但是我想探讨一下为什么软件开发这么难。 软件开发受本身四个特性之困，而这些特性也将其推到了“复杂的自适应系统”之境地，并且更将其逼入混乱之困局（至少足够接近）。这些特性是：

• 非线性
• 反馈
• 时间延迟
• 变化

以上并不是什么新鲜的发现，而且我们很多人都已经对其习以为常。也许有些人虽然听说过，但却不能理解背后的真正含义。这也使得 Ken 的博客文章有了用武之地：

在高峰期时，公路上车流密集，也许大家的行驶速度都还不慢。突然，某个人想看看车外的风景，将时速降至 30 英里，而且只维持了几秒钟。这会带来什么后果？交通大堵塞。曾经经历过堵得一辆接一辆的路况吧，却没想到突然可以时速 70 英里前进？之前的状况，是因为出现了变化——有人想游车河，非线性因素掺杂在一起，造成堵车。很多类似复杂系统都是可以自我维系的，交通堵塞正是其中一例。最后还是畅通了，但是其恢复速度却远低于任何人的直觉。

一个人减速——这并非偶然事件——却造成全线大塞车！问题的关键在哪里？软件既难而又危险，最微小的事情也有可能导致全盘皆输。难道就这样束手就擒么？

要想在流量有限的高速公路上避免严重塞车，就得让大家都把尾灯打开，这样可以让整个交通系统的利用率保持在安全的水平，一些正常的变化也就不会被无限放大、造成问题。我们在处理生产系统服务器的 CPU 占用率问题时，采用了同样的方式。我们会让 CPU 的占用率不超过 30%，这样就可以防止峰值流量对服务器造成过大冲击。

因此，系统中必须提供反馈机制，使得它可以应对变化，不至于因此而崩溃：

在敏捷中，可以调整一个 sprint 接受的故事点数，以使 sprint 中的所有任务都能在 sprint 之内抵达“完成”状态。这就是“尾灯效应”。

Jurgen Appelo 在《敏捷项目时间管理 10 原则》一文中提出的十项原则，可以视作敏捷软件开发的调整和“尾灯”：

1. 定义“完成”条件
2. 使用时间盒管理工作
3. 不要为任务估算添加松懈时间
4. 推迟决策
5. 减少周期时间
6. 让处理管道短小而狭窄
7. 保持纪律
8. 减少任务切换
9. 防止长时间连续加班
10. 分离“严重程度”和“紧急程度”

Jurgen 详细阐述了这十条原则，并提供了各自深入阅读的参考资料。软件开发之难，很大程度上因为其过程类似于复杂的自适应系统。敏捷，如果可以正确实施，将会提供稳定的反馈。

查看英文原文： Software Developer：A Traffic Jam Waiting To Happen

在英文站文后的评论中，读者 Karl Scotland 指出：利用“看版”系统限制在制品，可以“让整个系统的利用率保持在安全的水平，一些正常的变化也就不会被无限放大、造成问题。” 读者 Jim Leonardo 在名为“避免拥塞，保持距离”的评论中说到：

若想使用拥塞作为比喻，我建议先定义其真正含义。拥塞等同于瓶颈。团队构成上的问题，可能会造成有些人在忙着解决难题的时候，其他人却处于空闲状态。如果有这些情况发生，你应该考虑一下因素： 1） 团队中人员的职责是不是划分得太明确了？如果有瓶颈产生，是不是因为在跨职能方面做得不够？赶紧多做点培训，多进行知识分享吧。

2） 有多少任务需要其他任务作为前置条件？如果因为前置任务没有完成，导致有些人的工作限于停滞，是否有其他的任务可供这些人上手开始工作？对于团队和项目来说，功能特性切分成任务的方式合理么？是不是可以用另外的方式进行划分、组织开发？

3） 简单之极……为任务的开发准备足够的时间了么？现实一点，如果总是发现瓶颈（拥塞），也许是因为过于低估了某些类型的任务的完成时间，或者在做规划时没有考虑到不同的开发速度（要注意，“速度慢”的开发者之所以慢，可能是因为他们对代码质量的要求比较高，所以要全面考虑问题）

最后一点，也是我最想在 infoq 上反复强调的……

4） 团队的工作时间是不是太长了？有人陷入停滞，是不是因为他们觉得自己应该每周工作 70 个小时？相反地，总是成为瓶颈的程序员，是不是也是把所有时间都投入工作的那位？倘若果真如此，这个人就像一个正在形成的火药桶。如果它现在还没有爆发，将来一定会（强制对他的代码进行复查绝对不可取！）。

作者 Amr Elssamadisy 引用了 Flemming Funch 的博客，对于 complex 和 complicated 之间的不同进行了分析：

我们每天都会用“complicated”和“complex”，不相区分。要讨论复杂性（complexity）就变得困难了，比如说探讨自然界中的复杂性。 可以说我们需要复杂性的科学定义，可是科学却给出了至少 32 种不同的诠释，每种都不一样。要是我们能摆脱迷惑的困扰，就可以发现下面这种可行的说法：

构成上的复杂性（complicated），是指某项事物包含了很多错综关联在一起的组成部分，很难搞清楚各个部分之间的关系。即使能搞清楚，也不能保证这些部分是以合理的方式组合在一起的。

系统上的复杂性（complex），是指某项事物作为一个系统出现，它所展示的系统属性并不明显。这与一些部分的简单叠加之和有所不同，更难以理解。构成的部分不一定很多，但是组合在一起之后的结果却难以搞得很明白，在某些方面以一个整体的方式呈现。

一架空客 380 具有构成上的复杂性（complicated）。一条水母具有系统上的复杂性（complex）。巴黎地铁网络具备构成上的复杂性（complicated），人们使用它的方式具有系统上的复杂性（complex）。你的骨骼框架具备构成上的复杂性（complicated），作为人的你具有系统上的复杂性（complex）。一栋建筑物是具有构成上的复杂性（complicated），而一个城市具有系统上的复杂性（complex）。