輕鬆談軟工

一夥程式設計師正在啟奏當今皇上。『今年有什麼偉大的成就嗎？』皇上問道。 程式設計師私下討論了一會兒，然後回話：『比起去年，我們今年多修正了50% 的Bug』 皇上滿臉困惑的看著他們。他們顯然並不知道『Bug』是什麼。他低聲與宰相商量一會兒，然後轉向這些程式設計師，面露慍色。『你們犯了品質管制不良之罪。明年起不得在有任何的Bug！』他當庭宣下這道聖旨。 當然啦，明年當這夥程式設計師再度向皇上奏報時，就完全不提 Bug 的事了。 以上是取自 G.M. Weinberg 的著作 Quality Software Management v1: System thinking 的中譯本： 軟體管理學-系統化思考 內的一個小故事。Prof. Wenberg 是我個人滿喜歡的一位軟體工程作家，他總是能用淺顯易懂的小故事道破許多軟體工程的問題。把這本好書推薦給大家，有空的話真的可以好好看看。

自從2002年Scott W. Ambler寫了一本叫" Agile Modeling - Effective Practices for eXtrem Programming and the Unified Process "以來，Agile Modeling(AM)的觀念與方法逐漸大行其道，由於AM的觀念可用之於各種物件導向軟體發展方法上，因此希望來輕鬆談談AM這種方法論(methodology)，以收拋磚引玉之效，同時也呼應『目』與『F』那篇文章。這篇文章所談的大部分來自Ambler的說法，我只不過摘要式地加以闡述，但仍然可做為軟體工程師創製模式時借鏡。 依照Ambler的定義，AM是一種渾沌、實用為基礎的方法論，其有效地用於模式化與文件化軟體系統，「渾沌」(chaordic)一詞可說道盡AM的精神，依個人的詮釋是「不受限但處理的事物漸趨規則」之意，也就是說，規則來自於渾沌的演進，至於此地所說的方法論(methodology)並非指發展軟體的方法，而是指每天由軟體專家們應用的一些常規(practices)，這些常規依照AM原則與真義(value)而定。Ambler依他的經驗，擬定了核心與補充原則共17項，以及共21項的常規，至於AM的真義有4項來自於XP(Bechk 2000)，但加上「謙卑」(humility)一項，而形成Ambler所說的AM真義，我想這5項真義值得加以簡單說明，因為所有的原則都源自於這5項真義： 溝通(Communication)： 發展團隊成員之間以及專案相關人士間的溝通必須有效。 簡單(Simplicity)： 發展符合需要的最簡單的解決方案。 反應(Feedback)： 盡早並且時常獲取對工作的回應。 勇氣(Courage)： 要有嘗試新技術的勇氣，而且成為決策。 謙卑(Humility)： 必須謙卑允許別人提供對於你專案工作的意見。 這五項真義以及各項常規與原則是引自於敏捷聯盟(Agile Alliance)的四項敏捷宣言，因篇幅受限，我不便在此地詳述這些17項原則與21項常規，讀者如有興趣可參考Ambler著作Agile Modeling，或網頁： http://www.agilemodeling.com/ ，不過我希望討論其中最主要與實用的「簡單」這一項真義所在。 Unix的發展者之一P.J.Plauge