对于一个轻量级的流程，轻量级开发非常适合，但是要让一个保守公司采用敏捷技术还是非常困难。本文学习如何在您的公司里推荐并促进轻量级流程。

划皮船的人和划独木舟的人不会融洽相处，但是当组建探险队时，他们则会抛开相互的分歧。独木舟可以存放更多东西，并且探险者可以容易地离开船只快速探索；皮船不会沉没在大水中，有助于抢救偶然从倾覆的独木舟中滑出的独木舟划桨（或划船人）。它无关个性，而是合力穿流而下。

本文介绍合力完成一种不同的活动：应用程序开发。敏捷开发流程，比如极限编程（Extreme Programming，XP）和 Scrum，寻求降低流程开销。尽管存在许多不同的流程，但它们当中都有一些共同的趋势：

• 越来越重视客户参与，而非重量级需求文档
• 通过重构改进质量和设计；重的、自动化的单位测试；连续集成
• 小团队，较少的正式沟通和更多的非正式沟通（15 分钟的站立早会，更多的配对编程）
• 短而一致的周期，最后是客户反馈

敏捷方法剔除了不需要的流程，直到只留下完成工作所必需的流程。尽管许多编程人员理解轻量级、敏捷方法的强大功能，但许多管理人员习惯使用更传统的流程。如果您认为敏捷可以帮助您，那么通过应用下列思想来学习如何协调传统管理与敏捷开发流程：

• 将您使用的语言改为侧重于原则，而非流程。
• 创建小而灵巧的团队。
• 重视可测量的交付。
• 重视简约性。
• 重构代码并自动化测试。
• 获得客户反馈。

原则而非教条

当编程人员或架构师试图将敏捷流程注入保守公司时，最好是抛开教条 —— 即，将重点放在原则而非教条上。如果您对 XP 的优点大肆吹嘘 10 分钟，典型的老板会关注一个词 极限。因为老板关注的是减轻风险，所以您注定失败。相反，您可以挑选一些您的管理层想要解决的问题。然后，选择敏捷原则来帮助解决这些问题。

例如，考虑您的产品带有一个严重的 bug，然后要求进行更自动化的单元测试。或者，存在一个偶然事件让您的客户不满意，然后通过频繁演示来达到更好地访问您的客户。您可以在集成问题被忽视之后，请求运行带有巡航控制的自动化版本。

在每种情况下，您都指出特定的问题并提供解决方案。每一步还让您更接近更敏捷的流程。不要理会那些描述已经失败的或不可能获得认可的实践的反驳言论。例如，配对编程 通常让人难以接受，但更好的团队合作 或辅导 则不同。更改您的流程的第一步是更改您的语言。

小而灵巧的团队

在保守公司里，文化可能演变成了中庸之道盛行。项目成功的一个最大的标准是项目团队的组成。具有才能、技能和动力的小团队才会成功。如果真想改进您的流程，请确保构建软件的小团队知道他们在干什么。这听起来有些荒谬，您通常将不得不处理不执行这条规则的队友。由于当前全球压力和构建软件的成本，执行固定负载成本太高，所以整个团队的福利胜过任何单个队员的福利。

培训也十分重要。您可能在短期内节约了培训成本，但如果长此以往，您会变得一团糟。您不必一次花数周时间让人们去上课。您可以每周腾出半天来学习和应对新技术。完美的周末讨论会，比如 No Fluff, Just Stuff 系列，可以帮助您稳步提高，而无需占用太多办公时间。

最后，确保您的团队具有成功所需的所有个性类型。您需要创新者和小心翼翼的记录保持者，也需要能够深入细节的编程者和能够把握宏观方向的编程者。要确保具备所有的关键角色。

对工件计数

流程的每一步生成一个或多个可度量的结果和交付，叫做 工件。敏捷流程寻求将工件数目减少到客户需要的数目。工作代码是一个最重要的工件。敏捷流程依赖频繁的重构和单位测试来改进设计。敏捷流程通常不要求成堆的文档。您通常可以构建有助于完成工作的设计文档，但您应该把重点一直放在交付工作代码上。

保守公司通常想要更多的文档和更重的流程。管理层可能将较少的工件与较少的原则一视同仁。事实并非如此。敏捷流程具有同样多的原则；它只来自其他来源，如图 1 所示。早期的频繁的客户接触与简单的需求电子数据表代替了传统的功能规格说明书和复杂的用例图。对重构和自动化测试的特别重视动态地改进了设计，而且免去了画满类图的笔记本的需要。

图 1. 敏捷流程中的原则来源

　

如果管理层需要正式文档，您通常可以使用工具来从工作代码直接生成 Unified Modeling Language (UML) 图，而无需从头开始构建文档。IBM Rational Suite® 中的产品可以简单地从现有代码生成文档，而只需要很少的用户介入。如果您不能花钱购买这类工具（低于 200 美元），您可以使用叫做 Enterprise Architect 的工具来从您的代码构建 UML 文档。只需要一点布局工作，即可以交付成捆的文档，而不会对您的进度表有太大影响。通常最好是在它帮助您推进日程之后，生成文档，而不需要大战一场来正式地更改流程。

重视简约性

在大公司里，很容易陷入构建太多代码来处理未来需求的坏习惯。确实，您需要构建灵活的可扩展的软件，但您可能相去甚远。最好是构建易于重构的并且完全是您所需要的代码。不成熟的优化、对可能的未来特性的支持以及不支持您的直接需求的设计模式会浪费太多精力。如果您发现自己陷入圈套，那么以下技术可以帮助您：

• 列出迭代的需求清单，只编写支持这些需求的代码。在极限情况下，只按照正式需求或 bug 来创建代理。
• 在编码之前不断寻找更简单的解决方案。您想要您的代码复杂性仅仅是您必需的。
• 首先编写测试用例，并且只编写足以让测试用例通过的代码。

彻底重构和自动化测试

如果您致力于简单编码，您的简单抽象有时会一下子出现。当出现这种情况时，您需要重构您的代码。但如果您害怕破坏一些东西，您就不愿意重构，尤其是在迭代末尾。重构与自动化测试是携手并进的。

在比较大的公司里，当管理人员发现开发人员正在进行自动化单元测试时，他们通常会阻止。准备好为实践辩护。为此，最好的方法是指出您的测试用例有助于限制您编写的生产代码的数量，允许您在 bug 第一次出现的时候就捕获它们，而且修复 bug 的成本比较便宜（从时间和金钱上来说）。按照我的经验，测试驱动的活动通常与其对应物一样多产。

获得反馈

创建优质产品的一部分是制作您认为您要制作的东西。自动化测试可以帮助您。更为重要的是，质量意味着制作您的客户想要的东西。您必须频繁地从用户那里获得反馈。以下技巧可以帮助您：

• 每周为您的客户安排演示。为他们展示所有的新功能。
• 当看不到进展时，用户和管理人员就会受挫。一定要记住，直到您可以在屏幕上看到成果，否则就不算完成。如果您正在制作管道，可以通过用户界面 —— 可能是管理面板 —— 来查看管道。
• 邀请更高的管理人员来观看您的演示。他们喜欢参与其中，而且，当他们可以看到稳定的进展时，您就有更大的机会让他们站到您这边来。
• 关注业务需求而非成块的功能，并且将最高优先级的单项特性放在第一位。如果每个编码任务实现有形的业务价值，则可以停止任一点的迭代，并向您的客户交付最重要的特性。

好的反馈不是偶然发生的。而是需要您去询问。

独木舟和皮船

敏捷流程和保守公司未必像油和水（或独木舟和皮船）。为大的保守公司开发软件不一定会将您降到传统流程，您不必声明您在做敏捷或极限编程。您可以通过集成新的敏捷实践来获得巨大的价值。

在本系列后面的几篇文章中。我将向您展示一些 Java™ 技术的备选方法。我们将学习 Java 编程语言本身中可能损害您的生产率的问题。然后，我们将探讨为特定类型的问题提供极好的生产率的框架，比如 Ruby on Rails。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
• 轻量级开发是一个大的主题，开发人员如此频繁地使用这个词，以至于很难说清它到底意味着什么。“轻量级开发的成功秘诀，第 1 部分：核心原则及原理 ”介绍了本系列，以及运动背后的原则和哲学。
• 轻量级架构（比如 Enterprise JavaBean）可能是对每日问题的过度杀伤。“轻量级开发的成功秘诀，第 2 部分：如何减轻容器”介绍了轻量级容器，并解释了它们可以如何提供您的业务需要的服务，而不会把您捆绑到给定的编程模型上。
• 在本系列的第三部分“轻量级开发的成功秘诀，第 3 部分：Spring 露出水面” 中学习轻量级容器的基础知识。
• 在本系列的 轻量级开发的成功秘诀，第 4 部分: 轻量级容器的比较 中，Bruce Tate 比较了三种流行的容器：Spring、HiveMind 和 PicoContainer。
• 当代码满足管理且对进程表没有太大影响时，使用 IBM Rational software products 从代码构建文档。
• 阅读 Manifesto for Agile Software Development 获得有关敏捷流程的详细信息。
• Bruce A. Tate 和 Justin Gehtland 编写的 Better, Faster, Lighter Java （O’Reilly，2004 年），很好地概述了轻量级开发。
• Richard Hightower 编写的 developerWorks 文章“无需容器的对象关系映射”展示了如何使用 Spring 持久性与 Hibernate。
• e从 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 获得评估产品，开始构建应用程序并将其部署在 IBM 中间件上。选择 Linux® 或 Windows® 版本的免费 Software Evaluation Kit (SEK)。
• 访问 developerWorks 开放源码区 获取大量 how-to 信息、工具和项目更新，以帮助您使用开放源码技术进行开发，并将它们与 IBM 产品一起使用。

获得产品和技术

• 使用 IBM 使用软件 改进您的下一个开放源码开发项目，这些软件可以通过下载或购买 DVD 获得。

• 通过参与 developerWorks blogs 加入 developerWorks 社区。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号