这项工作要花多长时间？
现在是早上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条款和导致市场成功的因素等），并作为另一项用户素材工作。
