精炼统一过程(EssUP),UML之父新作,轻量UP

精炼统一过程（Essential Unified Process）
软件过程的一个新鲜起点

作者：Ivar Jacobson, Pan Wei Ng, Ian Spence       翻译：tianxinet(胖猴) －－最近致力于研究、介绍一些“最佳实践”

精炼统一过程（Essential Unified Process）结合了来自统一过程阵营、敏捷阵营、过程改进阵营的实践。

Ivar 是组件、组件模型、UML、RUP之父，Pan-Wei和Ian是Ivar Jacobson 咨询的首席科学家。


--------------------------------------------------------------------------------

注：

    轻量的UP，RUP他爹终于直面RUP的缺陷了，也终于听进敏捷阵营及过程改进阵营的呼声了。

     它具有很好的“敏捷”或超越敏捷的特性吗？（观察中）

     也期待XP的改进！XP很好用，但不能完全满足我们苛刻的需求。还因为敏捷特性可能不再是XP等专属了（这是好事，“对手”的进步能促进原有敏捷过程的改进）。

    * 精炼统一过程(EssUP)－－Essential Unified Process，字面意思还可翻译为“基本统一过程”、“实质统一过程”...等，google、baidu了一下，并没有找到可参考的正式译法，这还是一个新东西，没什么中文资料。翻译成“精炼”，因为我觉得原来的RUP太臃肿沉重。

    * 我看到了过程的吸收、演变和改进，发现EssUP增加了不少为实际开发以及开发者的着想，但并不都是EssUP独有或最新的。只有实践才能检验EssUP，一切结论现在还为时过早，对待新东西我们要大胆学习，谨慎应用。


--------------------------------------------------------------------------------

译文：

每个人都认可对过程的需求是改进软件开发，每个人都认可对敏捷、灵活性、适应性的需求,并且每个人都一致认为需要(好的)质量。但是我们中的许多人发现现有的过程是笨重的、有限的、并且妨碍了我们的创造力。

开发者厌烦过程，UP变得过于沉重，过程改进需要太多令人厌烦的工作，敏捷阵营承诺的太多。我们需要好的实践来按时间、按计划开发好的软件，简而言之，我们需要从根本上重新建造用来设计、配置、培训、应用和部署的过程。


精炼统一过程（EssUP）
EssUP 是建立在现代软件开发实践基础之上的新过程。EssUP (www.ivarjacobson.com)是一个新鲜起点，它慎重地集成了来自UP阵营、敏捷阵营、过程改进阵营的成功实践。

我们需要一个新过程的原因可能是下列之一:

• 传统软件过程过于沉重，没有一个人愿意阅读又大又长的过程描述。
• 过程必须聚焦于支持开发者，而不仅仅是过程专家。
• 除了过程质量，过程也必须帮助团队获得好的产品质量，不仅仅是通过CMMI，也包括交付好的软件。任何软件开发过程的焦点必须是在生产好的软件上。
• 过程必须提供规程的敏捷性，平衡管理的需求而不遏制创造力。
• 这种方法必须让项目团队（没有过程工程师帮助的开发者）容易添加好的实践到现有的过程中。
• 过程应该授权于团队。

（*这些原因说的太好了，早干嘛去了^_^）

新范例：让实践(practice)成为一等公民
传统过程（象UP）用不同的活动和制品来描述，这些活动和制品可能服务于不同的目的－－用use case做需求、测试驱动设计、或者基于组件的开发。这些实践是不清晰、不可见、没有命名的。这个过程包含了实践的混合。

为了容易识别、设计、发布新实践，我们需要让实践成为一等公民，过程只是你选择的实践的结果。为了让这成为可能，我们需要能够从另一个设计、发布、改进中分离不同的实践。

在这方面，EssUP与其他过程或方法非常不同，它包含了一个新进入过程行业的点子－－关注分离（Separation of Concerns，SOC。译者注：这也是IoC和AOP产生的最原始动力)，一种面向面向方面的思想。当我们在过程开发中接受这个点子，我们创造了一个从根本上不同的过程－－一种让你更容易、更本能去选择的定制软件过程。

每一个实践与其他实践保持独立。你仅选择你需要的实践，而不需要取消选择活动和制品。只选择你需要的实践，并且与其它实践和你现有的过程一起妥当的安排它们。
从一个普通的平台开始，你用一个得自游戏行业灵感的、非常简单的技巧描述你自己的过程。基于此，你能够添加实践而不需要对所有实践推倒重来。你得到你需要的和你思索的，并且是你的组织能够接受的，而没有严重的风险。
   

EssUP把过程的两个不同意见分离开－－过程制订者和软件开发者的意见。在过去，过程完全聚焦在过程制定者的需求上。EssUP把开发者的意见划分成不同的优先级，它使用来自游戏行业的技巧来开发、讲授、申请、使用过程，使过程变得轻量和敏捷，并且，我们保证更多的功能。


我们把精炼（或基本）和非精炼（或非基本）的内容分开，这让我们创建一个有空前增长潜力的核心轻量级过程（数以百计的实践）。
我们认识到，多年来很少有人真正阅读书籍和web上的过程材料，因此我们提供真正的本质，来代替许多虽然提供给开发者但被忽略的信息，并且让开发者学习任何他们想要的其它内容，有大量文章和书籍可以学习它们，还有其它学习方式比如和已经掌握这些知识的人一起工作。精炼和非精炼内容的分离使EssUP成为轻量的、容易应用和改变的过程。



EssUP用一种平衡的办法分离了外在的和隐含的认知。隐含的认知是你已经获得的一种方法或者你头脑中的其他东西。外在的认知以你可用的描述方式存在。
过去，过程尝试以一种外在形式捕获所有的相关认知（译者注：这就好比假设过程使用者脑子里没有任何东西，他们甚至不能在脑子里清晰的构建一个约束条件并通过语言很好交流，即便团队对某个约束条件已经很熟悉了而且是默认的^_^）。尽管这是一个好的企图，但它使过程变得沉重。EssUP仅仅捕获本质的外在认知，其它则是隐含的认知或对本质的引用。无论如何，处理认知最优雅的方法是当需要时通过明智的代理得到它－－我们把这叫做“聪明的实践”（smart practice），这样一些聪明的实践可以在来自Jaczone的Waypointer得到(www.jaczone.com)。



EssUP分离创造性的工作和非脑力劳动，这是已经准备好的(prepared)。这让你花费时间在人类擅长的创造性工作上，并且把非脑力工作交给明智的代理去处理。我们使用“准备好的(prepared)”这个词，因为EssUP和代理不是一起提供的，代理是附加的。


EssUP分离了两类制品－－alphas和betas（译者注：非软件的alpha、beta版）。我们也没有给它们命名。我们认为alphas和betas之间的差别是所有项目种最基本的东西之一。你暂时可以用"关键事物"代替alpha，用"关键事物的相关内容"代替beta。

Alphas制品是软件项目最重要的东西之一，无论它们存在于一个描述表格与否。实际上，alphas对任何特定的过程来说都不是特有的。例如，每一个软件项目都有这些alpha制品:项目、实现的系统、待办事项、风险。每一个alpha都有一套betas：一个项目alpha可能有一个项目计划，一个迭代计划；一个风险可能有一个风险列表；一个待办事项可能有一个规格列表和变更列表。

Betas是alpha的明确内容，它们可能是描述、图表、流程图、或者任何你喜欢的文档或非文档介质。“非文档”意味着团队人员头脑中保有的知识。

Alphas是稳定的和过程无关的，betas可能因你选择使用的实践不同而不同。alpha和beta的分离让你保持最小的项目文档。你能够精确的论述需要多少文档。这让你以一种训练有素的方式“敏捷”。



EssUP的基础
EssUP的中心是大量简单和经过验证的实践，能够用做所有类型和等级软件开发的基础。这些实践设计成能够单独应用或者以任何你期望的联合方式来应用。这使它易于应用，并且为真正满足你需求的过程的创建和组装提供基础，包括开发者的需求、开发组织的需求。

EssUP有5个基本实践和3个工作实践，使你可以轻松的把这个过程介绍到你的组织。这5个基本实践处理技术开发工作，补充开发实践提供的技术实践，3个工作实践则促进有效的团队工作和过程改进。

测试无处不在，我们相信“无论你做什么，在你验证你做了你想做的之前，你什么都没做”，或者“每一个人是他自己的清洁工”。我们使测试成为我们所作任何事情的一个完整部分。Use-case精炼包括测试驱动设计，因为use case是早期的测试用例。组件精炼包括组件的单元测试。

这套实践提供了处理计划和实现的一种敏捷方式的基础。你能够应用所有的实践、你需要的实践、一个单独的实践、甚至一个局部的实践。你可以混合匹配实践以满足你的需求，书写你自己的实践扩展过程，混合你已有的实践来构建自己的经验。这是和传统过程的一个重要区别，传统过程使用所有紧紧缠绕在一起的实践来开发。


用一种激进的新方式来呈现
EssUP的变化超出了“关注分离”，而是呈现出一种更加激进的方式。

每一个实践作为一组包含创建过程所需元素的过程卡片来呈现，包括能力、活动、制品。这些卡片帮助你构建和使用过程。这些卡片意味着使过程敏捷而且易于使用。用电子档作为物理卡片，它们很容易使用，可以促进过程的应用、项目计划，并且为从业者提供便利的参考。这些卡片使过程恢复活力，并且使过程比一个web站点或书籍更加易见。

图1呈现了来自use case精炼实践的的例子。图1(a)是一个制品卡，实际是一个beta，1(b)是一个活动卡，1(c)是一个能力卡。每一种卡片有2-4页指导方针(图2)呈现需要放到实践中的最精炼的信息。它们页链接到一套参考、脚本、工具、模板、例子。例如，活动指南包括一个介绍、参与者信息、完成标准、以及一组提示避免常见错误的提示。这个信息形成给你实践建议的精炼信息。

图2:指导方针


(a)


(b)


(c)


图 1: (a) 制品卡; (b) 活动卡; (c) 能力卡.

过程怎样打包?
与EssUP过程一起，有一组用卡片形式提供的基本实践。基本实践设计被设计成可用支持包扩展。你可以自己来些满足你需求的扩展，或者使用其它人提供的扩展。包括针对实践的扩展，象面向服务的架构、业务模型、企业架构、结对编程、CMMI、以及其它类似的。

这些卡片可以有许多不同的方式应用。例如：



• 构建需要的卡片组支持你的项目。
• 为团队成员或新的过程元素合并卡片创建工作项目。
• 用许多卡片描述实际交付物和项目任务。
• 向卡片添加与你的项目有关的注释信息。
• 捕获能够应用于你的卡片的实现的实例数据。
• 分配卡片给项目组,并且提供他们需要的过程信息。
• 作为一个项目组成员绘制卡片，以便你能够有和他们有关的信息。
• 在你的团队中交换卡片。
• 书写新卡片支持你自己的环境。


你怎样实现EssUP
你可以通过改善已有的过程来实现EssUP，一次一个实践，这样一种进化发展的方式。你拿走你需要的和你的组织能接受的，没有任何严重的风险。你分配卡片给项目团队，给他们需要关注的信息。卡片包括精炼信息，项目经理可以添加项目的特殊说明。过去，过程完全聚焦于制定者的需求，EssUP关注开发者的意见，并把它们区分优先次序。



结束语

精炼统一过程:

• 全神贯注于针对所有项目的精炼的适用性。
• 是你能够在已有的技能基础上创建过程。
• 为实现一种一致的方法提供指导。
• 聚焦于提高*人们关于开发的技能。
• 添加刚好够的过程去处理你的项目风险。

EssUP的目标是一个长期设想: 从每一个人被迫去思考过程的“过程”时代，过渡到我们不再讨论特定过程的“无形过程”时代,但这是一个设想。



原文见：The Essential Unified Process

评论

27 楼 zqrain 2007-07-13  

可能说的不太严谨：我觉得楼上的很多朋友可能要么对XP不太了解，要么对UP不太熟悉。

我觉得XP和UP从诞生的一开始，就没有谁排斥谁！的确有一些细节上他们可能是不相容的。但是，总体上，他们完全可以方在一起使用。

而且论坛上很多朋友谈敏捷就是XP,Scrum,TDD,而把UP当作靶子作为敏捷的敌对方，我觉得这都是对UP认知不够的表现！

UP的具体细节的确非常繁复，但是，它明确指出，所有的过程都是可以裁减的！Up也可以是敏捷的！它本身并没有“重”或“敏捷”的规定。实际上，对于项目实践，它既可以是文档化，规范化很重的过程，也可以是很简单，很敏捷的过程。

26 楼 partech 2006-09-15  

9月20 ivar大师，来深圳，去看看。

25 楼 tianxinet 2006-09-15  

论战似乎要开始了...

24 楼 partech 2006-09-08  

抛出异常的爱 写道

看谁能出更少的规则办更多事
更能节约时间。。。。。。
当程序员成为上帝。。。架构师成为公扑
这个方向走下去的话程序员的生活会更好一点吧

以前是客户。。销售。。项目经理。。。程序员。。。测试。。。售后。。
这种等级差别。。。。。

又来忽悠......

23 楼 抛出异常的爱 2006-09-08  

partech 写道

yuxie 写道

partech 写道

robbin 写道

其实XP2.0都出来了，不知道你们注意没有注意。Kent Beck在XP第二版几乎把大部分内容都重写了。XP也不是一成不变的，现在有好多新东西在里面呢。

XP2.0也有向UP靠拢的趋势，比如构架师角色的引入。

要存活下来，大家都需要取长补短，也就越长越像了。

靠近UP，也就是要取代UP亚。。
我看第二版里边一个很重要的变化就是“XP适合小型项目开发”改成了“同时也适合大型项目开发”。。虽然这一点早被人提出来了。。。

UPer也可以说，加入了敏捷元素，就是要超越敏捷阿。
其实，谁比谁好，并不重要，关键看能不能揭示一些本质和有规律的咚咚出来。
新的论战即将开始，让我们拭目以待吧。

看谁能出更少的规则办更多事
更能节约时间。。。。。。
当程序员成为上帝。。。架构师成为公扑
这个方向走下去的话程序员的生活会更好一点吧

以前是客户。。销售。。项目经理。。。程序员。。。测试。。。售后。。
这种等级差别。。。。。

22 楼 tianxinet 2006-09-08  

UP、敏捷，（或衍生方法），谁说要取代另一方我就跟他急。
只剩一个，最终结果就是留一潭臭水给我们。
想忽悠俺，没门儿，俄明白着泥

21 楼 partech 2006-09-08  

yuxie 写道

partech 写道

robbin 写道

其实XP2.0都出来了，不知道你们注意没有注意。Kent Beck在XP第二版几乎把大部分内容都重写了。XP也不是一成不变的，现在有好多新东西在里面呢。

XP2.0也有向UP靠拢的趋势，比如构架师角色的引入。

要存活下来，大家都需要取长补短，也就越长越像了。

靠近UP，也就是要取代UP亚。。
我看第二版里边一个很重要的变化就是“XP适合小型项目开发”改成了“同时也适合大型项目开发”。。虽然这一点早被人提出来了。。。

UPer也可以说，加入了敏捷元素，就是要超越敏捷阿。
其实，谁比谁好，并不重要，关键看能不能揭示一些本质和有规律的咚咚出来。
新的论战即将开始，让我们拭目以待吧。

20 楼 yuxie 2006-09-08  

partech 写道

robbin 写道

其实XP2.0都出来了，不知道你们注意没有注意。Kent Beck在XP第二版几乎把大部分内容都重写了。XP也不是一成不变的，现在有好多新东西在里面呢。

XP2.0也有向UP靠拢的趋势，比如构架师角色的引入。

要存活下来，大家都需要取长补短，也就越长越像了。

靠近UP，也就是要取代UP亚。。
我看第二版里边一个很重要的变化就是“XP适合小型项目开发”改成了“同时也适合大型项目开发”。。虽然这一点早被人提出来了。。。

19 楼 partech 2006-09-08  

robbin 写道

其实XP2.0都出来了，不知道你们注意没有注意。Kent Beck在XP第二版几乎把大部分内容都重写了。XP也不是一成不变的，现在有好多新东西在里面呢。

XP2.0也有向UP靠拢的趋势，比如构架师角色的引入。

要存活下来，大家都需要取长补短，也就越长越像了。

18 楼 robbin 2006-09-08  

其实XP2.0都出来了，不知道你们注意没有注意。Kent Beck在XP第二版几乎把大部分内容都重写了。XP也不是一成不变的，现在有好多新东西在里面呢。

17 楼 partech 2006-09-08  

引用

“核心统一过程”（EssUP）呈现出与其他的过程或方法有很大的区别。它给过程工业引入了一种新的思想：关注点分离（Separation of Concerns :SOC即面向方面的思想）。

赫赫，玩AOP，都玩到过程中来了。

16 楼 tianxinet 2006-09-08  

原贴太长，不再一一引用了，呵呵

我认为软件过程领域现在迫切需要新空气，因为不管是RUP还是XP，都已经味道十足了。RUP块头大，味道大些，XP等块头小，味道小些。

流水不腐，户枢不蠹。

所以EssUP带来的一个重要潜在讯息就是：敏捷方法现在需要思考演变和革新了。

15 楼 partech 2006-09-08  

yuxie 写道

partech 写道

yuxie 写道

深刻同意老庄的看法。。与其使用不三不四的UP，还不如直接用纯粹的XP...
而且这个EssUP，看上去虽然很规范，又很吸收了敏捷的元素，但是远远没有XP来的环环相扣。XP里边推荐的每一件事，你都能找到这么做的原因。而EssUP呢，貌似说了一堆大道理。。但是远不能让偶们信服 。。。

反对，UP不是光看起来规范，其实它是在阐述一种规律。
根据我的实践，开发过程要顺利，不知不觉地就会符合它总结的规律。
如果仅仅停留在了解阶段，就不要妄加评论。

1、不同的项目开发过程差异之大，“一种规律”能适用吗？
2、“开发过程顺利的话”。。。 似乎等于没说。。。
3、UP还是缺乏最重要的部分：对人的激励。

1.适合不适合我不知道，但里面肯定有规律。
2.其实，往往是项目危机或混乱的时候，才想起来，“缺啥想啥”。
3.对人的激励好像不属于开发过程需要考虑的问题，UP并没有漠视人的重要，否则，出现QA角色不可避免。

14 楼 庄表伟 2006-09-08  

tianxinet 写道

老庄的blog中提到“明确知识”和“心照不宣的知识”，应该就是我翻译成“外在认知”和“隐含认知”的东东，Jacobson在演讲中把它作为UP与Agile的主要区别吗？这似乎有些奇怪了，因为在这篇介绍文章中Jacobson体现了对“隐含认知”的充分尊重，如果拿自己都在用的东西去攻击“对手”似乎不太厚道。

那是在2005年的时候，他进步了，不再鄙视“隐含认知”了。

所以我才说他是“漂亮转身”嘛

13 楼 庄表伟 2006-09-08  

tianxinet 写道

1、重视实践
“让实践成为一等公民"，EssUP提出或者说接受了一个完全正确的观念。这会让很多软件开发者感到欣慰，似乎有种一吐为快的感觉，而EssUP另外还提供了可扩展最佳实践。

是我的实践，还是人家的实践？
是团队的实践，还是最佳的实践？
是我们自己摸索出来的实践，还是专家推荐给我的实践？

tianxinet 写道

2、关注开发者
”在过去，过程完全聚焦在过程制定者的需求上。EssUP关注开发者的意见，把开发者的意见划分成不同的优先级“。这是一个重大的”人性化“改进。

要注意的是：“把开发者的意见划分成不同的优先级”，而不是那个“关注开发者”的标题。扪心自问一下，我的意见，被他们划在哪个优先级呢？

tianxinet 写道

3、轻量化
”我们把核心和非核心的内容分开，这让我们创建一个有空前增长潜力的核心轻量级过程“，摒弃过于沉重的弊端，这是过程”可用性“的重大改进。

空前增长潜力，还是空前膨胀潜力？如果是后者，那么，那些过去的，沉重的弊端，还是会回来的。

tianxinet 写道

4、更关注质量
”除了过程质量，过程也必须帮助团队获得好的产品质量“，以往很多人有疑惑，过程质量似乎和产品质量并不是都成正比，好了，EssUP现在正视这个问题，这同样是一个重大改进。

这个还是不错的，相对于UP原有的基础。奇怪的是，他们原来怎么就好意思宣传“不重视产品质量的UP”呢？或者说，他们原来是怎么宣传自己的呢？
重视过程质量：产品质量将随之而来？
现在呢？
仅仅重视过程质量，产品质量有可能毫无改善？

tianxinet 写道

5、简化繁复的文档
”每一个实践作为一组包含创建过程所需元素的过程卡片来呈现“，卡片比之文档，在某些环节有所简化。

还是那个问题，卡片会有多少？多了怎么办？掉了怎么办？
根本问题在于，按照Jacobson博士的惯性思维，那些瘦身下去的东西，一定会再回来的。他们已经在回来的路上了。参见：第3条

tianxinet 写道

6、可定制及灵活性
”添加刚好够的过程去处理你的项目风险“，而不是在任何场景下都全部照搬沉重的全套过程，这会让过程的适用性、灵活性更强。

刚好够，由谁来决定？参见：第1条

tianxinet 写道

最激发我好奇心的，是EssUP“超越敏捷”和“超越过程”的想法。尤其是后者，很好啊，因为在软件过程领域很久没有新鲜空气了，不管是RUP还是XP，都已经味道十足了。我倒是很希望有某种过程能超越现有过程并最终淡化自身，让我们不再过于关注过程，这个“重任”最终会落在谁的肩膀上呢？
我认为“超越敏捷”和“超越过程”才是EssUP根本创新的理念（其它很多都是借鉴来的），我最关注这两点，这是新鲜空气。

超越听起来当然好听，当然激动人心。
问题在于，EssUP这种东西，看起来就像是“已知好东西的大拼盘”，而不是一个超越。1+1并不见得就会大于2的。

12 楼 tianxinet 2006-09-08  

老庄的blog中提到“明确知识”和“心照不宣的知识”，应该就是我翻译成“外在认知”和“隐含认知”的东东，Jacobson在演讲中把它作为UP与Agile的主要区别吗？这似乎有些奇怪了，因为在这篇介绍文章中Jacobson体现了对“隐含认知”的充分尊重，如果拿自己都在用的东西去攻击“对手”似乎不太厚道。

11 楼 tianxinet 2006-09-08  

翻译的这篇介绍文章中，EssUP提出的一些理念比较吸引人，这些理念似乎可以让我们把EssUP当作和RUP完全不同的东西来看待，我稍稍总结了一下：

1、重视实践
“让实践成为一等公民"，EssUP提出或者说接受了一个完全正确的观念。这会让很多软件开发者感到欣慰，似乎有种一吐为快的感觉，而EssUP另外还提供了可扩展最佳实践。

2、关注开发者
”在过去，过程完全聚焦在过程制定者的需求上。EssUP关注开发者的意见，把开发者的意见划分成不同的优先级“。这是一个重大的”人性化“改进。

3、轻量化
”我们把核心和非核心的内容分开，这让我们创建一个有空前增长潜力的核心轻量级过程“，摒弃过于沉重的弊端，这是过程”可用性“的重大改进。

4、更关注质量
”除了过程质量，过程也必须帮助团队获得好的产品质量“，以往很多人有疑惑，过程质量似乎和产品质量并不是都成正比，好了，EssUP现在正视这个问题，这同样是一个重大改进。

5、简化繁复的文档
”每一个实践作为一组包含创建过程所需元素的过程卡片来呈现“，卡片比之文档，在某些环节有所简化。

6、“关注分离”、可定制及灵活性
“EssUP与其他过程或方法非常不同，它包含了一个新进入过程行业的点子－－关注分离（Separation of Concerns，SOC。译者注：这也是IoC和AOP产生的最原始动力)，一种面向面向方面的思想。”“添加刚好够的过程去处理你的项目风险“，而不是在任何场景下都全部照搬沉重的全套过程，这会让过程的适用性、灵活性更强。


这些理念与传统的UP似乎有根本上的不同，但要注意的是，根据我目前的了解，EssUP还都只是貌似有这些优点。或者说EssUP试图做到以上几点，至于是否做的到，未知。

最激发我好奇心的，是EssUP“超越敏捷”和“超越过程”的想法。尤其是后者，很好啊，因为在软件过程领域很久没有新鲜空气了，不管是RUP还是XP，都已经味道十足了。我倒是很希望有某种过程能超越现有过程并最终淡化自身，让我们不再过于关注过程，这个“重任”最终会落在谁的肩膀上呢？
我认为“超越敏捷”和“超越过程”才是EssUP根本创新的理念（其它很多都是借鉴来的），我最关注这两点，这是新鲜空气。

10 楼 yuxie 2006-09-08  

partech 写道

yuxie 写道

深刻同意老庄的看法。。与其使用不三不四的UP，还不如直接用纯粹的XP...
而且这个EssUP，看上去虽然很规范，又很吸收了敏捷的元素，但是远远没有XP来的环环相扣。XP里边推荐的每一件事，你都能找到这么做的原因。而EssUP呢，貌似说了一堆大道理。。但是远不能让偶们信服 。。。

反对，UP不是光看起来规范，其实它是在阐述一种规律。
根据我的实践，开发过程要顺利，不知不觉地就会符合它总结的规律。
如果仅仅停留在了解阶段，就不要妄加评论。

1、不同的项目开发过程差异之大，“一种规律”能适用吗？
2、“开发过程顺利的话”。。。 似乎等于没说。。。
3、UP还是缺乏最重要的部分：对人的激励。

9 楼 partech 2006-09-08  

yuxie 写道

深刻同意老庄的看法。。与其使用不三不四的UP，还不如直接用纯粹的XP...
而且这个EssUP，看上去虽然很规范，又很吸收了敏捷的元素，但是远远没有XP来的环环相扣。XP里边推荐的每一件事，你都能找到这么做的原因。而EssUP呢，貌似说了一堆大道理。。但是远不能让偶们信服 。。。

反对，UP不是光看起来规范，其实它是在阐述一种规律。
根据我的实践，开发过程要顺利，不知不觉地就会符合它总结的规律。
如果仅仅停留在了解阶段，就不要妄加评论。

8 楼 buaawhl 2006-09-08  

庄表伟 写道

最后再说一下为什么很划算，因为今天的这个会，送了好多书，我一个人，就拿到了一本《AOSD中文版》，《程序员——9月》《程序员——10月》两本杂志，还是很划算的。

啧啧，恁多奢侈品，着实羡煞人也。