精炼统一过程(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

不错，辛苦了，感谢分享。

这些天偶尔会翻译一些文章，本来都是想放在CSDN的Blog上给人看的，以为都翻译一遍了应该还是有人费些神看一下的，不要整天去“学习”怎么混到一个项目经理的岗位、学习项目管理理论了么，那是靠理论“学”出来的么，看看实践是怎么做的，结果......（只花了少少空闲时间写的几篇“散文”倒是都被放到过首页。这几篇翻译的项目管理、软件经理、软件过程的文章我认为还是不错的，没人看，枉费我的时间啊）

只好转到这里，看的人还是有一些，尽管回的人很少。虽然有partech老大的鼓励，不过不打算再翻译了，有好文章会直接给出链接或转贴。

不错，这种东西才是精华。
在这种大神级的东东中挑错，结合自己的思考，才是至高享受。

现在这种软件过程正式发布、登陆了。
CSDN大张旗鼓的在介绍这种软件过程，关于这种过程的首页放的就是我翻译过的这篇文章的CSDN版译稿，有兴趣可以关注一下。


CSDN上正式缩写就是EssUP，中文名称是：核心统一过程。（我更喜欢精炼，呵呵）。

另外看到Ivar Jacobson博士说到：“敏捷是不够的，复杂的软件开发需要超越敏捷，需要一种聪明的方法。”这种提法我非常同意，但EssUP是否能力达到这个目标，目前还是未知数。

Ivar Jacobson的漂亮转身？

《Jacobson博士演讲观后感》
这是我在2005年10月25日写的一篇blog

“通过他的严密的逻辑分析，建立在这种模模糊糊的知识基础上的软件开发，是不可能取得成功的。”



“IvarJacobson公司，还按照此理念，开发了一个叫做WayPoint的软件，据说能够让人们不用再去翻阅那厚厚的手册，而是在开发过程中，这WayPoint会主动的提醒你，帮助你，教育你，纠正你，带领你去运用那些明确的知识。”

看来Jacobson博士推销UP专家系统的努力依然在继续，不过变成EssUP的专家系统了。



再对照前面一段：

大量？多少个？3个、5个、还是几百个？
随便自己任意选择组合，还是必须由专家来指导？

还有Jacobson博士提到的卡片，这是个新东西（对于UP来说）。他可以编写，交换，绘制。。。要是这些卡片掉了一张怎么办？

再次贴出我那篇blog的那个笑话：
给太阳安上开关
给黄河装上栏杆
给飞机配上倒档
给长城贴上瓷砖
给泰山装上轮子
给UP配上专家系统

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

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

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

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