1.2.5 软件与模型构建

作者: Alistair Cockburn著，苏敬凯译 出处:机械工业出版社华章公司 　2008-02-21 15:59　   砖    好    评论  条 　进入论坛

阅读提示：《敏捷软件开发》以“软件是创造和沟通的合作博弈”为中心向读者展示一个看待软件开发的崭新视角。第一章内容写了创造和沟通的合作博弈，本文是讲了软件与模型构建。

1.2.5   软件与模型构建

在最近的10年中，很多人都在提倡模型构建，包括Ivar Jacobson，他宣称：“软件开发就是模型构建”。
把软件开发刻画为工程化，并不能为管理项目提供大量的指导，而把它刻画成模型构建，则直接会导致不适当的项目决策。

如果软件开发是模型构建，那么对于软件或开发过程的质量的度量就应该是模型的质量、它们相对现实世界的保真度以及它们的完全程度。然而，全世界几十个成功的项目团队告诉我：

“我们所要表达的东西的有趣部分没有记录在那些模型里。有趣的部分是我们一边在白板上画一边跟对方说的东西。
我们没有时间创建精美或完整的模型。我们往往根本没有时间创建模型。”

我发现，在那些人们在勤奋地创建模型的项目中，软件都没能交付。对于模型的关注阻碍了软件的开发。

构造模型不是项目的目的。只有当它能帮助赢得这次博弈的时候，构建模型才令人感兴趣。 博弈的目的是交付软件。任何其他活动都是次要的。模型就像任何一种沟通一样，只要它能使下一个人继续他的工作，这个模型就足够了。

应当对团队的工作产品进行度量的是它们在向目标组传达信息方面的充足性。模型不完全、画图时使用了错误的语法以及实际上模型不像真实世界，这些都不是问题，只要他们能够传达充分的信息给接收者就行。

正如Jim Sawyer在一封讨论用例的电子邮件（Cockburn 2001c）中曾经精彩地说过：

“……只要模板感觉上不是那么正式，以至于在通往设计空间的路上，你就会迷失在满是蛀洞的递归下降之中。如果开始发生这种情况了，我说那就干脆剥去这裸露的小家伙并开始讲故事和在餐巾上乱画”。
沟通的效果比沟通的形式更重要。

与有些不成功的团队相比，有些成功的项目团队构建的模型更多、更精美。很多人由此得出了建模越多越好的结论。

与有些不成功的团队相比，有些成功的团队构建的模型更少、更马虎。另外一些人则由此得出了建模越少越好的结论。

这两种结论都没有根据。建模是团队沟通的一部分。过多建模和过少建模都可以。有时在餐巾上画个草图就足够了，而有时则需要更详细一些。

理解应进行多少建模以及在什么时候建模，正是本书的主题。应把软件开发作为一个有首要目标和次要目标的合作博弈来思考，这样会帮助你深刻地理解如何细化要构建的模型或者否确实需要构建模型。

回书目   上一节   下一节