1. 我們最優先要做的是通過盡早地、持續地交付有價值的軟體來使客戶滿意。
2. 我們歡迎需求的變化，即使到了開發後期。敏捷過程能夠駕馭變化，為客戶創造競爭優勢。
3. 經常交付可以工作的軟體 ，從幾個星期到 幾個月，時間間隔越短越好。
4. 在整個專案開發期間，業務人員和開發人員必須朝夕工作在一起。
5. 圍繞鬥志昂揚的人構建專案。給他們提供所需的環境和支援，並且信任他們能夠完成工作。
6. 在團隊內部，最有效率也最有效果的資訊傳達方式，就是面對面的交談。
7. 可以工作的軟體是 進度主要的度量標準。
8. 敏捷過程提倡可持續開發。出資人、開發者和使用者應該總是保持穩定的開發速度。
9. 對卓越技術和良好設計的不斷追求有助於提高敏捷性。
10. 簡單——儘量減少工作量的藝術是至關重要的。
11. 最好的架構、需求和設計都源於自我組織的團隊。
12. 每隔一定時間，團隊都要總結如何更右效率，然後相應地調整自己的行為。
我們最優先要做的是通過盡早地、持續地交付有價值的軟體來使客戶滿意
在這條原則中我看到這幾個亮點：盡早、持續、有價值、使客戶滿意。
1）盡早，專案開始設計開發後，什麼時間開始交付給客戶第乙個可用版本呢？盡早！那盡早到底是多早呢？這個問題敏捷開發中是有定義的，兩個周！
2）持續，也就是說我們交付給客戶的軟體是乙個連續的、週期性的。現在的軟體公升級週期很多都是固定的，其中乙個主要的目的就是讓客戶能感受到我們存在，讓客戶看到我們一直在努力。
3）有價值，敏捷開發中指出我們每次交付的產品並不是乙個全而不專的產品。我們一定交付的一定是乙個切實解決客戶問題的軟體。也就是敏捷宣言中提高的「可以工作的軟體」。
4）使客戶滿意，這是很多公司的口號，無數工作者為之奮鬥的目標。可是我們發現客戶真的不是很容易滿意。我們做錯了什麼呢？有沒有是我們前三點的問題呢？
回過頭來我們看一下敏捷開發是如何推動產品研發方案的。這裡我著重介紹和本節相關的幾個概念
1）使用者故事
為了專案能按照計畫進行開發，讓工作有序可依，對於每個專案我們都需要進行需求調研。這裡的使用者故事也是一種需求，但它又與我們平常做的需求調研不同。使用者故事並不關注過多的細節，因為具體的細節會隨著時間而不斷的變化。使用者故事是一種用來制定計畫的工具，我們可以使用它並根據需求的優先順序和估算代價來安排實現該需求的時間。但因為需要估算出時間，因此使用者故事也並不是「實現許可權管理」、「實現生產報表統計」這樣的描述。它必須是確切的，可以進行度量的。
2）迭代計畫
我們講到的第乙個概念「使用者故事」，並不關係細節，而且細節是不斷變化的。那我們是不是又一次將自己置身於不斷的變化中呢？迭代計畫就是解決這個問題的。每次迭代通常耗時為兩周，這也是我之前說的盡早的時間。每次迭代都是一次小的產品支付。
一旦迭代開始，客戶就需要同意不能修改本次迭代中的使用者故事的定義和優先級別。這樣就保證了我們在一次迭代中將不會再次面臨著需求的變更。同時迭代對開發者的要求是迭代結束後必須提交規定的使用者故事的產品。一旦無法開發完成迭代計畫，需要對迭代中的故事在徵求客戶許可的前提下盡早進行調整。
開發管理者可以根據多次的迭代計畫對開發速度進行統計，這樣能更好的保證迭代週期內工作量的飽和和工作的按期完成。對於新組建的團隊前期迭代需要有足夠的預留時間，以保證能按期完成。
3）發布計畫
大約6次迭代（約3個月）後，產品通常進行一次發布計畫。它表示一次較大的系統功能交付。發布計畫和迭代計畫一樣，需要提前與客戶進行溝通確認，並制定嚴格的時間規劃。
4）時間安排
這備份的結論主要來自於《人月神話》。對於專案開發時間規劃和安排，《人月神話》中提出如下結論：
程式和產品的成本比為1:9（如下圖，兩個箭頭都是表示x3）
軟體任務的進度安排：1/3計畫、1/6編碼、1/4構件測試和早期系統測試、1/4系統測試
看了這些結論發現，也許我們之前真的對自己太自信了。
5）完整團隊
那我們進行開發後，在使用者故事中不明確的事情如何解決呢？這就需要有完整的團隊。乙個完整的團隊中必須包含客戶或能代表客戶需求的人員。在系統實現中能進行實時溝通和交流保證對使用者故事理解的正確性。
乙個完整的開發過程初步勾畫出來了，還有很多的部分需要進一步需要理解完善。以上幾部分也基本上闡述了我們的第一條原則。這其中每乙個小的部分又有很多需要學習和**的地方。我也是現學現賣，說的不對請多多指正。
以上介紹的幾個概念中，重點就是使用者故事。雖然上文中講使用者故事並不關心細節，但是使用者故事是作為規劃時間的方案之一，因此使用者故事應該還是很詳細的。試問我們的需求說明能準確的度量時間嗎？如果不能，那使用者故事就應該比我們的需求說明書更詳細。書中指出使用者故事並不一定需要完整記錄，這應該是和敏捷軟體開發宣言中的「可以工作的軟體重於面面俱到的文件」一脈相承。當我認為文件還是必要而有效的手段。文件是我們與客戶進行溝通交流的產物和留存，更是我們工作結果的展示。所以我認為文件是必須的！對於敏捷開發中一些文件要求，我想還是理解的問題吧！
敏捷開發過程中還有一些比較好玩的方法，基於delphi估算原理的估算撲克。開發至於還可以打打撲克？當然不是了，這是一種民主性的估算方式。有興趣可以看看奧。
第乙個原則就介紹到這裡，隨著後面原則的介紹，敏捷開發的過程也將為我們展示其靈活性和優越性，讓我們一起開始敏捷開發的學習吧！
敏捷開發原則
原則一 我們最先要做的是通過盡早的持續的交付，有價值的軟體來時客戶滿意，初期交付的系統中所包含的功能越少，最終交付的系統的質量就越高，交付的越頻繁，最終產品的質量就越高。原則二即使到了開發的後期也歡迎改變需求敏捷過程，利用變化來為客戶創造競爭優勢。原則三經常性的交付，可以工作的軟體交付的間隔可以從幾...
敏捷開發 原則 模式與實踐 1
這的確是一本關於開發者的好書，對於我們開發者 研究人員，它提出了乙個開發的全新的價值觀 對我來說 甚至人生都有啟發。需要認真閱讀。書中總結了敏捷開發的例項，確確實實更夠感覺到對於專案的完成大有裨益，有種相讀恨晚的感覺。想想自己之前的開發狀態，想想自己導師安排公司專案的情況，就是低效率，就是小兒科，就...
敏捷軟體開發 敏捷開發原則
編寫單元測試是一種驗證行為，更是一種設計行為。測試時乙個無價的文件。如果你想知道如何呼叫乙個函式或者建立乙個物件，會有乙個測試展示給你看。什麼是設計？不應該認為設計就是一組和 分離的uml圖。一組uml圖也許描繪了設計的一些部分，但是它不是設計。還是要 化 僵化性是指難以對軟體進行改動，即使是簡單的...