敏捷实践的秘密

《敏捷实践的秘密》开发、测试不可多得的思想Infont c目录前言.我和敏捷团队的五个约定如何在敏捷开发中做好数据迂移RICHCLIENT/RA原则与实践(上)22R| CHCLIENT/RA原则与实践(下)…28为什么我们要放弃 SUBVERS|ON….137持续集成"也需要重构。。。。。。。日。。。。日。。。。。。。。日。。。。日。。。。日。。。。日。。。·日。。。。B。。。。。日。。。。看。。44MOCK不是测试的银弹58环境无关的环境64TECH LEAD的三重人格69自动化测试的分层结构….77(番外篇)TDD之实践主义·日■·日自。·自日。。。日·。。日。。日···日看。。。看。·看曹85ThoughtWorks感敏捷中国大会AGILE CHINA 2010由 ThoughtWorks主办,CSDN承办, InfoQ提供票务支持的第五届敏捷软件开发大会“敏捷中国2010″将于10月14-15日在新世纪日航酒店举行。大会将分四个主题:业务、技术和实践、领导力与组织及工具。敏捷中国2010旨在为敏捷爱好者搭建开放的交流平台,向社会公开征集演讲话题及讲师。● Martin fowler,著名作家,软件咨询师及演讲家, ThoughtWorks首席科学家● Mary Poppendieck,电信领域精益软件开发方法权威,著有《 Lean SoftwareDevelopment: An Agile Toolkit》(曾获Jot大奖)● James Grenning, Renaissance Software Consulting公司创始人,全球知名讲师,过程教练及咨询师● Jean tabaka,拥有30年软件开发行业经验,著有《 Collaboration ExplainedFacilitation Skills for Software Project Leaders y何勉,上海贝尔高级项目经理,长期从事电信产品软件开发、产品项目管理和软件部门能力建设等工作张为民,曾任爱立信(中国)项目经理,现仼中国移动通信硏究院业务拓展经理点击报名,享有优惠10月14日至15中国北京新世纪日航饭店fooInfoQ中文站作为第四届敏捷中国大会合作方,共同组织策划帮助 ThoughtWorks实施了以“实效敏捷”为主题的敏捷中国2009大会。Infont c第一章我和敏捷团队的五个约定賈其熬 Thought Works公司敏捷咨询师我一一作为一名测试人员一一有一个与众不同的习惯:每当要加入一个新项目的时候,我总会找到项目中的同伴,真诚而亲切地说:“为了更好地合作,我有5个约定,希望大家能尽量遵守”。约定1.业务分析师们,我们其实是同一个角色的两种面孔,请叫上我们参加客户需求会议我们的团队需要让客户频繁的得到可用的软件客户的不断反馈会给软件的未来做出最正确的方向指引如果我们交付的软件有很多质量的问题,存在大量的缺陷,客户会被这些缺陷的奇怪行为干扰,没有办法把注意力放在软件本身的价值是否符合他们的真正需求上,不能给出最有价值的反馈。所以,我们只有频繁的做测试,在每次交付之前都把质量问题找出来告诉我们的团队,问题才能及时的得到改正。而我坚信" prevention is better than cure"(预防胜于治疗),我会要把工作的重点放在预防缺陷上,这样可以节省Dev们很多修复缺陷的时间与精力为了达到这个目的,我需要跟你一起参加客户需求会议,尽早的了解客户需求与使用软件的惯常行为。那么在你完成需求的验收条件的定义的时候,我也基本完成了测试用例的准备。我们可以赶在开发人员们写代码之前就告诉他们我要测什么,让他们减少因为过于乐观而漏掉的一些重要的有破坏性的情况,减少缺陷的发生。这是我测试的一项重要任务。如果你们在大部分需求都整理好了再交给我们,我会浪费掉等待的时间。更重要的是,开发好的软件里面已经有很多本来可以不存在的缺陷在里面了开发人员们可能需要加班加点来保证在项目最终交付时间之前把它们改好。这样很容易产生新的缺陷的。所以,请让我尽早了解需求,请不要让我到项目后期才能开始测试。约定2.开发人员们,虽然你们是编写自动化测试的专家,但请听听我们意见我知道,对于你们,自动化测试不过是利用 junit, rspec, selenium, watir, automation等等Infont c写出的“另一段程序″而已。而对于80%的QA来说,编写自动化测试并不是一件简单的事情。不过我仍然相信,有测试人员介入的自动化测试更有价值你们用单元测试,集成测试来保证代码的质量。然而你们的这些日常测试离代码更近,离最终用户还点远。很多测试都不是在测软件功能。你们可以把功能测试写的又快又多而我们可以指出什么功能测试最有必要加到自动化测试中,你们平时大部分精力都在编码上,没有太多时间去査都有什么缺陷。而我们可以指出什么地方缺陷可能会出现的比较频繁,建议在这些脆弱的地方加自动化测试。所以请听听我们的意见,我们可以给你们提供这些信息。约定3.项目经理们,请不要要求我们测试软件的所有路径软件测试是一个永无止尽的任务。基本上没有什么软件简单到我们能够尝试完它的每一个可能的路径的。就连一个看似简单的微软计算器都有无穷尽的路径,无止尽的输入,更何况比这个更复杂的商用软件如果你们担心没有尝试过全部的路径不可靠,疑惑我们怎么敢说这个软件质量是好的还是坏,都有什么风险。请你们先注意,我们是跟业务分析师一样,都了解软件的价值的。价值可以帮我们做出判断,什么时候可以停止测试并对客户说我们的软件已经满足您的要求了,请放心使用。因为我们了解价值,我们可以肯定的说哪些软件的使用方式是至关重要的,哪些是不太可能出现的。我们会在全面测试了软件以后,把主要精力放在价值高的功能点上。合理的利用项目有限的时间。因为我们了解价值,我们可以正确的把发现的问题分类。我们可以帮助deν们把精力放在重要的缺陷上,避免把时间放在对于客户微不足道却不得不花费大量精力才能修正的问题上。所以,请不要要求我们无止尽的测试一个软件。我们了解价值,请相信我们的判断。约定4.迭代经理们,如果对于交付风险有任何疑问,请来询问我BA和De们都是关注一个软件在什么情况是可以良好的工作。而我们除了验证这些情况以外,大量的时候都用在寻找什么样的情况软件不能正常的运行。所以除了针对定义好的软件行为进行测试,我们还会做很多探索性测试。我们通常可以通过这样的测试发现一些没有定InfoEnterprise Software Development Community义的、不曾预期的行为。这些行为往往将会构成软件交付的风险。我们会告诉你们现在都发生了什么问题,分别分布在哪里。我们会告诉你们,在什么情况下软件可能会有异常行为,是不是会牵连到其他的部分,是否可以绕过去。我们会告诉你们,哪些部分功能比较不稳定,需要更多的留意。约定5.测试人员们,那些敏捷实践对于我们也是有用的。结对不是dev们的专利。我不希望总见到你们独自坐在自己的位置上冥思苦想。走出去,跟其他队友多多交流!多跟测试队友交流,pai看看设计的测试用例是不是够全面独自一个人想到的未必足够好。他们会给你诚恳的意见的。对他们,也请一样认真对待。如果你发现开发人员们做出的架构决定使测试工作变得更困难。那么请大声地告诉他们,design for testability(提高你们设计的可测性如果你发现业务分析师写的需求无法验证,定义的客户行为不够具体,一个用户故事中包含太多了功能点,等等,那么也请大声地告诉他, INVEST(独立,可协商,价值,可估算,短小,可测也请你们多跟开发人员结对写自动化测试,既可以帮助你们学习怎样更好的编写自动化测试,也能帮助开发人员们结对更多的了解用户行为。这就是我的五个约定,它们是我在团队中顺利展开工作的基础。作者简介:覃其慧, ThoughtWorks敏捷咨询师。她参与了大量的敏捷软件开发的实践和敏捷咨询。目前主要关注以价值为驱动的敏捷测试。原文链接:httpwwwinfogcom/cn/articles/thoughtworks-practice-partiInfont c第二章如何在敏捷开发中做好数据迁移烹黑恒 Thought Works公司敏捷咨询师数据迁移是指在系统软件开发中,将具有实际业务价值的数据,依据功能需求或系统开发的要求,在不同存储媒介、存储形式或计算机系统之间转移的过程。数据迁移是系统开发经常涉及到的一项工作。在企业级应用系统中,新系统的开发,新旧系统的升级换代,以及正常的系统维护,不可避免地涉及到大量的迁移工作。而在一个以数据为核心的业务系统中,数据的迁移更是无处不在。比如:在以数据仓库为架构原型的系统设计中,EπL(抽取,转换,装载)部分的实现就是一种数据迁移;对大型数据系统的分布式实施,数据迁移就是整个实施过程的主要部分。而在敏捷实践中,渐进式的数据库开发,更是涉及到大量的数据迁移和同步工作。我们时常会听到用户提出这样的要求“我们并不过于关心应用的好坏,但需务必保证数据准确″。的确,在以数据为运营基础的行业里,数据质量本身就是软件质量的权重部分,尤其在电信、金融和控制领域里,这一特征表现的格外明显。数据迁移也是敏捷开发中相当重要的环节,它影响着各个发布版本的数据质量,而数据质量又决定着系统的有效性和可靠性,因此高质量地完成数据迁移不容忽视。数据迁移往往被视为一件很简单的工作。在很多人眼里,数据迁移仅仅是用sq语句向相应数据表装载数据的过程。但在实际操作中,数据迁移涉及到很多层面的因素,如用户需求,系统功能,数据库建模等,若岀现问题,将导致开发进展缓慢或质量不高。常见问题有业务系统逻辑模糊、脏数据、遗留系统的技术债和管理债等。那么如何有效的避免这些问题,提高迁移质量呢?本文将以 Thought Works中国公司与客户合作的CRM项目为背景,为读者介绍如何在敏捷开发中高质量地处理数据迁移工作,从而在数据层面提高系统质量。开发背景A系统(旧系统)是客户原有的一套CRM(客户关系管理)系统。系统采用B/S架构,使用 sql server2005做为后台数据库。旧系统的数据建模设计采用了高度范式化的设计思路Infont c其目的是极度追求灵活性。业务数据被大量拆分并散布存储在上百张数据表里。数据表内和表之间不存在参照约朿。大量的业务逻辑采用存储过程封装以提高效率。存储过程体系相当庞大,且存在复杂的相互调用。数据库中存在一些脏数据,可能是长期的使用、维护或误操作导致,但没人知道它们有多少,具体存在哪里。应用界面可用性不理想而且系统效率较低,用户常抱怨系统反映迟缓或无反应。数据库存储的业务数据约50G左右。ThoughtWorks团队将为客户提供一套新的CRM系统用以替换旧系统主要功能。新系统精简整理旧系统功能,并整合了客户的最新需求。在设计上做了巨大变更,以改善界面可用性,同时为了保障终端用户对系统服务的需要,新旧系统要求能够同时运行并实现数据同步,当终端用户全部过度到新系统后,终止旧系统。在这个过程中,DBA团队需给予足够的数据保障。以下为项目版本的发布图。旧系统发布版本14发布版本2更多发布版本发布版本n一性廷鍪数据同龙数据迁移开发方法1.DBA需要制定目标并且管理自己的任务尽管在每个迭代中,团队都会讨论决定如何组织‘需求故事′( story),但是DBA仍然需要有自己的“故事墙′( story wal〕,并且花时间组织自己的 story。在实际开发中,数据迁移仅仅是DBA工作的部分,DBA还要完成相应的stoy开发和数据分析,有时还要给开发人员提供数据支持。混乱的管理会带来开发上的冲突。因此,有效管理任务是做Infont c好数据迁移的首要环节。故事墙是管理这些任务的最好方法。尽管这个故事墙对客户提供的商业价值是间接的,但从整个团队角度来看,任何需要数据的人或程序都是DBA的用户,故事墙有利于管理每个 story包含的数据需求,避免数据迁移任务与其它数据库开发任务之间的冲突,从而减少重复性工作或修复性工作。DBA有必要将这种方法引入到数据库开发中。DBA要从商业价值角度决策数据迁移的需求。系统开发中,客户和开发员常常会向DBA提出自己的数据迁移要求,但往往这些要求并不具有全局性和决定性,毕竟他们仅仅是针对一个 story的需要而提出。如果DBA盲目执行,将起到事倍功半的效果。DBA应当积极参加PM(迭代计划会议。它是在每个迭代开始时的会议,全体成员共同讨论 story计划完成数量〉无论是直接与用户交互,还是参与团队合作,DBA有必要将每个 story内容了解的清清楚楚。通常,DBA可以不必像开发人员一样去了解stor的开发细节,但通过与业务分析师和开发员的沟通,潜在的数据需求自然浮出水面。针对这些数据需求,通过再次组织并加以优先级我们很容易回答这些问题接下来应该完成的任务是什么?它的实际商业价值是什么?谁将需要它?什么时候需要?实践证明,多花些时间和团队或客户沟通是事半功倍的好方法而且DBA通过了解业务数据可以给开发员更好的指导,减少开发员对数据的误解,有利于提高整体团队的开发效率。通过对每个 story的了解,我们总结并制定了针对当前发布版本需要的7个数据迁移story,并且确认了它们的确不存在任务上的重复,也邀请项目经理和客户一起确认了这份计划。如此我们的目标已经制定。2.思考实施策略我们已经管理好所有数据迁移的任务,接下来考虑如何实现。通过以往的经验,我们发现如果没有仔细思考全局和细节问题而直接编写代码,带来的后果是无法控制的。我们应该首先充分了解这个过程可能存在的风险,然后决定采用什么样的策略,是否可以借助工具提高效率。这里的潜在风险主要包括21数据质量旧系统的数据库建模是一个高度范式化的结构,每个表之间存在相当大的依赖关系。旦一个表存在脏数据,我们如何保证得到正确的查询结果?22对原有系统的了解