下面的文字來自于《敏捷軟件開發 原則、模式和實踐》一書,作者是Robert C. Martin。我把這些文字發布在這里,希望對敏捷軟件開發還不是很了解的朋友所有幫助。我推崇這本書,是因為它提出了許多有價值的軟件項目管理的理念,以及軟件設計思想和方法,其中,很多可以直接用在我們的工作中,或用來指導我們的工作----敏捷軟件開發是務實的。
一、敏捷軟件開發宣言
我們正在通過親身的實踐以及幫助他人實踐,揭示更好的軟件開發方法。通過這項工作,我們認為:
個體和交互 勝過 過程和工具
可以工作的軟件 勝過 面面俱到的文檔
客戶合作 勝過 合同談判
響應變化 勝過 遵循計劃
雖然右項也有價值,
但我們認為左項具有更大的價值。
二、敏捷宣言遵循的原則
我們遵循以下原則:
我們最優先做的是通過盡早的、持續的交付有價值軟件來使用客戶滿意。
即使到了開發的后期,也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
經常性地交付可以工作的軟件,交付的間隔可以從幾個星期到幾個月,交付的時間間隔越短越好。
在整個項目開發期間,業務人員和開發人員必須天天都在一起工作。
圍繞被激勵起來的個體來構建項目。給他們提供所需的環境的支持,并且信任他們能夠完成工作。
在團隊內部,最具有效果并有富有效率的傳遞信息的方式法,就是面對面的交談。
工作的軟件是首要的進度度量標準。
敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恒定的開發速度。
不斷地關注優秀技能和好的設計會增強敏捷能力。
簡單----使未完成的工作最大化的藝術----是根本的。
最好的架構、需求和設計出自于自組織的團隊。
每隔一段時間,團隊會在如何才能更有效地工作方面進行反省,然后相應的對自己的行為進行調整。
三、面向對象設計的原則
SRP 單一職責原則
就一個類而言,應該僅有一個引起它變化的原因。
OCP 開放-閉合原則
軟件實體(類、模塊、函數等)應該是可以擴展的,但是不可修改。
LSP Liskov替換原則
子類型必須能夠替換掉它們的基類型。
DIP 依賴倒置原則
抽象不應該依賴于細節。細節應該依賴于抽象。
ISP 接口隔離原則
不應該強迫客戶依賴于它們不用的方法。接口屬于客戶,不屬于它所在的類層次結構。
REP 重用發布等價原則
重用的粒度就是發布的粒度
CCP 共同封閉原則
包中的所有類對于同一類性質的變化應該是共同封閉的。一個變化若對一個包產生影響,則將對該包中的所有類產生影響,而對其他的包不造成任何影響。
CRP 共同重用原則
一個包中的所有類應該是共同重用的。如果重用了包中的一個類,那么就要重用包中的所有類。
ADP 無環依賴原則
有包的依賴關系圖中不允許存在環。
SDP 穩定依賴原則
朝著穩定的方向進行依賴。
SAP 穩定抽像原則
包的抽象程序應該和其穩定程序一致。
四、極限編程實踐
1、完整團隊
XP項目的所有參與者(開發人員、業務分析師、測試人員等)一起工作在一個開放的環境中,他們是同一個團隊的成員。這個場所的墻壁上隨意懸掛著大幅的、顯著的圖表以及其它一些顯示他們進度的東西。
2、計劃游戲
計劃是持續的、循序漸進的。每2周開發人員就要為下2周估算候選特性的成本,而客戶則根據成本和商務價值本選擇要實現的特性。
3、客戶測試
作為選擇每個所特性的一部份,客戶定義出自動驗收測試來表明該特性可以工作。
4、簡單設計
團隊保持設計恰好和當前的系統功能匹配。它通過了所有的測試,不包含任何重復,表達出了編寫者想表達的所有東西,并且包含盡可能少的代碼。
5、結對編程
所有的產品軟件都是由兩個程序員、并排坐在一起在同一臺機器上構建的
6、測試驅動開發
程序員以非常短循環周期工作,他們先增加一個失敗的測試,然后使它通過。
7、改進設計
隨時改進糟糕的代碼。保持代碼盡可能的干凈,具有表達力。
8、持續集成
團隊總是使系統完整地被集成。
9、集體代碼所有權
任何結對的程序員都可以在任何時候改進任何代碼
10、編碼標準
系統中的所有代碼看起來好像是被單獨一個--非常值得信任的--人編寫的
11、隱喻
團隊提出一個程序工作原理的公共景象
12、可持續速度
團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作。他們保存精力,他們把項目看作是馬拉松長跑,而不是全速短跑。
原文轉自:http://www.kuqin.com/shuoit/20130916/335244.html