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

  • Amr Elssamadisy
  • 郑柯

2008 年 8 月 23 日

话题:敏捷Scrum文化 & 方法

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

敏捷Scrum文化 & 方法