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

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）。