簡單的說下敏捷開發的一些知識：

敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果都經過測試，具備可視、可整合和可執行使用的特徵。換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。

個人理解：敏捷開發在我看來並不是沒有缺點，它強調自組織，對人的要求太高，實施起來有點難度。現實中，團隊的開發人員水平不一，性格不一，追求不一，而敏捷開發對人的要求又非常高，導致很多團隊很難真的做到敏捷，我也是隻能用敏捷的一些思想和方法，在原來的開發方法進行改進，提高了團隊開發效率和質量，但要說是敏捷，嚴格上我也沒實施過敏捷開發。

價值觀：

敏捷建模的價值觀包括了XP（極限程式設計）的四個價值觀：溝通、簡單、反饋、勇氣，此外，還擴充套件了第五個價值觀：謙遜。

敏捷開發是針對傳統的瀑布開發模式的弊端而產生的一種新的開發模式，目標是提高開發效率和響應能力。除了原則和實踐，模式也是很重要的，多研究模式及其應用可以使你更深層次的理解敏捷開發。

個人理解：五個價值觀，十個字。說起來容易，做起來不易，讓團隊都有更為不易。不說在工作中，就說做人，能都做到這五個都不容易。

敏捷開發原則：

一、快速迭代

二、讓測試人員與開發者參與研討

三、編寫可測試的需求文件

四、多溝通，儘量減少文件

五、做好產品原型

六、及早考慮測試（早點讓程式碼通過測試，也能夠早日對程式碼進行重構）

個人理解：雖然我的開發方法不是敏捷開發，但是讓測試人員參與研討和編寫可測試的需求文件是很有必要的。因為專業角度，開發人員和測試人員考慮的點將會不一樣，這樣能在研討中發現更多的問題及解決；測試參與了需求研討，也能更快的出測試用例，測試用例對需求的覆蓋率相對也會更高。但原則四，很多人存在著一些誤解，儘量減少文件也會變成沒有文件。多溝通是指對問題或需求，要多進行溝通；但是溝通，應該有個記錄，也可以說是文件，記錄溝通問題及結果，這樣，這個問題再次向其他人解答或者忘了的時候，就可以用文件來解釋說明了，但這要求有文件更新的習慣，如果沒有，會可能會造成資訊不同步。但也比同一個問題向不同人解釋幾次好吧，畢竟大家都那麼忙。

建模誤區：

一、建模就等於寫文件

二、從開始階段就可以考慮到一切

三、建模就意味著需要一個重量級的軟體開發過程

四、建模就是浪費時間

五、資料模型就是一起

（其實還有，但是個人不是很理解，就不寫了）

開發宣言：

一、個體和互動勝過過程和工具

二、可以工作的軟體勝過面面俱到的文件

三、客戶合作勝過合同談判

四、相應變化勝過遵循變化

遵循原則：

一、我們的最高目標是，通過儘早和持續地交付有價值的軟體來滿足客戶。

二、歡迎對需求提出變更——即使是在專案開發後期。要善於利用需求變更，幫助客戶獲得競爭優勢。

三、要不斷交付可用的軟體，週期從幾周到幾個月不等，且越短越好

四、專案過程中，業務人員與開發人員必須在一起工作。

五、要善於激勵專案人員，給他們以所需要的環境和支援，並相信他們能夠完成任務。

六、無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。

七、可用的軟體是衡量進度的主要指標。

八、敏捷過程提倡可持續的開發。專案方、開發人員和使用者應該能夠保持恆久穩定的進展速度。

九、對技術的精益求精以及對設計的不斷完善將提升敏捷性。

十、要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術。

十一、 最佳的架構、需求和設計出自於自組織的團隊。

十二、團隊要定期反省如何能夠做到更有效，並相應地調整團隊的行為。

個人理解：雖然遵循原則不少，我們也要根據條件去改變而不是一味的遵循。我覺得，不管是不是敏捷開發，如果能夠遵循五、六、九、十、十二。那麼對團隊也會有能大的提升。五的話不用多少了，劉邦論三傑。六的話需要注意，面對面交談也需要技巧，找人溝通的時候要看好時機，如果一有問題不經思考或者不看對方狀態就問，會影響工作效率；最好詢問下對方狀態，因為回答一個沒空不會太影響問題思路，但是要思考另一個問題並回答，也許自己原本思考的問題思路就沒了。九十十二也不需要多說了，除了需要團隊成員自覺上進，還要領隊人組織帶領。

以下是複製一篇部落格中的一些話，覺得挺不錯的，構建敏捷團隊，哪怕只是某幾個方面較原來好些，對整個團隊也是很大的提升。

構建敏捷團隊：

1.團隊好奇心，通過分析技術方式，調動團隊成員好奇心。

2.團隊慣性，或者叫團隊文化，作為一個主管，你要設法建立一種機制，讓團隊從慣性中掙脫出來，辦法就是走在前面，讓別人願意跟隨。

3.鏡子，當你想要改變團隊文化，或者某些自我感覺良好的成員，你所要做的事情，就是找出一面鏡子，讓對方看到自己。

4.從一開始，就要高標準，對團隊設定高期望值，團隊才會擁有持續改進的動力和願景。

5.程式設計師文化，反思自己職業，只有從過去中反思，才能知道下一步怎麼做。

6.程式設計師與建築工人，是不同的，編譯器才是建築工人，程式設計師是設計師。

7.程式碼重構，團隊崇尚程式碼重構

8.讓實踐落地，即要不斷總結，複習

9.權威，有職業賦予的權威，也有專家權威，前提是，要無私，用於說不知道。

10.點燃程式設計師的激情，即成就感。

11.排除技術障礙，建立和諧舒適的技術環境。

12.功能，以回報率為主

13.讓領域模型解耦，降低模組耦合度。

14.做正確的事，即使再正確的做事，做的事不正確，也失去意義。

15.不要沉迷於解決方案，最終要的是使用者問題，如何實現，只是你自己的解決方案，使用者壓根不在乎。

16.每做一件事情，多問為什麼。

17.估算的意義，在於揭示大家的理解和所擁有的知識的不一致，而非估計工作量。

18.有些規則，不懂為什麼，就照做，有一天，你會懂，懂了再改進。

19.測試有先

20.建立分享環境。

敏捷，不是一種狀態，而是一種持續改進的姿態。