来这家公司一直是做敏捷迭代的，在这么长的时间，对敏捷也有一些初步的认识
一个完成的敏捷开发从需求确认到开发到整个迭代结束的一个周期，包括搜集需求，需求方的优先级评审（当然这些不需要我们测试参与），产品框图的准备，产品组的内部评审，技术可行性的评估（这时就需要测试的参与），然后就是prd的编写，框图的交付等等，然后再次交给产品leader评审，评审过后及开产品冲刺会，然后技术开发，测试，上线。。。。
但是在敏捷开发过程中进场出现的一些问题：
1 产品每个迭代都会加一些需求，这时增加需求首先就得评估工期，并且每个迭代增加的需求涉及到的产品，开发，测试，task，工作量都有相关记录。至于好处个人认为可以在每个迭代的总结会上提出，1 减少后期迭代需求的增加，2 明白每个迭代对应负责人增加的工作量
2 对于一个项目多个分组沟通的情况： 同一个项目组多个分组，以至于经常会出现多个组改一个模块的东西，不同需求改动一个功能不能同步，导致代码冗和容易出错
出现问题：一个小组改同一个模块的功能导致小组间的测试一直有问题：
解决办法：1 各组产品在需求评审时尽量都在一起。特别是涉及到同一大块的模块功能探讨清楚
2 各个小组的master及时沟通，并发现问题
3 开发在修改别人的模块的代码时尽量先沟通，提前了解一些注意事项，减少无所谓的bug
3 对于项目开始中删除和增加功能，都得发到群里，让大家周知并督促产品更新prd
4 如何提高敏捷测试的效率：工程效率是每个大公司都比较重视的一点，当然最关键的一点就是提高提测质量，如何提高提测质量目前来说：就是制定CC及时率和通过率的标准并严格执行CC通过率和及时率，并在每天日报更新并标记不通过原因同时加上负责该功能更的开发
5 对于项目风险的把控：敏捷对与项目风险的把控不想普通开发，讲究的是一个快，所以很多东西来不及打磨就上线了，所以测试就得每天吧可能存在的风险在每天的早会和日报里面提出来，争取规避，并对每个迭代的出现的漏测bug输出原因及总结并存档，
6 关于需求，可能有的需求不合理，有的需求冗余，对于这种需求，尽量及时提出来，最好通过沟通把这些没必要的需求砍掉。
7在开发过程中，开发实现方法与产品要求的不一致，可能大多数是基于技术实现的问题。关于这种需求，及实现方案和风险，也要记录下来。
8.合理的拆分task，API的尽量排在客户端之前，留给开发联调时间。每个task要有优先级。如果API不能排在客户端之前，要跟开发沟通，如何通过mock来测试
9 有的项目需求非常的复杂，这些东西一定要让产品给开发和测试及时梳理出逻辑。最好能在立项的时候就把这个逻辑给大家梳理出来。在项目过程中，遇到产品prd文档没写，但是现实的逻辑，需要做出来的，这些东西，不急，甩给产品。
10 越来越觉得项目的把控，进度的把控，风险的把控的重要程度完全不亚于技术
11 对于项目的排期：一个好的排期对测试也是很有帮助的，一般在开发排完后，负责相关功能模块的的测试及时反馈排期是否合理，比如api排期比和客户端和FE晚，这样依赖接口的功能排期最好相互对照一下，寻找折中的时间。如果优先级不高可跟开发沟通是否可使用mock测试，相信办法总比困难多