Agile的相关概念

敏捷测试(Agile testing)
敏捷开发的最大特点是高度迭代，有周期，并且能够及时、持续的响应客户

的频繁反馈。敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的

有效需求能得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。

首先敏捷测试(Agile testing)是测试的一种，原有测试定义中通过执行被测系
统发现问题，通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。
敏捷测试是遵循敏捷宣言的一种测试实践：
1、强调从客户的角度，即从使用系统的用户角度，来测试系统。
2、重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。
3、建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。
敏捷测试与普通测试的区别：
1.项目相当于开发与测试并行，项目整体时间较快。
2.模块提交较快，测试时较有压迫感。
3.工作任务划分清晰，工作效率较高。
4.项目规划要合理，不然测试时会出现复测的现象，加大工作量。
5.发现问题需跟紧，项目中人员都比较忙，问题很容易被遗忘。
6.耗时、或较难解决对项目影响不大的问题一般会遗留到下个阶段解决。
7.发现BUG能够很快的解决，对相关的模块的测试影响比较小。
8.版本更换比较勤，影响到测试的速度。
9.要多与开发沟通。
10.要注意版本的更新情况。
11.测试人员几乎要参加整个项目组的所有会议。
Scrum——橄榄球式开发模式：
Scrum 是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程，是敏捷开发的一种实现机制。Scrum以经验性过程控制理论（经验主义）为理论基础，主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个冲刺（Sprint）。
    在Scrum中，使用产品Backlog来管理产品需求和开发任务。产品backlog是一个按照商业价值（或实现优先级）排序的事项列表，列表条目的体现形式通常为用户故事。在规划Sprint时，Scrum团队从产品Backlog中挑选最高优先级的需求，在Sprint计划会议上经过讨论、分析和估算得到相应的任务，并分配给具体的成员去实现。
    当前Sprint需要完成的任务会展现在特别设计的面板上，清晰地展示每个任务的负责人、当前状态、实现过程中的问题和变更等等信息。项目团队和各利益攸关方能清晰地把握每个任务的开发进度和遇到的问题，并以此分析、控制项目的进度、成本和风险。
    Scrum以站立会作为项目规划、过程控制和资源分配的内部交流协商机制。
    在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。
XP极限编程：
那么什么是XP呢？XP是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比，其最大的不同在于：
在更短的周期内，更早地提供具体、持续的反馈信息。
在迭代的进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断的发展它。
依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。
依赖于口头交流、测试和源程序进行沟通。
倡导持续的演化式设计。
依赖于开发团队内部的紧密协作。
尽可能达到程序员短期利益和项目长期利益的平衡。
Kent Beck曾经说过“开车”就是一个XP的范例，即使看上去进行得很顺利，也不要把视线从公路上移开，因为路况的变化，将使得你必须随时做出一些这样那样的调整。而在软件项目中，客户就是司机，他们也没有办法确切地知道软件应该做什么，因此程序员就需要向客户提供方向盘，并且告知我们现在的位置。
敏捷方法之极限编程(XP)和 Scrum区别：
区别之一： 迭代长度的不同
XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周。
区别之二: 在迭代中, 是否允许修改需求、
XP在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现， 则可以考虑用另外的需求将其替换， 替换的原则是需求实现的时间量是相等的。而Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队受到干扰。
区别之三: 在迭代中，User Story是否严格按照优先级别来实现
XP是务必要遵守优先级别的。但Scrum在这点做得很灵活，可以不按照优先级别来做，Scrum这样处理的理由是：如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10。
区别之四:软件的实施过程中，是否采用严格的工程方法，保证进度或者质量
Scrum没有对软件的整个实施过程开出工程实践的处方，要求开发者自觉保证。但XP对整个流程方法定义非常严格，规定需要采用TDD、自动测试、结对编程、简单设计、重构等约束团队的行为。

敏捷框架Scrum的核心要点（“3355”）：
Scrum是敏捷实践中最知名的一套框架。对于初学 Scrum 的同学，领会精髓需要实践和时间，但借助对其中最成型的部分的了解，能最快速的一窥其概貌。虽不精确，但有助于建立宏观的体感。Scrum 的核心可以简单归纳为“3355”。
3个核心角色：
Scrum的三个核心角色分别是：Scrum Master、Product Owner（产品负责人）和 Scrum Team（团队）。
3个工件：
Scrum的工件主要包括：Product Backlog（产品待办事项）、Sprint Backlog （Sprint 待办事项）和 Increment（可交付产品增量）。
5个事件：
Scrum的五大事件，或 event，包括：冲刺、Sprint规划、每日站会、Sprint评审会和回顾会。
承诺 Commitment - 愿意对目标做出承诺
5大价值观：
专注 Focus – 全身心都用到你承诺的工作上去
开放 Openness – 团队内所有信息对所有人开放
尊重 Respect – 每个人都有他独特的价值和经验
勇气 Courage – 勇于承诺，履行承诺，敢于说不
敏捷十二原则：
1、我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
3、要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
4、项目过程中，业务人员与开发人员必须在一起工作。
5、要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
6、无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7、可用的软件是衡量进度的主要指标。
8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
9、对技术的精益求精以及对设计的不断完善将提升敏捷性。
10、要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11、最佳的架构、需求和设计出自于自组织的团队。
12、团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
TDD（Test-Driven Development）：
TDD是测试驱动开发（Test-Driven Development）的英文简称，是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践，但不只适用于XP（Extreme Programming），同样可以适用于其他开发方法和过程。
优缺点：
优点：在任意一个开发节点都可以拿出一个可以使用，含少量bug并具一定功能和能够发布的产品。
缺点：增加代码量。测试代码是系统代码的两倍或更多，但是同时节省了调试程序及挑错时间。
BDD(Behavior Driven Development)：
行为驱动开发是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。它包括验收测试和客户测试驱动等的极限编程的实践，作为对测试驱动开发的回应。
CI、CD：
持续集成(Continuous integration)是一种软件开发实践，每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
持续部署（continuous deployment）是通过自动化的构建、测试和部署循环来快速交付高质量的产品。