在敏捷中引进新技术

敏捷项目通常持续的周期都很短。因此，在如此短的时间段里引入新技术总是充满风险的。假若你准备引入任何新技术，并且最终完全失败，那么搭建基础设施所花的时间和成本，加上冲刺的失败，将会把你打倒。

适宜性

在给应用选择技术时，有一件重要的事情得记住：要看这项技术本身是否适合这个应用，而不是去考虑它在市面上的流行程度。在制定决策时，技术针对所需解决方案的适宜性应该要比市场趋势得到的关注程度要多得多。

我们曾经有一个项目，它需要非结构化的文本分析；UIMA 似乎是理想之选。但 UIMA 使用的是外部序列化，而不是一个序列化接口（那会让它的对象变得臃肿），这就需要在序列化数据方面做大量的工作。结果，这个功能是自行开发的，没有使用 UIMA。

知道如何不选择某种技术也非常重要。期望得到某种技术仅仅是因为它的流行程度、易于使用或价格，那你可能无法得到最佳的技术选型。

Ellyssa Kroski 谈到了选择 / 不选择某种技术的五个原因。

“团队会倾向于他们觉得用起来顺手的技术，因为每个团队已经建立起了一系列的技能。首要的关注点应该是特性和功能，而非技能集。一定要跟你的技术专家合作，好让他们理解他们要扩充他们的技能集，而且得到他们需要的培训。

你的老板会从杂志上读到它，在培训时听到它，在梦里梦到它。如何告诉你的老板其他选择，而又不致于显得是在贬损他们的发现？这得把握住分寸，小心翼翼地试探。通过把手头做的调研工作扩展至其他选项，自愿地让他更全面的掌握信息 - 当然，应他的请求！

你的朋友告诉你“它是重大创新！”。接受熟人生动地转述来自客观源头的原始数据是我们的天性。但要是选择技术解决方案也如此的话，这种道听途说的证据并不能给我们提供一个对于该软件、其特性、功能或公司可行性的全面评审。

它是昂贵的，是便宜的，还是不要钱的。很容易假设，因为产品最贵，所以它就一定比它的竞争对手要好。类似的，我们大多数有预算压力的人总是斤斤计较。评估某项技术解决方案时有非常多的因素要考虑，不要孤立的把价格作为衡量价值的指标。”

能力

另一件重要的事情是团队掌控被引入的新技术的能力。要是你发现有人在一个问题上纠缠了好几天，大可不必感到惊讶。

在引入新事物时，这是司空见惯的情形。因此，在使用新技术时进行结对是必要的。对于某些问题，所需的脑力超出了单个开发者的水平，因此，结对肯定能对此有所促进。

在敏捷里，团队规模相当小，因此，假若某人一直在从事新技术，那么团队就会对他产生依赖。在结对编程时，关于新技术的知识随之分散到了整个团队里，团队就有了一个平衡的“车号”（Truck Number，译注：车号是评估软件项目长期存活力的非正式度量，它指的是对于项目成败非常关键的开发者个数，该数值越低越好。更多的描述请参见这里）。

在新技术上结对编程的一个附加好处是团队的学习。

个人学习是必须的。要想变得高效，程序员必须用最新的技术武装和增强自己。这不仅对项目有益，而且可以满足程序员对于知识的渴求。学习将让他们对自己的工作满意，进而增加个人和团队的生产力。

Andrew 谈到了学习对于工作的重要性。

“为了找到正确的平衡，所有工程师都了解他们整个冲刺过程中在做的事情很重要。假如出现一个症状，如你发现有个工程师在角落里埋头苦干了几个小时，一两个 Scrum 中他们都说只剩下一两个钟头就可以搞定了，然而时间流逝了，却还是一事无成，那么你就清楚你遇到麻烦了。 有时，这可以通过结对解决，但它还可能是团队准备工作做得不充分的迹象。”

稳定性、支持和文档

另一件需要注意的事情是该技术可以得到支持和文档。我曾经遇到过有些 API 完全没有或者只有寥寥几个甚至是错误的文档，搞清楚它们非常难。要是你是该技术的早期采用者之一，那么情形会变得更糟，因为很少有支持可以以博客 / 文章 / 论坛的形式找到。然而，某些没有非常完善文档的工具几乎没法用，除非你愿意花大量的时间对其进行彻底的探索。

我曾试着在一个项目中使用 Apache Batik，关于它的文档和支持并没有太多。我经常会遇到问题，在互联网上找不到关于这项技术使用的太多资料。相反，JavaFX 也解决同一问题，但它有很好的文档和支持。

有一个项目需要一种用户界面，它既可以作为桌面应用运行，也可以在 Web 浏览器里运行。我们选择了可伸缩向量图（利用 Apache Batik）来解决这一问题。

使用 Apache Batik 的时间很快就因为遇到的问题而到头了。但是，Apache Batik 曾经在团队里讨论过、探索过，然后甚至在作为解决方案搭建基础设施之前就被抛弃了。接着开始去寻找其他技术，JavaFX 脱颖而出。JavaFX 看起来前途远大，易于使用而且是新兴技术。在一个冲刺内，它的基础设施被建立起来，其中创建了一个简陋的 UI，之后进一步的开发就采用了 JavaFX。

新技术与项目里已经实现的技术之间的兼容性也非常重要。就像前面提到的项目，有些 Swing 组件已经开发了出来，JavaFX 提供了一个特性可以嵌入 Swing 组件，这使得那些 Swing 组件得到了重用，避免了返工。

对于特殊技术的支持也相当重要，因为你可能会碰壁，需要找到条出路。开源产品在此会得到加分，即便你没有任何关于这个技术的支持，你还可以看看代码，然后修改它。要是它是闭源的，如果无法得到对于这项技术的充足支持，你就可能会发现自己在某个地方被卡住了。对于开源技术，如果你本身没有能力去完成，还可以找到公司为你修改和定制产品。

很多流行的开源解决项目都有绝佳的文档以及一大票免费和商业的支持选择可以找到。由于社区发展的天性，文档和说明往往从不同角度来阐述——造就了非常全面的信息、说明和教程。此外，开源项目无法隐藏使用信息，这得归因于免费可以获得的代码。免费的技术支持也可以以邮件列表或新闻讨论组的形式得到。然而，某种形式的背景研究、知识或经验常常是需要的。

Jesus M. Gonzalez-Barahona 谈到了利用开源技术的优势。

"可以获得源代码和有权进行修改是非常重要的。它促进了软件产品的无限优化和改进。 有权以任何形式使用软件。这进而帮助我们搭建起一个软件支持和定制的市场，可以吸引越来越多的开发者参与项目。

软件的未来不会依赖于某个实体。如果某个最初创建该代码的组织或公司打算停止开发，总是有可能找到另一家软件组织继续维护和改进，没有任何法律条文的限制。

修改软件不需要按拷贝付费。尝试新技术的人们可以立即的集成和采用它们，没有商业门槛或保密协议许可。"

算算从它出现在市面上和预计生命长度之间的时间间距。使用一项马上就要过时的技术毫无意义。如今，技术都以闪电般的速度发展，因此，总是看看技术的竞争者，你可能会得到些惊喜。

迭代引入技术

要想引入新技术 / 框架，一次一小步是个好习惯。一种好的做法就是探索该项技术一点，然后就分析它是否适合作为解决方案。然后尝试使用这个新技术 / 框架解决最简单的业务问题。不要一开始就全面依赖它，只让项目的一小部分使用这项技术然后再观察它的效果。

这有助于熟悉这个技术 / 框架的语法和其他特性。这种方式的另一个巨大优势在于你无需花时间单独的搭建使用所有新事物的基础设施。

我有一个项目选择 Drools 5 来作为解决某个问题的方案。但是，关于 Drools 5 的应用能力和特性还不知道。除此之外，Drools 5 对团队成员来说还是新事物。因此，有一个冲刺专门来使用 Drools 5。一个被设想出来的简单问题在 Drools 的帮助下得到了解决。这肯定了 Drools 将作为本次冲刺的基础设施被搭建。而且，团队成员也有时间去了解它。

使用 Drools 解决简单问题使得有机会亲手实验，这增强了对于技术的信心。

作为一个 Java 项目，对 Drools 5 的依赖被加到了 POM 中。Spring Bean 被定义出来创建会话，简单的 drl 文件也被书写了出来。每个 drl 文件都有一个 Drools 特定的规则书写语法。使用 Session Bean 把对象传给代码，代码在这些对象上执行规则。这个冲刺之后，Drools 的基础设施就位了，团队了解了它的语法和其他技术。更重要的是，有了一个 使用 Drools 5 的解决方案。因此，对于技术的信心增强了。

Robert McIlree 谈到了迭代引入技术：

“随着时间的推移，通过足够的成功递增引入一项新技术，对于技术来讲，可以获得切入组织其余部分的牵引力。万一引入因为其他什么原因失败了，组织整体的风险和成本很低。”

在这个阶段，解决方案要实现的问题不应该非常重要。其主要目标是搭建新技术的基础设施。一旦项目基础设施创建完成，并且看起来让人赏心悦目，足以继续下去，这样，实现它的风险就会小一些。

性能

一旦应用采纳 / 接受新技术，那么预期结果和它的功能接受标准就都要完成。然而，在你开始深入更复杂的例子且技术成为应用的一部分之前，功能的卓越程度不是你唯一要考虑的东西。性能相关的问题可能会开始让你烦心。

如果从一开始接触新技术你没有关注其性能，那么它很有可能成为当下的负担，最终丧失采用新技术时投入的所有努力。因此，在引入技术时就得严肃地对待性能问题。如果技术可能会成为瓶颈，那么就把它找出来，尽早丢弃它。

风险承受能力

团队在项目当前状态下的风险承受能力是决定引入新技术与否的另一个考虑因素。如果项目不那么稳定，团队甚至还在陷于当前的实现技术和其他问题，那么再增加需要用新技术完成的新任务就不理智了。在这种情况下引入新技术会使团队遭受重创。他们将在错误的时间处理掌握新技术的额外任务。然而，如果团队表现 良好，产品也很稳定，那么大可大干一番。

Dave Nicolette 撰写了关于管理和计算风险的因素。

“如果提议的解决方案涉及到 IT 组织支持的标准技术基础设施中还没有建立起来的技术或产品，高可觉察风险和低实际风险就会出现。看看是否有机会引入没有技术实现难度，但你的公司之前没有使用过的新技术。. 这将推动传统项目的估算增高，而又不增加项目的实际难度。“

信任

最后，在已经接受技术之后，你所需要做的全部事情就是“信任”它。它是一种个人现象。然而，你对所接受技术的信任程度将导致你跟它相处的难易程度。就像 Bahmanziari 说的，它完全因人而异， Tammy 在计算机信息系统刊物上撰写的文章谈到了信任。

“个人采纳者的性格在对信任不熟悉事物的习性上扮演了重要角色。这种性格特征通常被称为信任度。某些人在毫无任何理由这样做的时候表现出高度信任，而另一些人则在有理由给予高度信任的时候表现出信任程度很低。”

技术采纳者必须完成前文提到的分析以形成对技术的理解。利用分析中收集到的信息，可以加强对技术的信任。你需要信任，因为技术还没有被尝试和测试。假使它们被尝试和测试过了，那就没有信任的必要了，因为你已经对它了如指掌。

计算机信息系统刊物也谈到了信任在技术采纳过程中的重要性。

“绝大多数信任理论者可能都同意，尽管没有人可以给信任下个定论，它在所有情形下都是有用的，但是不确定性和某种程度的漏 洞必需因为信任而存在。毕竟，对完全确定的事物而言，信任是不必要的。正是由于这种不确定性的存在，造就了漏洞。技术采纳者在不确定的环境中穿行；因此，他们的评估必然包括对于该技术以及其提供者的个人看法和不完全知识。"

总结

引入的技术应该能够解决业务问题。它的流行程度不应该作为选择的基础。技术的早期采纳不应该在项目处于逆境的时候进行。开发者不应该惧怕学习曲线，因为它将增强他们的知识。技术应该迭代引入。每个迭代取得的成功 / 失败应该决定下一个迭代的步骤。结对编程应该在新技术上实行，好让知识在团队内传递。在完全接受它之前需对它留心。一旦信任技术之后，你将化蛹成蝶。

查看英文原文： Introducing New Technology in Agile

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。