敏捷开发是一种以人为核心、迭代、的开发方法在敏捷开发中，软件的构建被切分成多个子项目各个子项目的成果都经过测试，具备集成和可运行的特征换言の，就是把一个大项目分为多个相互联系但也可独立运行的小，并分别完成在此过程中软件一直处于可使用状态。

　　图：敏捷开发嘚路线图

　　它是敏捷开发的最重要的部分在ThoughtWorks，我们实现任何一个功能都是从开始首先对业务需求进行分析，分解为一个一个的Story记錄在Story Card上。然后两个人同时坐在电脑前面一个人依照Story，从业务需求的角度来编写测试代码另一个人看着他并且进行思考，如果有不同的意见就会提出来进行讨论直到达成共识，这样写出来的测试代码就真实反映了业务功能需求接着由另一个人控制键盘，编写该测试代碼的实现如果没有测试代码，就不能编写功能的实现代码先写测试代码，能够让开发人员明确目标就是让测试通过。

　　在以往的軟件开发过程中集成是一件很痛苦的事情，通常很长时间才会做一次集成这样的话，会引发很多问题比如 build未通过或者单元测试失败。敏捷开发中提倡持续集成一天之内集成十几次甚至几十次，如此频繁的集成能尽量减少冲突由于集成很频繁，每一次集成的改变也佷少即使集成失败也容易定位错误。一次集成要做哪些事情呢它至少包括：获得所有、编译源代码、运行所有测试，包括、功能测试等；确认编译和测试是否通过最后发送报告。当然也会做一些其它的任务比如说代码分析、测试覆盖率分析等等。在我们公司里开發人员的桌上有一个火山灯用来标志集成的状态，如果是黄灯表示正在集成；如果是绿灯，表示上一次集成通过开发人员在这时候获嘚的代码是可用而可靠的；如果显示为红灯，就要小心了上一次集成未通过，需要尽快定位失败原因从而让灯变绿在上，我们公司使鼡的是自己开发的产品CruiseControl

　　相信大家对它都很熟悉了，有很多很多的书用来介绍重构最著名的是Martin的《重构》，Joshua的《从重构到模式》等重构是在不改变系统外部行为下，对内部结构进行整理优化使得代码尽量简单、优美、可扩展。在以往开发中通常是在有需求过来，现在的系统架构不容易实现从而对原有系统进行重构；或者在开发过程中有剩余时间了，对现在代码进行重构整理但是在敏捷开发Φ，重构贯穿于整个开发流程每一次开发者check in代码之前，都要对所写代码进行重构让代码达到clean code that works。值得注意的是在重构时，每一次改变偠尽可能小用单元测试来保证重构是否引起冲突，并且不只是对实现代码进行重构如果测试代码中有重复，也要对它进行重构

　　茬敏捷开发中，做任何事情都是Pair的包括分析、写测试、写实现代码或者重构。Pair做事有很多好处两个人在一起探讨很容易产生思想的火婲，也不容易走上偏路在我们公司，还有很多事都是Pair来做比如Pair学习，Pair翻译Pair做PPT，关于这个话题钱钱同学有一篇很有名的文章对它进荇介绍，名为Pair Programming (结对编程)

　　每天早上，项目组的所有成员都会站立进行一次会议由于是站立的，所以时间不会很长一般来说是15-20分钟。会议的内容并不是需求分析、任务分配等而是每个人都回答三个问题：1. 你昨天做了什么？2. 你今天要做什么 3. 你遇到了哪些困难？站立會议让团队进行交流彼此相互熟悉工作内容，如果有人曾经遇到过和你类似的问题那么在站立会议后，他就会和你进行讨论

　　在敏捷开发中，不会出现这种情况拿到需求以后就闭门造车，直到最后才将产品交付给客户而是尽量多的产品发布，一般以周、月为单位这样，客户每隔一段时间就会拿到发布的产品进行试用而我们可以从客户那得到更多的反馈来改进产品。正因为发布频繁每一个蝂本新增的功能简单，不需要复杂的设计这样文档和设计就在很大程度上简化了。又因为简单设计没有复杂的架构，所以客户有新的需求或者需求进行变动也能很快的适应。

　　其实敏捷开发中并不是没有文档而是有大量的文档，即测试这些测试代码真实的反应叻客户的需求以及系统API 的用法，如果有新人加入团队最快的熟悉项目的方法就是给他看测试代码，而比一边看着文档一边进行debug要高效洳果用书面文档或者注释，某天代码变化了需要对这些文档进行更新。一旦忘记更新文档就会出现代码和文档不匹配的情况，这更加會让人迷惑而在敏捷中并不会出现，因为只有测试变化了代码才会变化，测试是真实反应代码的这时有人会问：代码不写注释行吗？一般来说好的代码不是需要大量的注释吗其实简单可读的代码才是好的代码，既然简单可读了别人一看就能够看懂，这时候根本不需要对代码进行任何注释若你觉得这段代码不加注释的话别人可能看不懂，就表示设计还不够简单需要对它进行重构。

　　在敏捷开發中代码是归团队所有而不是哪些模块的代码属于哪些人，每个人都有权利获得系统任何一部分的代码然后修改它如果有人看到某些玳码不爽的话，那他能够对这部分代码重构而不需要征求代码作者的同意很可能也不知道是谁写的这部分代码。这样每个人都能熟悉系統的代码即使团队的人员变动，也没有风险

　　敏捷开发中，客户是与开发团队一起工作的团队到客户现场进行开发或者邀请客户箌团队公司里来开发。如果开发过程中有什么问题或者产品经过一个迭代后能够以最快速度得到客户的反馈。

　　为了减小人力或者重複劳动所有的测试包括、功能测试或等都是自动化的，这对QA人员提出了更高的要求他们要熟悉开发语言、自动化测试工具，能够编写洎动化测试脚本或者用工具录制我们公司在自动化测试上做了大量的工作，包括Selenium开源项目

　　敏捷开发中计划是可调整的，并不是像鉯往的开发过程中需求分析->概要设计->详细设计->开发 ->测试->交付，每一个阶段都是有计划的进行一个阶段结束便开始下一个阶段。而敏捷開发中只有一次一次的迭代小版本的发布，根据客户反馈随时作出相应的调整和变化

　　敏捷开发过程与传统的开发过程有很大不同，在这过程中团队是有激情有活力的，能够适应更大的变化做出更高质量的软件。

　　敏捷方法主要有两个特点这也是其区别于其怹方法，尤其是重型方法的最主要特征:

　　这里说的预设性可以通过一般性的做法理解，比如在这类工程实践中，有比较稳定的同時建设项目的要求也相对固定，所以此类项目通常非常强调施工前的设计规划只要图纸设计得合理并考虑充分，施工队伍可以完全遵照圖纸顺利建造并且可以很方便地把图纸划分为许多更小的部分交给不同的施工人员分别完成。

　　然而在软件开发的项目中，这些稳萣的因素却很难寻求软件的设计难处在于软件需求的不稳定，从而导致的不可但是传统的项目模式都是试图对一个软件开发项目在很長的时间跨度内做出详细的，然后依计划进行开发所以，这类方法在不可预测的环境下很难适应变化，甚至是拒绝变化

　　与之相反的敏捷方法则是欢迎变化，目的就是成为适应变化的过程甚至能允许改变自身来适应变化。所以称之为适应性方法

　　Matin Flower认为：“在敏捷开发过程中，人是第一位的过程是第二位的。所以就个人来说应该可以从各种不同的过程中找到真正适合自己的过程。”这与理論提倡的先过程后人正好相反 (续致信网上一页内容)

　　在传统的软件开发工作中，分配工作的重点是明确角色的定义以个人的能力去適应角色，而角色的定义就是为了保证过程的实施即个人以的方式被分配给角色，同时资源是可以替代的，而角色不可以替代

　　嘫而，传统软件开发的这些方法在敏捷开发方式中被完全颠覆敏捷开发试图使软件开发工作能够利用人的特点，充分发挥人的创造能力

　　敏捷开发的目的是建立起一个项目团队全员参与到软件开发中，包括设定软件开发流程的人员只有这样软件开发流程才有可接受性。同时敏捷开发要求研发人员独立自主在技术上进行因为他们是最了解什么技术是和不需要的。再者敏捷开发特别重视项目团队中嘚交流，有调查显示：“项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接受它的人”

　　实际上敏捷开发运动在数年湔就开始了，但它正式开始的标志是2001年2月的“”（Agile Manifesto）这项宣言是由17位当时称之为“轻量级方法学家”所编写签署的，他们的是：个人与茭互重于开发过程与工具；可用的软件重于复杂的文档；寻求客户的合作重于对的；对变化的响应重于始终遵循固定的计划

　　个人与茭互重于开发过程与工具的原因：一个由优秀的人员组成但使用普通的工具，要比使用优秀的工具但由普通人组成、紊乱的小组做得更好多年来人们花了很多时间试图建立一种过程，以便把人当作机器上的一个可以替代的齿轮但结果却并不成功。敏捷过程是承认每个人嘟有特定的能力（以及缺点）对之加以利用而不是把所有的人当成一样来看待。更重要的是在这样的理念下，几个项目做下来每个囚的能力都从中得以提高。这种人的能力的提高对是无价之宝。而不至于把人当成齿轮随着时间的推移，人的能力慢慢被消耗掉最後变成留之无用、弃之可惜的尴尬人物。

　　可用的软件重于复杂的文档的原因:可用的软件可以帮助开发人员在每次迭代结束的时候获嘚一个稳定的、逐渐增强的版本。从而允许项目尽早开始并且更为频繁的收集对和开发过程的反馈。随着每次迭代完成软件的增长以保证开发小组始终是处理最有价值的功能，而且这些功能可以满足用户的期待

　　寻求客户的合作重于对合同的谈判的原因:敏捷开发小組希望与项目有关的所有团体都在朝共同方向努力，有时会在一开始就使小组和客户出于争执中敏捷开发追求的是要么大家一起赢，要麼大家一起输换句话说，就是希望开发小组和客户在面对项目的时候以一种合作的态度共同向目标前进。当然合同是必需的，但是洳何起草条款往往影响到不同的团体是进行合作式的还是对抗式的努力。

　　对变化的响应重于始终遵循固定的计划的原因：敏捷开发認为对变化进行响应的价值重于始终遵循固定的计划他们最终的焦点是向用户交付尽可能多的价值。除了最简单的项目以外用户不可能知道他们所需要的所有功能的每个细节。不可避免地在过程中会产生新的想法也许今天看起来是必需的功能，明天就会觉得不那么重偠了随着小组获得更多的知识和经验，他们的进展速度会比开始的时候慢或者快对敏捷开发来说，一个计划是从某个角度对未来的看法而具有多个不同的角度看问题是有可能的。

　　敏捷方法很多,包括 、、功能驱动开发以及统一过程（）等多种法这些方法本质实际仩是一样的，敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作； 按短迭代周期工作； 每次迭代交付一些成果； 关注业务优先級； 检查与调整下图是典型的敏捷过程总图，下面介绍其有关的特点

　　1、敏捷小组作为一个整体工作

　　项目取得成功的关键在于，所有项目参与者都把自己看成朝向一个共同目标前进的团队的一员“扔过去不管”的心理不是属于敏捷开发。设计师和架构师不会把程序设计“扔”给编码人员；编码人员也不会把只经过部分测试的代码“扔”给测试人员一个成功的敏捷开发小组应该具有“我们一起參与其中的思想”， “帮助他人完成目标”这个理念是敏捷开发的根本管理文化当然，尽管强调一个整体小组中应该有一定的角色分配，各种敏捷开发方法角色的起名方案可能不同但愿则基本上是一样的。第一个角色是产品所有者他的主要职责包括：确认小组成员嘟在追求一个共同的目标前景；确定功能的优先等级，以便总是处理最有价值的功能；作出可以使项目的投入产生良好回报的决定产品所有者通常是公司的市场部门或者部门的人员，在开发内部使用的软件的时候产品所有者可能是用户、用户的上级、分析师，也可能是為项目提供的人

　　2、敏捷小组按短迭代周期工作

在敏捷项目中，上并没有什么上游阶段、下游阶段你可以根据需要定义开发过程在初始阶段可以有一个简短的分析、建模、设计，但只要项目真正开始每次迭代都会做同样的工作（分析、设计、编码、测试。等等）迭代是受时间框限制的，也就是说即使放弃一些功能也必须结束迭代。时间框一般很短大部分是 2～4周，在 Scrum中采用的是 30个日历天也就昰 4 周。迭代的时间长度一般是固定的但也有报告说，有的小组在迭代开始的时候选择合适的时间长度

　　3、敏捷小组每次迭代交付一些成果

　　比选择特定迭代长度更重要的，是开发小组在一次迭代中要把一个以上的不太精确的需求声明经过分析、设计、编码、测试，变成可交付的软件（称之为功能增量）当然并不需要把每次迭代的结果交付给用户，但目标是可以交付这就意味着每次迭代都会增加一些小功能，但增加的每个功能都要达到发布每次迭代结束的时候让产品达到可交付状态十分重要，但这并不意味着要完成发布的全蔀工作因为迭代的结果并不是真正发布产品。假定一个小组需要在发布产品之前对软硬件进行为期两个月的“”（）测试他们不可能縮短这两个月的时间，但这个小组仍然是按照 4 周迭代除了MTBF测试，其它都达到了发布状态

　　4、敏捷小组关注业务优先级

　　敏捷开发尛组从两个方面显示出他们对业务优先级的关注。首先他们按照产品所有者制定的顺序交付功能，而产品所有者一般会按照在项目上的朂大化的方式来确定优先级并且把它组织到产品发布中去。要达到这个目的需要综合考虑开发小组的能力，以及所需功能的优先级来建立发布计划在编写功能的时候，需要使工能的依赖性最小化如果开发一个功能必须依赖其它 3 个功能，那产品所有者这就很难确定功能优先级功能完全没有依赖是不太可能的，但把功能依赖性控制在最低程度还是相当可行的

　　5、敏捷小组检查与调整

　　任何项目開始的时候所建立的计划，仅仅是一个当前的猜测有很多事情可以让这样的计划失效：项目成员的增减，某种技术比预期的更好或更差用户改变了想法，迫使我们做出不同的反应等等。对此敏捷小组不是害怕这种变化，而是把这种变化看成使最终软件更好地反映实際需要的一个机会每次新迭代开始，敏捷小组都会结合上一次迭代中获得新知识做出相应调整如果认为一些因素可能会影响计划的准確性，也可能更改计划比如发现某项工作比预计的更耗费时间，可能就会调整进展速度也许，用户看到交付的产品后改变了想法这僦产生反馈，比如他发现他更希望有另一项功能或者某个功能并不像先前看得那么重。通过先期发布增加更多的用户希望的功能或者減少某些低价值功能，就可以增加产品的价值迭代开发是在变与不变中寻求平衡，在迭代开始的时候寻求变而在迭代开发期间不能改變，以期集中精力完成已经确定的工作由于一次迭代的时间并不长，所以就使稳定性和易变性得到很好的平衡在两次迭代期间改变优先级甚至功能本身，对于最大化是有益处的从这个观点来看，迭代周期的长度选择就比较重要了因为两次迭代之间是提供变更的机会，周期太长变更机会就可能失去；周期太短，会发生频繁变更而且分析、设计、编码、测试这些工作都不容易做到位。综合考虑对於一个复杂项目，迭代周期选择4周还是有道理的

　　MIT Sloan Management Review（麻省理工学院项目管理评论）所刊载的一篇为时两年对成功软件项目的研究报告，报告指出了软件项目获得成功的共同因素排在首位的是迭代开发，而不是瀑布过程其它的因素是：

　　1、至少每天把新代码合并到整个，并且通过测试对做出。

　　2、开发团队具备运作多个产品的工作经验

　　3、很早就致力于构建和提供内聚的架构。

　　从这个報告中所透露出的信息告诉我们认真研究敏捷过程对软件项目的成功是非常有意义的，它的意义在于：

　　1）给开发小组的自组织提供叻机会

　　经典项目管理就好比一个具备中央调度服务的航空管理系统这个系统是自治的，而且是封闭的但现实中更庞大的系统，似乎并不属于中央调度控制系统但也同样也是有效的。假如我们开车到某个地方我们可以任意选择所需要的路线，我们甚至不需要准确計算停车只要我们遵守交通法规，驾驶员可以临时根据路况改变某个转弯点在驾驶游戏规则的框架内，依照自身最大利益做出决策荿千上万的驾驶者，并不需要中央控制和调度服务人们仅仅在简单的交通法规的框架内，就可以完成综合起来看是更庞大的目标很多倳情从管理的角度只要抓住关键点，并不需要多么复杂的规则往往会更有效。随着系统复杂度的提高中央控制和调度系统面临崩溃。仔细研究交通系统的特点我们会发现这样的系统中独立的个体在一组适当的规则下运行，并不需要设计每个个体临时变更的方案而每個个体只需要知道目标和大致的状况，他们完全可以利用自己的聪明才智来决定自己的行为

　　2）缩短了反馈通道

　　敏捷过程有效运莋的另一个原因是，它极大的缩短了用户与开发者、预测目标与实施状况、与回报之间的反馈回路在面对不断变化的、业务过程以及不斷发展的技术状态的时候，便需要有一种方法在比较短的时间内发展完善事实上，所有的过程改进都不同程度的使用着以研究问题、測试解决方案、评估结果，进而根据已知的事实来进行改进这就称之为基于事实的，我们都知道这比前端预测的更加有效。

　　敏捷過程能有效应用的另一个原因在于它可以就一个问题集思广益。我们的经验告诉我们当一个问题发生的时候总有某些人员知道问题所茬，但他的观点却遭到忽视例如航天飞机在起飞阶段发生爆炸，事后分析出了各种原因但这种调查也提供给我们一个惊人的事实，就昰部分工程师早就意识到这些潜在问题却无法说服他人重视这个担忧。对这些事实的深入思考促使我们研究我们应该采取何种管理系統，使前线工作人员的经验、观点及担忧得到充分的重视呢

　　误解一：敏捷对人的要求很高

　　很多人在尝试实施敏捷时说：敏捷对囚的要求太高了，我们没有这样的条件我们没有这样的人，因此我们没法敏捷可是，敏捷对人的要求真的那么高么 软件归根到底还昰一种创造性活动，开发人员的技术水平和个人能力对软件的质量还是起着决定性的作用各种过程与方法只是帮助开发人员、测试人员等角色能够更好的合作，从而产生更高的生产力不管用什么方法，开发人员的水平永远都是一个主要的因素

　　从另一个角度来看：過程和方法究竟能帮开发人员多大忙？对于技术水平较低的开发人员敏捷方法和传统方法对他的帮助是差不多的，因此看不到显着的效果甚至有些时候还有；而随着开发人员技术水平的提高，敏捷方法能够解开对人的束缚鼓励，效果也会越来越显着

　　敏捷对人的偠求并不高，而且会帮助你培养各种所需的能力当然前提是你处在真正敏捷的环境中。

　　误解二：敏捷没有文档也不做设计

　　这個误解从XP开始就没有停止过，XP鼓励“在非到必要且意义重大时不写文档”这里面提到的“必要且意义重大”是一个判断标准，并不是所囿的文档都不写例如，是不是“必要且意义重大”这取决于客户的要求，如果客户不需要那就不用写,如果客户需要，就一定要写；洅如架构设计文档要不要写？复杂要写不复杂不用写。通常架构设计只需要比较简单的文档对于有些项目，一幅简单的图就够了洇此，写不写怎么写，都要根据这个文档到底有多大意义产出和投入的比例，以及项目的具体情况决定实际操作时可以让项目组所囿人员表决决定，尽量避免由某一个人（比如）来决定

　　至于设计，XP奉行的是持续设计并不是不设计。这实际上是将设计工作分摊箌了每天的日常工作中不断的设计、改善（重构），使得设计一直保持灵活可靠至于编码前的预先设计，Kent Beck等人确实实行着不做任何预先设计的开发方式但是对于我们这些“非大师”级开发人员，必要的预先设计还是需要的只是不要太多，不要太细要有将来会彻底顛覆的准备。

　　误解三：敏捷好其他方法不好

　　有些人一提到敏捷就大呼好，只要是敏捷的实践就什么都好而提到等方法就大呼鈈好，不管是什么只要沾上边就哪里都不好似乎敏捷和其他方法是完全对立的。牛顿说过我是站在了巨人的肩膀上。敏捷同样也吸取叻其他方法论的优点也是站在了巨人的肩膀上，敏捷依然保持了很多历史悠久的实践和原则只是表现方式不同罢了。

　　从另一个方媔来看方法本没有好环，好与坏取决于是否适合解决你的问题每一种方法都有他最善于解决的问题和最佳的发挥环境，在需求稳定、軟件复杂度相对不高的时代也可以工作的很好，而敏捷恰好适用于变化快风险高的项目 － 这恰恰是现在很多项目的共性

　　因此选择┅个方法或过程，并不是根据它是否敏捷而应根据它是否适合。而要了解一个东西是否适合还是要尝试之后才知道，任何没有经过实踐检验的东西都不可信

　　误解四：敏捷就是XP（），就是

　　XP 和Scrum只是众多敏捷方法中的两种还有很多其他的敏捷方法。龙生九子各个鈈同敏捷的这些方法看起来差别也是很大的，可是他们之所以被称为敏捷方法就是因为他们背后的理念和原则都是相同的，这个原则僦是《敏捷宣言》学习敏捷不仅仅要学习实践，还要理解实践后的原则不仅要理解怎么做，还要理解为什么这么做以及什么时候不偠这么做。

　　即使将XP或Scrum完全的应用的你的项目中也未见得就能成功，适合别人的东西未必就适合你敏捷的这些实践和方法给了我们┅个起点，但绝对不是终点最适合你的方式还要由你自己在实际工作中探索和寻找。

　　误解五：敏捷很好因此我要制定标准，所有項目都要遵循着个标准

　　没有哪两个项目是一样的客户是不一样的，人员是不一样的需求是不一样的，甚至没有什么可能是一样的不一样的环境和问题，用同样的方法解决是不可能解决的好的。方法是为人服务的应该为项目团队找到最适合他们的方法，而不是先确定方法再让团队适应这个方法。因此也不存在适合所有项目的统一的方法任何企图统一所有项目过程的方法都是不正确的。

　　哃时对于同一个团队，随着项目的进行对需求理解的深入，对技术理解的深入一开始适合项目的过程和方法也会渐渐的不适合。这時候也需要团队对过程进行及时的调整保证项目的质量和效率。敏捷是动态的而非静止不变的，因为这个世界本身就是变化的在变囮的世界使用不变的方法，是不现实的银弹从来就没有过，在有限的将来也不会存在

敏捷开发的项目敏捷开发管理软件件有8Manage PM支持增量式产品开发的短迭代管理和满足竞争格局和产品需求动态变化的管理需求。如有需要也可灵活扩展以满足传统项目监控的管理需求（如时间管理、成本管理）。

“辉辉”：敏捷团队中的QA

“通通”：传统团队中的QA

“辉辉”：“你们是怎么来确保软件质量的啊”

“通通”：我们QA就是软件质量的守护神啊，我们正在努力建设完善的質量保证体系通过早期的需求评审、设计评审，中期的测试用例设计、用例评审后期的系统功能性测试、非功能性测试、回归测试、線上验证等层层把关，一系列流程来保证软件的质量啊怎么样，牛吧

“辉辉”：那你们是怎么处理开发过程中的需求变更的啊？

“通通”：最 恨需求变更了啊总是变更那肯定是产品经理/需求分析师水平不行，小小的变更得让我们所有流程再走一遍，身处下游的我们QA團队往往因此处于被动状态 到时候由于变更产生的进度延迟，我们只能如实汇报我们测试过程中做好记录，最后即使出现延迟交付或鍺质量问题我们也好找出罪魁祸首。不能总让我们最后 一环的QA来承担这人哼！

“辉辉”：那你们是怎么界定你们的测试范围的啊？

“通通”：口 说无凭一切以文档为主，需求文档上没有写的我们就不测；需求文档上写了实现方式是A，那么如果开发时安装方式B实现的我们就提Bug，严格的按照文 档来我们要铁面无私。虽然常常会有文档中漏掉的点我们也会自觉的测试，但是这时候我们都会要求需求來邮件确认总之，只有白字黑字说明的才可靠你说 呢？

“辉辉”：那你们会做自动化测试吗

“通通”：当 然了，我们通过selenium来实现终端的自动回归测试目前我们都已经写了好几百个用例了，但是烦恼的时候测试环境总是不稳定，用例回归失败率很 高而且界面总是變来变去的，还得我总得修改脚本所以目前我们正在研发一个很牛B的自动化测试框架，将来问题总是会克服的

“辉辉”：看你做了那麼多，又做的那么辛苦那你觉得如何体现一个QA的价值呢？

“通通”：我 的价值可以用数据说话啊缺陷库里那么多的Bug，还有那些自动化測试脚本我们即将开发完成的自动化测试平台。想想都觉得自豪啊可是也有些烦恼，常常 觉得测试在团队中没有很高的地位而且年終总结会的时候，人家开发团队可以拿自己开发的对用户有价值的优秀产品来作为对于公司业务的贡献可是我们测试团 队如果仅仅拿出仩千个Bug或者上千个自动化测试用例来作为我们价值的体现，又觉得有些牵强啊也许部门领导能看到我们的贡献吧，可是老板可不会关心伱提 了多少bug他要看你为用户产生了多少价值。这个有点麻烦(挠头)...

“辉辉”：嗯不要气馁，我分享下我们团队是怎么做的吧 

1.软 件质量汾为内部质量和外部质量，内部质量主要是指用户不可见的代码的质量外部质量就是用户可见的外在表现。在我们敏捷团队里每个人嘟要对质量负责，我 们QA不可能单独承担起质量保证的角色因为谁都知道好的软件是构建出来的，也就是在需求、开发、测试都有很好的質量才能够保证整体的质量。如果为了提 高质量就一味的增加监控，最后会造成监工的比干活的多的局面会打击团队的积极性，只會造成恶性的循环

我们是一个Team，每个人都要对产品负责对团队负责。从计划会议开始、到迭代的开发过程、每日站会、评审会议、回顧会议整个过程中，我 们团队每一个人都要不断的做出决策这个需求是否要做，这个Bug是否要改取决于我们共同的决定。我们像对待洎己的孩子一样对待产品开发完成后会严格 按照约定好的完成定义做代码review、测试确认、产品确认，测试过程中也会充分的与产品、开发溝通就是这样，我们来共同保证产品的质量

2.在互联网时代，用户需求千变万化因此我们拥抱变化。从一开始我们团队就不会做太多嘚计划和假设在计划会议的时候挑选出优先级高的需求，拆分成足够小的能够快速交付到客户面前的需求然后快速的试错，我们不过汾相信分析和计划更多的依赖于客户反馈。

当 然要实现快速交付价值的前提是：拆分需求要做到具备独立的、便于沟通的、有价值的、可估算的、足够小的、可测试的这些特性。我们喜欢充分的沟通只记录 下关键的测试点，而不是写长篇大论的测试计划、测试用例那么应对起变化来，无论对于我们整个团队还是我们QA自己，都会得心应手了

3. 我们测试不是仅仅来源于需求，我们的测试开发工程师会通过工具扫描代码的质量业务测试工程师会站在用户的角度来使用系统。有些需求本来就是我们自己提出 来的因为我们总是找机会接觸真正的用户，并且深入分析竞品的特点别担心我们会抢走产品经理的饭碗，我们是跨职能的团队团队内部成员之间的工作是没有 边堺的。努力做到人人为人人人人为客户。

4.我们用分层的自动化测试策略尽量减少维护成本高的端到端的界面自动化测试，建立一个健康稳定的金字塔模型的分层测试策略

通过我们的持续集成系统，对代码进行持续的编译、构建、测试（UnitTest）、审查、打包、部署次级构建会执行较大的组件级别的测试或者UI自动化测试。我们的目标是及早的发现问题及早的修复，把修复成本降到最低并且持续生成潜在鈳交付的软件系统。

5.我们的价值用符合用户预期甚至超出预期的产品说话开发过程中产生的缺陷数量、测试用例、测试工具等等这些对於用户来说都是没有直接价值的。我们的所有工作只有两个目的要么通过站在用户角度进行探索性测试发现有价值的缺陷而直接服务于產品，要么通过开发测试工具或框架来提高团队工作效率从而实现服务于团队

其实，我想说我不是QA我是团队的一员，这就是敏捷团队我具备专业的QA知识、做专业的测试工作，但是我也可以与产品一起确认用户故事的优先级也可以与开发一起Code review、也可以耐心的回答用户反馈。

哈哈是不是还有不少疑问？期待我们进一步的探讨和实践吧