摘要：经过了极限编程的洗礼，赛门铁克的开发人员、测试人员、技术撰稿者和管理者们都感到收获颇丰...甚至其高层管理者都为之震撼

正文

这是一个阳光明媚的三月早晨，我在犹他州的American Fork市，这里的小型工业园区被Wasatch众山所环绕，其中有一座双层建筑，在它的二楼的一间宽敞的四面玻璃的房间里，25个工作人员（一共有120位工作人员）正环绕着中间的一组办公桌和电脑围成一圈。这是一个站立的会议，团队每位与会成员要向大家汇报工作进展情况，而且汇报时间最长不能超过20分钟。讨论内容包含了像是以下的这些事情，“我们正开始搭建自动化测试工具。”；“我们已经完成了数据库结构的更改。”；“我们正在和HP的管理者一起工作，而且我们需要会HP-UX的人过来帮忙！”；“我们已经定位了问题所在！”；“夜构建（译注1）跑起来了！”。

我应OO大师Robert Martin之邀来到赛门铁克探访，这是为了了解他们的工程师是如何对其安全响应方面的新产品Orca用Java进行历时一年开发的。受探访的开发团队正是其公司向极限编程（译注2）变革的先头部队。此外，还有另外两个产品开发的先头团队，一个是同在犹他州的Rubicon更新版的开发团队，还有一个是叫做Jaguar的新产品的开发团队，他们在德克萨斯州的圣安东尼奥市。

以终端用户软件Norton AntiVirus而享誉中外的赛门铁克公司也提供各种安全产品和服务，诸如缺陷评估（vulnerability assessment）、防火墙、入侵防护（intrusion prevention）、内容过滤和反垃圾邮件（Internet content and e-mail filtering）、端点安全技术（remote management technologies）和安全服务。该公司于1982年成立，总部位于加利福尼亚的Cupertino市，这家上市公司与36个国家间都有业务往来。在2000年的12月，赛门铁克收购了一家从事企业安全的公司Axent Technologies，并于2001年三月，赛门铁克宣布于圣安东尼奥正式启动这家公司，将其作为提供管理、监控和响应服务的安全控制中心。

可是，将极限编程技术应用于赛门铁克这样的公司可以说遭受的质疑多于赞同。XP最初兴起于1996年，是Kent Beck和他的几位同事在从事C3（Chrysler Comprehensive Compensation）人力资源项目的时候发明的。可是作为一个独立软件开发商，它该如何去适应XP过程中必不可缺的“客户”（译注3）角色呢？是否可以从地缘上来划分多个彼此独立的团队并进行XP呢？当产品开发进入到两周一次的迭代开发过程中的时候，该如何撰写需求文档来达到高级主管们的要求呢？独立的质量保证和文档撰写部门该如何适应这种以代码为中心且测试为优先导向的开发过程中呢？该怎么才能知道XP行之有效？最后，如果允许谈论这家公司的技术细节及其相关领域的话，一个采访者是否能够清楚的描绘出这家公司的开发过程呢？

要找到这些问题的答案，我要在接下来的六个月里仔细观察赛门铁克的进程。

这是个好点子，而并非命令

看起来过渡来得并不太痛苦，American Fork研发中心要求入侵检测和缺陷评估的专家们参加为期12个月的“XP变革”课程。这其实也只是Object Mentor（1991年Martin在伊利诺斯州的Vernon Hills领导创建的培训咨询公司）第三次做这样的培训。为什么要摒弃原有的做法？是否有什么不可抗拒的命令驱使他们将XP付诸实施？

赛门铁克的开发过程管理总监Carlos Cortez说：“公司雇用我是要我来改善开发过程的可预见性、效率、内容和质量的，没有必要使之成为一种强制，这是形势所趋”，他负责犹他和德克萨斯州的开发团队，曾与赛门铁克掌管产品发布的副总Russel Stay在加入赛门铁克之前共事于辛辛那提的Structural Dynamic Research Corp.公司有超过10年之久。在赛门铁克于2000年收购Stay的公司后不久，他向Cortez申请从事改善开发过程方面的工作。

Cortez怀疑仅通过让开发人员从书本自学是否足够有效，他回忆曾经对Stay说：“要改变我们开发的传统和方法，并从C语言过渡到C++或是Java，不仅仅是每个人自己努力的事，我们还要依靠曾有过成功合作的Object Mentor的Robert C. Martin。我曾目睹过Martin在很短的时间内就为一些纠缠复杂的难题带来了希望，并告诉那些自认为洞悉OO一切的优秀工程师们该如何真正做到OO”。在Stay的邀请下，Cortez很快就开始展开了在赛门铁克的开发过程优化的工作。

挑战困难

其实原本极限编程并非是唯一的开发方法的候选，有拥有25年IT经验，曾发明过软件成熟度模型（CMM）的Watts Humphrey（译注4）所创建的个人软件过程（PSP）曾一度引起了Cortez的关注，况且赛门铁克也已经实现了自己的“解决方案为中心的开发过程”（译注5）。此过程包括了六个阶段（探索、定义-评估-再定义、计划、实现、发布和考量）和五个检查点（随机、需求、实现过程、准备发布和发布后），实现了开发过程事无巨细地呈现于开发团队面前。最后，PSP这种以自我完善和度量为导向的方法还是没能战胜来自XP的强大诱惑，尤其是考虑到一些American Fork的开发人员已经有了XP的苗头。

“我们已经从事XP两年了，虽然还处于菜鸟水平”，在赛门铁克工作过五年的开发总监Joseph Shull说到，“高层管理者们曾犹豫该向左走还是向右走，但现在已经倾向于它了。当培训刚开始的时候，只有25%的工程师知道XP是什么，而现在的情形大有改观”。

“我们过去曾实践过很多方法”，Stay谈起变革的头一个月的感触，“那些都过于教条、拘禁，大家都觉得束手束脚。和当时向瀑布模型变革时情形一样是，一开始都有很多人抱怨变革。不同的是，现在随着接触的时间久了，这些抱怨之声也都慢慢的消失了，可是过去的情形却是正好相反的。不过最大的改变还要属结对编程了，开发人员担心会‘失去个人空间’，我也在怀疑难道接下来的6到12个月里他们都要这样靠在一起工作？”

这项工作要花多长时间？

现在是早上10点，这是他们XP变革以来开的第二次发布计划会议，Orca的开发人员已经被划分为了两组（每10人一组），他们正在一张3乘5寸的索引卡片上记录着用户素材（译注6）--即可能在两周以内实现的简单功能。因为赛门铁克的产品素来是为市场而设计的，并非为了内部的需要，产品经理Karen Rowell就正在代表客户的角色。她快步的穿梭于各团队之间，并为之解答问题。

“我们正在确定所要支持平台”，Rowell解释说，“HP-UX、Solaris、Windows。现在确定它是让开发人员能够清晰的描绘出完整的用户素材来”。人群之中，团队的成员们快速的传递着五张卡片，在每一张上面都写有编写完验收测试以及其所需的功能代码完成构建所需要周数（只能是一周或是两周）。突然，他们卡在了某张卡片的一项功能上，“我知道这是个难题”，Rowell插话道。她的意思是这需要一些简要的实验才能确定到底完成它需要多长时间。“这项功能是全新的，而且这次产品发布后可能就不用了”，她说。

要明白我们只有一个Rowell、两个团队和有限的一些时间，“我们不希望他们太依靠客户（即Rowell，关于客户在敏捷领域的真实含义请参见译注4）”，主导这次XP变革的Object Mentor的高级顾问David Farber说，“如果他们非要她才能解决问题的话，他们应该写在卡片上然后递给她”。这样做并非是不鼓励与客户进行紧密交互（XP恰巧非常看重客户交户），而是在推动这些开发人员更快速的工作。

除了开发人员和管理者之外，还有一些测试人员和一个技术撰稿者也同在房间内。“我们在仔细聆听呢”，QA团队的高级经理Matt Sellers对我说，“如果我发现要测试三天的事情他们却告诉我要用一天的话，我会马上大声告诉你们的”。

项目在一边磨合一边进展着。到中午为止，整个团队已经想出了74个用户素材，Faber得意洋洋的汇报到。这是自第一次发布计划会议以来所取得的一个巨大进展，记得几周前的第一次发布会议上，整个团队只完成了大概20个左右的。“这个早上对于整个团队来说都是个飞跃”，他解释说，“在此之前，他们都在讨论些非常抽象的概念：这是基于Web的，这是基于XML的，这是管理上的反映。现在，他们能够去处理真实可见的问题了”。团队也在享受着XP的用户素材所带来的好处--避免不必要的复杂性。像这样的事情就经常发生在我们中间：Rowell希望实现的一项用户素材超出了Orca的能力范畴，因为它实现起来太耗时了。在讨论这个特定用户素材的时候，开发人员解释了为何实现这项功能需要花上六个月，于是Rowell就砍掉它了。

Orca项目进行得很顺利，可是Cortez说American Fork的第二个XP的项目--Rubicon产品的更新，进展得并不如意。可能误以为我有超强的分析能力吧，他让我对于Rubicon进展缓慢的问题给出一些可行建议。当我加入了他们的会议，我能看见唯一还保持着微笑的人就只有Object Mentor的企业教练James Grenning和“客户”了。在这两个人的指导下，团队成员开始试图去定义用户素材，但还是有人不断的抱怨这些方法是徒劳的。直到我们离开时，依然还没看到任何的用户素材完成。

从用户需求到用户素材

就像她的大多数的同事一样，Karen Rowell拥有计算机科学的学位，而且热爱所从事的安全领域。她曾是Unix系统工程师并工作过12年，还有6年半的时间工作在赛门铁克。在团队了解到公司已经采纳此法之前，她从未听说过XP。在做“客户”之前，她用过一些传统的需求搜集的办法来创建关于Orca这个安全响应产品的市场计划，她从客户顾问或是政府和安全学术机构那里来汲取有效的商情报告。

Rowell现在发现用编写用户素材代替先前的空凭想象，并且关注两周一次的迭代过程意味着所有的用户需求都能按照客户或市场价值所需正确的表达。“这并非亦步亦趋的方法，实际上我们已经直接看到了结果--两个界面已经完成了”，她自豪地说。

用户素材本身并非是用户需求，然而，“这是一个挑战，因为每次迭代都要去发布一些部件”，Joseph Shull说，“我们总是倾向于作出一些功能却无法发布，在能测试它之前我们都无法亲眼看到它。我们需要一个支持测试优先编程的基础架构”。其实相关的QA正在进行这样的一个项目，而这个新开发的基础架构是福是祸还有待继续考察。

让QA融入进来

XP的一方面创新构想就是试图去整合传统的质量保证部门到定义、评估和编码阶段之中，而避免过去那种把问题丢掷脑后的习惯。然而真想做到这一点，绝非易事。

“按照我们过去的做法，开发工程师的工作结束了，QA才开始测试产品”，开发过程管理的高级经理Bruce Ackerson解释说，“现在，我们整合了整个团队，这包括QA（IQA）部门和自动化测试QA部门，并在开发过程中就与之协同工作”。开发工程师编写单元测试，AQA工程师编写验收测试，而IQA工程师对用户集中关注的功能作评估。为了达到如此程度上的紧密协同，他们坐在一起开了八、九个会议，令Cortez感到悲哀的是到目前还有些角色和职能尚未清晰界定。

“还有一个QA总是和我们的这种开发过程对着干”，Object Mentor的Faber观察到，“那些‘反对阵营’的人数目前还多于我们这些支持者”。

然而，七位AQA工程师的经理Matt Sellers对这种做法的可行感到非常兴奋，他计划去实现一个更加自动化的QA说法，他研究了这本经典的《实现极限编程》一书（译注7），说：“上面讲道客户应该提供验收测试，并且将其自动化。于是我们已经编写了很多用于自动化测试的素材，而且已经开始用XP的方式在开发这个运行的框架”。他设想用一个数据库来保存这些测试用例，“在Orca项目之前，我们没有搭建一个库的需要，现在，我们将会用到数据驱动的运行测试脚本的部件，这会带来更多的重用价值”。

三个月后...

希望也能像是电影慢镜头回放一样并从中发现一些迹象，我又回到了American Fork ，这回是在八月里的炎热的一天，依然为这众山环抱之城的美丽所倾倒，我期待着再次的驾车到访Carlos Cortez他们。

Orca这个新产品的进度还在掌控之中，然而，另外的一个产品Rubicon的更新项目却依然停滞不前。几周前，开发人员撤出了那个项目并转移到了当前Orca中，因为这个产品需要保证其按时发布。Orca现在就成了American Fork的唯一的XP团队，虽然Cortez还指望着Rubicon团队能与十月中旬再度开工。

“问题是难于给产品方向做出定位”，他说，“人们已经转移到其他项目了，就像你所看到的，在用户素材的问题上还存在分歧”。

分歧的部分原因是因为Rubicon项目已经违背了XP的关键原则--保证客户的参与其中。这位在一开始就担当产品经理一职的同事每周只能从东海岸过来四天，而对于此，Cortez认为是个错误。

他们下回不会再这样做了。

Orca的开发人员成功地将它们的成功经验传授给了负责入侵检测产品Blackbird的圣安东尼奥团队的同事们，此产目前内置于防火墙之中运行，负责过滤和检测入侵，而后项功能是到目前为止Blackbird产品中唯一用XP方式打造的部件。

“我们努力让圣安东尼奥的团队转向XP，众望所归，他们也成功的按时完成了这个历时四个月的项目，而且还比我们之前所计划的具备更多的功能”，Stay夸赞道。他说圣安东尼奥的团队虽比Orca稍小些，但在变革过程中却更加守旧，“三个领头的架构师想用Rational统一过程，但我们让他们去参考比较工作。还有三个不在本地的同事，我们让那些开发人员通过远程连接与开发人员协同工作，但XP却让我们更需要工作于同一间办公室里”，他说。遵照Stay的想法，一个过去工作在奥兰多Boulder市的主要开发人员已经搬到了圣安东尼奥来跟他的合作开发人员一起以双倍的效率结对编程。回到Amercian Fork，他们正在探索一种针对文档撰写的“结队撰稿”方法。我对“结队撰稿”的第一反应是恐怖，因为我观察过很多开发人员对这种结对方法都有发自内心的恐惧感。经过进一步的思索，我发现很多文档撰写相关的工作是可以采用结对方式的，尽管如此，Cortez还是承认此种方法存在不少抵触意见。

圣安东尼奥终于彻底的完成了XP的变革，并且他们用了“异地结对编程”（cross-site pair programming）的方法，用CRC卡片和UML图表来交流工作。经过了这次的变革，他们中的五位开发人员加入到了Orca项目，这样Orca就总共有10位开发人员、一个半的技术撰稿者、五个QA工程师和一个客户代理。变革并未带来不良影响，除了有一位测试人员离开去功读微生物学，仅此而已。

Cortez认识到去度量并汇报一个XP项目有些困难，尤其是该如何与现有的解决方案为中心的过程（SCP）相结合。“赛门铁克传统开发过程是试图去做到充分的预期，但是问题不在计划上。他们试图将软件开发过程看成是一组可以预先计划清楚的事件，但它实际上是个非确定过程”。据Cortez所述，掌管企业解决方案的高级副总裁Gail Hamilton到访了他们，并表示她被团队的工作热情感到震撼，并告诉Cortez要去改善SCP。基于这点，他告诉我说这些主管们吵着闹着要改进需求文档（包括了预算、license条款和导致市场成功的因素等），并作为另一项用户素材工作。

摸爬滚打

设施还存在一些问题，因为先前的会议室已经被XP团队“占领”了并作为他们的XP战场（所有会议和结对编程都在这里进行），这样就太狭小了。Cortez带我下楼，走到更宽敞的一楼，这里曾经布满小隔间，而现在是团队的所在。虽然开发人员非常乐意在几千平米的宽敞房间里办公，但Cortez打算划分这块区域。在必不可缺的中央办公桌的上方悬挂着一条充气鲨鱼。白板、XP的小贴士和彩色的项目进度示意表（显示了验收测试的成功率和用户素材的完成度）随意的贴在墙上。

又是一个周三，Orca的团队完成了一个新的发布。在七月，这个团队代码的完成进度比开发经理先前所预料的要早得多。“这与以前的情况相反，我们往往是有非常多的方法级函数而不是用户级的”，Cortez兴奋的说道。可是迭代计划会议仍然比理想的两个小时要长。“每个用户素材不应该花半个小时来讨论，如果真的用了那么多时间，那应该称作是训练，而不是真正的计划会议”，他说。谁应该成为XP导师也尚未明确，因为团队的内部成员现在都成了XP的积极拥护者。

QA在过去两个月来...

测试人员在过去的几个月里一直非常繁忙于构建基于XML格式的测试框架，并用HTTPUnix中的JUnit、Perl、Python和Java的脚本来呈现测试结果。我在一间昏暗的房间里看着屏幕上的命令行正在飞快的滚动过一系列的单元测试的执行状态。高级QA工程师Mike Kirsch和QA主管Matt Sellers向我演示了XML是如何在夜构建完成后的验收测试执行过程中输出，并弹出自动生成的测试结果页面。

“因为每个团队都有他们自己的测试脚本语言：Orca项目用JUnit，圣安东尼奥的青睐Perl。所以我们已经搭建了一个称之为shell的程序，它能将结果返回到XML之中，”Kirsch解释说。程序会根据结果自动生成了一张彩色示意图（就是我先前说过贴在墙上的那种）来展示验收测试的成功和失败率。在迭代的一开始，验收测试完全失败了，但随着迭代开发的进行成功率也在逐渐增加，直到他们经过最后一次为时两周的迭代，所有的就都跑通了。从这里可以看出，除了使用用户素材，否则很难去展现真实的进展。

虽然说QA的团队认为他们的工具很棒，他们的代理客户Karen Rowell对测试的结果并不认同。“我不是Java开发人员，我也读不懂Java。这些测试还不够有说服性，公司怎么知道我们是成功的呢？”她问道，“我想让他们换一种方式来做这些事情，我想让QA详细地说明任何的一种可能的测试组合”。当然，我也参加了这个会议，Rowell拿起一个写着“#382：可理解的验收测试”的卡片然后宣布，“我想要在这次迭代里面做这件事情，因为我无法理解它，我给你们时间来作它”。开发经理Alex Smith告诉团队他们也需要指出过去的那些单元测试都是用来做什么的。

显而易见的进度

如果测试过程还算波澜不惊的话，测试优先编程的结果却不然。这是一个中午，我和Shull、Ackerson、Smith、Rowell、Cortez和Grenning围坐在一起。我们离中心工作台只有几步之遥，那里有好几本《Inside XML》和《Software for Use》（译注8）很整齐的摆放在其他零散的书旁；我们谈论的时候，开发人员正在使用Visual SlickEdit进行编程。

我感觉空气中散布着成功的味道，可能真是如此，也或是作为一个到访者对在这里所做得感到很满意吧，因为Orca团队已经成功发布了产品最新版到位于爱尔兰的i18n团队（译注9）了。这个团队与Orca的进展时刻保持着同步，所以用句Ackerson的话说，他们能确保一直收到稳定的代码。而且他们现在已经完成了所有必要的字符本地化。

不只如此，XP已经慢慢地变成了他们的第二天性。“团队更加善于自我完善了”，Joe Shull笑着说，“感觉运用XP更加自如了。软件开发在周而复始的调整中进行着，虽然我经历XP好几年了，但这还是头一次得到了管理层的充分支持”。目前为止，结对编程还没导致什么人承受不了而离开房间，而且就像Alex Smith所说，“来自同行的压力是保证代码质量的首要原因，要不然的话，等到合并的时候就有你忙的了”。

“不幸的是Perforce（一种源代码版本管理配置工具）影响了我们的进度，尽管我们正在试着去解决这个问题 ”，XP的方式增加了像Perforce这样的版本管理系统的负载，因为它现在几乎替代了调试器的位置。“过去我们一只习惯使用调试器，但这几个月来我们都没摸过它”。Shull自豪地说。

在我离开之前，Smith给我做了个安全响应系统的原型演示，这看起来基本上就是个产品了。

六个月后...

现在已经是十月下旬，我在和Carlos Cortez讲电话，通过电话我疯狂的记录着Orca团队的目前进度。“今天我们开了个很棒的会议”，他对我说，“我们已经按照意愿把安全响应列表加入到界面中了，你可以操控、排序、并通过拖动鼠标来动态转换报表的格式”。我问他是否有任何的矩阵示意图来描绘目前开发进度。

“嗯，在这两阶段开发的过渡期，我们发布了一个硬件产品，这可是是头一次准时发布的，而且beta版仅遇到5个一般性bug。Orca今天结束了第二阶段的开发，经过了这六个月的开发，我们在13次迭代过程中（每两周一次）只遇到14个bug”。这可是一个大概有5000行Java代码的产品，再加上另外4000个验收测试和单元测试。“我已经目睹了验收测试带来的代码的不断减少，这令我想起了读过的一篇Grady Booch的文章，上面提到你应该会看到代码行的减少，这就意味着重构的进行是成功的”，Cortez说。Booch白皮书建议去度量每个发布中的类的数量，而且记录下代码行数，并且将上述两个数字进行对比来发现在重构过程中架构是否真正改进了。Cortez已经提议将一个类似的方法提交到委员会，并使之加入到赛门铁克解决方案为中心的过程中。

更重要的是，他认为QA的难题最终得到了解决。“我们曾问过‘为什么测试的速度非常缓慢而且成本颇高？’，AQA部门认为是因为他们产品间的距离，它形成了阻隔。两周前我们重新调整了QA的组织架构，我们打乱了原有的组织，而且把这些QA员工分散在了三个现有的产品团队之中。技能的混合使得产品导向型新QA团队可以创造出更清晰的产品测试，并且通过结对编程过程，他们能做到更高的测试覆盖率。测试的可读性和速度缓慢的问题也解决了75%”，Cortez指出，这意味着Rowell现在能理解它们了。

赌局的丰收

“你们对开发过程是无计可施的”，副总裁Stay说道，“我们曾经有一些怀疑论者，所以我们说如果大家都同意的话我们才会进行XP变革”。赛门铁克把扩招雇员的经费转移到了XP培训上，并且希望通过效率的提高来平衡成本。“如果你每扩招100位员工，却不能提高至少百分之三、四的产能的话，其实是南辕北辙了”。有意思的是，以前圣安东尼奥的那些保守主义者，现在倒成了XP的激进分子。

圣安东尼奥的XP变革是由那些高级工程师们推动的，Cortez解释说，而它么现在已经成功地发布了两个较小项目（三到四个人月）。“开发总监和开发流程总监曾是两个最不看好XP变革的人，最近他们告诉我说，从现在起，他们绝不会再用XP以外的方法了。我说，‘你们俩是不是也太对XP偏执了，没有任何过程是完美的。’”

一年以后...

Cortez赞扬了Orca产能的提升和这种欢愉气氛的弥漫开来，Stay期望通过Orca，Rubicon和Jaguar团队来培训希望采纳XP的团队。高级开发人员Stan Paulson已经被任命为XP导师，负责保持此种开发方法在传授过程中的纯粹性，同时避免向老习惯退化的迹象。Alex Smith被任命为导师长，这与目前的他管理者的职责相一致，他更是一位跟踪者，他要保持跟踪每个人的进度和所有在迭代过程中被列为任务的情况。这两位将会帮助其他的组员，他们甚至也要负责自己XP技能的不断提升。

尽管QA团队成员们还并未培训过XP，变革之风也使得他们认识到与开发团队更紧密合作的重要性。

赛门铁克的研发团队再过六个月会怎样？可以想象在接下来的六个月中，Orca团队会持续的实现目标，每两周就能发布一次“可发布”的软件。是什么让XP如此具有吸引力？可能是因为它那质朴而又迭代的过程，不像是其他的那些强调编程细节的敏捷方法。经过我这次的访问，问题已经清晰起来，采纳极限编程并非是下属的意愿，软件开发的高层管理者们进行干预和执行，员工们遵循公司的开发过程，这才是赛门铁克到目前为止成功的关键。更重要的是，要在高质量的培训上进行投资，并鼓励整个核心团队都进行改变。在用一句Kent Beck的话来结尾吧--拥抱变革才是XP精髓所在。

译注：

1，nightly build，夜构建，与日构建基本相仿，但强调构建的时间是在夜间进行，避免与白天的开发过程相冲突。

2，极限编程，即XP，全称是eXtreme Programming，是敏捷方法中最重要的一个。它是由一系列简单却相互依赖的实践组成。这些实践结合在一起形成了一个胜于部分结合的整体。

3，客户，XP强调客户和开发人员在一起紧密地工作，以便于彼此知晓对方所面临的问题，并共同去解决这些问题。XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或是团体。有时，客户是和开发人员同属一家公司的一组业务分析师或是市场专家。有时，客户是用户团体委派的用户代表。有时，客户事实上是支付开发费用的人。但是在XP项目中，无论谁是客户，他们都是能够和团队一起工作的团队成员。

4，Watt S. Humphrey，在软件工程领域享有盛誉，被美国国防软件工程杂志CrossTalk评为近百年来影响软件发展的十位大师之一。他曾于卡内基·梅隆大学提出能力成熟度模型（CMM）思想。在CMM浪潮席卷软件工业界之时，他又力推个人软件过程（Personal Software Process），成为软件开发人员和开发团队的自修宝典。

5，解决方案为中心的开发过程，原文是Solution Centered Process，赛门铁克内部简称其为SCP。

6，用户素材，原文user stories。索引卡片，原文index card。为了进行项目计划，必须要知道和项目需求有关的内容，但是却无需知道得太多。需求的特定细节很可能会随时间而改变，因此，在离真正实现需求还很早时就去捕获该需求的特定细节，很可能会导致做无用功以及对需求不成熟的关注。在XP中，我们更愿意客户在索引卡片上写下一些我们认可的词语，这些片言只语可以提醒我们一起这次交谈。用户素材就是正在进行的关于需求谈话的助记符。它是一个计划工具，客户可以使用它并根据它的优先级和估算代价来安排实现该需求的时间。

7，国内将此书译为《实现极限编程》，原文eXtreme Programming Installed，作者Jefferies R、Anderson A、Hendrickson C，于2001年Addison-Wesley出版。

8，《Software for use》，国内一般译此书名为《面向使用的软件设计》，此书曾于1999年获得Jolt大奖，作者Larry L. Constantine & Lucy A.D. Lockwood，于1999年Addison-Wesley出版。

9，i18n，全称是internationalization，即国际化，因为在第一个字母i和最后一n之间存在18个字符，所以一般简称为i18n。

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

京公海网安备110108001071号