|
 |
级别： 初级 Bruce Tate (bruce.tate@j2life.com), 总裁, J2Life, LLC 2005 年 9 月 26 日 对于一个轻量级的流程，轻量级开发非常适合，但是要让一个保守公司采用敏捷技术还是非常困难。本文学习如何在您的公司里推荐并促进轻量级流程。 划皮船的人和划独木舟的人不会融洽相处，但是当组建探险队时，他们则会抛开相互的分歧。独木舟可以存放更多东西，并且探险者可以容易地离开船只快速探索；皮船不会沉没在大水中，有助于抢救偶然从倾覆的独木舟中滑出的独木舟划桨（或划船人）。它无关个性，而是合力穿流而下。 本文介绍合力完成一种不同的活动：应用程序开发。敏捷开发流程，比如极限编程（Extreme Programming，XP）和 Scrum，寻求降低流程开销。尽管存在许多不同的流程，但它们当中都有一些共同的趋势：
敏捷方法剔除了不需要的流程，直到只留下完成工作所必需的流程。尽管许多编程人员理解轻量级、敏捷方法的强大功能，但许多管理人员习惯使用更传统的流程。如果您认为敏捷可以帮助您，那么通过应用下列思想来学习如何协调传统管理与敏捷开发流程：
当编程人员或架构师试图将敏捷流程注入保守公司时，最好是抛开教条 —— 即，将重点放在原则而非教条上。如果您对 XP 的优点大肆吹嘘 10 分钟，典型的老板会关注一个词 极限。因为老板关注的是减轻风险，所以您注定失败。相反，您可以挑选一些您的管理层想要解决的问题。然后，选择敏捷原则来帮助解决这些问题。 例如，考虑您的产品带有一个严重的 bug，然后要求进行更自动化的单元测试。或者，存在一个偶然事件让您的客户不满意，然后通过频繁演示来达到更好地访问您的客户。您可以在集成问题被忽视之后，请求运行带有巡航控制的自动化版本。 在每种情况下，您都指出特定的问题并提供解决方案。每一步还让您更接近更敏捷的流程。不要理会那些描述已经失败的或不可能获得认可的实践的反驳言论。例如，配对编程 通常让人难以接受，但更好的团队合作 或辅导 则不同。更改您的流程的第一步是更改您的语言。
在保守公司里，文化可能演变成了中庸之道盛行。项目成功的一个最大的标准是项目团队的组成。具有才能、技能和动力的小团队才会成功。如果真想改进您的流程，请确保构建软件的小团队知道他们在干什么。这听起来有些荒谬，您通常将不得不处理不执行这条规则的队友。由于当前全球压力和构建软件的成本，执行固定负载成本太高，所以整个团队的福利胜过任何单个队员的福利。 培训也十分重要。您可能在短期内节约了培训成本，但如果长此以往，您会变得一团糟。您不必一次花数周时间让人们去上课。您可以每周腾出半天来学习和应对新技术。完美的周末讨论会，比如 No Fluff, Just Stuff 系列，可以帮助您稳步提高，而无需占用太多办公时间。 最后，确保您的团队具有成功所需的所有个性类型。您需要创新者和小心翼翼的记录保持者，也需要能够深入细节的编程者和能够把握宏观方向的编程者。要确保具备所有的关键角色。
流程的每一步生成一个或多个可度量的结果和交付，叫做 工件。敏捷流程寻求将工件数目减少到客户需要的数目。工作代码是一个最重要的工件。敏捷流程依赖频繁的重构和单位测试来改进设计。敏捷流程通常不要求成堆的文档。您通常可以构建有助于完成工作的设计文档，但您应该把重点一直放在交付工作代码上。 保守公司通常想要更多的文档和更重的流程。管理层可能将较少的工件与较少的原则一视同仁。事实并非如此。敏捷流程具有同样多的原则；它只来自其他来源，如图 1 所示。早期的频繁的客户接触与简单的需求电子数据表代替了传统的功能规格说明书和复杂的用例图。对重构和自动化测试的特别重视动态地改进了设计，而且免去了画满类图的笔记本的需要。 图 1. 敏捷流程中的原则来源 
如果管理层需要正式文档，您通常可以使用工具来从工作代码直接生成 Unified Modeling Language (UML) 图，而无需从头开始构建文档。IBM Rational Suite® 中的产品可以简单地从现有代码生成文档，而只需要很少的用户介入。如果您不能花钱购买这类工具（低于 200 美元），您可以使用叫做 Enterprise Architect 的工具来从您的代码构建 UML 文档。只需要一点布局工作，即可以交付成捆的文档，而不会对您的进度表有太大影响。通常最好是在它帮助您推进日程之后，生成文档，而不需要大战一场来正式地更改流程。
在大公司里，很容易陷入构建太多代码来处理未来需求的坏习惯。确实，您需要构建灵活的可扩展的软件，但您可能相去甚远。最好是构建易于重构的并且完全是您所需要的代码。不成熟的优化、对可能的未来特性的支持以及不支持您的直接需求的设计模式会浪费太多精力。如果您发现自己陷入圈套，那么以下技术可以帮助您：
如果您致力于简单编码，您的简单抽象有时会一下子出现。当出现这种情况时，您需要重构您的代码。但如果您害怕破坏一些东西，您就不愿意重构，尤其是在迭代末尾。重构与自动化测试是携手并进的。 在比较大的公司里，当管理人员发现开发人员正在进行自动化单元测试时，他们通常会阻止。准备好为实践辩护。为此，最好的方法是指出您的测试用例有助于限制您编写的生产代码的数量，允许您在 bug 第一次出现的时候就捕获它们，而且修复 bug 的成本比较便宜（从时间和金钱上来说）。按照我的经验，测试驱动的活动通常与其对应物一样多产。
创建优质产品的一部分是制作您认为您要制作的东西。自动化测试可以帮助您。更为重要的是，质量意味着制作您的客户想要的东西。您必须频繁地从用户那里获得反馈。以下技巧可以帮助您：
好的反馈不是偶然发生的。而是需要您去询问。
敏捷流程和保守公司未必像油和水（或独木舟和皮船）。为大的保守公司开发软件不一定会将您降到传统流程，您不必声明您在做敏捷或极限编程。您可以通过集成新的敏捷实践来获得巨大的价值。 在本系列后面的几篇文章中。我将向您展示一些 Java™ 技术的备选方法。我们将学习 Java 编程语言本身中可能损害您的生产率的问题。然后，我们将探讨为特定类型的问题提供极好的生产率的框架，比如 Ruby on Rails。 学习
获得产品和技术
讨论
| ||||||||||||||||||||||||||||||||||||||||
