敏捷開發與沒有規範，沒有文件的程式碼編寫者的區別

與某些觀點相反，敏捷開發人員並非不按規則或限制編寫程式碼的特立獨行者。“牛仔編碼”是缺乏規則和管理糟糕的跡象，並且很不專業。如果團隊裡面存在這樣的編寫程式碼的現象，為了客戶的利益著想，您應該竭盡全力地改變這種情況。

敏捷開發最少需要開發和維護哪些文件？

但現實中的情況是大多數人不喜歡編寫文件、也不太喜歡研讀文件，因此太多的文件只會消耗團隊有限的時間，並不能帶來多大的好處；

一份概要性的高階的文件是使用者和開發團隊之間的契約，雙方的一致理解有助於溝通和互動；使用者只關心他要什麼，不關心如何實現，更不關心實現有多難，所以我們不能奢求使用者理解我們遇到的技術問題，甚至讀懂我們的程式碼或者註釋；

敏捷開發重視文件的作用，也重視文件的維護；它認為文件宜少且精煉，一般情況下建議開發並維護三份文件：

《軟體需求規格說明書》或者《產品規格說明書》：定義軟體應該具有的功能、邊界等，使軟體相關的涉眾對軟體有一致的理解，它作為使用者同開發團隊之間共同的討論基礎，並在開發過程中不斷的更新維護；

《架構設計文件》：軟體如何實現，內部之間是什麼關係？

《專案管理計劃》：計劃如何分期實現、測試、釋出等；

敏捷開發是否需要系統設計？

     敏捷開發是以小週期代替大週期，小週期包括：需求、設計、開發、測試、釋出，這個過程中是包括設計環節的，也就是說需要做系統設計；

     由於做完整的設計需要有相對完整的資料和比較長的時間，與小週期是相對立的，因此敏捷開發不主張高度細化和完整的設計，提倡做出一個大粒度的框架性設計，一般指架構設計或者系統設計或功能模組的概要設計，避免在以後的重構中發生架構級別的變化，然後在逐步實現的過程中逐漸深入展開、細化；

       做到概要設計即可，不用到詳細設計。[即可劃分模組，類，公共介面]。

       類的實現可以由編碼人員直接確定，完成專案後，可以通過後處理工具得到類的實現模型和類關係圖。

    傳統的一些設計方法比如結構化設計、面向物件分析(OOA)、面向物件設計(OOD)、自頂向下、快速原型法都是可以融入敏捷開發過程中加以使用的；

敏捷開發是否需要專案計劃？

     商業軟體開發需要承擔獲取利潤的責任，因此對產品的功能完整性、穩定性、即時性等都有較高的要求， 它是一種有組織有目標的行為，因此它需要專案計劃，但這個計劃是一個短程計劃，根據未實現的功能情況、前一個版本的反饋和組織目標制定開發計劃；唯有這樣才能不斷的融入新的變更；

       年度規劃，月度實現計劃。[年度規劃一般不可變，月度計劃則可以依據實際情況對需求實現進行進度安排]

敏捷開發的迭代週期大概多長？

       對於通用小專案而言，可以每月交付一個大的功能版本，每兩週交付一個變更或Bug版本。在進行專案開發進度估算時候需要對交付的內容大致有一個規劃。

當然也不能頻繁的釋出，特別是重大Bug的緊急釋出，這樣會降低使用者的期望並提高使用者成本，給使用者心理上帶來額外的負擔：他會認為產品質量低，質量控制不嚴謹等；

敏捷開發為何提倡小版本？小版本有哪些優勢？

     小版本的目的就是分解複雜度、降低風險，改善團隊士氣等；小版本有眾多優勢：

Ⅰ、總體風險比較少：小版本變化小，總是在上一個版本基礎上區域性調整和增加，技術複雜度低；由於規劃的功能較少，工作量也易於估算，所以其總體風險比較少，常常能如期釋出；

Ⅱ、需求的接納能力強：由於小版本快速實現併發布測試，然後就進入下一個版本的規劃實現週期，這樣新需求一旦提出就能快速進入開發視野，就能儘快實現；

Ⅲ、測試和開發高效協作：開發和測試可以並行工作，當開發實現第一個版本時，測試設計測試方案和用例；釋出第一個版本後，開發就進入下一個版本輪次，測試就應用測試方案測試剛才釋出的版本，提交Bug；開發在下一個版本結束時修正所有上一輪發現的Bug，然後釋出新版本，如此迴圈往復，開發和測試實現高效協作；

敏捷開發與重構的關係如何？

敏捷開發以重構為基礎，時時刻刻處於重構過程中；

敏捷開發為何強調團隊人員的參與、使用者的參與？

人是一切關係的主體，是生產力提升的主體；敏捷強調團隊成員的高度參與就是要統一認識，把團隊的目標變成每個人的工作目標，使之為每個團隊成員的認同，形成高度的凝聚力，以達到群策群力、高效協作的效果；

     由於沒有高度細化的文件，成員之間交換資訊的唯一渠道就是面對面溝通，良好的團隊氛圍和協作關係促進這種溝通，並使訊息準確有效傳達；

     使用者由於缺乏專業訓練，無法清晰、準確的表達其意圖，導致需求的歧義和模糊；使用者的參與使模糊、邊界不確定的需求在互動的過程中得到確認和完善；

     我們努力做的事情就是實現使用者需要的東西，並最終讓使用者喜歡它，唯有使用者喜歡它才能用好它，那麼我們怎能不認真聽取使用者的意見呢？

     一句話總結就是：使用者參與幫助我們做正確的事情！

怎麼才能評估我們團隊和開發過程已經敏捷了？

     由於敏捷開發沒有標準的可供參考的實踐過程，所以很難通過某個過程而斷定其開發過程敏捷了，那麼我們如何來評估我們的團隊和開發過程是敏捷的呢？這裡採用辦法是根據團隊呈現出來的氛圍、專案運作狀態、團隊成員的感性認識等方面來評估團隊和其開發過程是否敏捷，我們認為評估專案團隊和開發過程是否已經敏捷的方法如下：

1、團隊有共同的願景，並且對這個願景充滿信心

2、團隊有明確的階段目標並且為每個成員所知曉；

3、團隊知曉當前計劃：做什麼、何時完成、預期效果等

4、團隊任務是低耦合的，並且緊密協作；

5、釋出過程是輕鬆愉快的，構建版本並不斷測試是常態行為之一；

敏捷開發能縮短專案時間並提高質量嗎？

     敏捷開發能縮短專案週期並提高整體質量嗎？能，但我目前無法提供量化的資料做參考，只能從幾個方面評估和推斷：敏捷開發是能縮短專案時間並提高質量的；

1、使用者的參與幫助團隊把功能一次性完成並做正確，縮減了返工的時間；

2、不斷的重構和測試釋出能把問題發現在早期，整體質量顯著提高；

3、過程目標導向，使團隊高度集中於專案目標，提高了生產力；

4、不斷的釋出對團隊是種正向激勵，榮譽感和成功欲使團隊保持持續的激情；

敏捷開發與CMMI最大區別：

我覺得CMMI是由大及小的過程，Agile是由小及大的過程。

CMMI是給出所有可能需要考慮的點，讓你從中選擇你可能需要的

Agile是給出所有必須考慮的點，然後讓你再在其上進行擴充套件

方法無所謂好壞，關鍵要選對、用對方法，如果只是對於這些書籍上的理論進行討論，本身就是有缺陷的。