项目背景：2014年公司新做一个移动客户端项目，领导推动按照敏捷的方式做，当时我们每个人都学习了精益看板管理，结合敏捷的思想，大家兴致勃勃的开始，希望能够从原来1个月上线，变成1周交付一次，迭代周期从1个月缩减为1周。
团队人员：项目经理、测试人员（我的岗位）、开发人员、产品人员
实施方式：1、产品同学把需求进行了拆分，分解为一个一个故事，把所有的故事进行了优先级排期，每周要发布的功能需要提前一周确认；
2、确认要交付的故事，放入任务池，由开发人员自己去选择任务开发，同时测试人员要提前做好环境和用例准备
3、每日站会反馈进度和问题，由项目经理统一收集进行处理
项目结果：实际上原来一个月完成的工作，引入新的方式后2个多月才完成，每周都能上线，但是后面上线基本都要修复前面的问题，很多上线不是新功能上而是为了修复问题。
回顾分析：1、大家并没有真正理解敏捷的思想，只是照着这个在做 ，从一开始就觉得做不成功，因为领导要做才做的，思想是最大问题
2、这个新项目依赖于外部的公共能力，前期没有沟通好，导致我们选择的一些故事依赖外部的能力不能如期上线
3、产品同学没有需求文档，原型做得比较粗糙，大家理解有偏差，故事的划分不够合理，每个迭代的功能存在强关联导致，在一个迭代周期里也不断有需求更改，测试的工作量成倍反复增加，时间增加，发现的问题反复出现
4、对于敏捷要求的站会和回顾，没有很好的做，会议效率和效果都不好，基本大家都是流水应付，着急去开发代码，不太能理解这些会议的重要性，具体干活的同学觉得浪费了时间
总结：1、项目组一定要达成高度一致，思想一定要先转变，只是形式改变没有好的结果
2、敏捷是一种价值观的体现，并不是表示不需要文档，不需要规则，更不是表示不需要把需求搞清楚，每一个迭代的需求应该非常确定，在迭代周期内不应该频繁变更需求，规则应该执行的更严格，大家都要行动一致目标一致
3、个人感觉做敏捷一定是要求人要合适，技能要强，对敏捷也应该很了解，能力弱不了解敏捷就不合适做起来非常痛苦
