年初参与到研发团队，决定使用敏捷的方法进行项目管理。经过两个月的实践，随着项目的进展及环境的变化，这项实践并未持续下去，现对这段失败的经历进行总结如下：
一、项目背景
原有项目管理状况为：
项目成员6人，其中测试人员1名；项目经理根据公司业务要求，估算工期，指定开发计划、分配任务给相关开发人员进行开发，开发完成后，开始测试，修改Bug。没有例会，所有人员有问题直接找项目经理，每个人只负责自己的模块，所有的问题的决策都由项目经理一人决定。
二、实施过程
1、目标：希望建立一个自组织的团队
2、实施方法：先建立敏捷的形式，逐步完善敏捷中的实践，通过不断学习和积累逐步使团队敏捷。
（1）最初的实践：召开每日站会，基本按照站会中的三个问题进行。
（2）增加的实践：通过白板和TAPD管理用户故事和迭代，收集产品需求，根据优先级纳入到迭代计划中，控制迭代周期和工作量
（3）完善实施过程：通过GoCD进行每日构建
（4）召开迭代回顾会议：总结问题与不足、完善敏捷过程
三、失败因素
1、敏捷流程和知识准备不足，敏捷实施流程不完整。
没有进行正式的迭代启动会议、没有进行功能演示
2、结对、TDD、重构未能在团队中实施
对单元测试进行简单培训，但未强制实施
结对编程未能得到团队认可，每个人仍习惯单兵作战
开发人员不具备重构技能，没有重构意识，只关注当前任务的完成
3、实施过程未进行项目度量
没有让燃尽图发挥作用
没有衡量团队的生产率
4、团队能力的培养
只注重业务功能的开发，加班加点工作但未能让团队抽出时间学习
对于项目中需要的重构技术、TDD技术没有经验丰富的人员进行培训
5、管理层的压力及团队变化
因创业公司压力大，领导层对研发团队的产出不满意，加班加点仍不能满足新功能的需要。
增加人员、更换项目经理，敏捷实践未能继续完善。
四、收获
1、星星之火，可以燎原。传播了敏捷知识，部分人员在后续工作中开始接受结对、接受TDD。
2、对Scrum和XP的过程和价值有了更深的认识，更加坚定了对这种方法和实践的信心，如有机会仍然继续探索
