什么是敏捷 软件开发
这是一本书。
在这本书中，享誉全球的软件开发专家和软件工程大师Robert C.Martin将向您展示如何解决软件开发人员、项目经理及软件项目领导们所面临的最棘手的问题。这本综合性、实用性的敏捷开发和极限编程方面的指南，是由敏捷开发的创始人之一所撰写的。
·讲述在预算和实践要求下，软件开发人员和项目经理如何使用敏捷开发完成项目;
·使用真实案例讲解如何用极限编程来设计、测试、重构和绝对编程;
·包含了极具价值的可多次使用的C++和JAVA源代码;
·重点讲述了如何使用UML和设计模式解决面向客户系统的问题。
什么是敏捷软件开发
敏捷开发即 测试驱动 开发 请理解 测试驱动 开发;
1.先有测试再有实际的代码;写代码的目的只是为了让测试通过;
2.测试通过之后要对代码进行重构,并保证重构的代码不增加也不减少功能,即仅仅是重构而不增加功能;
3.完成2之后即可再次进行1操作;
1 2 两步缺一不可,互补;
做到了以上极为:敏捷开发;
敏捷开发管理为另外一个概念!
什么是敏捷开发框架？
软件开发，程序员就是不断地跟变量、方法、类、接口这些东西打交道，随着开发经验的积累，聪明的程序就会发现虽然开发出来的每个软件都不一样，但是它们在很多地方又都是一样的。每个软件的底层差不多都需要进行增删改查、文件操作、权限管理等等。最后才是根据需求把这些底层功能组合包装起来做成一个成品软件，这个底层就是传统意义上的软件开发框架，而敏捷开发框架则是在这基础上做了跟多的完善，最大程度上提高开发效率。
敏捷开发模式用的测试是什么模型
【编者按】敏捷的理念已经深入人心，开发过程已经渐入佳境，测试的处境却稍显尴尬。测试从业者应该何去何从，怎样才能拥抱敏捷，体现出自己新的价值呢？InfoQ特地邀请了来自Google的敏捷测试专家段念，为读者答疑解惑，希望所有测试从业者可以从中得到自己的答案。更多关于敏捷测试的内容，请访问InfoQ中文站敏捷测试相关内容。
在与不少测试从业人员讨论到敏捷的时候，被问得最多的大约是两个问题：到底？，敏捷软件开发还需要测试工程师吗？。前一个问题是对于敏捷测试本身定义的疑问，第二个问题则是对敏捷开发将测试工程师排除在外的担心。其实，在探寻这两个问题答案的过程中，我们可以更清晰的了解敏捷软件开发中测试的工作定义，测试价值观，以及敏捷开发中开发与测试工程师的配合。鉴于这两个问题的意义，在本敏捷测试专栏的第一篇文章中，本人尝试从自己的实践出发，尽可能清楚的回答这两个问题。
确实，相对于敏捷开发红遍大江南北的状况而言，对敏捷测试的讨论则低调得多。敏捷联盟定义了敏捷的4个价值声明，以及伴随的12条支持原则，这12条原则中没有一条单独提到测试。这是不是意味着测试在敏捷开发中并不重要呢？实际上，如果仔细研读敏捷的12个原则，以及各种不同的敏捷实践，就会发现，测试在敏捷开发中占有非常重要的地位。无论是原则中的频繁交付，还是对可工作的软件的度量，或是敏捷开发实践中的测试驱动开发，行为驱动开发，都离不开测试的支持。在本人看来，敏捷开发中不把测试单独拿出来描述的原因，恰恰是因为在敏捷开发中，测试不再是一个单独的、和开发独立的过程，而是变成了驱动开发、衡量产出的主要的手段，成为了敏捷开发中所有工程师在工作时必须时刻考虑和实践的一个部分。简而言之，敏捷软件测试更多的是一种理念，而非过程。
既然是这样，为什么我们还要在这个专栏中专门来讨论敏捷软件测试？本人接触过不少软件开发和测试工程师，他们所处的组织有的正在努力向敏捷开发转型，有的已经实践了一段实践的敏捷开发，但由于由来已久的工作习惯，他们中的绝大多数并不能自觉的认识到测试在敏捷开发中的关键作用，而是有意无意的将测试仍然看作是与开发截然分开的下一个阶段，导致在实践敏捷开发的过程中遇到种种问题：要么是忽略了代码质量，导致在频繁的迭代过程中，每一个迭代的问题层出不穷；或是沿用原有的方法安排对系统的系统测试，导致测试团队疲于奔命，却总也赶不上开发所要求的进度。在这种情况下，专门来讨论敏捷软件开发中的测试，也就是敏捷软件测试的话题，对这些工程师应该会有一些帮助。
那么，到底？很难给敏捷测试下一个精确、完善的定义，在本人看来，接纳了敏捷的核心价值观（沟通，简单，反馈，勇气，尊重），在敏捷软件开发过程中开展的测试就可以被称作是敏捷软件测试。因此，敏捷软件测试并不是一个与敏捷软件开发同一层次的划分，而是敏捷软件开发中的一部分，与传统的测试不同，敏捷软件测试并不是一个独立的过程，相反，它与整个敏捷开发中的其他活动交织在一起，处处都能看到它的影子。由于敏捷软件测试并不倾向于一个单独的过程定义，本人拟从敏捷软件测试与传统测试观点的比较、敏捷软件测试中采用的方法、测试工程师在敏捷软件测试过程中的工作等方面来阐述之。在这篇文章中，我们主要从宏观的角度来描述敏捷软件测试，而在本专栏的后续文章中，我们将对敏捷软件测试中采用的方法、工程师在敏捷软件测试中的工作内容等进行进一步的描述。
使用Dashboard、燃尽图等方式展示当前工作与可交付产品之间的距离
建立单元测试覆盖率等度量指标
共享质量目标意味着质量责任由所有工程师共同承担
开发测试应该建立一定的测试覆盖率标准，例如，在单元测试这个级别上，建立60%或80%的覆盖率要求
通过使用TDD、BDD等技术，保证产品和代码的可测试性
建立足够多的自动化测试，保证测试能够满足快速迭代的要求
检查表提到了团队、反馈、质量文化和开发测试四个方面的内容，在本人看来，这四个方面体现的就是敏捷软件测试与传统软件测试的最大的不同。传统软件测试关注的是通过尽可能完备的覆盖去发现尽可能多的问题，把测试和开发当成是两个独立的过程，测试是对开发阶段产生成果的验证
。而敏捷软件测试则建立了一种不同的质量文化：测试的目的是为了保证产品快速发布，也就是对生产率本身的提高。基于验证的出发点必然会要求测试与开发的独立，以及尽可能客观和完备的度量产品质量；而基于生产率的出发点则要求建立敏捷的团队，要求测试与开发尽可能紧密，要求建立具有高度可测试性的软件，以及基于这些的高度自动化测试。
在检查表列出的所有项目中，质量文化是基础，团队是敏捷软件测试得以实施的条件，反馈和开发测试则是敏捷软件测试的具体方法。当然，你可以可以从敏捷的核心价值观来阶段这些项目：团队关注的是沟通与尊重；反馈直接对应于反馈；质量文化基于勇气（承担质量责任的勇气）与尊重；而开发测试则是反馈与简单的具体体现。
另一个在本文最初提出来的问题是：敏捷软件开发还需要测试工程师吗？，对这个问题，业界有不同的观点。有人认为需要，因为总有一些是需要测试工程师的技能完成的工作；当然，也有人认为不需要，因为敏捷开发中的测试注重开发测试与自动化测试，开发工程师就可以自己搞定与测试相关的工作。在实践中，那些大规模实践敏捷开发的公司（例如Google），倾向于在组织中设置数量较少的测试工程师，在项目中分配较少的测试资源，甚至对某些项目，完全不使用测试工程师。
就我的个人实践经验，对大部分的项目，尤其是为明确的客户开发的项目，需要在敏捷开发团队中设置专职的测试工程师，因为：
测试与开发具有不同的思维方式：测试更注重全面的验证和检查一个系统，而开发工程师往往很难在大的范围内建立这样的思维方式。因此，无论是从系统的层面验证产品，或是从应用系统的角度发现值得测试和验证的点（access point），专职的测试工程师都更有效。
专职的测试工程师能够更关注于测试基础，建立测试需要的基础架构：由于测试工程师具有更好的对测试的理解，通常他们能够更多的考虑测试的需求而开发适合项目的测试基础架构（自动化测试框架），而开发工程师可以使用这些框架来建立面向功能或代码的测试。
但是，不得不说的是，敏捷开发对开发和测试工程师都提出了更要的要求，尤其是对测试工程师而言，传统的只能精确模拟用户操作的测试工程师，因为不能为产品带来生产率的提升，在敏捷开发的团队中，很难有所作为。在本专栏的后续文章中，我们会进一步讨论测试工程师在敏捷软件开发中的工作和任务。
关于作者段念：Google中国高级测试经理，毕业于华中科技大学，先后在通讯、嵌入式软件、互联网等多个行业的国内外知名公司中从事软件开发与测试工作。对软件测试中的技术和管理工作有独到见解，对软件测试团队管理、自动化测试、性能测试与开发测试有较多研究。
敏捷开发的开发宣言
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
虽然右项也有价值，但是我们认为左项具有更大的价值。
什么是敏捷软件？
首先什么是敏捷开发呢？
敏捷开发指的是一种面临迅速变化的需求快速开发软件的能力！
什么是敏捷设计
“在按照我的理解方式审查了软件开发的生命周期后，我得出一个结论：实际上满足工程设计标准的唯一软件文档，就是原代码清单。”——Jack Reeves
敏捷开发人员如何知道要做什么
简而言之，敏捷开发人员知道要做什么，是因为：
他们遵循敏捷实践去发现问题。
他们应用设计原则去诊断问题。
他们应用适当的设计模式去解决问题。
软件开发的这三个方面间的相互作用就是设计。
结论
敏捷设计就是一个过程，不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净及富有表现力。
请记住，敏捷开发人员不会对一个庞大的预先设计应用那些原则和模式。相反，这些原则和模式被应用在一次次的迭代中，力图使代码以及代码所表达的设计保持干净。