一段時間以來，由於學習的需要，涉及到了很多軟體系統分析與設計以及軟體體系結構相關的問題。而軟體系統開發流程中，不得不提到的，便是敏捷開發。

接下來，將由淺入深地來分析分析敏捷開發的基本概念，然後說明一下敏捷開發的代表–XP(極限程式設計)與Srcum過程。

敏捷開發概念與價值觀

敏捷開發運動歷史相對於整個軟體開發而言算是較為悠久的，其真正開始的標誌是01年2月提出的”敏捷宣言(Agile Manifesto)”，這項宣言由17位當時稱之為“輕量級方法學家”所編寫簽署的，他們的核心價值觀是:

以上來自於敏捷宣言的官方網站，敏捷宣言作為指導敏捷開發的核心思想，下面簡單地解釋一下其內容的基本含義。

• 個體和互動高於流程和工具。往往勤於溝通合作，目標明確的個人優秀的團隊比那些使用最高階工具的團隊做得更好，因為軟體產品是人完成的，中間有太多的不確定性，因此互動與個人能力對變化的適應性就顯得尤為重要；

• 工作的軟體高於詳盡的文件。能夠讓軟體能夠順利給使用者交付使用是最終的目的，並不在乎將專案開發的過程文件寫得多麼漂亮，由於敏捷開發注重效率，而如此耗時的工作在後期並沒有很好的效益。

• 客戶合作高於合作談判。讓客戶參與到軟體開發的過程中，能夠更好地瞭解客戶的需求。

• 響應變化高於遵循計劃。軟體開發的過程中，往往會有諸如需求，設計等的改變，對於傳統的瀑布模型將軟體開發定義地過於死板，不具有對變化的適應性，開發出來的產品很可能並不是滿足需求的“高質量”產品。

敏捷開發特徵總結

關於敏捷開發的特徵問題，網上已經有相當多的介紹資源，以下僅僅按照個人的體會針對一些與傳統開發方式差異較大的部分進行總結。

• 以瀑布模型為代表的開發方式有著嚴格的過程化，沒有較強的響應變化的能力，不利於瞭解使用者變化的真正需求。而敏捷開發實際上是測試驅動的。瞭解了使用者的需求之後設計測試用例，編寫測試程式碼，如果產品能夠通過所有測試，那麼其就是一個可以release的版本。

• 敏捷開發的主要文件是測試文件。傳統的開發過程中特別看中需求分析，設計與實現等部分的文件，而敏捷開發則更為注重測試文件。其本質原因是因為敏捷開發的過程中，伴隨著極其快的軟體版本迭代，如果注重實現等的文件，很容易產生程式碼修改不一致的問題。而如果以測試文件為主要文件，則便於專案的管理。同時也可以減輕團隊成員調整帶來的學習成本。

• 敏捷開發以合作為中心，也就是實現程式碼共享。敏捷開發過程的程式碼不是為一人所有，任何人都有權利看到所有程式碼並原則上允許修改所有程式碼，並不需要徵得原作者同意。這在很大程度上就降低了人員調動所帶來的風險。

• 敏捷開發要求開發人員的水平基本相當，一般而言，較高。由於敏捷開發的程式碼共享性以及程式碼的高需求適應性，其對開發人員的整體水平要求較高，同時開發人員之間的水平基本相當。

敏捷開發典型代表

當下用得比較多的，有兩類敏捷開發的方法。一類是XP(極限程式設計)，另外一類是Scrum。由於兩者都是基於敏捷開發價值觀的具體實現，因此下面簡單地談談兩者之間的差異。

區別之一： 迭代長度的不同

XP的一個Sprint的迭代長度大致為1~2周, 而Scrum的迭代長度一般為 2~ 4周.

區別之二: 在迭代中, 是否允許修改需求

XP在一個迭代中，如果一個User Story(使用者素材, 也就是一個需求)還沒有實現， 則可以考慮用另外的需求將其替換， 替換的原則是需求實現的時間量是相等的。 而Scrum是不允許這樣做的，一旦迭代開工會完畢, 任何需求都不允許新增進來，並有Scrum Master嚴格把關，不允許開發團隊收到干擾。

區別之三: 在迭代中，User Story是否嚴格按照優先級別來實現

XP是務必要遵守優先級別的。 但Scrum在這點做得很靈活， 可以不按照優先級別來做，Scrum這樣處理的理由是： 如果優先問題的解決者，由於其它事情耽擱，不能認領任務，那麼整個進度就耽誤了。 另外一個原因是，如果按優先順序排序的User Story #6和#10，雖然#6優先順序高，但是如果#6的實現要依賴於#10，則不得不優先做#10.

區別之四:軟體的實施過程中，是否採用嚴格的工程方法，保證進度或者質量

Scrum沒有對軟體的整個實施過程開出養個工程實踐的處方。要求開發者自覺保證，但XP對整個流程方法定義非常嚴格，規定需要採用TDD, 自動測試， 結對程式設計，簡單設計，重構等約束團隊的行為。因此，原作者認為， 這點上，XP的做法值得認同的，但是卻把敏捷帶入了一個讓人困惑的矛盾, 因為xp的理念，結合敏捷模式，表達給團隊的資訊是“你是一個完全自我管理的組織， 但你必須要實現TDD, 結對程式設計, …等等”

不難發現，這四個區別顯見的是： Scrum非常突出Self-Orgnization, XP注重強有力的工程實踐約束。

一般建議， 在管理模式上啟用Scrum， 而在實踐中，創造一個適合自己專案組的XP(“start with Scrum and then invent your own version of XP.”)

總結

通過對敏捷開發相關理念以及突出特點的瞭解，個人覺得其思想是一種很不錯的正規化。後續承擔的某專案本人將嘗試使用敏捷開發。

參考文獻