個人感受：
過去我的做法：
1、以前每個部分都是分開各做各的，做好自己的事情就好了，不需要管其他的。獨立開發，想做什麼做什麼，只要實現佈置的任務就行。
這樣做的缺陷：
無法做到團隊快速開發，很難提升速度。
問題解決方法：
1、要自己挑選任務；每次Sprint結束之後，還要總結不足，提出改進，並且自己要實施這些改進。
2、每個人要聯合起來對專案負責，有人工作落後了還要幫助他改進，專案缺少某類資源還要自己頂上去。
3、每個人都全面負責，自己搞定規格說明書，和別人溝通，同時自己搞定測試。
重點記錄：
軟體專案的團隊各式各樣，假設一個團隊做得還不錯，現在要變成敏捷流程，那團隊要做下面的改變：
1、自主管理： 以前領導佈置了任務，我們實現就可以了，現在要自己挑選任務；每次Sprint結束之後，還要總結不足，提出改進，並且自己要實施這些改進。“自主管理”不等於“沒有管理”。
2、自我組織：
以前做好自己的事情就好了，安心下班。現在每個人要聯合起來對專案 負責，有人工作落後了還要幫助他改進，專案缺少某類資源還要自己頂上去。
3、多功能型：
以前規格說明書由PM來寫，測試由測試人員來做，現在每個人都全面負 責，自己搞定規格說明書，和別人溝通，同時自己搞定測試。
如果你的團隊很弱，那麼強行把敏捷套在上面也沒有用，也許還會適得其反，往往需要多次Sprint才能讓Scrum走上正軌。換句話說，如果你的團隊已經有這麼厲害的一幫人，那麼用不用Scrum都能寫好軟體！
敏捷不是萬能的。敏捷的方法能幫助你更早地知道你是否能如期完成任務，僅此而已。敏捷的方法能幫你儘快讓使用者看到專案的部分價值。當你儘早交付部分價值時，也許使用者對你目前交付的東西已經很滿意了，這樣你就不用再花時間來實現其他需求。另一種可能是，使用者看到了部分系統，他們有新的需求，這樣你就可以實現新的需求，而不用再浪費時間實現過時的需求了。
需要敏捷的開發流程，但是不需要匆忙或忙亂的開發流程。在實際情況下，有許多號稱敏捷的專案好像也敏捷不到哪裡去。要記住，有許多最佳實踐在各種開發方式下都在使用，所以各種開發方式並不是井水不犯河水、老死不相往來的那種關係。