一个即成功又失败的敏捷实践

背景

公司主要做项目，项目前期需求不明确，需要快速交付最有价值的产品给用户，综合考虑，于是乎项目就开启了敏捷实践。我也即成为敏捷项目的一名测试员

成功之处

敏捷的东西应有尽有
-人员配置：产品负责人、项目经理、敏捷教练、质量过程工程师、开发工程师、测试工程师、实施工程师
-工具：kanban、燃尽图
-会议：每日晨会、迭代回顾会、迭代评审会、产品演示
-周期：两周一迭代，刚刚好
按这样的配置，足以证明公司的敏捷理论基础还是很好的，但是理论确实只是理论，实践还是检验理论标准的唯一真理！

失败之处

即知失败，那便是实践过后方可知晓。
-----迭代需求不明确----
需求清单就是一个excel，无产品原型，部分有产品原型但却跟需求描述千差万别，需求规则描述无，只有一句简单得客户需求
说到需求不明确，脑子里是不是发出个问好？不就是因为不明确才用的敏捷吗？拜托，所谓的需求不明确用敏捷，是因为用户
的需求不明确，产品负责人再跟用户沟通后，给到敏捷团队的，是明明白白的需求，不然返工成本会非常高！
-------迭代过程中会出现直接让开发改需求或者中间插入需求----
在学习PMP中，敏捷的十二原则有一条是拥抱变化，那是不是在开发的过程中可以随意变更需求呢？如果是的话那不是越来越乱！！拥抱变化指的是用户需求的变化，用户需求变化后，需要产品负责人重新评估，重新排优先级，然后在迭代评审会上进行评审放入下一次迭代，而不是直接本迭代改。要有规划地去拥抱变化才是正确的做法。
-------人员能力配置很低------
80%工作年限2年以下，水平差，导致bug修无止境。若想要做一个成功的敏捷项目，需要人员能力水准比较高，能快速调整、快速修复、具备重构能力。而不是普普通通的copy code
-------缺少培训-----
团队水平差一方面，大部分没有接触过敏捷，最惊讶的是一年的项目，竟然没有对敏捷方面的只是进行过一次培训。燃尽图大家没看，看板大家不会用，每日晨会不知道说什么，回顾会议啥都不说。
------产品演示基本在晚上9点左右演示，大家无精力思考----
------产品演示没有叫客户参与甚至产品负责人都没参加，不知道需求是否符合用户期望----
-------回顾会议都是定在周末，大家都是无心回顾，敷衍了事。回顾后没有形成过程文档----
-------责任田落实差：项目经理倡导敏捷项目T型人才，大家除了自己的事情，别的职能事情也可以做，比如开发可以做分析的事，测试可以做开发的事导致更多的时候，开发没有干好开发本职的工作，就跑去收集需求，跟用户对接，留下一堆技术债务。
-----开发人员直接对接用户，直接开发任务。乱