[Best Practices] UP关键实践

[James Chan]

UP关键实践

Mr. James Chan

<james...@gmail.com>

Jan 12 2006

---

摘要

用于指导软件生产的UP（统一过程）包含了许多实践内容。众所周知，对UP应用的关键在于自定义。那么该如何自定义软件开发过程呢？对于资源有限的项目团队来讲，如何定义出符合自身情况，成本最小而又可行的软件开发过程，更是重中之重。本文中笔者将根据自身经验为大家介绍UP的关键实践。虽说这些关键实践的实施不能保证项目的成功，但是缺乏这些关键实践的项目往往必然失败。

·         UP统揽

大凡UP都涉及到业务建模、需求、分析设计、实施、测试、部署、配置和变更管理、项目管理和环境等方面的活动。完完整整地依照UP所要求的内容来实施某个项目，对于大多数项目组来讲，几乎必然导致失败。因为项目不是学术研究，是有各方面限制的。从诸多都很有用的活动中选择出最关键的几个活动是非常困难的。筛选的方法应当以保证项目成功为核心目标，评判放弃某一活动是否必然会导致项目的失败。经过在数个项目中的实践，笔者筛选出计划、概念模型、界面原形、用例等四个关键实践。不管项目约束条件如何，不管项目组资源如何，这些都是必须进行的活动。缺一都将导致开发过程的混乱，而这种混乱几乎必然导致项目失败。那么为什么会筛选出这样四个活动呢？下面我们逐个分析筛选的必然性。

计划

《孙子兵法》开章明义就讲“夫未战而庙算胜者，得算多也；未战而庙算不胜者，得算少也。多算胜少算，而况于无算乎！”，先谋而后动是关键。之后的结果是“未战妙算者，得算多也”――事先算好了能胜才可能胜。这句话很精辟地产明了计划的重要性。许多人从学着掌控项目组的第一天起就开始做计划，但是这些计划始终都摆脱不了应付客户的嫌疑，进而沦为废纸一张，乃至于成为项目经理的负担。那么既然“无用”，干脆不要是不是就好了呢？笔者在一个项目中对此进行了实验。那个项目并不困难，但是花了一个多月才做完。开发过程中随时都在脑袋里面想哪些事情已经完成，还有哪些没有做。项目初期还能想得清楚，但是随着时间的推移，到项目后期逐渐想不明白到底还有什么没做了。项目好像每天都可以结束，但是每天都发现不能结束。从第一次说项目明天可以结束到项目真正结束，月亮升起了20回――还没算阴云密布的那几天。这是一个让人“痛苦”的实验。当时做梦都在想如果上帝能够赐予一张单子，做完了的东西就打个勾，只要看看还有哪些东西没有打勾就知道还有哪些路要走。这样一来，每走一步就真的有了盼头了。

其实计划之所以沦为废纸的原因不在于重视程度不足。而是在于没有制订出可以从中获益的计划。计划本身包含两个维度：X轴是时间，Y轴是事件。可以把对计划的诉求分为两个阶段：第一阶段追求计划的完备性；第二阶段追求计划的时效性。在要做哪些事情还都没有想明白的时候，不要妄下一件事情需要多长时间做完的定论。做了也白做，一定不准。一般情况都是滞后。计划沦为废纸的根本原因就在于没有解决第一阶段的问题，而直接步入第二阶段。第一阶段的问题解决好了，那么计划至少可以告诉你还有哪些事情没做，这一点也很重要，至少它已经是有用的了。但是大多数项目计划往往只有那么草草几条，多也就几十条而已。试想这样的计划能够指导开发过程吗？想都别想。对开发过程有帮助的计划，在项目结束时应该有成百条、上千条、甚至数以万计的任务项。当然这还要取决于项目的规模、复杂程度、以及项目组成员的技术水平。计划任务项的粒度最好契合于单一任务资源能够快速独立完成的程度。如何制订有效的计划是一个很长的故事，需要单独撰文来讨论，这里就不再累述。

概念模型

概念模型有时也被称为领域模型。其目的是通过抽象的手段对目标领域的重要实体（概念）建模――产生概念及其关联。没有任何一组开发人员能够一辈子都只做驾轻就熟的系统。任何系统的开发中都必然会存在不清晰的业务或者对业务不清晰的人。那么如何才能让项目受众迅速地了解系统的目标与核心思想呢？最有效的途径就是概念模型了。哪怕是一张手绘的草图，只要符合UML规范，其作用也是不容低估的。任何人在图的辅助下只要稍加讲解，就能够迅速明白系统的核心目标是在做什么。

那么，有了概念模型之后是否就万事大吉了呢？当然不不可能，因为项目过程中还有其他许多因素左右着项目的成败。但是一个好的概念模型，必然能够为系统建立一个稳固的基础。好的概念模型具有正确、稳定、简单这样几个特点。其正确性表现为正确描述了领域中的实体及其关系，而非其他。一般而言，业务领域中对功能的要求会随着社会发展不断变化，而领域概念相对稳定的多。所以正确的概念模型大多相对比较稳定。而保持稳定的另一个有力支撑就是简单了。纵观历史，但凡被大家奉行为公理的东西都非常简单，简单到了任何人都能理解的地步――甚至简单到可能被一些人任务毫无用处的地步。譬如：两点产生一条直线。正是这种单纯性保证了它的稳定性。概念模型也是如此，细细思量，会发现对一般业务领域抽象出来的模型大多很简单。从概念模型入手，稍有经验的人都能迅速掌握系统的核心。可以说概念模型是推动理解系统的原动力。

构建好的概念模型能够从中受益良多，也许并不难于理解。那么如果产生劣质的概念模型，乃至于没有概念模型会是什么样的情况呢？开发简单系统的时候，扎一看好像没有抽象概念模型，同样也能很好地完成开发任务。其实该系统的模型已经简单到了稍有经验的人都能想得清楚，不必画出来的地步了，而并非没有。而随着系统复杂度的增加，情况加完全不同了。有时复杂的系统犹如一个盘丝洞，即便是法力强大的悟空也会昏头转向、难以自拔，更何况开发人员呢？而且随着复杂度的增加，业务需求的变化几率也在迅速增加，也就是说开发人员的成果更有可能被付之一炬。此时的开发人员犹如捆在焦油坑里的史前巨兽，虽有浑身力气却始终挽救不了被吞没的命运。若此时能够有依赖良好概念模型构建的内核就能够为系统提供相对稳定的基础，同时能够有效地保护开发人员的努力成果――血汗不能白流。

读到这里也许有人会问，怎么才能构建好的概念模型呢？同样这也是一个很长的故事，需要单独找时间来讨论了。

界面原型

很少有系统是给自己开发的。系统开发过程的终极目标是提供满足业务要求的系统。这就要求必须有人能够评判系统是否满足业务要求。鉴于软件开发技术与业务领域知识的隔阂，这两个部分知识一般分别集中在两类不同的人身上――软件开发人员和业务专家。由于立足点不同，语境不同，导致他们之间的往往会出现沟通问题，最终技术人员生产的产品与业务专家的想象相去甚远。为了解决这个问题，降低不良沟通带来的影响。那么必须为他们提供统一的语境――这就是界面原型。技术人员把自己领会的想法制作成界面原型，然后让业务专家将其与自己的想法进行比对，直至大家达成共识。这样一来，大家有了共同的讨论基础，不会出现各说各事的尴尬境况。

	业务要求与用户需求的差异。
	文中使用业务要求来表达业务领域中实际的需求。不管掌握在开发组织内部的业务专家手里，还是在用户手里，终归是业务的要求，而并非用户需求。笔者认为用户需求往往掺杂了用户代表（你不可能了解每个用户的需求）个人主观想法，所以在上面的段落里面使用了“业务要求”而非“用户需求”。

界面原型之所以能够让项目相关人员迅速达成共识的优势就是成本低廉。低成本必然可以加快响应速度，提升交流效果。在项目前期产生的界面原型不仅可以让业务专家有机会在技术人员正式开发产品之前，了解系统未来概貌，而且可以有时间在开发过程中不断改进优化业务流程，调整开发方向。在开发简单系统的开发过程中，界面原型有可能代行用例的一部分职能。

用例

用例存在的理论基础是，它能够驱动开发过程；能够将零散的“系统功能”（菜单、界面）有效地组织起来，为用户（Actor）提供可见的结果值。它能够左右开发过程的关键在于，它为开发人员提供了一个以用户视角来审视系统的机会。开发人员不可能每天面对用户，但是开发系统的时候他们必须时刻铭记系统的核心目标。这个时刻用于比对的标杆就是用例。用例描述了用户对未来系统的使用场景，也必然是系统应该提供的功能集合。它代表用户“使用”系统，审核未来系统的分析设计，测试系统，帮助使用者了解系统。

由于用例的存在，系统不再是一堆零散的菜单、界面、文档，而是能够创造价值的成体系的流程。讨论用例的书籍文章非常多，这里就不再累述。

·         结论

<span style='font-size:12.