《软件工程实践者的思想(PDF格式)》第22章

环节也有各自的方法论，即使站在具体环节之外，过程本　
身也有方法论的问题，这还不包括管理方法等等在内。
由于方法在过程环节以及过程总体层面上具有贯通　
性，因此保证“方法（或其行为）　”的实施的“工具”也会　
…99
…………………………………………………………Page　104……………………………………………………………
第　8　章 是思考还是思想
出现在过程的各个环节和层面上。因此这样得到的软件工　
程模型将不是经典的、层状的“牛屎图”，而可能象太极　
图一样由阴阳交汇而生万物。
为了不使读者认为我已经入了道家理论的歧途，这样　
的一副图还是交由你自己去画吧。只不过你应该清楚，即　
使画出了太极图的软件工程模型，你所视见到的仍旧是工　
程的细部环节。就如同以管窥豹一般，斑是斑，豹是豹。
你能把每一个“管见”拼合起来，你得到的才能是　
“豹”，而不是“斑”。所以尽管本书割裂了软件工程的各　
个要素，并从每个孤立的层面来审视。然而实质上，你应　
该回归到软件工程的本体上来思考问题，而不是仅关注于　
每一个局部的要素。
工程的整体问题仍旧是“实现”。
2。 其实　RUP　是一个杂物箱
我或许总是在批评　RUP　，但是我不得不承认它是对　
前人在软件过程思想方面高度包容。
请注意我用“包容”这个词，而不是按照语言习惯那　
样用“概括”。因为如果是“高度概括”，那你应该把目光　
投向瀑布模型，而　RUP　其实就象一个杂物箱一样“包容”　
了全部的已知理论。
你可以把　RUP 定制成其它任何模型所表述的过程形　
态。——RUP 本身的特质决定了这一点。——因而它也　
如同一个杂物箱一样放满了各种希奇古怪的东西。你可能　
…100
…………………………………………………………Page　105……………………………………………………………
『大道至简』
从这个杂物箱里面拿出了一把剪刀，或一只苍蝇拍，或者　
是一根钓杆……
喂，等等。面对“软件开发”这样的一个需求，钓杆　
能有什么作用呢？在你扔掉它之前，请转换一下你的思　
维：钓杆可能带给你的团队以精神上的激励。如果你能意　
识到这一点，那么它将立即转化为生产力：把钓杆挂在开　
发部的墙上。
RUP 能不能被用起来，将取决于在于你刚才那个挑　
挑捡捡的行为，以及现在你在拿到钓杆后的辨识能力与组　
织能力。
…101
…………………………………………………………Page　106……………………………………………………………
第　8　章 是思考还是思想
3。 UML　与甲骨文之间的异同
在你真的打算用甲骨文来写项目文档之前，请先明确　
UML　与甲骨文之间的异同。
在这本书里，他们都被作为沟通的工具。因此目标是　
沟通，而不是“选用工具”这件事本身。更进一步的推论　
是：即使你因为个人喜好而选择了甲骨文，也不要试图在　
结绳记事的原始人面前去用它。
UML 与甲骨文都是符号文字，都具有象形含义。然　
而这并不表明　UML　符号本身能表达多么丰富的含义。如　
果要象甲骨文一样用几代人、上千册的论著去解释它，那　
么　UML 图的价值也就只剩下象征性的意义了。
出于沟通的必要，这种语言的象征意义在一个图中应　
当被表述得足够准确和详细，乃至于针对于不同的阅读者　
来说都能提供了充足的信息。然而，一方面　UML 的规范　
中没有提供一个标准来衡量“怎样的　UML 图是描述充分　
的”；另一方面，UML　作为一个语言，也无法直接在某个　
硬件平台中被语法检错和调试。
所以在工程中使用　UML 图，应该有相应的文字来描　
述它。而且这种描述与图之间的对应关系要持续地维护下　
去。如果这种关系松散了、断裂了，那么下一个阅读　UML　
图的人所面对的，将是无异于甲骨文出土时的困境。
…102
…………………………………………………………Page　107……………………………………………………………
『大道至简』
好在做　UML 图的那个工程设计人员（在辞世之前）还　
有机会为这些古怪符号写下规约。
4。 经营者离开发者很远，反之亦然
使我第一次意识到　EHM　模型反映了角色所关注的不　
同视角的人，是我的老板。
事实上，他是一个完全不懂软件技术的老板。在　EHM　
模型中，他所处于的位置在最右端，而开发者在最左端，　
在二者之间没有相同的关注界面（关注点）　。EHM　真实地反　
应了“老板不懂技术”的合理性，同样也真实的反应了“开　
发者转型为老板”的道路将是相当地漫长与艰难。
于是，项目经理这个中间角色就有了一种使命：协调　
经营者与开发者之间的沟通。
例如招来一名开发高手，对于公司的运作并不会有深　
入的影响（　当然如果你招来了　Anders Hejlsberg　就另当别　
论）　。因此，我甚至不需要与　BOSS 讨论这名高手的来历　
及作用。同样，与一个技术分析人员讨论一个产品的技术　
价值与市场价值之间的差异，以及市场运作方式与技术实　
现手段的无关性，是毫无必要的。
你要理解这种根源：角色的关注层面完全不同。
…103
…………………………………………………………Page　108……………………………………………………………
第　8　章 是思考还是思想
5。 矛盾：实现目标与保障质量
在需求阶段我们就会面临“目标”的问题。然而（在　
大多数时候）　，与此相反的是我们会在项目交付和试用时　
才会碰到客户在质量上的投诉。
需求人员会把所有的责任归咎到开发人员，而开发人　
员又不停地埋怨需求的不清不楚或者变更的没完没了。又　
如果正巧需求和开发都是同一个人或者小组来做的，那么　
他们便会开始埋怨客户的苛刻以及工期的紧张。
总之一件事，没有人会跳出来说：我们原本就错了。　
然而事实上可能真的出在源头：我们把目标定错了。
我们看到，在项目的平衡三角（　时间、资源和功能）　中　
讨论的是目标问题，但并不讨论质量问题。也就是说，经　
典教材中总是关注：如何更快的完成项目，并减少资源占　
用，以及实现更多的功能。然而，即使平衡了这种关系，　
项目的结果仍可能产生一个天生的残障。
因为目标可能在平衡中确立，但质量却要在过程中控　
制。即使在时间、资源和功能三者中取得了平衡，即使客　
户、项目组和公司同样满意于这个平衡“目标”，它仍然　
有可能是“不能实施”的。
如果原定的目标（　的整体）本身就过大，那么无论如何　
平衡这三者之间的关系，其结果仍旧是保障不了质量。
…104
…………………………………………………………Page　109…………………………………………