公司从外面聘请了敏捷顾问来给我们做了三天的培训，系统地学些了敏捷的一些基本概念，不能说对实际工作没有帮助，但是三天下来，感觉培训效果不是很理想。
因为讲的都是一些基本概念、工具和方法，我觉得这些东西更适合一个敏捷初学者，我不敢说自己对敏捷软件开发过程有多么的了解，但起码在形式上已经玩敏捷快两年
时间了，所以说这些东西更适合初学者或者对从传统瀑布模型转向敏捷的团队。
总的感觉敏捷还是一种信仰或者理念，敏捷强调自主管理，SM(Scrum Master)其实就是为团队服务的，他并不是以前想象那样是团队的领导或者负责人，SM和团队成员
是平级的，甚至在Scrum的团队里，没有什么等级之分，大家共同要对产品负责。所以敏捷对人的要求很高，要求团队成员基本上水平要差不多，最好每个人的知识面都成
”T“型，这样才能更好的协同工作。个人觉得敏捷团队要能成功最基本的一个前提就是 ”人本善“，这样每个人都能主动负责的完成任务。
我暂时能想到的对当前项目的改变：
1.以前有问题用户故事在当前Sprint没有做完，不知道该怎么办
解决：用户故事划分的不够细致，此用户故事可以再次划分。
2.工作量估计不准
解决： 用”故事点“来评估每个用户故事，然后划分出的任务卡片最好能以天位单位（就是最起码每天能完成一个任务）
3.燃尽图
解决：时间的燃尽图基本上可以不用，任务的燃尽图是用来每天看的，能反映目前项目进度情况，而不是在 ”审查会议“上来讲的
3.回顾会议
解决：必须的一个会议，产出：一个 "行动列表" 来指导下一个Sprint需要做的工作。
4.开发人员杜彼此任务不熟悉，会带来项目风险
解决：使用结对编程的方式，来提高代码质量和降低项目风险，而且在评估任务时，对彼此的任务也能估计的更准确一些,结对编程
还有一个好处就是可以彼此监督工作。
5.关于 用户故事 的更新
解决：用户故事尽量按照按照模板“作为一个xxx用户，我想要.....所以我就能.....”,写，而且在 用户故事 “详细”里（如果是纸质卡片，可以在背面）
写上完成标准(Completion Criteria)若干条。
我们还需要的东西：
部门制定一个统一的code standard,而不是每个项目组一个
关于看板的问题，卡片的问题，是否要采取。。。。