在某些環境下，敏捷開發可以帶來的收益並非被所有人知曉。更多的情況下，敏捷軟體開發被當做是一種神聖的或者使用範圍侷限的活動。然而，在國內大多數軟體開發者素質平平的情況下，倘若敏捷教練無法通曉敏捷開發的基礎知識，那麼敏捷軟體開發在團隊中的實踐很可能變成讓人懊惱的制度性約束。那麼，以下這些知識可以說是敏捷軟體開發的核心。
開發原則
那麼，或許在某個場合，你聽說過「開閉原則」、或者「過度設計」之類的專業術語麼？的確，在某些人的口中，能夠說出這些詞彙的人並不多（只有一次在創新工廠參加面試的時候，面試的那個大牛問到了）。在我看來，作為乙個高階軟體開發者，這些技能應該是必須掌握的。
1：簡單設計
在當前的需求環境下，這樣的設計是最好的。
如果要寫乙個「hello，world」，你是會分析其業務邏輯，對邏輯進行拆分，然後寫成不同的類，最後組裝到一起？還是只是最簡單的方式，一句「printf」解決問題？當然，你可能會說，如果需求變更怎麼辦？比如輸出環境從原來的標準輸出，到現在的輸出到某個檔案，那麼這樣的設計是否合理？
那麼，請看假設：在當前的需求環境下。
這句話意味著，當前的需求環境是目前所有的需求，敏捷開發不處理過渡軟體設計。如果你只要我輸出乙個「helloworld」，那麼我絕對不會考慮未知的需求。
可能有疑惑了，敏捷軟體開發不是為解決需求頻繁變更的問題麼？倘若不過渡設計，那麼如何應對？
2：隨時重構
倘若需求變更，那麼重構就會被啟動。其實在實際開發中，只要發現軟體中的**冗餘或者設計「臭味」，都需要進行重構。
如上面的例子，當你寫了乙個最簡單的「helloworld」時，客戶提出了多種輸出方式的需求，那麼這個時候，將輸出部分進行提取和封裝，你可能會做乙個輸入的判斷，如：引數等，也會做對應的輸出的判斷。更有甚者，將輸入輸出部分進行提取，然後利用介面和基類的方式，同時定義基本方法和通用屬性，來滿足這種需求。
這樣的改動會造成**混亂和**冗餘。那麼啟動重構，根據設計原則（sip、ocp等，後面會說到）對**進行重構。
重構是隨時隨地進行的，時間間隔有時會是幾天，有時可能只有乙個小時，它的意義在於：它幫助殺死**冗餘。
3：開發原則
什麼是ocp（開閉原則）？什麼又是sip（單一職責原則）？這些內容傳統的軟體工程書籍似乎並未提到。敏捷開發中對軟體的擴張也是依賴這些原則進行的，尤其是**重構過程。
ocp（the open-close principle），開閉原則：軟體實體（類、模組、函式等）對擴充套件開放，對修改關閉。
簡單的說，當我們抽象出乙個基本類的時候，那麼這個抽象體一旦被確定，必須是不可修改的。在它之後的開發中，如果遇到功能的擴充套件或者變更，那麼要求只能對其擴充套件，如過載、多型等，而不能對其內部實體進行更改。
sip（single responsibility principle），單一職責原則：就乙個類而言，只有乙個引起它變化的原因。當軟體需要變更時，涉及到的類是否需要跟著變更？倘若是的，那麼它符合srp原則，類跟著變動；否則需要對類進行拆解。再通俗點，乙個類只解決一類問題，乙個方法只解決乙個問題。
另外，還有lsp（liskov替換原則）、dip（依賴倒置原則）、isp（介面隔離原則）等，依靠這些原則，重構的軟體重用性高，軟體耦合度低。
計畫
迭代（sprint）是scrum中使用的術語，它將一組龐大的需求，根據時間限度對其進行任務分解，同時保證在乙個迭代內需求不能變更。一次次的迭代產生持續整合，最終完成完整軟體。在開發過程中，需求相對與最初的需求可以變更，並且歡迎變更，但是在已經計畫好的迭代內需求被禁止變更！
任務（backlog）是開發中的具體事務。根據任務分解顆粒度（如以小時為單位），按照任務的耗時程度，每個任務應該在1~4個小時內完成。
立會（stand-up meeting）每天早上花費15分鐘左右進行立會，總結昨天做了什麼，今天要做什麼，遇到什麼困難。立會幫助團隊掌握開發進度。
反思會（retrospective）迭代結束後進行，回顧迭代中的內容，提出其中的意見並予以解決
敏捷開發原則
原則一 我們最先要做的是通過盡早的持續的交付，有價值的軟體來時客戶滿意，初期交付的系統中所包含的功能越少，最終交付的系統的質量就越高，交付的越頻繁，最終產品的質量就越高。原則二即使到了開發的後期也歡迎改變需求敏捷過程，利用變化來為客戶創造競爭優勢。原則三經常性的交付，可以工作的軟體交付的間隔可以從幾...
敏捷開發的原則
一 單一職責原則 the single responsibility principal srp 就是說盡量的單一化類的功能，不要使類具有多個功能。如果類具有多個功能時，任意乙個功能的修改都需要改寫這個類，也就會影響其他的類，而這些類根本沒有使用修改的這個功能。如果單一化功能，這種情況就可以避免。例...
敏捷開發 原則 模式與實踐 1
這的確是一本關於開發者的好書，對於我們開發者 研究人員，它提出了乙個開發的全新的價值觀 對我來說 甚至人生都有啟發。需要認真閱讀。書中總結了敏捷開發的例項，確確實實更夠感覺到對於專案的完成大有裨益，有種相讀恨晚的感覺。想想自己之前的開發狀態，想想自己導師安排公司專案的情況，就是低效率，就是小兒科，就...