2、Scrum 敏捷过程的优点和局限性

一、优点

在项目测试的过程中，项目组的所有成员已经非常强烈地感觉到Scrum敏捷过程所带来的积极变化。总结起来说:

1、快速适应需求的变化并且按时发布

敏捷过程能够驾驭变化，Scrum敏捷方法不是要抵制变化，而是努力尽可能容易和有效地适应变化。

在测试过程中，不断伴随需求的变化，在本项目中，测试组长（Scrum  Master）制定测试计划实际就是做这样的工作。

在实际工作中，开始根据测试任务和需求的优先级制定了计划，而在每个Sprint，会有多次的简短和突发性的计划，有效地运用Scrum  测试，可以随时按需进行多次计划。

计划永远是在变化的，不可能出完美的计划，计划改变反应慢也是V-model  的一个缺陷。如果一次计划做得不够好，那就多做几次。在项目规模小、复杂程度低而不确定因素又多的情况下，不能够不做计划，Scrum可以对计划做有效的快速反应 。对于测试计划的调整，来保证满足需求的情况下，按时发布。

2、提高测试生产率

通过实践，大多数测试组成员都意识到了明显的生产率提高。这体现在Sprint Backlog 的精确反映实际产品的变化；不断的反馈，使可能影响测试的问题能够较快的得到解决；各方的沟通将很多复杂的问题迅速得以澄清；测试人员对其它项目组成员的建议得到很好的反馈。

Scrum  建议的每周40小时工作制，通过计划的调整代替加班，使得测试人员能够保持充沛的 精力，始终保持在高效的状态下，单位时间内发现缺陷的效率也明显提高。

3、降低过程进度控制风险

Scrum方法配合精确的测试度量工具，多种层次的沟通，便于控制工作量和风险，客户的需求和反馈也能够得到及时处理，体现了敏捷的控制进度风险的优点。

4、提升产品质量

V-model的一个误区是将一个巨大一次成型的系统一次性拿到测试人员的面前。而测试人员面对如此多的功能进行测试，不可预见性非常大，大量的缺陷的发现，使得开发人员在极大的压力下解决BUG,  解决的质量和数量随着产品发布的临近，非常难以控制。

Scrum  测试过程提倡开发一部分测试一部分，测试人员对于软件系统的认识可以作为一个循序渐进的过程，并且如果中途发现了任何问题能及时提出，开发人员可以早期讨论解决缺陷，这是一个每天进行的工作。便于控制工作量和风险，测试的需求和反馈也能够得到及时处理，体现了敏捷的优点。

Scrum  敏捷开发过程中在每个Sprint  提倡多次集成、建立成品系统很多次，而且随着产品变更，要进行不断地回归测试。此时自动化测试是推荐的测试方法。     

二、局限性

Scrum方法作为新生事物，过程发展得还不成熟，并且在不断提高中，难免存在各种不足。敏捷过程的发展，未来有可能克服

1、对分布式开发环境的支持非常弱

Scrum  过程提倡的强调在实践中沟通协作。团队成员和客户在地理上分布的开发环境可能无法支持敏捷过程提倡的面对面的交流。

项目中，发现在开发Scrum  team  初期少数项目成员在不同的城市，并且有地域的时间差异；在这种情况下，只能过诸如视频会议的技术手段进行面对面地交流，导致成本昂贵，而且不一定达到预期效果。

而时间的差异，导致反馈速度变慢，所有Scrum  team集中在同一地点才能够发挥其最大有效性。Daily  Scrum  meeting  无法发挥，此时可以对远程的Team  成员作定期面对面交流，所以，面对面的交流在分布式的开发环境和在非分布式的开发环境中同等重要，两次交流之间，文档成为主要的交流方式。

2、缺乏对大型复杂软件的支持

本项目是一个小型项目，没有体验到这一点；在资料研究中可以看出，所有的敏捷过程都是针对小规模管理的过程，Scrum  作为敏捷的一种过程，也不例外。

可以预见，对于大的团队，必须维护的交流线索会降低诸如面对面交流和评审会议等实践所带来的效果，敏捷程度可能会比在小项目中使用小得多。而对于测试来讲，同时要考虑测试的项目规模和整个项目的规模。

三、客观地看待敏捷测试过程的应用

了解到Scrum  测试应用的优缺点，能够帮助我们更好地看清问题的本质。

在采纳之前，要全方位考虑，并且综合考虑整个项目的开发过程，考虑应用可以获得的收益，以及不适用的情况。对于不适用的方法是否有解决方案等。开发长期规划、大型复杂分布开发的系统的公司在目前形式下不太可能采用敏捷过程。所以可以比较两种方法在不同规模下开发工作的资源占用情况，规模中也要考虑分布式。

实际过程中的敏捷与否不是绝对，测试项目要根据实际情况来决定是否采用，并且在微观上作出更适合的调整，比如，Scrum  强调沟通，轻视文档，但是对于测试来说，测试用例文档是必不可少的。

敏捷和不敏捷之间要找一个合理的折衷。