專刊內文

當前位置:首頁>專刊分享>內文

瀏覽次數 : 4765



 

淺談敏捷式開發

Andy Kao

                                                   
前言

近年來,軟體工程技術日益複雜,方法論也越來越多,如何在有限的資源與預算,去滿足功能上需求又能確保一定的品質與如期交付,看來似乎是越來越難了;科技的進步並沒有帶來更容易的開發環境與開發方法,相反的,卻是漸行漸遠,遙不可及。

為何會如此呢?主要還是因為進步所產生的變動關係,因為這些變動(如作業系統的網路環境)必須使用新的技術與方法,而這些新的技術與方法都是必須重新的學習與適應,一個新的技術引入到成熟,往往要花上2到3年,還必須視項目的大小與成員多寡。除了環境本身的複雜性,使用的體驗與要求也是日益升高,這也讓軟體工程步入不可逆的深淵當中的重大原因。

影響我們開發者最深的不外乎開發語言與工具,重點也不在開發語言,畢竟學習一種新的語言其實很快也不難;問題是大家的資源都是不足的,人力短缺,一個系統不可能有專職的PM,專職的SA/SD人員,專職的開發與測試人員,大家能省就省,一個人當作多人使用。這樣問題就來了,PM與SA/SD工具沒有因為科技的進步差距過大,但開發工具就會差距很大了,因為無法專職就無法將開發工具學得透徹與成熟,開發工具就以目前市面上Java或.net兩大陣營來說,除了龐大如恐龍之外,版本變化也很快,如此造就了目前軟體工程的生產力低落的困境。


何謂敏捷式開發

有沒有一些方法可以改善這個生產力低落的問題呢?敏捷式開發就是用來解決這個問題的方法之一。所謂敏捷式開發,(Agile Development)是一種開發的精神與方法,適合較短的開發週期的軟體項目,以漸進式開發方式來交付。也就是說,希望軟體項目的開發過程中,包含計畫、需求、設計、成果等都會隨著項目進行當中逐次的漸漸完整,而非在一開始將所有的計畫與需求擬定完成。

敏捷式開發目的是用來應對快速變化需求的軟體開發能力,他並非是一個制式的開發方法,而是一種軟體開發的精神(spirit),只要能滿足這種漸進式且允許需求變動頻繁的精神即可,這很像之前的雛形設計法,先讓使用者可以看到具體的外觀再往下做細部的開發;而與敏捷式開發的差異在於交付不僅是雛形更是部分成果,能讓使用者感受到進度與真實體驗。

敏捷式開發是有明確的精神定義,限於篇文我們只簡單扼要來說明重點如下:

 1.    工作成員互動勝於流程與工具的管理,代表"充分溝通"重於一切。

2.     工作產生的軟體結果勝於廣泛而全面的文件,因為結果是最重要的,當然不代表不用做文件。

3.     與User或客戶的合作勝於契約的談判,目標一致和平共處在軟體項目中是多麼重要的一件事。

4.     回應變動勝於遵循計畫,上有政策下有對策是對的,但要積極有效,勇於面對變動到歡迎變動,永遠不說NO,說得容易,執行起來還是很困難的。

5.     精簡或未完成工作的最佳化之技巧是不可或缺的,將複雜的事做得更簡單, 做得更快就是敏捷式的重點。

6.     頻繁的交付工作產生的軟體,從數週至數月,週期越短越好,分批交付將帶給User極大的信心。
 

敏捷式開發與其他模式比較

從上述的敏捷式開發精神來看,這種不嚴謹又不重視文件與制度的方法論,似乎與國內軟體界熱衷一時的CMMI軟體品質評量有極大的衝突性,CMMI並不是沒有必要,要看軟體項目的規模與品質指標,更要看開發的成本與預算,另一項重要的指標就是方法導入的容易度。當然,也不代表魚與熊掌不能兼得,也可以按照自己團隊的特性,各取其優點捨其缺點,如可以在CMMI的模式中選擇部分項目引用敏捷式開發模式來簡化管理,達到更有效率的目的等。

如果再與傳統的瀑布式方法比較,後者主要問題是過於嚴格分階段導致的自由度降低,項目早期就要完整分析各種需求且希望不要有任何需求變動,如此變得不太實際,過程中如果經常有需求變更都會導致一連串的災難,代價高昂。相對來講,敏捷方法卻是不必這個嚴謹,隨時可以承受需求變更,並做適當的應對與改變;等於是一個是要求需求不能被改變,另一個是需求可以被改變而且是歡迎改變,這樣用戶的滿意度當然會差距很大。


如何導入敏捷式開發

導入敏捷式開發方法,最有名有Scrum、XP兩種方法,在VS2010中也有Agile Scrum的開發模式,由於國內的軟體開發團隊大都不大,90%以上都在10個人以下,所以真正能適合導入這些方法論的團隊應該也不多,加上導入這些模式都必須要有經驗Agile導入教練與專家,否則很難有顯著的成效。

為了避免空談理論,針對中小型的項目與小的團隊來說,筆者認為具有Agile精神的開發工具可能才是重點,畢竟開發成本與時限將是重點所在,但往往現今的開發工具不但複雜龐大,更因為功能過於繁多而難以學習與導入。

那怎樣開發工具才能具備敏捷開發的精神了,以下為筆者拙見:

 1.    開發速度要快速:速度快是工具的本能,而不是憑藉開發者的經驗,Wizard式或Click-One應該是快的關鍵,可以快速開
        發出雛型迅速交付使用者進行規格討論與改善。

2.     學習導入要快速:學習的成本也很重要,畢竟成員的變動是存在且不可避免, 如何在成員變動之下,能快速進入狀況也是很重要。

3.     所見及所得:不管是服務模組或外觀模組,都必須能夠所見即所得的方式, 讓開發團隊可以用最直覺的方式來開發,快速之外而兼具容易維護的特性。

4.     能讓SA直接開發使用:系統的開發可以從SA與SD開始一貫化作業,一直到系統開發完成都是在同一套工具內,這樣可以讓SA或SD人員以工具完成80%以上的工作,剩下的20%再交給開發者去細微調整,除了可以節省人力降低因SA/SD與開發人員溝通不足所產生的差異。

5.     小而美更簡捷:開發工具並不是功能越多越強大越好,因為多與強大的後果將會導致操作複雜或難以學習,所以工具如何呈現重點功能,並可以簡捷的發揮生產力,最後再以傳統的方式增加彈性能力即可。

6.     自動輸出文件:如果說敏捷式開發可以不太重視文件而重視成果的話,也不代表不需要文件或不重要;因此,如果工具可以隨時幫忙代勞將最新的成果自動輸出成系統文件,那就真的可以不必在乎了。


結論

這幾年軟體工程的發展說了太多的軟體品質與方法論,但相對對於軟體生產力與成本控制較少人重視,可能也是較難以控制的原因;多數的團隊光只是針對問題解決問題就疲於奔命了,更別想說去開發新的系統滿足新的功能,時代的進步卻沒有帶給軟體工程也帶來進步,即使Agile這樣概念行之多年,但也很難被真實的成功引用與導入,隨著雲端時代的來臨,新的雲端技術與服務念興起,衷心盼望,開發工具可以朝向Agile的思維前進,讓軟體的開發更為便捷快速,讓開發的工作可以更為順手,讓使用者的變更可以讓我們大膽的跟他們說;「 yes,we can!」