所有開發流程都有共通的環節，因為軟體產品的生產就像其他產品一樣，不可能實現奇蹟性的產出。
敏捷開發解決的是應對變化，本質是縮短週期，增加校對點。幾天、一周、最長乙個月的週期裡，一般至少有一次校對機會，減少實際和預期的偏差。
即使採用敏捷方法，應對各種需求變更也只是理想的目標。因為**和測試的調整要遠慢於需求的改變。需求的變化仍然需要有乙個截止點，在這個點之後則不能改變。
敏捷不代表沒有計畫，在具體操作中計畫不斷改變，但總有乙個明確的目標。
敏捷不代表沒有文件，需要的是高效的文件，而不是華麗的表面工作。
敏捷不代表無限制的變化，產品開發是收斂的過程，而不應發散。所謂收斂是指軟體行為應越來越明確，需要做的工作應隨backlog的完成而減少。
敏捷需要在每個sprint開始前定義將要完成的backlog和完成的標準。在sprint過程中不應改變backlog的定義，不應改變資源的投入。
應盡量在sprint開始完成依賴的條件，如開發環境、測試環境、第三方的介面等。避免在過程中出現阻止團隊前進的障礙。
第乙個sprint應搭建可測試的環境，完成自動構建、自動部署、自動測試的架構。即使只是最簡單的環境，但保證可以滿足真實產品的開發。
scrum master的職責應為project manager和program manager的結合。帶領團隊的同時應定義產品的功能和行為。
敏捷定義的是團隊的產出，不對個人做評估。在敏捷中團隊的所有人都是平等的，這也代表所有人都應可以互換，開發可以做測試，測試也可以做開發，人人都可以是scrum master。但實際中，因為每個人的能力和知識領域的差異，很難做到互換。
sprint計畫時，應先定義backlog，團隊一起評估時間，最後分配任務。首先以最擅長為原則分配，最後將剩餘的backlog分配給空閒的人。如果沒有人可以分配，則按照優先順序減少backlog。
敏捷過程中最容易出現的是，被不斷的變更打亂計畫，最終被變更牽著鼻子走。堅持計畫->實施->反饋的原則，避免只關注變更。
可以嘗試讓團隊成員輪流擔當scrum master，也許有意外的驚喜。
關於敏捷的一些想法
敏捷軟體開發宣言 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 勝過 合同談判 響應變化 勝過遵循計畫 今天看了robert martin的ppp一書的第一部分，敏捷開發 回顧了自己曾經加盟過的幾個公司，經歷過的大大小小的專案，感慨良多。這些公司中不乏奉過程開發為寶典...
關於逐步實踐敏捷開發的想法
由於將會要組織乙個全新的研發團隊，而且可能團隊中講會以年輕人為主，應屆畢業生尤其巨多。我覺得這是乙個嘗試全新的開發模式的好時機，但是當然需要平穩過渡。首先，我們都沒有敏捷開發的經驗，其次，敏捷開發所有的概念也未必完全適合團隊，需要動態的來尋找結合點。1.簡單設計及重構 首先需要較為嚴格的確立工程的概...
關於敏捷開發的一點小想法
針對最近又比較火熱的敏捷開發，我有一些個人的想法和認識，粗淺之處，還請大家指教了。個人不太感冒，或者說持觀望態度吧，原因如下 1 首先概念是國外提出來的，是英文的，翻譯成中文往往就會有質的區別，中國人喜歡歪曲外國人的概念，也可能是翻譯的問題吧 2 敏捷開發對個人素質的要求是很高的，國外的軟體人員要比...