总结：敏捷开发的愚见

什么是敏捷开发？

目前互联网行业已占领软件行业的半壁江山，越来越多的企业开始实施敏捷研发。那么什么是敏捷开发呢？

简而言之，敏捷开发就是一种以人为核心，迭代循序渐进的开发方式。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成功都经过测试，具备集成和可运行的特征。而敏捷开发离不开迭代，迭代就是我们所说的一个子项目或者一个版本，通常一个迭代是3周左右，每3周进行一次上线包括需求开发、测试和上线。

图中就是一个完整的迭代过程中项目经理、PO、研发和测试整个Scrum team的工作流程。首先是PO组织相关Scrum人员进行迭代需求评审，然后是Scrum团队中的研发人员进行研发的过程，这个过程一般持续2周左右；在研发的过程中测试需要完成这个迭代的用例编写；然后是研发人员转测，测试人员执行用例，这个时间大概一周左右，测试人员完成测试工作，PO验证完成这个迭代进行上线。在规划的所有迭代完成之后，会产出一个最终的产品软件，这个时候交付客户，进行线上验证和后期推广等操作。

在敏捷开发中测试如何工作？

在互联网企业中，每个测试都要求独当一面。一个人常常负责一个单独的模块或多个模块。互联网发展快的特性使得企业为了快速响应需求，上线要求周期短而且发布频繁。互联网易变的特性使得惬意需求变更成为老生常谈。

此外，负责的模块会经常变化，负责的需求人员、研发人员及测试人员也会变化，最终导致我们制定或参与的测试计划也会经常变化。在互联网这个大环境下，我们更需要自我管理，自我计划的能力。

这时候，需要执行测试计划，需要通过计划去管理变化，将风险降至最低，以致于可以将风险扼杀在摇篮中。

从下面这张图中我们可以看到敏捷开发的核心是拥抱变化和递增变化。

在敏捷开发中，测试的工作是贯穿始终的，在需求阶段测试已经介入工作进行需求的合理性验证。在完成需求评审之后，测试需要根据需求规格说明书和原型完成测试计划，然后采用合理的测试策略进行测试用例设计。在开发人员进行研发的过程中，相关测试人员同步进行需求的用例编写，这个过程也是不断了解需求，完善需求的过程。

一般经过两周左右的开发，在第二周周四左右，测试会提供这个迭代的测试用例给开发人员，研发人员需要根据测试用例的优先级和重要性，将需求中已经实现的功能进行自测，不断完善代码，自测通过之后，将于周五进行转测申请提交，至此这个迭代的工作重心将从研发人员转职测试人员，变为测试为主。

这个时候测试人员会根据测试计划和项目约定的要求，采用2+2+1的模式执行测试用例。

这里的2+2+1模式是对于上线迭代的此需求，需要测试进行3轮测试任务。

第一轮：完成此迭代涉及到的所有需求的测试用例的执行(根据不同项目情况，需要执行的测试分为接口测试、功能测试、性能测试、兼容性测试等)。

第二轮：完成该迭代的bugs的回归操作，并且保证所有上线功能的bug中等级别以上bug全部修复，bug等级低或者其他UI、易用性问题可以根据项目时间安排尽量在本迭代内完成修复。

第三轮：第二轮bugs回归完成之后，进行的第三轮则主要是产品和UI验收阶段。

PO和UI验收完成之后则进行上线发布阶段。这个时候需要邮件通知相关项目干系人进行线上部署、发布以及验证和后期推广等操作。

一般在项目结束之后，需要项目管理者和PO以及Scrum team人员总结此次迭代中的经验和教训，不断完善、提高整个团队的合作能力。

至此，在敏捷开发中，一个完整的迭代就这样结束了。这里举例的模式是2+2+1，不同的项目不同的迭代功能需要根据项目实际情况进行合理安排测试的时间，具体问题具体对待。如果说整个迭代的功能需求多，那可能采取的是3+2+1，或者其他更好的方法。

上面说明的敏捷开发中整个迭代是3周，最后一周需要测试、研发修复bugs和验证验收之后进行上线发布、验证；但是有些情况下，可能整个项目划分了N个迭代，而每个迭代的时间紧，任务重；这个时候可能就没有一个完整的一周时间留给测试和研发人员进行bugs的修复工作，这个时候在第三周开发进行第二个迭代的研发功能，测试执行第一个迭代的用例，需要研发人员合理安排时间进行bugs修复和第二迭代的研发。整个项目计划中必须留出足够的时间给测试人员完成用例的执行，不能压缩测试人员的工作时间；所以这个时候就是考验项目管理者和PO的时候，需要合理安排计划。

敏捷开发中遇到的问题？

对于敏捷开发而言，需求的变化、人员的变化会导致出现各种问题。

迭代需求变更不同步

前面说了，敏捷的核心原则就是变化，所以敏捷开发中需求变更会很频繁。经常是研发过程中发现某一需求实现和之前的功能冲突，这个时候研发和PO经过协商会更改部分需求，但是变更的需求没有及时同步至测试相关人员，直至测试时才发现这个需求已经变更。

出现这个问题原因有：整个项目开发团队人员比较分散，如果需求变更比较多，导致遗漏部分变更的需求；这个时候就需要产品和项目经理以及研发和测试人员及时同步需求变更问题。需求变更的源头是产品经理而最终测试必须通知测试人员。所以需要相关负责人建立一套完整的需求变更反馈机制，不能遗漏任何一个环节。

延迟提测时间

研发提测时间的推迟，最直接的结果是如果无法延期上线时间，导致测试时间不充分，则软件的质量可能会出现一些无法预测的问题。这里延迟转测可能有以下原因：

1. 研发过程发现需求缺陷，增加需求或变更需求比较大
2. 测试用例编写过程发现需求缺陷，增加需求或变更需求比较大
3. 产品中间插入紧急用户新需求，影响了整个迭代的开发进度
4. 线上版本出现bug，紧急修复

针对问题1和2，则需要PO在定义需求时，更加严谨，而且研发人员在制定计划时，要仔细拆分各个功能点，每个功能点的实现方式做到胸有成竹。

这样即使再次出现问题1和2，也不会是大的需求变更，相对增加的工作量都在可控范围内。

针对问题3，我们需要建立一套适合的用户反馈需求的机制。项目经理和PO需要根据当前迭代的任务量适当处理用户的紧急需求。

针对问题4，对于线上版本的bug修复，需要根据bug的严重和影响程度以及修复成本，确认是否修复。对于影响和严重级别比较高的bug，则必须马上修复。所以如果出现此类程度的bug则需要测试人员自查，确认bug产生的原因是漏测还是环境配置造成的问题，需要测试人员在以后的测试中关注此类问题，避免再次出现此类bug。

需求理解不同导致上线延迟

产品提出的需求可能描述不清晰，导致研发和测试执行过程中没有发现此类需求功能缺陷，直到产品验收时才发现此需求实现有问题，没有达到产品的预期，这个时候的修复成本就比较高。

这里就需要产品在评审时明确需求说明书和原型中的每一个功能点，而研发和测试在评审和研发以及测试执行过程中有任何疑问都要及时提出来，不能想当然。

管理工具使用不同步造成时间成本增加

目前使用的项目管理工具是JIRA和confluence，通常产品的需求在confluence上会有一份功能点说明和原型图链接地址，而在JIRA上是各个功能任务详细说明和开发分配拆分的子任务。而变更需求只会在JIRA中标记，confluence中又不会出现变更的需求功能点。而测试和开发人员又是以confluence为主，JIRA对于开发人员而言就是拆分子任务和关闭分配的任务的工具，对于测试人员而言，在提交bug时会使用JIRA。

实际上这也是导致需求变更不同步和延期的一个原因，增加了产品、开发和测试的沟通成本，所以在项目开始时需要根据情况确定项目的使用工具，以免出现此类问题。

沟通问题

在敏捷开发中，项目经理、PO等Scrum team需要明确自己的工作职责，项目经理和PO要做好各方面的沟通协调工作，使得测试更集中精力执行测试工作，而开发则专注于研发工作，提高工作效率，降低无效沟通。

以上就是整个敏捷开发团队中所遇到的问题，对于项目管理、PO整个Scrum team团队而言，需要不同维度协调提高团队协作能力。敏捷开发团队每个人都要有主动沟通和协作的意识，测试要树立正确的敏捷测试观念，整个团队要以积极的心态拥抱变化。

部分内容摘自慕课网