个人感受：
过去我的做法：
1、以前每个部分都是分开各做各的，做好自己的事情就好了，不需要管其他的。独立开发，想做什么做什么，只要实现布置的任务就行。
这样做的缺陷：
无法做到团队快速开发，很难提升速度。
问题解决方法：
1、要自己挑选任务；每次Sprint结束之后，还要总结不足，提出改进，并且自己要实施这些改进。
2、每个人要联合起来对项目负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。
3、每个人都全面负责，自己搞定规格说明书，和别人沟通，同时自己搞定测试。
重点记录：
软件项目的团队各式各样，假设一个团队做得还不错，现在要变成敏捷流程，那团队要做下面的改变：
1、自主管理： 以前领导布置了任务，我们实现就可以了，现在要自己挑选任务；每次Sprint结束之后，还要总结不足，提出改进，并且自己要实施这些改进。“自主管理”不等于“没有管理”。
2、自我组织：
以前做好自己的事情就好了，安心下班。现在每个人要联合起来对项目 负责，有人工作落后了还要帮助他改进，项目缺少某类资源还要自己顶上去。
3、多功能型：
以前规格说明书由PM来写，测试由测试人员来做，现在每个人都全面负 责，自己搞定规格说明书，和别人沟通，同时自己搞定测试。
如果你的团队很弱，那么强行把敏捷套在上面也没有用，也许还会适得其反，往往需要多次Sprint才能让Scrum走上正轨。换句话说，如果你的团队已经有这么厉害的一帮人，那么用不用Scrum都能写好软件！
敏捷不是万能的。敏捷的方法能帮助你更早地知道你是否能如期完成任务，仅此而已。敏捷的方法能帮你尽快让用户看到项目的部分价值。当你尽早交付部分价值时，也许用户对你目前交付的东西已经很满意了，这样你就不用再花时间来实现其他需求。另一种可能是，用户看到了部分系统，他们有新的需求，这样你就可以实现新的需求，而不用再浪费时间实现过时的需求了。
需要敏捷的开发流程，但是不需要匆忙或忙乱的开发流程。在实际情况下，有许多号称敏捷的项目好像也敏捷不到哪里去。要记住，有许多最佳实践在各种开发方式下都在使用，所以各种开发方式并不是井水不犯河水、老死不相往来的那种关系。