总结：敏捷开发的愚见

什么是敏捷开发？

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

简而言之，敏捷开发就是一种以人为核心，迭代按部就班的开发方式。在敏捷开发中，软件项目的构建被切分红多个子项目，各个子项目的成功都通过测试，具有集成和可运行的特征。而敏捷开发离不开迭代，迭代就是咱们所说的一个子项目或者一个版本，一般一个迭代是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团队而言，须要不一样维度协调提升团队协做能力。敏捷开发团队每一个人都要有主动沟通和协做的意识，测试要树立正确的敏捷测试观念，整个团队要以积极的心态拥抱变化。

部份内容摘自慕课网