敏捷開發原則

~學點新東西

 

敏捷開發原則

 

1.儘早的,經常性的進行交付。努力在項目剛開始的幾周內交付一個具有基本功能的系統,然後努力堅持每兩週就交付一個功能漸增的系統。
2.團隊努力保持軟件結構的靈活性。這樣能夠歡迎需求的變化(變化可以爲客戶創造競爭優勢)。因此要學習面向對象設計的原則和模式,這會幫助我們維持這種靈活行。
3.要經常性交付軟件,並且是可以工作的軟件。週期越短越好。不贊成交付大量文檔。
4.業務人員和開發人員要進行頻繁的交互,天天一起工作。
5.圍繞被激勵起來的個人來構建項目,改變對團隊工作的阻礙的過程步驟。
6.在團隊內部,最有效果並且富有效率的傳遞信息的方法,就是面對面的交談,而非文檔。
7.工作的軟件是首要的進度度量標準,而不是那些基礎結構或者文檔。
8.保持一個長期和恆定的開發速度。儘量不要拖延和加班,要善於調整速度完成高質量的標準。
9.關注好的設計和技能,編寫高質量的代碼。如果今天製造了混亂,不要拖到明天去清理。
10.簡單。不要預測明天的問題。高質量完成今天的工作,深信如果明天發生了問題,也會狠容易的處理。
11.每一個成員都具有項目中所有方面的參與勸。最好的構架、需求和實際來自於自組織的團隊。
12.每個一段時間,團隊會在如何才能更有效的工作方面進行反省,然後對自己的行爲進行調整。

 

 

原則

1.        我們最優先要做的是通過儘早地、持續地交付有價值的軟件來使客戶滿意。

2.        我們歡迎需求的變化,即使到了開發後期。敏捷過程能夠駕馭變化,爲客戶創造競爭優勢。

3.        經常交付可以工作的軟件 ,從幾個星期到 幾個月,時間間隔越短越好。

4.        在整個項目開發期間,業務人員和開發人員必須朝夕工作在一起。

5.        圍繞鬥志昂揚的人構建項目。給他們提供所需的環境和支持,並且信任他們能夠完成工作。

6.        在團隊內部,最有效率也最有效果的信息傳達方式,就是面對面的交談。

7.        可以工作的軟件是 進度主要的度量標準。

8.        敏捷過程提倡可持續開發。出資人、開發者和用戶應該總是保持穩定的開發速度。

9.        對卓越技術和良好設計的不斷追求有助於提高敏捷性。

10.    簡單——儘量減少工作量的藝術是至關重要的。

11.    最好的架構、需求和設計都源於自我組織的團隊。

12.    每隔一定時間,團隊都要總結如何更右效率,然後相應地調整自己的行爲。

極限編程實踐

   完整團隊             用戶故事             短交付週期        驗收測試             結對編碼             測試驅動開發  

   集體所有權        持續集成             可持續的開發速度         開放的工作空間              計劃遊戲

   簡單設計             重構       隱喻

避免設計的臭味

·         僵化性 rigidity ——設計難以改變。

·         脆弱性( fragility )——設計易於遭到破壞。

·         頑固性( immobility )——設計難以重用。

·         粘滯性( viscosity )——難以做正確的事情。

·         不必要的複雜性( needless complexity )——過分設計。

·         不必要的重複( needless repetition )——濫用鼠標進行復制、黏貼。

·         晦澀性( opacity )——混亂的表達。

設計原則

·         單一職責原則( SRP ):一個類應該只有一個發生變化的原因。

·         開放封閉原則( OCP ):軟件實體應該對擴展開放,對修改關閉。

·         Liskov 替換原則( LSP ):子類型( subtype )必須能夠替換掉它的基類型( base type )。

·         依賴倒置原則( DIP ): a. 高層模塊不應該依賴於低層模塊。二者都應該依賴於抽象。 b. 抽象不應該依賴於細節。細節應該依賴於抽象。

·         接口隔離原則( ISP ):不應該強迫客戶程序依賴並未使用的方法。

·         DRY Don’t repeat yourself Principle 。通過抽取公共部分放置在一個地方避免代碼重複。

·         封裝變化 Encapsulate what varies )。

·         面向接口編程而不是實現( Code to an interface rather than to an implementation )。

·         優先使用組合而非繼承( Favour Composition Over Inheritance )。

包和組件的設計原則

  • 重用-發佈等價原則(Reuse-Release Equivalence Principle, REP):重用的粒度就是發佈的粒度。
  • 共同重用原則(Common-Reuse Principle, CRP):一個組件中的所有類應該是共同重用的。如果重用了組件中的一個類,那麼就要重用組件中的所有類。
  • 共同封閉原則(Common-Closure Principle, CCP):組件中的所有類對於同一種性質的變化應該是共同封閉的。一個變化若對一個封閉的組件產生影響,則對該組件中的 所有類產生影響,二對於其他組件則不造成任何影響。
  • 無環依賴原則(Acycle-Dependencies Principle, ADP):在組件的依賴關係圖中不允許存在環。
  • 穩定依賴原則(Stable-Dependencies Principle, SDP):朝着穩定的方向進行依賴。
  • 穩定抽象原則(Stable-Abstraction Principle, SAP):組件的抽象程度應該與其穩定程度一致。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章