从一个游戏开始说起
有个非常有意思的游戏能够帮助大家理解敏捷和传统开发的差异。游戏有两个角色，一个是“老板”，另一个是“员工”，在2分钟内，“员工”需要在“老板”的完全指挥下，即“向前一步，向后一步，停，向左一步，向右一步”，完成60步移动的任务。“员工”需要执行“老板”的每一个指令，不允许做出相违背的动作。“老板”则不参与行动，只发出指令指挥“员工”的活动。我们体验这个游戏时，当场60% 的参与者成功完成了任务，大致估计出我们的工作效率是50%*60%=30%。游戏后，参与者被问及对这种行为方式的感受时，无论是“员工”还是“老板”都表示非常不满。
接着，大家又做了另一组游戏。2分钟内参与者被要求独立的、自主的完成60步移动任务，在这次游戏里，所有参与者任务相同，大家可以自行决定、并依据自己的判断随时调整其步伐方向，快慢。最后，我们发现所有参与者不但毫无折扣的按时完成了任务，因而工作效率也达到100%*100%=100%，而且所有人对于这种新的工作方式更是产生了极大的兴趣。
以上两个游戏方式的对比就折射出传统开发（前者）与敏捷开发、测试活动方式的对比，其中优劣不言而喻。
而敏捷开发、敏捷测试又是怎样一个概念呢？他们是否能够帮助我们的团队突破束缚，在日益激烈的竞争环境里表现得更为出色呢?请参考我的这个系列文章——“敏捷测试的最佳实践”。
敏捷的价值
首先我们解释一下什么是敏捷，在字典中我们得到解释，敏捷，即反应迅速、可以快速变化。如今敏捷开发已成为众所周知的时髦IT词汇，在这个领域里敏捷又被诠释为迭代的，快速应对需求变化，轻量级，并且简洁。
图1.面对客户业务复杂度问题提出敏捷解决方案
今天越来越多的企业在重视敏捷开发，敏捷的软件开发策略之也被广泛推广开来。这篇文章主旨为帮助那些愿意采用敏捷，和正在采用敏捷开发、测试的团队正确了解敏捷的实质。
笔者做敏捷项目已经近两年时间，对于敏捷的理解，认为最为关键的是需要注意两个方面，它们是“高度迭代”和“持续不断的客户反馈”。
高度迭代：迭代就是指产品的开发过程中，一个完整的开发活动周而复始的进行，产品的功能、性能、可用性在周期活动的叠加中不断得到更新和加强。甚至指在一个迭代周期内产品活动也具显著的周期性。同时，团队间、团队内部成员的高度协作及时帮助解决了各成员的依赖性问题，因此，也促进了各个成员工作的顺利开展，保障了产品活动稳定的持续性、周期性。以测试为例，传统开发模式下，测试人员可以因进入测试阶段的条件不完全满足而继续的等待。而在高度迭代的敏捷项目里，不同的是，我们希望测试人员能够尽可能的做能够做的工作，尽可能的早工作。“等待”在敏捷开发、敏捷测试范畴里已是一种错误概念了。
持续不断的客户反馈：指在产品开发任何时期，代表项目业务（Business）的利益干系人（Stakeholder）都要参与到产品的需求分析，设计，以及其他活动的决策制定中来。致力于在短时间内帮助团队实现将客户的需求转化为高质量的可消费产品，并转化成利润。
敏捷开发的价值
敏捷开发自2001年《敏捷宣言》（“AGILE MANIFESTO”）1的创生，经过多年的打磨和退火已经成为今天非常流行和有过许多成功案例的开发模式。正如前人所说，传统的东西就是用来打破的，传统的瀑布式开发模式必然逐渐退出历史舞台，敏捷开发、敏捷测试是在新环境里产生出来的打破传统的新开发模式。而敏捷也将会在将来，甚至现在转化成更适合现代化软件开发、测试团队的方法和实践。在本文的第一部分，我们以两个游戏类比了敏捷和传统开发的差异，这里为了进一步帮助大家对敏捷的价值有更清晰的理解，我们借鉴前人的研究结果：
图2.敏捷与传统开发的比较
首先敏捷开发过程比传统开发要为项目和产品带来更低的风险（RISK）。为什么呢？传统开发缺乏持续的客户反馈,产品一旦从需求阶段退出，整个开发团队近似封闭工作，团队虽努力去实现曾经认定的目标，但因月有阴晴圆缺，市场需求也瞬息万变（例如提出需求的客户已经退休）。这使得产品在数月后，数年后发布时已经失去了占领甚至进入市场的最佳契机。
而如果你还在考虑使用传统开发模式用现在乃至将来一、两年的时间来开发一个结构复杂，精益求精而又功能庞大的产品，那么你得好好做好失败的准备了。而正是因为出于对这种风险的考虑，越来越多的人认识到敏捷开发要比传统开发能够为企业带来更大的利润空间和更低的投资风险。
其次，利益干系人（Stakeholder）的频繁参，与使得团队在产品开发的各个环节遇到的种种问题得到了及时的解决。因此，我们认为敏捷开发拥着比传统开发更大的透明度（VISIBILITY）。作为老板，项目的负责人一定对这样的开发模式带来的可控性充满了向往。
团队或者产品的适应能力（ADAPTABILITY）也决定着其生命力，因为敏捷开发模式鼓励团队采纳新技术，欢迎变化，并能够快速应对之，使得产品和团队自身都有很强的适应力和生命力。而在传统模式里，当需求变更时，复杂的变更管理流程要求通过正式讨论、审批，也备以足够的文档和说明来支持每次“决策”。这不但带来了人力，物力的浪费，更重要的是它严重延长了企业投资到利益回报的周期。而只有拥有反应迅速的敏捷开发才能够帮助企业赢取市场，降低风险。
以上我们谈及了敏捷开发拥有的比传统开发能为企业带来更大的商业价值和提供企业更大的发展空间。而对于个人而言，笔者认为敏捷开发也提供给了个人更多的发展机会和提出了更高的要求。以下是笔者从个人角度做出的分析。
敏捷方法的共性
虽然各种敏捷方法的名称、所需环境、适合的团队有很大差异，但是他们拥有相似、相同的以下几大特点：
拥抱变化（Embrace the change）
无论是多么明智，多么正确的决定，也有可能在日后发生改变。因此，团队要能够充分理解我们的利益干系人（Stakeholder）和客户代表为什么经常提出新的需求和设计要求，一句话，就是心中有数“唯一不变的是变化”。团队更要信任 利益干系人（Stakeholder）做出的每次决定和需求的调整都是将产品开发推向更正确的发展方向，新变化将进一步降低风险，实现团队最大化利益，理解这是适应市场变化的必然行为。
而在接受变化的同时，我们应该积极的向利益干系人（Stakeholder）和客户代表反映实现活动中暴露出来的可能的设计缺陷和错误。在实际工作中，团队成员应该用优先级制度来划分事情和目标先后顺序，在迭代周期内对于还没有最终决定的设计方案可以予以后来实现、测试，不用急于投入资源展开全面的开发、测试活动。这样一来，开发测试团队也会人员也将更加适应，真正拥抱变化。
客户的参与（With Customer Representative on site）
首先谁是客户（Customer），客户代表（Customer Representative） 呢？利益干系人（Stakeholder），或者我们可以理解为我们的客户（Customer），产品的最终使用者（End user），内部使用者（Insider），商业伙伴（Business Partner）。利益干系人（Stakeholder）作为团队中最了解业务（Business）的人物将帮助开发团队的快速达到目标和做出适时决策。开发团队拥有很好的技术但在业务（Business）方面他们需要利益干系人（Stakeholder）的帮助。而通常在敏捷的开发项目中，团队中的任何一个人若需要帮助时，只要简单的邀请大家参加一个15分钟会议，或一封邮件、一个电话便可以解决。
但是，如果利益干系人（Stakeholder）各执一词怎么办呢？为解决这个问题，将Product Owner引入到讨论中来，作为 Product Owner他可以作为是利益干系人（Stakeholder）的代表，能够在分歧中做最后抉择。因此，通过这样的客户代表的参与，团队更好的了解了所做事情的价值和意义，其工作效率也因而得到很大提高。
利益干系人（Stakeholder）能够帮助团队中的每一个人更好，更快的完成了工作，他们的直接参与成为了敏捷开发、敏捷测试的重要前提。
较少的文档（With less documents）
敏捷开发更重视生产出可用的产品而不是详细文档。而时常有发觉文档又是无论敏捷还是传统开发、测试不可或缺的一部分。笔者认为，传统开发的文档在敏捷开发里仍有大用，只是原来十来页的内容精炼到现在的一页半页。
敏捷主义者相信文档不是最佳的沟通方式，他们鼓励通畅的交流和沟通，要求避免和减少陈词滥调和空头支票。尤其是复杂的文档说明只是增加了沟通成本，因而敏捷开发、测试的文档不需要长篇累读，需要的是简洁，清晰。任何一段清楚的文字，甚至一张图片，照片，一封记录着会议记录的邮件都是我们认可的敏捷文档。因为是无论是通过文字板书的文件还是其他的沟通方式和载体都是为了帮助团队进行更高效的交流和沟通。只有团队保持着沟通上、理解上的一致后才能够充分发挥出团队最佳战斗力。但凡这是帮助团队有效沟通的方式，敏捷开发是不会放弃的。
最大化的生产力（Maximize Productivity）
敏捷开发模式要最大化的提高团队的工作效率。无论是依靠剪除冗余的文档工作，还是提供民主的、通畅的沟通平台都是为了帮助团队能够集中有限的精力处理有意义的问题。据调查，通常人会在两个、多个任务并行的情况下产生出出最高工作效率。而敏捷也恰恰使用了各种方法得到团队的最大生产力。
敏捷开发的Scrum模式，要求在计划阶段，团队成员主动定制迭代周期的所有工作任务，因此，本身从团队开始迭代活动的那时起，已经在在多重工作的压力下紧张工作了。而在日常的迭代生产活动里，各个成员需要当众简单汇报当天的工作进度和承诺下一个24小时的工作计划。因此，通过增加敏捷人员的工作的透明度，无形之中，团队成员的生产力进一步得到提高。
测试驱动开发（Test Driven Development）
测试驱动开发，是让开发人员在编写功能代码之前，根据对需求的理解先设计和编写单元测试代码。先思考如何对将要实现的功能进行验证，再考虑功能的实现。然后迭代的增加新功能的单元测试和功能代码编写，直到完成全部功能的开发。
自动化冗余工作（Automate the redundant work）
将团队成员从冗余的劳动中解放出来，无论是自动化的测试还是自动化工具的开发只要能够节约成本都是敏捷开发、敏捷测试的目标。
民主的团队（Democracy in team）
敏捷团队是一支民主的团队，团队关系是平行的，每个团队成员能够平等的参与讨论，决策。传统开发的垂直的官僚机构在敏捷开发中已是过时的。
尊重团队（Respect to team）
敏捷团队的决定权交有团队自己，决定是团队统一制定。无论是产品设计方案还是产品的功能实现都是的最佳结果。团队脱离了任何一个成员的工作都是不完整的，所以我们应当足够尊重其他成员的劳动果实和表达对其他成员的充分信任。尊重团队，尊重团队中的每一个成员都是敏捷开发的原则之一。
敏捷测试的实质
测试不仅仅是测试软件本身，还包括软件测试的过程和模式。产品发布后才发现很多问题，很可能是软件开发过程出了问题。因此测试除了需要确保软件的质量，即软件做了正确的事情，以及软件做了应该做的事情以外，敏捷的测试团队还要保证整个软件开发过程是正确的。
敏捷开发的最大特点是高度迭代，有周期性，并且能够及时、持续的响应客户的频繁反馈。敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。敏捷测试人员因而需要在活动中关注产品需求，产品设计，解读源代码；在独立完成各项测试计划、测试执行工作的同时，敏捷测试人员需要参与几乎所有的团队讨论，团队决策。作为一名优秀的敏捷测试人员，他（她）需要在有限的时间内完成更多的测试的准备和执行，并富有极强的责任心和领导力。更重要的是，优秀的测试人员需要能够扩展开来做更多的与测试或许无关，但与团队共同目标直接相关的工作。他（她）将帮助团队其他成员解决困难、帮助实现其预期目标，发扬高度协作精神以帮助团队的最终获取成功。需要指出的是，团队的高度协作既需要团队成员的勇敢，更需要团队成员的主动配合和帮助。对于测试人员如此，对于开发、设计人员，其他成员也是如此。
敏捷测试的方法与实践
是的，敏捷测试也需要高度迭代工作、频繁得到STAKEHOLDER、客户的反馈，需要动态调整测试计划、测试的执行。并且，敏捷测试人员参与到了更多的敏捷生产活动中，积极的影响了团队做出的决定和计划。
是的，“人”才是敏捷的实体，敏捷测试也是以人为本的。不难理解，“敏捷”的一切都围绕着人展开，如敏捷鼓励直接，平行的沟通；敏捷需要持续的客户反馈以及敏捷活动的设计，方案和决策需要团队协同制定等等，敏捷测试需要一支非同寻常的团队，不同于以往传统开发模式下的团队结构。关于敏捷团队、敏捷测试团队的组成和介绍，将是我们讲述敏捷测试实践的第一步。
“人”是重心，方法、策略是辅。为了适应不同的团队结构，不同的项目环境，敏捷项目和敏捷活动的实践也应该因“人”而异，但是，并不是说可以天马行空，我行我素。一旦脱离了正确的敏捷方法、和敏捷原则的指导，我们的敏捷活动就好比摸黑前行了。
这正是我们需要学习前辈和敏捷主义大师们的经验意义所在了，笔者在过去的实践中受益颇多的也正是前人的实践经验和方法。因此，学习前人的经验和方法，并运用这些最佳实践来帮助敏捷开发团队，甚至是传统团队来解决时下重要的问题是十分有意义的事情。笔者不敢妄自尊大将自己的一般实践纳入经典方法范畴，但经历了两年的研究和改进，笔者提出的敏捷测试的原则也得到了业内同僚和“大师”的普遍认可。经过多次和其他项目团队的经验交流，我们也不断的改进着我们的原则、方法。因此，笔者要非常感谢参与讨论的同僚们，没有你们的热情参与，也不会有今天的笔者信心百倍的执笔了。正如笔者在借鉴了前人的成功案例中的经验和方法之后定制了符合项目需求的测试原则一样，相信，读者们在阅读了笔者的敏捷测试原则和方法后，同样也会有所收获。而对笔者经历的敏捷实践活动中的方法和测试模型的讲解将成为我们讲述敏捷实践的第二步，也是本文的重点。
综上所述，笔者将运用本文的主要篇幅为大家讲解这个敏捷实践。它们是：
敏捷团队组织构成，敏捷测试团队的任务和使命；
敏捷开发团队以测试为驱动的开发方式——测试驱动开发，这是种独特的测试？还是开发？
递增型的迭代测试，它首先是对敏捷测试过程活动和生命周期模型的介绍，通过学习经典的敏捷增量测试模型，我们将敏捷测试的各类活动有机的组合到了一起。在此之上，对定制后的独特敏捷增量测试模型的分析和理解，帮助我们理解测试活动的规划和管理；
以及需要特别关注的递增型迭代测试的关键活动之一——“静态测试”；这也是笔者认为的最高难度、最具影响力的敏捷测试活动。它将测试团队最早的引入产品开发环节，测试人员以第一用户的角度判断设计的有效性，此活动较早的暴露了设计缺陷、避免了团队对目标的不一致理解等，是测试活动中最有创造性价值的部分；
最后，笔者将谈谈测试活动中的测试计划和管理，即关于测试任务估计，测试活动计划，各个重要测试活动时间分配与安排的介绍。
然而，敏捷测试不是一蹴而就的，做到真正的敏捷，无论是从传统测试模式向敏捷测试的过渡，还是组建全新的团队都是需要循序渐进的，同时也需要团队成员的通力合作和不断的实践来完善敏捷测试的实践原则和方法。
今天，你敏捷了吗？
你敏捷了吗？经过上面的学习，我们应该已经了解了敏捷的实质，并且笔者认为如果您的团队已经表现出上述的特点，那么您的团队已经敏捷了。但是，往往很难做到如此理想的敏捷。而同时，我们需指出敏捷与否也并非我们的最终目标，我们的目标是能够通过学习敏捷的方法和最佳实践来开发可以适用于自身特点的方法和过程，帮助项目灵敏的适应市场变化，让我们变得敏捷起来。
因此，我们依然希望进一步帮助大家了解如何变得敏捷，而首先，还是让我们学习大师留给我们的一套基本准则帮助我们判断项目开发敏捷与否吧。通过按照此标准的衡量，我们将容易得出项目是否敏捷的结论，也能够因地制宜的找到问题所在，最终实现敏捷。
Scott W. Ambler在其文章How Agile Are You？中指出了以下七条原则帮助大家来判断什么项目是敏捷的项目。
项目中有利益干系人（Stakeholder）的参与
团队拥有并且可随时执行的回归测试
关注产品自身而不是冗余的文档
项目开发拥有严格的源码管理、版本控制
开发能够积极面对和响应项目需求变化
团队作为整体直接担负项目责任
能够自动化重复性的活动
公益传播测试知识、技能与正能量！感谢作者！分享测试生活，思考测试人生！
文章图片来自网络，如有侵权请见谅，请联系我们妥善处理。
twftesting@163.com
欢迎加入我们：
官网：www.huicewang.com
中国软件测试群： 172923163
测试编程技术交流群: 231767115
性能测试技术交流群: 385202672
咨询QQ：2657535456
公众号：慧测
