淺談敏捷式開發

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！」