敏捷有些时候，不仅仅是一个流程，很多时候，还要涉及到心态的变化，从产品研发的角度来说，就需要相关角色转变思想不能还是停留在瀑布的思想上。

    1.需求的心态
     A）我写完了，你们们慢慢做吧，有问题问我。
    ====》需求，研发，测试是一体的，需求人员需要随时关注产品状态，进行确认。产品的质量是大家的责任。
     B）这么多的东西，我哪能那么快的写完，你们再等等吧。
     ====》沟通比文档重要，当文档造成瓶颈的时候，要明白文档的作用就是交流沟通，那么可以暂时放弃文档，进行沟通，后续补充相关文档。

    2.研发的心态
    A）需求文档还没出完呢，着啥急。
    =====》研发与需求一样，都是要对产品负责的，要抱有需求也会随着迭代的思想,不要向以前一样，还是期盼着文档的大而全的出来才进行了解研发。
    B）需求就是这样写的
    ====》需求不光是需求人员负责，研发人员也需要对需求进行负责，需要给与需求反馈，需要验证需求文档是否合理。
    C）后面有测试呢，差不多就得了。
    ====》对于质量也是如此，不能总是依靠测试进行保证，作为研发人员本身也需要提高质量意识，达到每次交付的可交付状态。

    3.测试的心态
    A）需求文档啥时候出啊？
    ====》不能依赖瀑布式心态，等待需求文档完全出完，才能进行测试计划，可以与需求一起进行迭代，需求出多少，就进行多少的测试计划安排。
    B）研发必须在XXX时点结束，不然测试时间不足。
    =====》敏捷的流程要求测试也要跟随迭代，测试的时间被提前到了迭代中，所以不能还以以前的时间点要求研发必须在一个时间点结束。给与测试保留多长的测试时间，应该要求保留最后一次迭代的测试安全期+集成测试的时间即可。
  
    敏捷的流程要求大家都是一人多职的，而不是像现在的研发流程分出需求，测试，研发人员。经常都是团队里面都可以进行需求，测试，研发的角色，可以根据需求进行转换，虽然我们划分了这样的角色，但是从心态里面要转向敏捷的心态，淡化角色的约束。