| 软件过程的一个新鲜起点 精炼统一过程（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) |
