EEPW论坛

让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。 （原文链接网址：http://www.objectmentor.com/processImprovement/xpCaseStudies; Robert C. Martin的英文blog网址： http://www.butunclebob.com/ArticleS.UncleBob） 　　本文作者Alexandra Weber Morales，是Object Mentor公司的高级顾问。Robert C. Martin是Object Mentor公司总裁，面向对象设计、模式、UML、敏捷方法学和极限编程领域内的资深顾问。他不仅是Jolt获奖图书《敏捷软件开发：原则、模式与实践》（中文版）（《敏捷软件开发》（英文影印版））的作者，还是畅销书Designing Object-Oriented C++ Applications Using the Booch Method的作者。Martin是Pattern Languages of Program Design 3和More C++ Gems的主编，并与James Newkirk合著了XP in Practice。他是国际程序员大会上著名的发言人，并在C++ Report杂志担任过4年的编辑。