这篇文章本该几个月前就发，实习这么久来，实习的第一份工作是传统的大瀑布模型的项目，但是团队也是在搞敏捷迭代开发，所以也算是敏捷团队吧，那么这篇文章就聊一聊敏捷。

为什么要搞敏捷？

这就要说下传统的大瀑布的不足

    1.在开发中，如果有需求变更，那么变化会很大，可能之前开发的都要去重构，成本很高，响应变化困难

    2.开发完成后，PM才能看到项目的最终结果，在开发中，PM是看不到项目的全貌的，而且可能连模块级别的都无法看到，项目末期才能看到项目全貌

    3.如果项目有延期风险，都是在最终快结项时才会暴露出来，应对风险能力差

敏捷宣言：

    个体和互动 高于 流程和工具

    工作的软件 高于 详尽的文档

    客户合作 高于 合同谈判

    响应变化 高于 遵循计划

    百度百科对敏捷的解释是：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

    我所在的团队使用的是Kanban方法，每天早晨9点30准时开站会，站会内容大概如下：

        1.回顾昨天做了什么

        2.今天要做什么

        3.有什么风险

        4.需要协调什么资源

    站会发言顺序可以按职能来，产品—数据—前端—后端—测试

    站会发言顺序也可以按模块来，eg:登录注册功能—好友功能—朋友圈功能—个人信息功能

    具体怎么安排可以由leader去决定，每个角色按照站会内容去发言，会议中每个人要精简发言，控制发言时间，有歧义可以会后单独拉小会去讨论。

    敏捷这个概念一直都有，但是近几年国内的团队才开始转型敏捷，我所在的公司是有专门的敏捷教练，但敏捷教练不是一个团队一个，而是一个敏捷教练对应多个敏捷团队，教练定期给不同的团队leader做敏捷培训，再由团队leader去实施敏捷，这一定程度上也限制了敏捷实施的效果，因为敏捷教练并不是针对性的去对某一个团队做培训，而是通过各个团队的共性来制定的敏捷方案，所以最终可能会是不同的团队会有不同的效果。

1.在敏捷这种节奏下，作为QA该如何去应对呢？

    很多人认为团队搞敏捷就是去快速迭代，两周一迭代或者一周一发版，但是敏捷≠快，敏捷讲究的是颗粒度，任务的颗粒度，模块的颗粒度，我所理解的就是小瀑布，既然都是瀑布模型，那还是按着瀑布来走，不过是按颗粒度分。那么QA也应该要去适应这种节奏，开发的同时可以提前介入测试，梳理出测试case，并且提前准备好测试数据+测试环境，按照提测的模块来进行测试，提测多少就测多少，QA要有自己的测试节奏，今天提测哪些模块，测试进度要完成到多少，如果今天测试的模块有依赖项，需要提前报备风险，并且测试进度也要降低，对整体的测试进度要有把握。

2.开发测试如此快的周期，那么作为QA如何保障最终的质量呢？

    如果出现了bug，那么谁来背锅呢？PM说RD没按MRD开发，RD说QA没有测出来，QA说PM提的需求有问题，如此循环反复谁都不想背锅，这时候作为QA的质量意识、用户意识就要表现出来，一名QA不光是去和RD、PM沟通，也要把自己当做用户去体验产品，这也就是所谓的体验性测试。

    在设计、建筑、哲学等很多领域，有这么一句话——Less is More，少即是多，那么产品同样也适用于这句话，PM也好、RD也好、QA也罢，最终都是服务产品，服务用户，RD技术再好，开发的产品用到了多么高大上的技术，用户不买账，又有什么意义呢？在用户的角度看来，这个东西好用就行，能给自己带来什么好处，这才是用户所在乎的，同样作为QA的我们，就要在用户的角度去考虑所测的产品，RD可以不关心产品对用户的体验，但是QA必须要关心，因为QA是产品面向用户的最后一道关卡。 

    QA要有质量意识，在保障产品功能没问题的前提下，去考虑产品的可靠性和易用性，后期还要考虑到产品的可维护性、可移植性和兼容性。保障最终的质量，这一切的前提都是功能性完全OK，所以保障最终的质量，需要从多方面去考虑，但是最基础的还是保障功能性。

3.在敏捷中该如何去做测试？

    1).上面有提到过，作为QA要提前介入测试，尽可能的让自己的排期扩大

    2).RD提测之前要保证自测OK，QA可以根据测试case输出一版RD自测case，如果自测未通过，QA可以打回，并指导RD去做单元测试和简单的mock接口测试

    3).对于迭代周期较稳定的项目，可以定期进行功能全量回归，每周定期可以做性能、压力、模拟攻击等测试

    4).QA也有必要去针对性的做自动化，比如接口自动化/部分UI自动化，但是UI自动化维护成本较高，针对不同的项目去考虑自动化

    5).QA要做到上达业务，下通开发，提升自己的技能水平，针对不同的需求去用不同的测试方案进行测试

    6).要学会使用工具去提升工作效率，比如使用静态代码检查工具，可以减少在CR中遇到的坑，因为CR是比较耗时的事，但是CR大部分可以定位到疑难BUG

    7).测试环境，测试数据要提早准备，提前准备相关资源，减少后期测试中因环境等其他因素导致的延期

    8).QA自身也要遵循敏捷文化，面向价值，拥抱变化

    虽然现在所在的团队不是敏捷团队，但是所做的项目绝对是比敏捷还要敏捷的项目，万变不离其宗，再怎么变，QA还是控制产品的最后一道关。在大环境下，QA的要求并不是像以前简单的黑盒和功能测试，更多的是其他的能力，比如CR能力、产品能力、架构能力等等。

    感谢大家阅读，一只QA实习小菜鸟对敏捷的心得感悟，如果对敏捷有更多看法的欢迎留言探讨。

    祝大家新年快乐~