敏捷方法- 軟體業新思維

台灣軟體業積弱不振, 可能因思維較舊所致:
  1. 工廠思維: 軟體工程在 1968 NATO 大會出現時, 仿效其他工程領域, 把軟體視為工廠生產, 講求精細分工 嚴格控管 注意產量成本等. 但新趨勢是, 軟體講求創意及合作, 像 工藝家聯合工作室, 而不像工廠.
  2. 電機思維: 軟體本由電機電子而來, 從The Institute of Electrical and Electronic Engineers, Inc, IEEE 這代表性機構的名稱, 即可看出此沿革, 但演進至今, 軟體已與電機無關.
軟體業界深知軟體開發(含物件導向開發)需製作大量文件(含程式),構成龐大負擔,常導致很多溝通不準或思考不週之處 (即 Bugs)。有些公司製作不少文件卻乏人閱讀,全無溝通之效;甚 或冀望多年後維修程式時,將會閱讀文件,殊不知程式是不斷變動的,文件更新常趕不上變動的。

敏捷方法視開發為合作活動(如攀岩),力求以面對面直接溝通,來取代目前文件製作及閱讀的間接溝通,使開發變得快而準(即 agile)。 又,敏捷方法以測試來帶動開發 (Test-driven development),軟體品質極佳。

最後,除國外重視的溝通訓練外,吾人亦加強國人不足的思考訓練,溝通及思考乃深層基本功;–練功後人人紮實、軟體優質,再用逆向工程工具動態產生class diagram, sequence diagram等,有可能敏捷達 成CMMI 一些process areas 的 goals。 此敏捷方法係陳振炎教授擴充極限開發法 (extreme programming)而得,方法細節請見下面網站的上課教材:敏捷方法苗圃 (www.agilemethod.csie.ncu.edu.tw)

陳振炎教授
國立中央大學資訊工程系

留言

  1. 拜讀宏文,感覺提倡敏捷方法對發展台灣的軟體工業或有相當助益,不過要了解敏捷方法,不論是XP,TDD及其他方法,須先深入了解「敏捷宣言」(Agile Manifesto)的精神與哲學,否則無法了解敏捷方法的精髄,這一點文中似未著墨。敏捷方法的重點在於程式撰寫與測試上,這一點我認為須予延伸論述,撰寫程式在軟體工程發展軌跡上其抽象層次較低,因此有人提出結合agility與MDA,即所謂Agile MDA,Agile MDA主要是將模式視同程式,可用來執行,這個觀念解決不少(但非全部)軟工的問題,Agility可帶來effectiveness,而MDA可帶來efficiency,兩者結合可「活化」需求,這是最大的好處,我在「漫談模式驅動架構」三篇輕鬆談中曾有論及,另外agility對於軟體管理也有相當助益,這一點將來應有所討論,不知振炎兄可認同否?

    回覆刪除
  2. 我們會聽到這樣的話:"Agile development is a philosophy, not a methodology, but a set of values and principles."

    除非我們能夠瞭解並認同Agile方法的『精神』,否則 "just following a methodology" 可能對開發者而言沒有太大的幫助。如果不知道 agile methodologies中的程序背後的理由,那麼走極端可能又回到"code-and-fix"的『方法』了。

    回覆刪除
  3. 敏捷宣言確實揭開了軟工新時代 其背後的精髓就是: 溝通 這觀念用在 model driven architecture (MDA) 就叫 agile MDA

    依這觀念工作 人的思考方式與古早時 code and fix 是截然不同的

    回覆刪除
  4. 當你/妳要使用XP,TDD,Srum等敏捷方法時,腦袋必須常常想到敏捷宣言的精神,其中『溝通』只是其中第三項:"Customer collaboration ‧‧‧",由敏捷宣言引伸出12項「施行細則」更明白宣言的精神。Agility基本的『座右銘』(motto)就是"embrace change"(Kent Beck之言),也就是迅速而且彈性反應變更,再說如何迅速且彈性反應,據我所知,MDA是最有效而且安全的方法,因此我說Agile MDA可活化需求(live requirements)。我不太同意『溝通』用在MDA就是Agile MDA,因為MDA並非敏捷方法,它只不過能幫助敏捷方法容易達到『敏捷』的有效率的良方,之所以如此,請參考「漫談模式驅動架構(一),(二),(三)」。

    回覆刪除
  5. 由於陳教授認為軟體業績不振,乃因思維陳舊所致,本人十分認同這種說法,其原因可能許多人以「過程為中心」(process-centric)的發展思維所致,如果發展者,尤其管理者堅持這種思維,則可能產生所謂「隧道觀點」(tunnel-view),人們會忽略追縱建造系統的目標,無法有效率地符合客戶需求,因此敏捷方法的構想應該在於如何協助「人」而非「流程」,這是敏捷宣言最重要的一點,因此只要秉持"people over process"的精神,任何敏捷方法只要符合專案之需都是良方。在這個「意見」中我兩處使用可能語氣,一來我不十分確定我的觀點是否正確,二來希望能拋磚引玉,大家來輕鬆談陳教授所謂「軟體業新思維」這個嚴肅的議題。

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

TCSE 2017

加油站與小鎮