敏捷軟件開發簡述

前言：因爲我讀了鄒欣老師的《構建之法:現代軟件工程(第二版)》，所以對敏捷軟件開發有了比較大的興趣。因而我在網上找了一些論文，好比Requirements Engineering and Agile Software Development、A decade of agile methodologies: Towards explaining agile software development。在讀了這些論文以後，對敏捷軟件開發有了大體的瞭解。這篇博文主要是簡單介紹敏捷軟件開發，重點集中在主要的敏捷開發方法和它的優點，同時也做爲一個備忘錄，來記錄我在這個過程當中收穫到的重要的知識。

目錄

1. 敏捷開發簡介

2. 傳統軟件開發方法的缺點

3. 敏捷的優點

4. 主要的敏捷方法

4.1 Scrum

4.2   極限編程（eXtreme Prgramming）

4.3   精益軟件開發（Lean Software Development）

5. 參考文獻

1.  敏捷開發簡介

    軟件工程一直是一項複雜的任務，而縱觀其歷史，軟件工程也發展出了許多不一樣的理論。從最開始的原始狀態，到逐漸成型的瀑布模型，軟件工程正在不斷髮展。在二十一世紀初，有專家又提出了敏捷開發的概念，而且這個概念在近些年來被大量實踐。所以，本博客將主要介紹敏捷軟件開發的優勢以及具體內容。

    敏捷不是某一種方法論、過程或框架，也不是字面意義上的敏捷，而是一組價值觀和原則。這些價值觀和原則由17位軟件開發領域的領軍人物在2001年經過《敏捷宣言》傳遞給世界，也在那個時候宣告了全球敏捷開發運動的開始。

敏捷宣言

    咱們經過身體力行和幫助他人來揭示更好的軟件開發方式。經由這項工做，咱們造成了以下價值觀：

個體與交互 重於 過程和工具

可用的軟件 重於 完備的文檔

客戶協做   重於 合同談判

響應變化   重於 遵循計劃

    在每組比對中，後者並不是全無價值，但咱們更看重前者。

敏捷12原則

1. 咱們的最高目標是，經過儘早和持續地交付有價值的軟件來知足客戶。

2. 歡迎對需求提出變動——即便是在項目開發後期。要善於利用需求變動，幫助客戶得到競爭優點。

3. 要不斷交付可用的軟件，週期從幾周到幾個月不等，且越短越好。

4. 項目過程當中，業務人員與開發人員必須在一塊兒工做。

5. 要善於激勵項目人員，給他們以所須要的環境和支持，並相信他們可以完成任務。

6. 不管是團隊內仍是團隊間，最有效的溝通方法是面對面的交談。

7. 可用的軟件是衡量進度的主要指標。

8. 敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該可以保持持續穩定的進展速度。

9. 對技術的精益求精以及對設計的不斷完善將提高敏捷性。

10. 要作到簡潔，即盡最大可能減小沒必要要的工做。這是一門藝術。

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

12. 團隊要按期檢討如何可以作到更有效，並相應地調整團隊的行爲。

　　符合敏捷價值觀及原則的主流敏捷開發方法包括：極限編程（eXtreme Prgramming），精益軟件開發（Lean Software Development），動態系統開發方法（DSDM）,Scrum等等。

2. 傳統軟件開發方法的缺點

　　傳統型軟件開發是基於「瀑布模型」的開發方式，以軟件架構爲核心，採用結構化設計以及分析方法將軟件生命劃分期限，而且開發進度按照從上而下的順序相互銜接，如同瀑布通常。瀑布模型是Winston Royce在1970年提出的一種軟件開發模型，其嚴格遵照計劃、分析、編碼、測試、維護的步驟。階段之間經過文檔流通，每一個階段結束時要進行嚴格的審查，檢查功能設計和實現是否符合上階段流下了的文檔的要求，若是不符合就逆流到上個階段檢查並修正，以此往復，直到流到最後階段產品經過測試後進行發佈及運行期間的維護。

圖1  瀑布模型開發過程

　　因爲各個階段須要文檔相互流通，在軟件開發前期就須要對整個軟件的架構進行設計。優秀的架構可使軟件足以支撐整個功能體系以及便於維護，而這樣優秀強大的框架一般須要在十分有經驗而且有着獨特眼光的架構師在徹底理解開發用戶的需求以後纔可能設計出，一般難度是較大。而且軟件的框架一旦肯定下來就很難改變，甚至會牽一髮而動全身，難以適應的客戶需求。此外，在軟件開發過程當中須要人員之間交流的並很少，每個階段對代碼的編寫或者測試都由文檔規定。因爲各個階段要自上而下相互銜接，各個階段的溝通要經過大量臃腫、複雜的文檔來傳遞信息。這樣的軟件開發一般會將每一塊的功能作的相對完善，而模塊之間的銜接以及充分理解文檔的時間將顯得很是長。

3. 敏捷的優點

    敏捷方法主要經過迭代過程來應對需求和技術的變化。在每一次迭代週期結束時，都應交付用戶一個可用的，可部署的系統，使得用戶能夠儘早的體驗系統並給予反饋。每次迭代週期應儘量短，以便能及時頻繁地處理需求變化和用戶反饋。

    採用敏捷開發方式將會給企業和用戶帶來諸多好處：

　 交付用戶須要的軟件。它將帶給用戶其真正須要的軟件系統。瀑布模式一般會在產品的起點與最終結果之間劃出一條直線，而後沿着直線不斷往前走。然而當項目完成時，用戶一般會發現終點已經不是他們真正的目的地。而敏捷方法則採用小步的方式前行，每走完一步，都須要及時調整並肯定下一步的方向，直到抵達真正的終點。

　 更高的質量。敏捷對迭代週期的產出有嚴格的質量要求。敏捷提倡使用測試驅動開發（test-driven development），即在正式開發功能代碼以前，先開發該功能的測試代碼。這爲敏捷項目的整個開發週期提供了可靠的質量保證。

　 更快的將產品推向市場。敏捷提倡避免大規模的前期計劃，認爲那是一種很大的浪費。由於不少預先的計劃的東西都會發生改變，大而全的前期計劃一般是徒勞的。敏捷提倡逐步完善的計劃。敏捷團隊只專一於開發項目中當前最須要的、最具價值的部分。這樣能儘早地投入開發，縮短產品上市的時間，或者說使得軟件能夠更早的交付使用。

4. 主要的敏捷方法

4.1     Scrum

　　Scrum最先由Jeff Sutherland在1993年提出，Ken Schwaber 在1995年OOPSLA會議上形式化了Scrum開發過程，並向業界公佈。目前Scrum是應用最爲普遍的敏捷方法之一。Scrum中的主要角色包括：

　　Scrum Master: Scrum教練和團隊帶頭人，確保團隊合理的運做Scrum，並幫助團隊掃除實施中的障礙；

　　產品負責人: 肯定產品的方向和願景，定義產品發佈的內容、優先級及交付時間，爲產品投資報酬率負責；

　　開發團隊: 一個跨職能的小團隊，人數5-9人，團隊擁有交付可用軟件須要的各類技能。

　　在每一次衝刺或迭代當中，開發團隊建立可用的軟件的一個增量。每個迭代所要實現的功能來自產品訂單。產品訂單按照優先級排列工做需求。在迭代計劃會議中，產品負責人告訴開發團隊須要完成產品訂單中的哪些訂單項。開發團隊決定在下一次迭代中他們可以承諾完成多少訂單項。在迭代的過程當中，沒有人可以變動迭代訂單，這意味着在一個迭代中需求是被凍結的。

圖2 scrum 過程

　　Scrum中經過三個活動進行檢驗和適應：每日例會檢驗Sprint目標的進展，作出調整，從而優化第二天的工做價值；Sprint評審和計劃會議檢驗發佈目標的進展，作出調整，從而優化下一個Sprint的工做價值；Sprint回顧會議是用來回顧已經完成的Sprint，而且肯定作出什麼樣的改善可使接下來的Sprint更加高效、更加使人滿意，而且工做更快樂。

4.2     極限編程（eXtreme Prgramming）

　　極限編程（eXtreme Prgramming），是一種軟件工程方法學。如同其餘敏捷方法學，極限編程和傳統方法學的本質不一樣在於它更強調可適應性而不是可預測性。極限編程的支持者認爲軟件需求的不斷變化是很天然的現象，是軟件項目開發中不可避免的、也是應該欣然接受的現象；他們相信，和傳統的在項目起始階段定義好全部需求再費盡心思的控制變化的方法相比，有能力在項目週期的任何階段去適應變化，將是更加現實更加有效的方法。極限編程規定了一些實踐和簡單規則，包括：編寫用戶故事、架構規範、實施規劃、迭代計劃、代碼開發、單元測試、驗收測試等等。

　　像全部其餘敏捷方法同樣，極限編程預期並積極接受變化。它具備如下的價值觀或原則：

　　互動交流。團隊成員不是經過文檔來交流，文檔不是必須的。團隊成員之間經過平常溝通、簡單設計、測試、系統隱喻以及代碼自己來溝通產品需求和系統設計。

　　反饋。反饋是一種信息的交流，能使系統更加完善。反饋也和交流密切相關，客戶的實際使用、功能測試、單元測試等都能爲開發團隊提供反饋信息。同時，開發團隊也能夠經過估計和設計用戶案例的方式將信息反饋給客戶。

　　簡單。極限編程提倡簡單的設計，簡單的解決方案。極限編程老是從一個簡單的系統入手，而且只建立今天可能須要的功能模塊。由於它認爲，建立明天須要的功能模塊可能會因爲需求的變化而成爲浪費。

　　勇氣。極限編程理論中的「系統開發中的勇氣」最好用一組實踐來詮釋。其中之一就是「只爲今天的需求設計以及編碼，不要考慮明天」這條戒律。這是努力避免陷入設計的泥潭、而在其餘問題上花費了太多沒必要要的精力。勇氣使得開發人員在須要重構他們的代碼時能感到溫馨。這意味着從新審查現有系統並完善它會使得之後出現的變化需求更容易被實現。另外一個勇氣的例子是瞭解何時應該徹底丟棄現有的代碼。每一個程序員都有這樣的經歷：他們花了一成天的時間糾纏於本身設計和代碼中的一個複雜的難題卻無所得，而次日回來以一個全新而清醒的角度來考慮，在半小時內就輕鬆解決了問題。

　　團隊。極限編程提倡團隊合做，相互尊重。極限編程以創建並激勵團隊爲一項重要任務。同時它把互相尊重和實際的開發習慣相結合。好比，爲了尊重其餘團隊成員的勞動成果，每一個人不得將未經過單元測試的代碼集成到系統中。所以，每一個人的代碼質量必須過關。

圖3 極限編程示意圖

4.3     精益軟件開發（Lean Software Development）

　　精益思想的核心思想是查明和消除浪費。在軟件開發過程當中，bugs，沒用的功能，等待以及其餘任何對實現結果沒有益處的東西都是浪費。浪費及其源頭必須被分析查明，而後設法消除。精益開發的其它原則包括:

　　強調學習。軟件開發過程是一個不斷學習的過程。每一個團隊成員都須要從平常的失敗，互動，交流以及信息反饋中學習，不斷改進所開發的產品和開發效率。

　　在最後時刻作決定。這樣能夠避免在可能改變的事情上作無謂的努力，從而有效的避免浪費。

　　用最快的速度交付用戶。較短的迭代週期可以加速產品的開發及交付，加快交流，提升生產力。

　　給團隊自主權。激勵團隊並讓全部團隊成員自我管理始終是全部敏捷方法得到成功的基本因素之一。

　　誠信。確保整個系統正常工做，真正知足客戶的需求是整個團隊須要努力堅持的誠信和和對用戶的承諾。

　　全局觀。精益開發強調總體優化的系統。不管開發的組織仍是被開發的產品， 從總體上考慮優化比從各個局部去優化更高效。

圖4 精益軟件開發原則

　　對於上述的每一個原則，都有一些相應的實現工具。這些工具包括價值流圖（Value Stream Mapping），基於集合的開發（set-based development），拉系統（pull system），排隊論（queuing theory），等等。和其它敏捷方法相比，精益軟件更重要的是不斷完善開發過程的一種思惟方式。所以，將精益模式與其餘敏捷開發模式一塊兒使用將會取得很好的效果。

5. 參考文獻

[1].      敏捷開發宣言 http://agilemanifesto.org/iso/zhchs/manifesto.html

[2].      敏捷開發十二條原則 http://agilemanifesto.org/iso/zhchs/principles.html

[3].      《構建之法:現代軟件工程(第二版)》 鄒欣

[4].      Scrum 維基百科 https://zh.wikipedia.org/wiki/Scrum

[5].      敏捷軟件開發 維基百科https://zh.wikipedia.org/wiki/%E6%95%8F%E6%8D%B7%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91

[6].      極限編程 維基百科 https://zh.wikipedia.org/wiki/%E6%9E%81%E9%99%90%E7%BC%96%E7%A8%8B

[7].      Dingsøyr, Torgeir, et al. "A decade of agile methodologies: Towards explaining agile software development." Journal of Systems and Software85.6 (2012): 1213-1221.

[8].      Paetsch, Frauke, Armin Eberlein, and Frank Maurer. "Requirements Engineering and Agile Software Development." WETICE. Vol. 3. 2003.