敏捷軟件開發(Agile Software Development)的上位史
所謂敏捷,最常見的用法,便是用來形容動作的迅速與思維的活躍了,但若是給“軟件開發”這個計算機行業的術語強行戴上一個“敏捷”的帽子,讀者見了十有八九會一臉懵逼:厲害了我的哥,軟件開發怎么還能“敏捷”了?
從上面的漫畫可以看出,“敏捷軟件開發”並不是要求開發人員練出像猴一樣的敏捷身手(當然如果讀者真的是一位身手敏捷的程序“猿”,那就更好不過了),而是一種在最近十幾年才開始慢慢流行起來的新型的軟件開發的理念,下面將分版塊對其進行介紹,並將其與傳統的軟件工程在多方面的比較穿插其中。
<目錄>
進入上個世紀60年代,“軟件危機”的說法開始盛行,存在着軟件生產不能滿足市場需要、開發成本和開發進度估計不准確、開發人員之間交流不充分、客戶對軟件的滿意度低、軟件可維護性差等亟待解決的問題,而這些問題出現的重要原因之一,便是軟件人員的開發模式未能工程化,因此傳統的軟件工程在人們的千呼萬喚中誕生了。
傳統的軟件工程要求在開發過程中,應該根據不同時期的需要,將工程划分為前后有序的明確步驟,並在強有力的管理下依次完成。一般包含以下八個階段:可行性研究與計划、需求分析、概要設計、詳細設計、實現(包括單元測試)、組裝測試(即集成測試)、確認測試、使用維護。並且在工程的進行過程中,需要撰寫大量的文檔,例如:可行性研究報告、項目開發計划、軟件需求說明書、用戶手冊、操作手冊、測試分析報告、項目開發總結報告等。這些文檔有效地串通了業務人員、開發人員與管理人員,並且顯著降低了每個開發步驟的錯誤率,即使存在錯誤,也能夠通過分析文檔進行快速的定位修改,因此工程的開發過程更加條理化、系統化、工程化,生產出來的產品也更加穩定。
瀑布模型是一種典型的傳統軟件工程的開發思想,由W.Royce在1970年提出。下面以瀑布模型為例來簡要說明一下傳統軟件工程的應用。瀑布模型的開發過程是有固定順序的,並且每一階段的的輸入是由上一階段的輸出得來,因此也就意味着之前的工作沒有完成,是不能夠繼續進行下一階段開發的。因此,應用瀑布模型思想進行開發,雖然比較穩定,而且需求明確,但是由於其耗時長、任務順序固定、越往后越難糾錯、不能應對需求變化等缺點,使得開發人員開始找尋一條新的、適合於當今社會背景的開發之路。
敏捷軟件開發思想的根基在於將大的項目划分為多個相互聯系、可以獨立運行的小項目,並且在項目期間加強與客戶的交流合作,實時反饋並根據反饋內容實時修改開發計划。比起傳統的軟件工程,它更加強調面對面的溝通、頻繁交付新的軟件版本、更好地適應需求的變化以及重視人在軟件開發中的作用。
隨着客戶需求的變化日益頻繁,敏捷開發的本質使得它的出現幾乎成為了一件板上釘釘的事情。2001年,全世界范圍內的敏捷開發的愛好者聚集在了美國猶他州的雪鳥,組成了敏捷聯盟,並提出了自己的開發原則。自此,敏捷開發者正式擁有了一個像模像樣的組織
下面是敏捷開發的12條英文原則,以及自己在細讀原則后的幾點分析(其中包含了敏捷開發與傳統軟件工程的對比):
1.Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
我們應該根據客戶對功能的需求,首先為客戶提供最有價值的功能。這也就是說,敏捷開發能夠在開發的每一步看到並且運行已有的成果,而並不是像傳統的軟件工程那樣,只有等到整個工程結束后才可以看到成果如何,通過頻繁的迭代能夠在早期與客戶形成良好的合作,並得到反饋來及時調整自己的開發計划。
2.Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
敏捷開發的參與者不怕需求的變化,相反地,他們認為有需求變化是好事,因為這能夠充分發揮敏捷開發的優勢,畢竟傳統的軟件工程是不支持頻繁改變的需求的,因此這既是挑戰,也是機遇。
3.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
減小迭代的時間間隔,並將階段性的成果頻繁交付給客戶,讓客戶在每一階段都能夠有軟件可用,這樣能夠使得用戶提前體驗到已有的功能,增加客戶對開發人員的信賴程度,並且便於客戶根據現階段能夠看到的功能,對軟件的未來提出新的期許。
4.Business people and developers must work together daily throughout the project.
業務人員和開發人員應該每天都在一起工作,正所謂隔行如隔山,開發人員懂得如何開發,卻不懂得業務人員的使用習慣。這樣,每當程序員實現一個功能之前,都去吸收一下業務人員的建議,這樣能夠使得最終設計出來的軟件,受到更廣泛的業務人員的歡迎概率大大增加。
5.Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
比起傳統的軟件工程,敏捷開發更加注重以人為本,認為給開發人員提供一個適宜的環境,相信他們的工作並且在他們需要的時候提供強有力的支持,更能夠鼓舞人心,在這種積極的環境中,能夠想象到的最終結果一定是皆大歡喜的“提前N天結束,並超額完成任務”!
6.The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
面對面的交流比起其他的方式更有效率。敏捷開發的人員數量一般不會很多,因此比起通過文檔交流,湊在一起嘮個嗑會是更有效率的交流方式(當然,大家都得克制自己,在工作的時候少說或者不說題外話,否則,一天過去了,只寫了一個HelloWorld也不是沒有可能)。
7.Working software is the primary measure of progress.
比起傳統軟件工程不好計量工作進度的特點,敏捷開發由於能夠在不同的開發階段實現新的功能,因此更容易計量,在進度能夠量化的體系中,員工的效率更容易保持在一個較高的水平。
8.Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
開發者應該被允許在一個比較恆定的速度上開發。這個問題在國內的某些企業尤其嚴重,過多的加班使得員工的身體和精神隨時處於崩潰的邊緣,並且養成了“突擊”的意識。實際上,為了提前做完工程而使員工一直超負荷工作是不明智的,因為這樣會大大降低他們的工作興趣,並且產生一些消極的抵抗心理。
9.Continuous attention to technical excellence and good design enhances agility.
這句話正好驗證了中國的一句老話:活到老,學到老。作為一名開發人員,永遠不能自大,因為沒人敢說自己已經精通了所有的技能,或者能夠解決所有的問題,一定要懷着一顆謙遜的心,多看書,看好書。
10.Simplicity--the art of maximizing the amount of work not done--is essential.
在構建某一階段的工作模型的時候,不要過於復雜,實現最初期望實現的功能就好,因為客戶的需求是可能隨時改變的,一開始就構建一個完整的框架很可能會拖慢整體的進度。像是兩個在火災現場逃生的人,其中一個只以當前最迫切的逃生為目的,而另一個顧慮的比較多,想着逃生的同時,卻還想着拿點財物出去方便今后的生活。相比較而言,前者更容易逃生,后者能逃出來固然是好的,如果逃不出來,那之前的所有“為了未來更好生活”的計划便真的是一點意義也沒有了。
11.The best architectures, requirements, and designs emerge from self-organizing teams.
自組織團隊是敏捷開發的標志性特征之一,自組織團隊比起傳統的軟件開發團隊來說相對自由,團隊的凝聚不是靠管理者的管理,而是靠團隊文化對每個成員潛移默化的影響。自組織團隊的成員能夠更加自由地發表自己的見解,當然這條原則也經常是敏捷開發反對者們攻擊的對象,畢竟在他們看來,沒有的管理層的團隊更像是一盤散沙。
12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
反思是進步的前提工作,由於敏捷開發提高了軟件開發中人的作用,因此軟件項目在開發時,受成員的主觀影響非常大,出現錯誤的地方也是千差萬別。因此,團隊成員應該習慣在一個階段結束的時候,反思之前的工作,並為今后的開發提供更加合理的建議,以此來保持團隊的敏捷性。
在上世紀六七十年代,軟件行業從無到有地慢慢發展起來,但是由於當時尚處於啟蒙階段,落后的制造技術、復雜的操作以及高昂的成本使得軟件還無法面向普通民眾推廣,而是只能用在某些大型的、國家控制的行業中,像是宇航業、導彈業等等,而這些行業的第一要素顯然是高准確度與高安全性,因此,傳統的以瀑布模型為代表的軟件開發理念以其比較穩健的、不易改變的特性而備受青睞。直到現在也是這樣,對軟件的可靠性與質量有極高要求,而且需求固定(或者不頻繁變化)的行業,還是以傳統的軟件工程設計思想為主。
隨着時代的發展,如今家家戶戶都有自己的電子設備,開發面向大眾的軟件已是眾望所歸。比起之前所說的那些國家組織開發的高精度項目,這些面向大眾的軟件在復雜程度的層級上一般要遠遠低於前者,安全性要求也沒有那么高,但是突出了客戶的個性化需求,並且存在着客戶在開發的不同階段變更要求的可能性。因此,相比較而言,更經常與客戶進行交流,且對客戶的需求變化也能積極應對的敏捷軟件開發在此類情景中更占優勢。
敏捷軟件開發與傳統的軟件工程都有各自的優缺點與適用范圍,因此開發團隊可以根據自己的需要來選擇應用哪個開發思想,但是在選擇之前一定要根據自己團隊的現實情況來做充分的評估。
近些年,一股“敏捷熱”席卷而來,很多人甚至把敏捷開發狂熱化了。在我看來,這確實有些過了,因為技術與市場發展到一定程度,隨之產生新的思想是一種正常的規律,而新的思想也會被多年后更加新穎的思想所取代,只要社會還是發展的,更新便會永無止境。因此,在看待一個新興事物時,務必要多方面去看待,並從自己的角度去理解新技術、新思想的本質,切不可道聽途說。
引用:
[1]百度文庫《傳統軟件工程概述》
http://wenku.baidu.com/link?url=V8U0ajvchEcDhAK-EMImWHHxAbkn7EeQ4WoVAOgqL9jvpM-z0YMhvYAKwfsqctm8mBAQCtkrblCXTScC-_f8qc6zbhYeDNjM8epjFypLNg_
[2]wikipedia:Agile software development
https://en.wikipedia.org/wiki/Agile_software_development
[3]所有圖片來源於必應
http://cn.bing.com/images/trending?FORM=ILPTRD
2016-10-18 22:07:47