按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
“用你的话来说，不是真正的设计。”
项目管理通俗读物 最后期限 ID2002
173
“对，当然，以后会有一个设计出现，作为编码的副产品。但是被叫做‘设计’
的行为却没有制造出真正的设计，所以只能得到一个F，”
“嗯。所有的小团队都得了A和B，大团队则都得了F，这是怎么回事？”
“我还想问你呢。这是个难题。”
“首先，我注意到：如果没有一个好的设计．那么‘先贤’所说的‘最后一分
钟实现’就没有可能。”
“非常好，韦伯斯特，你开始进入状态了。”
“我还不敢肯定为什么A团队都这么惨。我可以肯定的是：他们根本不可能像我
们希望的那样进行编码之前的设计。”
“完全正确。实际上，他们根本不会实施‘最后一分钟实现’。这六个团队都
已经开始编码很久了。我没能说服他们推迟实现。我试过了，但是没有成功。”
“其他团队呢？”
“虽然程度不同，但是所有的B、c团队都在尝试先贤的方法。他们都在努力推
迟实现，并且在写下任何一行代码之前先尽可能地检查。其中的一些团队甚至严格
地将编码推迟到了最后的6个星期。”
“A团队没有这样做？”
“没有。”
“好吧．我认输了，这是为什么？’
科诺罗斯重重地坐在汤普金斯的安乐椅上，咧嘴笑着，但是没有回答。
汤普金斯又催问了一遍： “为什么A团队都没能做出设计？”
“太大了。”
“什么？”
“这就是我的理论。这些团队太大了。在本应该做设计的时间里，他们有太多
的人牵涉进来。设计是应该由小团队来做的，你可以让三个、四个或者五个人聚在
白板周围，一起进行设计。但是，你无法让20个人围在白板周围。”
“我还是不知道这会对设计有什么影响。你可以让三个、四个或者五个人去做
设计，其他人去做别的工作。为什么不呢？为什么他们不能去做别的事？”
“有什么别的事？”
项目管理通俗读物 最后期限 ID2002
174
“我不知道，总有什么事可做吧。”
“设汁是将整体划分为部分的关键。只要做完了这一步，你就可以把小块的工
作分配给手下人，让他们分别去完成。但是在此之前，你没有小块的工作，只有一
个整体。既然问题是一个整体，员工们就只能作为一个整体团队来处理它了。”
“这也无法解释他们为什么跳过了设计阶段。如果这件事必须做，那就必须先
做好它。经理可以让一支小团队去工作，让其他人都耐心等着。如果没有别的事可
做，就让他们到一边坐着去。”
“对。我想这就是QuickerstA团队的情况。”科诺罗斯说道，“但是，请从项
目经理的立场来想想你的‘解决方案’。假如你正在管理一个大型项目，你的团队
从第一天开始就有30个人，你还有一个紧迫的时间安排——这正是他们给你那么多
人的原因。现在，你能让25个人到一边去坐两个月吗？”
“我明白你的意思了。他们会造反的。”
“当然。而且，你会成为众矢之的。想象一下，你要怎么去见你的老板，还有
你老板的老板？你可以在六月一号之前完成任务，但是一大半的人都在消磨时间。”
“嗯。我看上来不像一个真正的经理。”
“你不像。那么，你想怎么做？，’
“好吧，我得给那些人找点事干。”汤普金斯说道，“我想，我应该去把整个
的问题切成小块，再分配给他们。”
“对。既然根据定义．设计就是按照合理的方式将问题切分成小块，那么你就
应该尽早完成切分，从而缩短设计的过程。”
“我明白了。早期，我为了分配工作而进行的任务划分反倒成了设计的笑柄。
必须这样做吗？”
“不完全是，但是很大程度上是这样。的确，在设计完成之前．总会有些小事
可以消磨时间的。但是，如果你想让大量的人都有工作，这些小事根本就不够。”
“为了让所有人都能做关键路线上的工作，我必须将设计本身适当划分。”
“现在，你该明白他们为什么最后没有任何设计了。”科诺罗斯说道，“你粗
略地把整个工作分成五块或者十块，这样你就可以让五个或音十个设计团队一起工
作。粗分是一个设计步骤，但是你并没有把它当成一个设计步骤。你其实是把它当
项目管理通俗读物 最后期限 ID2002
175
成一次人员划分。”
“而最初的这次粗分，就像你说的，正是设计的核心。”
“是的。．而且，既然没有人直接负责复审它的逻辑，它就会一直是设计的核
心。结果就是没有设计。更糟的是，编码和测试是最能消耗人力的工作，所以总会
有一种诱惑。让经理们想立刻开始这些工作，哪怕根本还没完成任何设计。”
汤普金斯先生还不相信：“如果真是像你说的这样，那么大多数项目在设计阶
段都存在严重人员超编。所以，大多数项目都无法真正完成设计。”
科诺罗斯苦笑着：“恐怕事实正是如此。就在某个地方．就在今天，某个新的
项目又开始了，它从第一天起就严重超编。这个项目会走过所有的步骤，起码看上
去是这样，但是根本不会有真正的设计。软件内部的结构会不断发展，但却不会有
真正的设计思考或者复审。然后，也许几年之后的某一大，需要重新做这个产品的
时候，新项目组的一个成员会对设计进行彻底的整理，他会重新组织出真正的设计。
而下面会发生的就非常可悲了。”
“什么可悲的事情？”
“以后重新工作的人才是第一个真正看到产品设计的人。”
在这天的大部分时间里，汤普金斯先生反复地想着“早期的超编妨碍了明智的
设计”这个概念。如果科诺罗斯的工作在某种程度上是正确的话，它就已经远远超
出了爱德里沃利。这意味着整个软件工业都处在非最优的状态，即注重早期的团队
建构，并因此做一些隐瞒真正的核心设计的工作。
贝琳达在午饭出去散步的时候，汤普金斯把这整套思想都告诉了她。她看上去
并没有被打动：“还有什么新的？管理就是不断的妥协折中，一件需要折中的事就是
设计。为了让人们有事做，你就必须接受不够完美的设计。”
“不够完美，起码也有吧。但是，假如你根本得不到设计，又怎么办？”
“总会有设计的，只是不够好而已。哪怕设计阶段完全是虚构的，也会有个设
计，否则，未来的项目组成员就永远无法从代码中重新设计。”
“好，我接受。我们讲的不是有没有设计的问题．而是在讲设计质量高低的问
项目管理通俗读物 最后期限 ID2002
176
题。既然需要模块划分的时候没有人真正考虑设计问题，那么模块划分这部分就是
做得不好的。”
贝琳达把白板擦干净。“现在，这就是我们要处理的，就像这样。”她飞快地
画着，“这是我们系统的整体，这是各部分的划分。”
“这只是一种划分方法。还有无数种别的方法。比如说．这儿就是另外一种。”
她又在第一种划分方法的旁边画上了第二种，“为了判断哪种划分方法更好，我们
需要考虑最后的接口。不必太正式，我们都知道：接口越多，系统就越复杂，划分
就越差。”
“当然，的确如此。”汤普金斯先生补充道，“不管划分的是什么。不管是在
划分系统还是在分配工作。”
贝琳达点点头：“你算说对了。现在，我们加上各部分之间的接口，我们现在
做的就是所谓的‘设计评估’．因为我们要选择接口组合最简单的划分方法．”
“那么，我们会选择右边的这个。”汤普金斯先生像一个过于热切的孩子那样
大声说道。
“对。我们会选择它，因为各部分之间的接口更少。现在，我们把这些部分分
配给团队的成员。人员的划分形式跟系统的划分形式是相同的。”她又画了一些。
“团队中人与人之间的接口跟系统各部分间的接口是同型的，所以……”贝琳
达指指两边的接口图，“……比如说，3号和4号这两个人之间的接口，就跟产品的3
号和4号这两个部分之间的接口是同型的。”
她坐下来，回头看着这些图：“现在我有点沮丧。如果模块划分的工作在设计
之前完成．人与人之问的接口肯定比真实的需要复杂得多。”
“肯定的。”韦伯斯特表示赞同，“如果在模块划分之前先做设计，人与人之
间交流的信息肯定会少得多。如果先划分模块．那么为了完成任何工作，人们都不
得不更多地与