今年下半年，公司项目管理转变， 采取“敏捷开发”（暂且不说是真敏捷还是假敏捷）；
第一次从“瀑布”开发 转战 “敏捷”开发的项目后，有一个感受：
1.敏捷，类似小瀑布--虽然这个表述不是那么准确，但是在一个迭代中，是这样的；在多个迭代中，跟瀑布才有比较大的差异 ---- 多个迭代是不断循环的，一个迭代在进行中，就开始准备下一个迭代，但是瀑布是一个版本完全结束后，才开始下一个版本
2.需求文档简化了，这对大家的理解、沟通要求高了很多
故在从传统转敏捷前，要先做好培训工作，让大家意识到会有这些不一样，显得非常有必要；让大家有心理准备后，在实践过程中才不会
1.太突兀，不适应新流程，没有做好充分的准备，比如以下提到的会议准备不充分
2.以为测试的“地位”被弱化
3.认为需求说明不齐全：敏捷不比瀑布有那么齐全的文档，需求说明以故事的形式存在，更多细节问题，不会在实现就充分考虑描述
敏捷的5个会议，关于会议准备不充分，那么在参与这几个会议之前，测试人员需要做什么？每个会议测试人员需要做什么？
粗略总结如下：
1、迭代准备会议（提前过滤要做的内容）：bug预筛选--选出下个迭代要修复的bug，在本次会议中提出
2、迭代评估会议（类似于传统的需求评审会议）：参会前，把本次会议的需求先过一遍（迭代准备会议有列出），生成用例框架， 带着疑问参加，在会议上，直接提出对需求的经过思考的疑问
3、迭代计划会议（类似于传统的立项--确定时间节点会议）：对评估会议剩余的疑问会后思考完后，在本次会议中确定，并预估测试时间，确定本次迭代的时间安排周期
4、每日站会：了解昨天做了什么，今天打算做什么
5、项目总结会：多说我们，少说我
这些事情，除了每日站会，其他跟瀑布一样，我们一直在做，只是在敏捷中，换了个名词
相比瀑布，敏捷的每日站会，大大提高了大家的衔接度，个人认为这个是敏捷与瀑布的一大明显且有提高的区别