課程緣由 產業未升級 使得台灣員工薪資低 觀念未更新 使得產業無力升級 所以軟體業要推動新觀念: 敏捷方法 全面從教育入手 學習本課程後 使產品提升品質 進而使員工快樂又高薪 根絕學用落差

驚濤駭浪！台灣軟體業的險境 台灣代工產業獲利微薄，舉國寄望軟體業勃然興起， 但真相是：軟體業乩童*亂舞、神壇遍佈， 導致產業不振！** *乩童 指軟體工程師不做設計(切割)，自然無法做單元測 則工作不精準(BUG未除盡;且不易閱讀維修)品質差 但他能很快做完軟體並demo，善男信女頂禮膜拜！ (其主管當年也是乩童，當然不知糾正此惡習) ** 乩童愈多、愈努力，則產生愈多垃圾 (指無設計、無法維修的軟體)；軟體公司如神壇，當然產業就烏煙瘴氣了

敏捷方法苗圃 座落於: www.AgileMethod.csie.ncu.edu.tw 有研討會投影片、最新上課教材 、實習教材、國外論文、產業體檢問卷、經驗心得， 有志開創新局之士 請鑑賞!

軟體行銷 vs. 軟體工程 軟體行銷 - 找出利基產品、客戶，經營品牌， 是軟體業最重要的事， 老闆們靈活地全球找商機 - 紅海(既存市場) 或藍海(全新市場)行銷 之後，開發團隊工程師們快速完成高品質產品， 這是軟體工程，才是本課程範圍 有人疾呼: 應行銷某軟體，軟體業就有錢賺 - 混淆議題了！須深沈反省 工程缺失

教材結構 文化, 溝通, 思考 p.265 方法 擴充 極限開發法 (敏捷工程法) (eXtreme Programming, XP) 而得的十一道工序,叫 myAgile p.382 範例 myAgile 的 Java 開發例子 p.414 附錄 SCRUM (敏捷管理法)

觀念

資訊 與 軟體 資訊 (information)是真實世界中，物件(object) 與物件之間的關係(relationship)的一種抽象概念(abstraction)，而這些概念可由人腦認知及處理 (注意:資訊不是電子的 0,1) 電腦軟體 (computer software) 是一種特別的資訊 (information)，用來描述電腦系統設計與實作的解決方案，生產電腦軟體的產業就叫軟體業 軟體 (software) 是否僅限電腦軟體？ NO! 小說、畫作、舞台劇等，亦是軟體

創新 軟體工程 方法 及專注的個人思考** (認知心理學*) (Test-driven development,TDD) 創新 軟體工程 方法 本課程以創新方法，提升軟體業工程實力 強調 綿密的團隊溝通 (組織心理學*) 及專注的個人思考** (認知心理學*) 並採新的測試帶動法(測試驅動式開發) (Test-driven development,TDD) * 軟體與心理學(如 cognitive informatics) 數學 (如 modal logic) 相關 ** 個人思考是陳教授針對國情而補充的，國外文獻無此

軟體業 文化最重要 法國研究者 Bossavit * 指出: 文化 藏於內心無重量至輕，卻影響至深， 所以是軟體業無法承受的輕 例子:鄉間深夜遇紅燈停車–乃是發自內心的文化(紀律)確實等候才可永保行車安全 反之 若自以為聰明 取巧通過 看到警察才紅燈停車 則某次可能因沒停車而釀成車禍 造成無法承受的傷害 * Bossavit,The Unbearable Lightness of Programming ,available at: www.cutter.com

軟體業 文化最重要 (Cont.) Bossavit * 指出某網路公司的文化是: 熱情(passion)大膽(daring)華麗(glamour) 常見網站設計如此 但這不見得好 因熱情,大膽 並不等同 勇氣 (courage) 網頁外表華麗 也不等同 程式品質 如抽象層次 模組程度 等 * Bossavit,The Unbearable Lightness of Programming ,available at: www.cutter.com

奠定新的軟體業文化 台灣房子蓋好後常漏水 -- 需 ”抓漏” 要請技術很好的師傅，用獨門”撇步” 修理漏水，一修再修，住戶很不方便 為什麼不在當初，就把漏水測試做好? 營造業長年缺乏紀律使然! 工人訓練不佳,工頭監工不嚴 軟體業亦然，不良工作文化 (粗糙,不細膩精準)， 造成軟體 ”常漏水”，用戶很不方便 為什麼：不在 當初 就建立正確工作文化， 以 測試來帶動開發 呢? 文化紮根愈早愈好，中學即應進行，大一已遲了

奠定新的軟體業文化 (Cont.) 陳教授房子裝潢時 遇過三級工序能力的木工工班: A級:IKEA工班 有零件工序的圖示文件,技術熟練,會不斷檢查品質,並與在場客戶確認 B級:本土年輕工班 技術熟練,但無文件 C級:本土年老工班 拼命認真,但品質及工時無法預估(不穩定) 台灣軟體工班大多屬C級,年輕人應以敏捷工法(可達A級水準)來創業,以滿足社會需求

文化是產業基礎 但不是產業* 舉例說: 若故宮博物院視辦特展為文化創意(文創)產業,而以高價門票的收入為產業產值,則這是膚淺短視而不對的 相反的,故宮應低價或免費供民眾觀賞精品,以提升人民文化水準,日後人民才可蘊育出高產值的文創產業 * 漢寶德,”當心，文化與產業兩失！”中國時報, 2009.11.29.

軟工是軟體業基礎 但不是產業 軟體工程(軟工)是任何軟體業都需的工作文化,是軟體業的基 礎, 但軟工本身不是產業 國內資訊教育要認知此點 例子: 影像處理軟體是影像處理領域的軟體業的產品,當某開發團隊做某影像處理軟體專案時,該團隊的工作方式 (特別是溝通方式) 就是該專案的軟工 而另一個金融軟體專案 必然有另一型式的軟工 注意 這些軟工都很重要 但它們不是軟體業

Agile 文化 如:架構設計會議 如:演算法設計 1) 綿密的團隊溝通 團隊成員隨時隨地面對面快速溝通， 2) 專注的個人思考 各成員個人思考每分每秒要專注週密， 如:演算法設計

1) 綿密的團隊溝通 敏捷方法的重點: 透過開發團隊成員綿密的溝通， 使開發團隊能因應 變動 (being able to support change) 這對任何成員都有效，不限資深成員，資深而抗拒敏捷方法的反而是最大阻礙 下面先談各種溝通管道，找出最佳的管道， 依此設計 軟體公司佈置 及測試帶動的開發方法

Communication Channels 溝通管道 A. Cockburn, Agile Software Development, p Communication Channels 溝通管道 A. Cockburn, Agile Software Development, p.95,Addison-Wesley, 2002.

Communication Channels 溝通管道(Cont.) 上圖上方 細線 有三點 表示三種 可提問(Question-and-Answer) 溝通管道: 1.二人傳 E-mail 2.二人通電話 3.二人白板前面對面溝通 (效果最佳) 上圖下方 粗線 也有三點 表示三種 不可提問 (No Question-Answer) 溝通管道: 1.書面文件(效果最差) 2.錄音帶 3.錄影帶

人際溝通的感覺豐富度(感度) 面對面溝通感度最高 具備十一種感覺，如信任感、視覺、聽覺 若用下面其他溝通方式 則其感度逐漸刪減 刪減 實質接近感度後 例如 視訊連線 (video link) 刪減 視覺感度後 例如 電話 刪減 聲音感度後 例如 e-mail 刪減 提問感度後 例如 手寫字條 刪減 所有感度後 就是:書面文件 (paper or document) Document communication 文件溝通 效果最差 (傳統軟工用的方式) Face to face communication 面對面溝通 效果最佳 (敏捷方法用的方式)

Face to Face Communication Document Communication 軟體工程 的大進步 Document Communication

Document Communication 真相是: 有軟體公司寫很多文件(甚至有不通順英文文件,無人看懂)-但乏人閱讀,且讀後是否了解,達成溝通效果-存疑！ 應設計 command file 用於電子檔文件 自動統計: 1)文件閱讀時間 2)讀者了解程度 等 當然 完整文件可用於新手訓練 但，典型而簡單的一個專案文件就夠了

Document Communication (Cont.) 例子: 台灣某知名軟體公司高層得意的說:其員工素質高,所以皆寫英文文件.但是,這些英文文件的溝通力(有無讀者?若有,是否易讀,是否能精準了解)頗令人存疑,更不用說維修力(是否易於修改延伸)了.甚至連最基本的精準度可能都成問題.這些文件恐淪為乩童做秀道具! 陳教授因而倡導英詞中句的文件(後敘)

Face to Face Communication XP 2012 General Chair Lundh 回憶當年三人團隊面對面開發經驗: 工業設計師使用紙筆做設計,電子工程師及軟體工程師很敏捷地做出產品 隨後,出現可怕繁瑣的設計動作 (design activities) 即過多文件的時代 現在Agile推動十年後,有人獲Agile認證後,就不 Agile 了 這也是不對的 * * XP 2012 web site.

何以敏捷方法叫敏捷? 因 face to face communication 遠比 document communication (如CMMI*) 快速精準,故稱之敏捷 (agile) 若用乩童式開發方法,不做設計切割,單元測試,這樣固然可快速 demo 軟體,但常有bugs,品質很差-這不是敏捷 * Capability maturity model integrated (CMMI) 是美國 Carnegie Mellon University (CMU) 評鑑軟體公司能力的分級制度

知道 溝通管道 (communication channel) 後 談一下 溝通目的 (communication purpose)

溝通目的 依 A. Cockburn,溝通具有三個目的: 1) inform (告知) 告知對方不知想法 2) remind (提示) 提示對方已知想法 3) inspire (激發) 激發彼此不知想法

溝通的三個例子 1) 寫小說 作家常年得各方 inspire 溝通: 累積想法 作家會記下小扎或拍照(聽說九把刀隨身帶相機) remind 自己想法 某夜作家文思泉湧振筆疾書(軟體創作)書成! 小說送出版商: inform 出版商小說內容 出版商校稿: inform 作家錯字筆誤

溝通的三個例子 (Cont.) 2) 攀岩 這是Cockburn喜歡舉的例子 攀岩要有體能條件,技術訓練,各式裝備等不是每個人皆可勝任 同理-不是每個人皆可勝任軟體工程師 攀岩時不可單飛(類似pair programming) 要等同伴的安全信號,才可向上攀,否則粉身碎骨,這需生死與共高度信任感及精準溝通

溝通的三個例子 (Cont.) 3) 編排舞台劇 編劇寫出劇本(是書面文件) 導演閱讀後,深受感動,思潮澎湃 (inform & inspire 溝通) 經無數次與音樂 佈景 演員 開會及彩排 (是面對面溝通,其中不乏拍桌咆哮的溝通) 整個流程中,電話 Email不斷 (remind 溝通) 終於,舞台劇推出,撼動觀眾人心!(軟體成功)

溝通目的 影響文件 依溝通目的的不同,文件須做調整 讀者經驗豐富:是remind溝通,文件要精簡 讀者經驗不足:是inform溝通,文件要詳細 因此,為適應多種讀者,文件應有精簡版 並用 hyperlink 閱讀詳細版 又,video文件比 文字文件 易溝通,也比 動畫文件 製作快, 而手機就可很方便的拍 video 了

CMMI and 敏捷方法 CMMI Level 2 (project management) 有助敏捷方法 須實現之 有助敏捷方法 須實現之 CMMI Levels 3,4,5 (engineering and process management)(註) 則與敏捷方法 觀點不同 不應進行之 * * Sison and Yang, Use of Agile Methods and Practices in the Philippines, Asian Pacific Software Eng. Conf. (APSEC), Nagoya, Japan, 2007. 註: Level 3 設專責單位制訂流程 Level 4 收集量化流程資料 Level 5 用該資料調整流程

CMMI and 敏捷方法 (Cont.) 有CMMI level 5 公司指出*: 可保有 CMMI level 2 的 goals, 但用 agile implementation. 例如: 用check list 以面對面溝通來 validate goals,使文件減量,這是可行的. * Jacobsen et. al., Mature Agile with a Twist of CMMI, Agile 2008. 本苗圃”論文選讀”有收錄本文

CMMI and 敏捷方法 (Cont.) 而非以 time-boxed iteration (固定時程的回合)及各人工作為主. XP 2010 業界最佳報告 (Best Experience Report*),Norway 公司指出: 敏捷方法要轉為以文件 (work item) 工作流 (work flow) 為主; 而非以 time-boxed iteration (固定時程的回合)及各人工作為主. 這是CMMI與敏捷方法的磨合:鐘擺略擺回CMMI,巧合的是:陳教授myAgile 倡導增加設計草圖及虛擬碼兩文件 * J.O.Birkeland,“Moving to Flow-based Software Development, XP 2010, Norway.

敏捷方法 減少文件 傳統軟工CMMI採工廠思維：視軟體工程師為被動的工人， 故訂出很多考核評量辦法 台灣學生從小應付考試，很被動的 相反的，敏捷方法則：提升為主動負責的人(改造的生命 changed human life)，所以辦法(及相關文件)就消失了 例子: 如要考核 pair programming，則 工程師每天要寫報告，秘書每週做報表，經理每週審閱報表

敏捷方法 減少文件 (Cont.) CMMI 與 極限開發法 (Extreme Programming, XP) 可謂連續光譜兩端點的極端,而光譜中間是二者相混合的 隨著人員面對面溝通能力逐漸提升,文件活化簡化了,文件量逐漸減少(決非強制消去文件)專案逐漸由一端 CMMI 轉為另一端 XP-這中間的任何點都算是敏捷方法

敏捷方法 減少文件 (Cont.) 這兒有一點要深思: 如果大家只在同一房間不斷溝通 但各人內心無深入思考 則仍不可能產出優良產品的

Method vs. Process Method 指的是軟工所使用的 符號 如 物件導向的 UML符號 或結構化程式的 結構圖 Process 則是執行 method 的 方式 如 以面對面溝通 或 以文件溝通 來開發UML文件 所以，嚴格說要講 Agile Process* 才對 但大家習慣稱 Agile Method 本教材也就依此 * 歐洲知名的 XP 200X conference 就叫 Agile Processes in Software Engineering and eXtreme Programming.

先進軟體公司 的五個敏捷點 愈接近這五點，團隊溝通愈敏捷: 1.開發者同處一室 (可面對面溝通 一室最多十人) (“華爾街之狼”片中一室有上百人 效果瘋狂 超敏捷) 2.有駐點客戶 (口頭溝通需求) 3.一個月交貨一次 (以產品與用戶溝通) 4.全自動的迴歸測試(一有變動全面重測) 5.有經驗的開發者 (人的素質最重要)

滲透式溝通 (Osmotic Communication) 同處一室 耳可聽(ear contact)、目可視(eye contact)，週遭資訊會潛意識地滲透到人腦，達成溝通，其溝通效果旣深層又自然！ 例子：小張老李討論某設計時，反覆提到某些詞彙；小林雖埋首工作，竟不知不覺”學會”了。數週後，小林與他人討論時，脫口而出這些詞彙！ 反之,惡質滲透溝通(如客服中心對話)需設牆壁阻絕

美國先進軟體公司 佈置圖 common white board caves

美國先進軟體公司 佈置圖 (Cont.) 粗估需30坪 (約99平方公尺)，台北很易設置的， 軟體業不求廠大人眾，求高素質高薪少人易溝通 上圖分 common 及 cave 兩區: Common 區: 兩人一組，在一台大尺寸螢幕前 工 作 (這叫 pair programming) 各組可目視、交談、溝通 Cave 區: 個人處理e-mail, 電話,閱讀資料等 此外牆上很多白板 white board，供討論用 粗估需30坪 (約99平方公尺)，台北很易設置的， 軟體業不求廠大人眾，求高素質高薪少人易溝通

回顧 台灣軟體公司 現場 一個小房間裏面坐著滿臉倦容、神情呆滯，工作一整天，仍加班中的軟體工程師小林，獨自看著一大疊列印出來，自己也看不太懂的程式碼 (別人當然更看不懂啦)，喃喃自語: 只要再改這地方，就可消除這可惡的最後一個 BUG！ 桌上有多本裝訂精美厚厚的文件，但與程式距離遙遠 三小時後，更悲慘了，BUG 仍在! 夜已深，開始自欺麻醉: 明天一早一定就可解決了！ (現場寂靜、死氣沈沈)

觀察、改善現場 1.辦公室要便於溝通，非必要勿隔間 2.要先寫test code 用工具依序test，則不會困惑 且二人邊討論邊做，現場有點喧嘩，但生氣勃勃、 且流露 祥和自在 專注自信的氣氛) 3.要閱讀虛擬碼，手動trace之，勿讀瑣細難讀的程式碼 4.要用工具瀏覽 hypertext (內含 hyperlink)， 勿列印(因無工具輔助搜尋、瀏覽) 5.文件常過時未與程式同步 裝訂本更易過時 6.勿加班，否則第二天很累，第三天更累… 7.勿自欺，久而久之，自豪感消失，倦怠挫折…戰將折翼!!

兩家軟體公司的省思 要進步就須改變，如本國軟體公司因 工程品質差 而業務外包 他國，吃虧的還是本國畢業生的就業權! 台灣不要代工,不要埋頭拼命趕工，不要處處省錢 cost down 要投資升級 cost up, value up,要豪氣做時尚精品 要敏捷工作不斷溝通，要心平氣和，慢活，慢食，深眠 趕工文化 要提升為 敏捷文化

不知不覺中精品呈現了! 兩家軟體公司的省思 (Cont.) Slow, but Firm - 要徐緩而確實地工作 徐緩(slow)使心沉靜,則工作平順確實(firm) 沒有失誤,沒有Bugs,沒有拼命,沒有加班, 每天快樂工作,每晚安然沉睡, 工作生活態度 要精準 怡然 快樂 不要粗躁 拼命 壓抑 不知不覺中精品呈現了!

軟體公司的省思 (Cont.) 假設有 A,B 兩家軟體公司: A 公司員工制服整齊 各人埋頭苦幹 一片寂然無聲 管理報表齊備 工作緊張 B 公司員工穿著隨意 大家不斷討論工作 隨時有哄堂大笑 沒什麼管理報表 工作從容 請問何公司有品質? 答案可能是B 但不可能是A 因A公司缺軟體公司核心要素 - 溝通

IKEA Office [IKEA 新莊店 2012.1.11] 下面是10坪 5 人團隊工作室 陳設於IKEA 照片1: leader 辦公處 照片2: 小餐桌 (下午茶用) 照片3: 4 人辦公處

Cost Down Cost Down 是工廠思維下的迷思,工廠作業合理化,杜絕混亂浪費,當然對,但是… 有教授半開玩笑的說:某電子廠不斷在研究如何抽掉省掉某零件而系統仍可運轉 不斷這樣做,則工廠不斷cost down,績效優良但產品品質不斷下降,使用期限縮短,故障率不斷提高,很快變垃圾

軟體公司 佈置* 軟體開發是密集合作的活動,開放空間 (叫 team room) 可鼓勵團隊談話及互動,增進非正式及深度的溝通;有自然光可使人舒暢 每人空間約4.5平方公尺(1.36坪) 有人擔心這帶來噪音,但同團隊的談話多半是與專案相關的;倒是不同團隊之間要隔間(最好用活動隔間牆,可彈性變動之) * Martin Fowler web site, posted June 14, 2010.

軟體公司 佈置 (Cont.) 團隊有全權支配空間,小秘訣: 1)勿用需工人搬動的傢俱,用簡單桌子即可 2)電源線,網路線走底下或頭上,易接到桌子 3)椅子勿節省!有人因背痛要跪姿椅或升降桌,去買! 4)白板要很多,含輪子白板,相機白板,動態顯示板(連接投影機,如顯示build狀況) 5)見下圖 Central Desk 有 eye contact U-Pod 則有 ear contact 且易看別組螢幕

軟體公司 佈置 (Cont.)

軟體公司 佈置 (Cont.) 白板又叫 information radiator (資訊發射器) 因為它會不自覺地將資訊射至週遭的人的眼球,極為有效! 一種有名的白板叫 kanban (看板),它源自豐田汽車著名的剛好及時 (just in time) 生產模式-因各生產人員可同時看到看板資訊,可剛好及時取得中間製品,故無中間製品庫存

Kanban (看板) Kanban (看板) 源自 Toyata 生產線上 顯示各站現況的白板, 它可使各人知道其他人動態而機動調整, 進而達到全線最高效率

Using Kanban to Limit Work in Progress 作數量，可減少在工作間轉換 的負擔，鬆弛緊張的神經， 讓團隊成員能平穩踏實的工作 流程最大產出才是真正目標，並非讓各工序人員隨時處於 100% 勞累狀態

Why introduce kanban?* Kanban 改善 transparency 及 cooperation --- which are key values in agile method. 公司在意的不是 individual results, 而是 team results! 同時做多件事時分散注意力，每多一事生產力便降低 15%。同時做五事時，便不具生產力了 * Olav Maassen & Jasper Sonnevelt, Kanban at an Insurance Company Are You Sure?, XP 2010.

軟體設計追求的品質 Creativity 創意性 Usability 易用性 Dependability 可靠性 Maintainability 易修性 Efficiency 效率性 以上只有「效率性」與電腦有關， 其餘皆與電腦無關，而與開發者人腦有關; 易用性涉及大量使用者的人腦，最為複雜

軟體設計中 創意性最重要 創意人先要有激情與放縱來發展創意構想, 再要有嚴格紀律來執行創意構想* 創意來自開發過程所下的苦工: 1) 用功 - 奠定踏實知識基礎 2) 勇氣 - 挑戰現有知識 這才能感動客戶, 要專注(concentration)及決心 (determination),絕非輕鬆的,速食式的 * 賴聲川, 賴聲川的創意學, 天下雜誌, 2006.

軟體設計中的紀律 以表演藝術為例,加拿大太陽劇團,台灣雲門舞集,都有令人崇敬的專業度 - 這來自團隊紀律與對細節的要求.所有看似自然卻精準的呈現,乃出自平日嚴謹的排練,並將之內化為身心狀態和生活態度. 這是勞力密集產業,講究專業分工和標準作業流程,幕前幕後人員須各司其職,以達最好演出品質* 這紀律正是軟體設計所需 * 朱宗慶, 紀律是藝術工作者的基本功, 中國時報, 2010.12.24.

軟體公司招募什麼人才? 台灣學生從小獨自做作業，禁與同學討論，故群育不彰，不善清晰精準溝通(口頭及文字)、集思廣益；美育也無，無美感、時尚感，難成就精品 例子: 巴黎街頭人人衣著搭色和諧 ， 有色感！ 例子:廣達林百里幼年住香港中環， 培養了美感 例子: 自從蘋果痛擊台灣筆電後 竹科廠商找了美學 大師蔣勳演講 這是補習式的 沒有用的 是否要再設個美學學分及美學證照?

軟體公司招募什麼人才? 台灣智育重視填鴨應付考試,以分數定高下，考試中不做思考、只是快速作答；因此，沒有平心靜氣慢慢仔細思考的習慣，不重內在修鍊,故做不出精品 例子: 90分鐘考30題，每題若3分鐘解不出， 老師說: 放棄那一題！ 軟體開發本是團隊合作的工作方式及生活方式，人才首重 群育 ；尤其忌招乩童

軟體公司招募什麼人才?(Cont.) 在此網路推平世界、全球競爭的時代，台灣學生國際觀不足,眼界見識低，未與世界接軌,例如: 1)大學生怕英文教科書，依靠陳舊而質差的中文翻譯本(其原文版更舊了)； 2)研究生無力上網吸收最新英文論文.卻自傲以為:憑拼命苦幹及臨機應變,耍小心眼小聰明 (誤以為是創意),就可做好工作 英文乃國際語言,英文不好則疏於了解吸收其他文化,可能造成台灣人信心,活力及創造力的流失. 幸好台灣學生會華語 (世界最大市場的語言)

軟體公司招募什麼人才?(Cont.) 例子: 某研究生自己承認上研究所後,較少接觸英文了,何以致之? 因無英文課了 可見他學英文是為了應付考試,取得學分;而非利用英文吸收新知 某研究生視英文為亂碼,聽英語如雜訊, 這造成自我封鎖,成井底之蛙 鎖國之民

軟體公司招募什麼人才?(Cont.) 例子: 台灣學生英文不佳,無法精準決定程式變數英文名稱(英詞),使程式可讀性不佳,影響維修品質,寫可用的英詞中句文件都不容易了,寫通順英文文件更是遙不可及 所以,英文比數學重要 (台灣學生修不少數學課,但對軟體業的幫助有多少?) 例子: 印度成軟體強國,與印度精英精通英文 恐怕有點關係吧!

軟體公司招募什麼人才?(Cont.) 例子: 有資訊系畢業生在履歷表上註明寫過數萬行程式,這表示: 1) 該生以此為傲,可能其他人不太會寫程式,2)公司想招募此種人 但真相是: 該生可能不會上網找open source 合適的程式來 reuse,也不會設計(切割)做單元測試,而那麼多行程式可能只是 – 昂貴的垃圾

軟體公司招募什麼人才?(Cont.) Microsoft 全球資深副總裁張亞勤說*: 不能招募 1) 雙面人,多面人 2) 負面心態,老是批評,澆冷水的 3) 玩世不恭,什麼都不在乎的 大器而努力的人,才有可能做好軟體 * 商業週刊, 2010.11.8, p. 30.

開發團隊 公民意識 (群育) 依 A. Cockburn 所見，有下面五點公民意識： 1. 準時與會 Getting to meeting on time 2. 回答問題 Answering questions from other people 3. 看到事情要主動講 Bothering to mention things they notice 4. 遵守程式規定 Following group coding conventions 5. 用程式庫 Using code libraries 注意:無擅長交友，順從他人等，要勇於表達自我， 包容異見，服装自由，特立獨行 例子:聯發科需要在兩人擇一時，不用絕頂聰明的人，而用可跟別人合作的人 [中國時報, 2009.9.20]

群育的極致 Cockburn 累積多年顧問經驗，發現軟體開發困難很多，失敗的專案比比皆是， 而成功的軟體開發有一特色就是: 在極度困難時，總有意想不到的團隊成員挺身而出，以意想不到的方法克服困難，因此解救了團隊， 這應該就是群育的極致表現吧!

兩個弔詭問題 1.某電腦雜誌問:台灣資訊教育不錯，何以無蓬勃軟體業? * 2.某教授提出:台灣硬體業很強，何不發展搭配硬體的軟體(嵌入式系統 embedded systems)? * 有人怪罪政府支持不力，或本國市場太小等因素

解答一 台灣資訊教育不錯，何以無蓬勃軟體業? 陳教授答: 因大部分開發團隊溝通不良， 大部分開發者思考不密，所以工程困難多， 另外還有行銷(市場)困難 - 落後而不自知！ 真相: 資工*畢業生辛苦地工作 (常加班) 資管**畢業生辛苦地找工作(大多找不到) *資工不重視軟工，用蠻力做軟體； **資管著重一般企業管理中軟體之應用，含領域知識，但不是軟體公司的管理，故無軟工 呼籲:資訊系大一計概改為 網路概論及軟體概論(含敏捷方法) 資工偏重 Java,C,C#,Scala 開發 資管偏重 DB,Python,Ruby,PHP 開發 打造就業力！

解答一 (Cont.) 2008金融海嘯後,南韓中國大器大膽改革,復甦快速,一線廠商 具世界競爭力;台灣以往個人電腦的成功,造成”成功為失敗之 母”台灣資訊科系若大膽改革: 計概教敏捷方法,Java (O-O, open source) 從新計概出發,也許軟體業八年後有競爭力 (大學四年,碩士兩年,上班兩年升主管) 但舊思維阻擋,不知幾年後才能開始?

解答一 (Cont.) 有資深工程師說: 台灣工程師能寫出任何程式，言下頗自滿! 陳教授答: 優質軟體的重點在溝通 : 如釐清需求，設計質感，易學易用易重用 回應快速，而不只是程式本身如何寫

解答一 (Cont.) 中國也有類似問題: * 指出兩個困難: 1)閉口合約使專案範圍進度成本無彈性,2)程序員素質不佳,大學出來的 OOP 不強,使test-driven development及refactoring 做不好,這樣則幾乎不可能做 collective code ownership 及 short iteration 沒有 short iteration 就沒有敏捷了 中國的計算機教育已成敏捷方法推廣及軟件行業發展的制約因素 * http://www.iteye.com/topic/19270

解答一 (Cont.) 例子: 某研究生說校計中某團隊coding很強,用API (application program interface) 也很強,言下很佩服! 陳教授答: 軟體團隊強在優秀溝通能力: 精準寫出 scenarios, acceptance test cases; 做CRC反覆推敲設計; 週密而自動化的 unit test cases等; 還有,由溝通而激發的創意,士氣及相互學習增強功力. 國人觀念落後,可嘆!

解答一 (Cont.) 例子: 某校計中開發的行政電腦系統很難使用 某教授多次使用失敗後 只好請系助理代為操作 例子: 某校計中開發的行政電腦系統很難使用 某教授多次使用失敗後 只好請系助理代為操作 陳教授答: 顯而易見的 開發人員需求分析做不確實 使用情節及驗收測試兩個工序不確實 這跟 OO 是沒有關係的

解答一 (Cont.) 在二十屆台灣物件導向(O-O)研討會* panel discussion 中,有人問軟體重用 (reuse) 效果如何?在場有業界人士指出:縱使同領域軟體,重用效果也不佳 陳教授答: O-O 動作要精準確實 且鎖定同領域 ,則重用效果數年逐漸浮現;若推動O-O二十年而無重用效果,則是設計不確實 method切不夠細 O-O落實與內化了多少?答案很負面! * 20th Object-Oriented Technology and Application (OOTA), Tai-Chung, Taiwan, Nov. 2009.

解答一 (Cont.) 承上述, 若某軟體公司長期鎖定某領域, 而且”真的”做 O-O,則公司長期諸多專案累積的 scenarios 必有重覆之處,而由這些 scenarios 開發所得的 相關的 classes (含 methods)即為 公司可重用 (reusable) 的 classes

解答一 (Cont.) 進入雲端運算(cloud computing)時代後,資料儲存,程式執行,都從本機移到遠方的一片雲,本機退化成 user interface device,手機即可勝任,不再需要功能強大的個人電腦 (personal computer, PC) 反之,需要雲裡的 server 及大量資料 (big data) 及網路軟體技術,這剛好暴露台灣資工系軟體教學缺失,下面舉兩個教學例子說明之

解答一 (Cont.) 資料結構(data structure)是資工系核心課程.架構設計切割出class interface後,各class要先做資料結構設計 然後,class中各method才做演算法設計,此時可用 Big O 評估 method Worst time, Average time,以便早期告知客戶 資料結構設計不良的徵候是:只用基本資料結構 array,導至演算法不簡潔精緻,軟體品質差矣!

解答一 (Cont.) 資工系教學中,編譯器 (Compiler)是重要而基礎的軟體工具,更是程式設計的絕佳教材:模組清晰,大小適宜.以陳教授經驗,可實作完下列各模組: scanner, parser, intermediate code generator, assembly code generator.(optimizer 可另開課) 但很多系所只教 scanner, parser 理論,編譯器教學危矣!而軟體教學中,Operating System, Data Base System 比 Compiler更複雜,實作更難教,軟體教學危矣!

解答一 (Cont.) 陳教授在上述兩門課 皆設計 Labs 讓學生用敏捷方法工序開發精簡文件及程式 讓資工系基礎課程變成活生生軟體業界存活可用的養分! 文件細節請參閱本苗圃 “其他課程” 陳教授認為資訊系(資工及資管)低年級(大一大二)應著重上述基礎軟體 這樣,基礎紮實了,高年級(大三大四)及研究所(碩一碩二)尖端課程才有可能落實於軟體業,醞釀出優質產品

解答一 (Cont.) MIT CSAI Lab 主任 Victor 舒 * 指出: 雲端來了! 台灣硬體代工(甚至電機)思維要改變為:以軟體為中心的思維-系統化的軟體開發應用(陳教授認為這就是上述軟體教學缺失之處),要重視 operating system, security, compiler 等,否則十年內產業消失 (即 2020 前) * 遠見, 2010.7.

解答一 (Cont.) 2014 四月 陳教授參加座談 得知經濟部技術處體認到台灣代工產業日薄西山 已邀集各領域專家研討 推動深耕工業基礎技術的計畫 其中軟體組的目標是要有技術製出大型軟體 而這正是敏捷方法的目標 需知軟體業的技術不在做出一個作業系統或某個軟體 而是在於一群人如何 team work 完成高品質軟體

解答一 (Cont.) 例子: Multi-Agent Programming Contest (MAPC) 2012 程式競賽 題目是人類在火星 (modeled as a directed graph with 300 nodes) 找水井 你的程式有 20 agents and 5 roles with 4 agents per role. The roles are 1) explorer 2) sentinel 3) saboteur 4) inspector and 5) repairer 你的程式將上網與其他組對戰 冠軍已出爐: Federal University of Santa Catarina, Brazil (巴西)

解答一 (Cont.) 由上例看出 程式開發已由物件導向 (Object-oriented Soft. Eng.) 進步到代理人導向 (Agent-oriented Soft. Eng.) 物件導向以 Java 集大成 而代理人導向則是以Java為基礎 向上建立抽象層 如 Jade, Jason, JaCa, JaCaMo 分別建立: agent communication, agent deliberation, agent perception, agent organization layers. 而台灣的現況連物件導向都無法確實做好 遑論代理人導向程式開發!

解答一 (Cont.) 中研院院長翁啟惠坦言*: 台灣學術界要自我反省,是否有培養對社會有貢獻的人 台灣產業界則要技術升級,不要滿足於量產代工賺取微利 這對資訊軟體業也是真心話 * 中國時報 2011.10.25

解答一 (Cont.) 廣達林百里痛批台大電機系不創新 相反的,哈佛,史丹佛重視數位人文教育,才能培養出創造 faceBook 及 Google 的學生,台灣學生不會創新,只能代工 代工廠微利4%,而蘋果因創新而獲厚利40% 賈伯斯更是人性工程師,而不只是硬體或軟體工程師,老賈應不會說只碰硬體不碰軟體 * 中國時報 聯合報 2011.10.26

解答一 (Cont.) 林百里說1990後的孩子,接受網路革命,用Google學習,用Facebook談事情,靠Twitter互動,在Amazon購物-他們的競爭力在創新 現行教育制度是工業時代思維,依學生年齡設生產線授課-這教不出創新人才 未來學生不用聽課,而是透過網路獲得知識,老師則轉成為個別學生解惑者* 例如,麻省理工(MIT)EECS課程上網:計概用Python教,軟工用Java教,比台灣多所學校用C++強多了 * 聯合報 2012.9.9

解答一 (Cont.) 鴻海郭台銘已宣告電子代工盛世結束(成長率減半),目前投資泡麵勝過筆電;以淨利率而言,傳統產業15%,而電子業只有2.8% * 台灣小筆電軟體很少,不好用;反觀蘋果的iPad 有 App Store 好用的廣大軟體;宏基敗給App Store,顯示問題在軟體,不要再追求硬體升級了** 宏達電 (hTc) 反映較快,已棄微軟,改用Android開放平台. 股價二度上千元,顯示品牌實力;詹宏志鼓勵進一步開發手機下載軟體,以匹敵 iPhone 封閉平台 *** 宏達電王雪紅且於2011超越鴻海郭台銘,成台灣首富 蘋果創新產品陸續推出,競爭激烈,三星手機行銷成功(法國偏鄉火車站有大幅廣告)2012超越蘋果 * 商業週刊, 2010.9.20.** 今週刊, 2011.4.11.*** 工商時報, 2011.2.22.

解答一 (Cont.) 2012 工程領域(含資訊)的論文世界排名,前五十名大學中台灣佔三席,列四強之一,這是花五年五百億所獲得的,而產業棒打台灣的南韓卻只佔一席 台灣的大學排名越來越高,台灣的產業卻越來越危險,社會太重視研究論文,會使學界不重視產業發展* * 吳瑞北,工程研究進世界四強高興不起來, 蘋果日報, 2012.8.23.

解答二 台灣硬體業很強，何不發展搭配硬體的軟體(嵌入式系統)? 陳教授答: 嵌入式系統需開發組合語言碼*， 陳教授答: 嵌入式系統需開發組合語言碼*， 並考慮底層資源限制故工作量增大，因此溝通要更多，思考要更密，這豈非難上加難? *因C語言兼具高階及低階(組合語言)特性, 所以今天很多組合語言碼已改以C開發, 難度降低不少了

解答二 (Cont.) 某教授指出: O-O 程式執行速度較非O-O程式慢，言下有些遺憾! 陳教授答: O-O 本來就是多一層包裝，使領域觀念更清晰，因而更易維修; 程式執行速度慢，就是付出的小小代價; 不可停留在 C++思維，要進至 Java (O-O)

解答二 (Cont.) 陳教授續答: O-O 軟體的好處在於:舊版軟體易於延伸 (extend) 成新版軟體 (見下例X延伸成Y), 藉著: 1) polymorphic reference (x可指X或其subclass Y的object) 及 2) dynamic binding (whatIAm() 可 bind 新或舊版的method), 使得新舊版軟體可同時使用.這樣,軟體才能活得長久

An Example of Extension /*舊版軟體*/public class X { int a; public String whatIAm() {return “I’m an X.”;} } //end of class X /*新版軟體*/public class Y extends X { int b; { return “I’m a Y.”;} } //end of class Y

public static void main (String[ ] args) throws IOException {X x; // reference “x” is declared to be of class X   BufferedReader reader = new BufferedReader(new InputStreamReader (System.in); String input = reader.readLine(); if (input.equals (“我要X”)) x = new X(); // x points to an object of class X else if (input.equals (“我要Y”)) x = new Y(); // x points to an object of class Y System.out.println (x.whatIAm());//dynamic binding } // end of main

解答二 (Cont.) 承上述,領域知識的每個觀念形成一個 class 要利用三種 class relationships (composition, use, and inheritance) 仔細構建各觀念之關係,才能開發出優質軟體 也要考慮不同程度使用者如何容易地使用 執行速度當然不可太慢,但這非首要考量,更何況執行速度瓶頸常在網路存取速度

解答二 (Cont.) 某教授指出: 台灣硬體產業已經做得很好了, 接著,要再接再厲,做好軟體產業 陳教授答:台灣硬體產業是工廠式代工產業(並無發明某創新硬體架構等),而軟體產業是創意產業,二者本質不同不相關的 只不過,剛巧電腦軟體要在電腦硬體上執行, 使人誤以為相關,勿誤導國人!

解答二 (Cont.) 某教授指出: 台灣是資訊王國,政府應採購國產系統,而不應考慮外國系統 陳教授答: 台灣確是資訊電子產品大國(PC Notebook面板等)電腦大國 但絕非資訊系統大國,更非軟體大國, 台灣軟體一般品質不佳 例子: 某研究生透過工研院計畫,看到某美國頂尖軟體公司的Java程式碼後,慨言:台灣差太多了!

台灣產業文化的省思 軟體業不是生產線，倒像工藝家聯合工坊， 不再需要傳統的拼命加班，而需要深層的敏捷精準: 近數十年,台灣生產線橫掃全球,從雨傘到鴻海帝國,靠拼命文化: 1) 老闆拼命回應客户需求， 2) 工頭拼命run生產線(台積電張忠謀頗賞識台灣工頭) 3) 工人則拼命加班,但不精準 拼命文化長期硬拼,傷害員工,如緊張焦慮,高血壓,肝腎病,癌症,跳樓自殺 又破壞環境,如台塑六輕污染空氣水土壤,全球暖化,且利潤微薄 軟體業不是生產線，倒像工藝家聯合工坊， 不再需要傳統的拼命加班，而需要深層的敏捷精準: 如何思考深且密? 如何溝通快而準?

台灣產業文化的省思 台塑六輕連續大火,燒毀台塑管理神話 原來,與海爭地人定勝天-今天造成海水鹽份腐蝕管線 原來,低廉建廠成本-今天發現用了低價易腐蝕黑鐵管線 原來,用低價原油提煉得高利潤-今天發現琉化物因而多了,易腐蝕管線* 台灣硬拼低成本的產業文化要檢討了! * 商業週刊 1237期 2011.8.8.

台灣產業文化的省思 (Cont.) 鴻海死對頭–中國比亞迪王傳福2009成中國首富,財富396億人民幣*中國已學會台灣生產線技術;但馬步不穩,其手機充電器召回,股價暴跌** 且吃不到蘋果訂單*** 2010王跌至12名 上海世博及北京奧運展現中國升級了,富士康跳樓事件使中國工資大幅升級,台商當年趾高氣昂,今天黯然被趕走,台商不應再流浪了,應返台升級或轉型!! * 旺報, 2009.11.6. ** 今週刊, 2009.11.30. *** 非凡周刊, 2010.9.5

台灣產業文化的省思 (Cont.) 台灣面板業,石化業佔國家生產毛額四分之一以上,但耗費五百萬人用水,產生的二氧化碳需十五萬個大安森林公園來化解 這種掠奪資源(水,空氣,土地)破壞環境的工廠已危害人民*,傳統工廠思維要拋棄了! 2011福島核災更突顯環境保護的重要性! * 天下雜誌, 2010.8.10.

台灣產業文化的省思 (Cont.) 世界經濟論壇評比: 台灣產業聚落競爭力全球第一 有毛豆,自行車,工具機等十三個小鎮,以毛豆為例 三個不認輸敢冒險的人用新品種,採機械化大面積耕作,不靠 ECFA,賺世界財.這些小鎮都在新竹以南,都非中央政府主導的產業,卻有技術門檻有品牌,且產值持續成長 * 台灣何時有軟體產業聚落?將靠不認輸,敢冒險的人, 且不要靠政府 * 商業週刊, 2011.11.7.

台灣產業文化的省思 (Cont.) 台灣有競爭力的可能是文化創意產業 例子: 周杰倫在中國演唱會及代言的產值高達一年7500萬人民幣,被譽為最成功的台商 發人深思的是:周杰倫的母親不追求周的文憑學位,而是全力培植其音樂才華,終於成就產業巨人,可譽為偉大的教育家! 例子: 台裔服裝設計師吳季剛 (Jason Wu)的母親也是偉大的教育家! 培植其服裝才華 而接受其同性戀傾向

台灣產業文化的省思 (Cont.) 趨勢大師奈思比解答中國經濟成功之謎* 在於高幹由上而下制定架構(像企業執行長)而社會大眾則由下而上創新發展,並影響上層,上下逐漸互信,社會逐漸進步,也就是:中國產業成功來自新的社會制度的成功. 台灣社會需”世紀接軌”**,開創新現實! 台灣發展遠勝中國式的”賣腎創造GDP”, 勿庸擔心*** * John & Doris Naisbitt, The 8 Pillars of a New Society: China’s Megatrends,天下遠見,中國大趨勢, 2009.10.26. ** 吳祥輝, 挪威驚喜, 遠流, 2009.5.1, pp.186-191. *** 吳祥輝, 陪你走中國, 遠流, 2011.2.1, pp. 112-113.

台灣產業文化的省思 (Cont.) 陳教授 2010 九月遊中國西安法門寺,發現其硬體建築極其浩大宏偉, 遊客如織 (門票不便宜,120人民幣合台幣600元), 但不見僧人禪修, 只見不少”假僧人”心不在焉的在場看顧,軟體蕩然無存矣! 趨勢大師奈思比可能未見及此事 2010 陳教授觀察: 中國大建高速公路鐵路,青藏鐵路已完成,新疆高鐵將動工,新疆最西的喀什將建經濟特區,各都市高樓林立,國力驚人,雄心萬丈,世人應正視借鏡之 但同時塞車頻傳, 一塞數小時, 可見其軟體管理面尚薄弱

台灣產業文化的省思 (Cont.) 2010 陳教授觀賞中國連續劇”闖關東”, 描述山東家庭勇闖東北開墾的大時代故事. 其編劇,導演,攝影皆思維精準豐富,戲劇張力很強,勝過台劇,可見其軟體的思維面是深厚的,只是軟體的管理面目前較薄弱而已 台灣人因歷史淵源及語言相通,遠比美歐日人士易於了解中國

台灣產業文化的省思 (Cont.) 台灣以經濟體名義與中國簽署經合架構協議 Economic Cooperation Framework Agreement (ECFA)舉國議論;但是,柯林頓來台演講指出此可帶來中國及世界的投資 後ECFA時代,台灣有品牌競爭力的企業(非耗能拼命的傳統製造業台商)應藉網購進入廣大中國市場,與全世界廠商競爭,求取發展機會 台灣軟體業能否在被殲滅前練出競爭力? 能否拋開過去,脫胎換骨,成就台灣製軟體精品? 成敗在一念之間!

台灣產業文化的省思 (Cont.) 例子: 三年前 阮啟偉開始做肉乾精品(工序很重要例如有一工序是手工剪開肉乾)今天他藉者網購 取得中國很大的市場 而且-廠留台灣 例子: 王馨儀做蛋糕精品 每月研發新品 一樣藉者網購 取得中國很大市場 而且-廠留台灣 [寰宇新聞二台 2013.04.27]

台灣產業文化的省思 (Cont.) 中國網購實力驚人 支付寶2012統計 每人每年平均消費1514元 較前一年成長1.2倍 消費力最高是浙江 廣東 上海 北京 總消費額超過一兆人民幣 佔中國全年GDP 2% 跟美國最大購物網 eBay 不相上下期待為台灣產業帶來利益 [台灣醒報 2013.05.07]

台灣產業文化的省思(Cont.) 例子: 電影海角七號震撼市場,創下台幣4.6億空前產值;這應歸功於優秀的編劇導演 演活台灣多元文化及族群,激發市場共鳴,掌握了行銷面 但是,因為細節處理(如服裝考據)不夠精準,即工程面不夠嚴謹 ,無法獲金馬獎最佳影片 接著,艋舺,雞排英雄也創佳績,賽德克巴萊製作嚴謹而浩大;那一年我們一起追的女孩,清新可喜; 2012台灣電影金馬獎失利, 但台裔紐約人李安的 Life of PI 奇幻的3D工程,舉世讚嘆! 2014 KANO (嘉農棒球隊)創佳績

台灣產業文化的省思(Cont.) 例子: 日月潭涵碧樓房價每晚一萬四千元，法國雜誌曾推薦，是觀光業成功例子 但因理念不同，外國經營團隊撤出，一段時間後，驚傳洗澡水呈土黄色 台灣老闆不知: 維持高品質須嚴謹步驟，這是很昂貴的，需投資的，不可只憑苦幹實幹省錢將就，要勇於投資升級

台灣產業文化的省思(Cont.) 觀光股王晶華酒店斥資十七億餘台幣，買知名麗晶飯店（Regent）品牌，創台灣觀光史首例，一躍為國際品牌管理者，掌管全球十七家五星級麗晶飯店，及四艘麗晶郵輪品牌特許權，將在台北成立全球營運中心，也計畫讓麗晶重返香港、東京、上海、紐約、倫敦、巴黎與雪梨等重要城市* 遠離工廠思維, 露出曙光了! * 聯合報, 2010.4.17.

台灣產業文化的省思 (Cont.) 台灣的連鎖休閒服務業,如超商,飲料店,快餐店的密度世界第一,因此競爭激烈,創新度高 85度C在中國展店順利,即為成功例子* 配息俱樂部林百里,郭台銘,王雪紅前三名;而宏碁掛零,這多少反映出企業創新力** 2012 郭台銘推出60吋電視,以創新行銷反擊三星, 台灣還是有抗韓名將! * 遠見, 2010.9, pp. 266-267. ** 中國時報 2012.7.4.

台灣產業文化的省思 (Cont.) 在新北市泰山區一片鐵皮屋工業區,都是傳統鐵工廠也有顯示器廠的當中,很神奇的有家餐廳叫香草花緣(Herb Garden),大樹成蔭,花木扶疏,生意鼎盛,客人悠閒愉悅,還有店員吹氣球做成帽子給小孩子玩,一客海陸餐賣750元,營收應不錯 傳統工廠提昇為庭園餐廳,感覺不錯! 穗科手工烏龍麵嚴守工序 加上簡約店面設計 悅耳平靜音樂 業績長紅 手工行業的基本功就是嚴守工序 這當然含軟體業

台灣產業文化的省思(Cont.) 經建會主委劉憶如說: 金融海嘯後,亞洲經濟大於歐美經濟,台灣過去重視製造業,以出口為重心;今後應重視創新服務業,出口及內需並重* 陳教授認為: 以創新的敏捷方法為基礎的軟體業 即是一種創新服務業 * 中國時報, 2010.12.18.

台灣產業文化的省思(Cont.) 台灣2013第一季GDP 慘跌至1.54 % 無法保三 因為宏達電及宏碁的手機及PC外銷不佳 政府做了什麼使外銷電子業轉型? 沒有! 政府只是期勉業界加油* 本苗圃早已指出軟體業升級做法 * 聯合晚報 2013.4.30

台灣產業文化的省思(Cont.) 慢活才能消去壓力 把事做好 得到高品質 例子: 某財務經理退休後 把休閒活動排的滿滿的 她認為這才有效率(這樣是有壓力的) 結果她失眠越加嚴重 軟體產業員工,用心工作三十分鐘後,應該休息活動五分鐘,眼離螢幕,心離工作 例子: 阿珠勞累時,Google找不到某家店鋪, 她出去玩一天後,精神好起來了,一下子就找到了! 例子:2012.11.23張忠謀親上火線,要求員工每週工作不超過五十小時,生活要平衡,痛擊加班文化,股價隨之大漲!

台灣產業文化的省思(Cont.) 林百里說:賈伯斯沒讀過工程學,不算工程師, 但因他融入人文思考,所以創造了截然不同的蘋果產品 人性工程才是真正的價值,製造冷冰冰的機器不再是獲利模式 * 2012.3.6 聯合晚報

台灣產業文化的省思(Cont.) 爾必達事件讓高科技產業中的科技成分現形；原來我們的DRAM產業不努力研發自有技術，年年捧著數百億鉅資向人討些現成專利；面板產業面對強敵三星節節敗退，最後淪落到撿食其棄之無味的雞肋；iPhone代工廠在單價中只能努力爭取區區百分之一代工錢，還要面對血汗工廠譴責。 結果，十餘年來台灣經濟一蹶不振，勉強維繫百分之三、四的成長，還胥賴對大陸世界工廠的出超支持；如今世界工廠瀕臨關閉的命運，我們要向何處尋求一線生機？ * 2012.3.8 聯合報 馬凱 廿年一覺科技夢

台灣產業文化的省思(Cont.) 早年,台灣留美學者抄美國早而多,“依賴而發展”遂成四小龍之首 近年,韓星港找到自主發展方向,台灣卻沒方向,只仰賴 ECFA,掉進墊底競賽 (race to the bottom)* 對軟體業,吾人要省思產業文化,英文能力 教育生態等基本問題,而進行自主思考,找出發展的大方向 * 南方朔,“笨蛋馬政府”,新新聞, 2012.5.17.

台灣產業文化的省思(Cont.) 日內瓦發明展台灣屢獲世界第一 因而學校評鑑加分 學生直升名校 然後呢 這些發明成了遺跡 另外 在商業專利戰場上 互告專利權時 台灣節節敗退 鴻海等大廠得花大錢買專利 * 資訊教育亦然 論文排名世界前茅 但寫程式這種基礎技職訓練蕩然無存 很多資訊系畢業生無法產出高品質程式 某知名軟體公司員工觀察 有兩派程式師 一種直接寫程式 另一種畫設計圖後寫程式 但程式與設計圖不符 這兩種都是低品質 * 網站“路仁教授談教育”, 盲目追求世界第一 台灣技職從根爛起

老闆賺大錢,員工享高薪! 台灣產業文化的省思(Cont.) 台灣名校學士去澳洲當台勞*,舉國嘩然,大家終於正視台灣因產業不升級,公司無利潤調薪,導致員工薪資偏低的事實 各行各業都要加油!軟體業當然也要引入最新的敏捷方法,以求產業升級 – 老闆賺大錢,員工享高薪! * YAHOO! 2012.9.13

台灣產業文化的省思(Cont.) <台灣成失落科技島>* 2010 宏碁當道, 全球九成筆電出自台廠,2012 蘋果三星當道,蘋果開啟四屏整合 (PC,平板,手機,電視),重新定義軟體價值 現在要像鐵人三項,馬拉松,游泳,自行車三項都要行,不可像宏碁只PC單項行.好消息是:廣達,華碩似已成功轉型為鐵人 * 今週刊 2012.10.15

台灣產業文化的省思(Cont.) 紐約時報評論 台灣電子業領先不再 當手機時代來臨PC時代遠去 台灣創新不足 反應太慢 又當 Android 平板突起 只有華碩跟進轉型 創新靠人才 但年輕人想去公家機關或學術界 投身產業界的人越來越少 好消息是 台灣電子業並沒有坐以待斃 宏基今年研發經費倍增 [中國時報 2013.05.14]

台灣產業文化的省思(Cont.) 矽谷再起 但台灣缺席了 取台而代之者為中國及韓國業者 何以致之 因為台灣廠商受困於代工生產的思維 而無創新思維 所以困於電腦產業 而無法升級到網路產業 矽谷再起 其實是換了一批廠商 例如當年昇陽公司的寬敞個別辦公室 如今是生氣蓬勃像美術館的臉書總部 [遠見 2013. 6]

台灣產業文化的省思(Cont.) 1 目標遠大 要進世界前茅 2 聚焦一項產品 3 深耕技術 投資研發 不低價競爭 4 從顧客身上學習 天下雜誌尋找台灣中小企業隱形冠軍 特徵是: 1 目標遠大 要進世界前茅 2 聚焦一項產品 3 深耕技術 投資研發 不低價競爭 4 從顧客身上學習 5 以世界為市場 例子有 旺旺控股 大立光 台灣晶技 等等 敏捷軟體公司只要十名員工加優質客戶 即有望成為下一個隱形冠軍 不容易但有可能 [天下雜誌 2013. 05.15]

台灣產業文化的省思(Cont.) 因為台灣產業投資不足無法升級 使得員工低薪 王品戴勝益勉勵年 因為台灣產業投資不足無法升級 使得員工低薪 王品戴勝益勉勵年 輕人在低薪下 要投資自己不要儲蓄 這是對的 有投資才能升級 戴的子女去紐約留學 他有十二點留學須知 不能整 天在圖書館 英文要很好 極力擴大視野千萬別儲蓄 等等 本課程目的即激勵軟體工程師提升自己 升級後才會有產業成功 中央社 2013.06.15

台灣產業文化的省思(Cont.) 台灣經濟悶與亂 張忠謀指出原因為缺乏人才 缺中層有創意又自動自發的人 也缺高層器大識深的領導級人才 * 但是 台灣大學很多 博碩畢業生很多 應該不乏人才啊 這表示教育失敗 回頭看台灣軟體產業 也可看到資訊教育失敗的跡象 只是有人不自知罷了 * 聯合晚報 2014.01.22

台灣文化的省思 台灣人被評價為呆胞,指的是見識不足,不精準,不確實,看來呆呆的同胞 台灣人一般單純熱情搏感情(有人情味),愛錢,生活上省錢,工作上拼命,到處找撇步,急就章“慶菜”貪小便宜(塑化劑應運而生),因陋就簡,沾沾自喜,自滿自大;思維不精準,規畫不足(無競爭力);沒有大方向,不大方,不大器,不求開闊視野,不提昇境界,不投資升級台灣(有些美味小吃 數十年來生意很好 卻不肯投資改善用餐環境 消費大眾也無所謂) 台灣人不自知自省,可悲!

台灣文化的省思 (Cont.) 士林夜市乾淨度已輸中國很多夜市,台灣業者長久不升級,可嘆!還好,客人排隊情形不錯(年輕人群育有進步) 還有,台灣機車氾濫成災,民眾只圖方便省錢,有見父母夾幼兒騎一車,極易傷亡,落後國家景象也,政府及民眾皆不謀求投資升級! 民眾要學開車 要買車 要買停車位 政府要規劃停車場 這些都需要投資 不肯投資當然不會升級 Bella Vita,君品酒店,艾美酒店等,提升台灣生活文化,猶如數年前微風廣場一樣,可佩!

台灣文化的省思 (Cont.) 近日舊金山籠罩反恐低氣壓 有點像台灣悶悶的 這都是社會信任崩解中 無力改革進步 反觀新加坡及荷蘭 小國寡民 但有高強度社會信任 才能創造出高強度興旺活力 [陳立恆 聯合報 2013.5.1]

台灣文化的省思 (Cont.) 緩慢民宿引入台灣新文化,它的傳單寫著: 緩慢 是一種心情 悠閒 從容 自在 放鬆 感動 深刻 緩慢 是一種能力 敏銳 纖細 清晰 克制 沉穩 恆久 快揮別傳統拼命文化,應付文化吧! 緩慢用在地食材做出懷石擺盤,又述說相關在地小故事,多精緻啊! 緩慢客人爆滿,還有國外遊客聞風而至;反觀旁邊不升級的傳統民宿,無競爭力,歇業了

台灣文化的省思 (Cont.) 2012.11.30 台北市有國小仿日韓,改變上課方式. 不用傳統的老師講課學生聽課,而把三張課桌排成一圈面對面,進行小組討論教學 學生說: 這樣不會打瞌睡了 這也許可除填鴨文化,有助創意產生

台灣文化的省思 (Cont.) 毒澱粉事件*暴露台灣文化落後之處: 1)人民無知: 只要口感Q 不知已服毒 2)政府無能: 衛生單位不執法 坐視人民中毒 漁民被菲律賓槍殺事件 暴露了以前政府的無能 在這落後社會中 人民要覺醒 要督促政府保護人民 * 中國時報 2013.05.28

台灣文化的省思 (Cont.) 台灣飲食業者用塑化劑毒澱粉都有二三十年歷史 政府食品檢驗當局卻睜一 隻眼閉一隻眼佯裝沒看到 台灣飲食業者並沒有在基本面做努力 只是自我感覺良 好 台灣飲食文化正加速退化中 台灣近年養成務虛不務實的文化 做秀宣傳當道 台灣美食王國的破產只是 整個台灣破產的一個側面而已* 台灣人要小吃有口感又要便宜 於是業者研發各種化學添加物 長期傷害肝腎 台灣形成毒食(非美食)王國 及洗腎王國 *南方朔 中國時報 2013.06.04

台灣文化的省思 (Cont.) 台灣人”貪俗” (撿便宜貨) 是文化的致命傷 便宜貨之所以便宜乃因品質不良 使用品質差的東西 日後維修費 甚至重置費通常更高 可謂得不償失 所以要以品質為先 而非價格 同理 做事要慢慢按步就班做 品質才高 若快快撩草的做 可能因品質不良 而需重做 反而更慢

台灣文化的省思(Cont.) 2010春 陳教授遊法國Evian,其飲食文化值得借鏡: 極慢食,逐一享用小酒,前菜,沙拉,熱湯,主食,甜點,咖啡,大家熱絡交談,一餐要吃兩小時, 這樣身心悠閒舒暢下,深度溝通自然發生,創意易產生.這也能使人全神貫注,易製出精品 反之,台灣人常埋頭拼命工作後,大魚大肉,大吃大喝,傷身體了,且工作會草率

台灣文化的省思(Cont.) 2013夏 陳教授悠遊北歐四國一個月 沒看到一件車禍 大家嚴謹行車 (台灣人開車常拼命趕 又不守規矩 趕來趕去車禍不斷) 高級旅館裏舊型電腦擦拭光亮正常使用 接上雷射印表機使用頗方便 而且 三台電腦接一台印表機頗為節省 (台灣人一昧追求電腦硬體昇級 可是旅館裏列印品質不佳 且使用不方便) 挪威 GDP 達 98000美元 人民嚴謹確實 而台灣僅 23000美元 升級老是升不上去 文化要改一改了 要嚴謹 要節省

產業失敗例子 震驚社會且引起國際嘲笑的高鐵售票專案即是失敗專案：國內知名的神通軟體公司 承包後，自己不開發，轉包IBM, 取得美國陳舊鐵路軟體，加以修改，結果釀成大禍，變成國際級笑話 真相是: 台灣是軟體落後國，要深切反省，認清事實，承認落後，才能掌握後進優勢後來居上. 國際競爭起起伏伏，落後真的不可怕，不知落後才可怕

產業失敗例子 (Cont.) 例子: 有一些台灣軟體公司在軟體程式碼開發完成之後,才補寫 文件,甚至另外找人(非原開發者)來寫文件 這是典型應付考試 心態 (可能是應付某 process 標準的要求,如 CMMI),真是匪 夷所思! 難怪產業不振! 例子: 在2013台灣敏捷國際研討會中 有知名公司人員提問說 到今天才知敏捷有做設計 (以前他一定以為敏捷是直接寫程式) 其實敏捷是有做設計 但不寫設計文件 通常用CRC 而myAgile 更進一步用逆向工程工具自動從 CRC 獲設計文件 國人對新知常一知半解 難怪產業不振!

似成功 實失敗 的例子 2007華航火燒機，全機乘客三分鐘逃離，飛機隨即爆炸。畫面傳及全球，俄國讚為奇蹟 (類似案件他們死數百)，華航譽機長為英雄 ..成功例子: 機組員訓練有素、乘客臨危不亂，構成高效率團隊！ 真相是: 機組員完全無指揮照顧，乘客爬過座椅，高呼開門，數百人耳聰目明、爭先恐後逃難，原來是台灣人自求多福、拚命求生的一幕，令人扼腕！

產業成功例子 2009 裕隆汽車推出納智捷 LUXGEN (for luxury and genius)智慧車 整合宏達電車用電腦系統,與全球大廠競爭 角逐世界最大汽車市場(中國) 雖然網友試駛意見,反映一些小瑕疵,但瑕不掩瑜,這是台灣資訊業創新成功的一例

產業成功例子 (Cont.) 台灣人才多，素材豐富，從高雄世運、台北聽奧的經驗，可看出台灣有能力舉辦國際大型活動且嶄露光芒。 尤其，活動中見到多媒體科技大量運用，讓節目畫龍點睛，豐富的變化顯現多媒體科技可應用於各領域，將成為我國產業的明日之星[web 朱宗慶文化觀測站, Sep. 2009] 例子: 據聞世博中國館內叫好的清明上河圖,即出自台灣軟體公司之手

產業成功例子 (Cont.) 台灣線上遊戲神諭之戰 (Runes of Magic) 奪德國大獎,歐洲每日上線突破四十萬人. 唐志偉(35歲)唐志宗(31)兄弟,因逃避考試制度,小學赴美,研究所畢業才回台,2005創立思維工坊.其父是台中鞋廠老闆,一輩子代工,倒是兒子自創品牌了! 神諭之戰玩家有13部位可打扮,背景音樂高價找德國管弦樂團,投4000萬,每月獲利800萬 唐家兄弟不是台灣培養的人才 而是美國培養的 * 遠見, 2010.8, pp. 366-367.

產業成功例子 (Cont.) 宏達電率先脫離較舊的微軟平台,跨入新的 android 手機平台,並以1100萬歐元併購法國手機軟體公司,這是軟體創新思維, 勝過聯發科的山寨機低價思維, 當然,股價也反映此點* 短短兩年後,2012宏達電受蘋果三星重擊 股價大跌,要不斷創新才可以! * 商業週刊, 2010.7.19, p.44.

以上回顧台灣軟工文化的缺失 下面則簡述敏捷方法帶給全球的 一些軟工新觀念

軟體只有設計 而無施工* 軟體設計圖(用Unified Modeling Language, UML畫出) 像畫家的草稿或作家的章節大綱，目的是便於後續的細部思考:資料結構、演算法、程式碼等(我們用設計草圖、虛擬碼來協助這思考，後敘) 軟體設計圖 不像 橋樑設計圖，它已完成細部思考，已定案，故可交施工部門。此時，因已定案，才可做長期詳細的施工時程及成本的規劃* 傳統軟工這方面觀念有誤解，敏捷方法矯正之 * Martin Fowler, From Nothing, to Monumental, to Agile , http://www.martinfowler.com

敏捷方法等於寫程式? 因敏捷方法最後只留下原始碼、測試碼等程式，所以有人誤解為: 只在寫程式 當然不是! 敏捷方法做規劃，但不寫規劃書(planning, but no plan)；做設計(CRC)，但不寫設計書(sequence diagram, class diagram等)。很多工作(tasks)用面對面溝通加短期文件(白紙白板)即達成了，所以長期留下的只有程式(及驗收測試)

客户關係 與客户為合作*(非合約**)關係，試想某軟體公司以200萬承接某專案；若該軟體很快推出且達到客户期望，客户可能獲利1000萬，如案子砸了，誰吃虧大? 客户！故聰明客户願派出駐點客戶*** 客户公司可能指定兩人探索需求，找出功能清單，再由其中一人任駐點客戶 分次付款-若該軟體分四次交貨，每次付50萬 * 此時社會成熟互信，無人詐欺，斯不易矣！ * 目前客户及軟體公司不很互信，故須以合約規範之 *** 反之，若開發團隊去客户端工作，也可以啊！

團隊組織 傳統三層: 1)system analyst (SA), 2)system designer (SD), 3)programmer (PR) 另有 project manager (PM) 現只 designer-programmer 簡稱developer (1或2 programmers，改為2 developers in pair-programming; 3或4 改 2 pairs) 駐點客戶(後敘)取代SA；溝通簡化低階PM消失；工讀生將 developer 做的test cases 轉成 test code

團隊組織 (Cont.) 由舊團隊轉型為新團隊時，有一靈魂人物: Coach (教頭) 網路上敏捷方法成功故事、 敏捷方法研討會、敏捷方法顧問 當然，上級及客户支持轉型是先決條件

團隊組織 (Cont.) Diversity and Software Development 一文*中引 Scott E. Page** 專書指出: 多樣化不同個性的成員有助軟體團隊 Diversity 指各人 perspective, interpretation, heuristics, and predictive model 的不同. 例子: 1949難民潮***帶來中國各省多樣化基因,是台灣最珍貴資產,其後代今日已成台灣中堅(如金溥聰是滿族) 例子: 美國融合各族 過世的賈伯斯 其父阿拉伯人 母美國人 *IEEE Software, May/June 2009. ** XP 2010, Norway, keynote speaker. *** 龍應台, 大江大海一九四九,天下,2009.8.31.

團隊組織 (Cont.) 團隊合作的背後是信任 例子: 中視超級星光大道中 有一新秀須在歌唱中一躍而後 後面則有舞群安全的接住他 但新秀看不到舞群 難免心生畏懼 這就合作不良影響歌唱表現了 若老手有信任感則不同了 同樣的 軟體團隊須信任他人程式可依文件所述執行 而勇於呼叫使用之 團隊才能合作

專案經理怎麽不見了？ 原有專案經理做: 工作分派、工時計算、預算規劃控制、進度報告，要做不少文件，何以不見了？ 原因是: 各人主動協調，不需經理指揮 (這超難!) 善用白板溝通，不需太多文件 因駐點客户在現場，不必報告客户了

專案經理怎麽不見了？(Cont.) 傳統組織使用 command & control 上級經理指揮 (command) 下級 然後檢查下級有無依令執行 (謂之 control) 反之 Agile 使用 self-organizing team 自然形成的團隊 每人主動工作 彼此協調說服 自然就沒有經理了

駐點客戶 (On-site customer) 駐點客户長期派駐團隊。它顛覆傳統問號很多: 使用者怎願到現場幫我們開發? 使用者程度很低，怎懂電腦，如何一起工作? 但開發者直接面對使用者時，需求瓶頸 消除了！ 他只要懂需求，不用懂電腦 開發時，駐點客戶整天與開發者在一起，可確保需求精準落實於程式中(尤其是氣氛，美感，情調等美學價值

駐點客戶的工作 有人以為這是涼缺，其實要做很多事: 1.寫使用情節 (Scenarios) 並與開發者確認使用畫面 2.由使用情節寫驗收測試(需準備大量data) 3.當某功能完成(即其methods皆已整合)，即刻執行其驗收測試(或督導工讀生去執行) 4.歸納驗收測試 整理出使用手冊 例子: 若某功能有五個使用畫面，每畫面有三狀況 則最多有 3的5次方243個驗收測試

駐點客戶何以要一直駐點 駐點客戶的工作都與需求有關 在驗收測試文件做好之後 需求已確定 何以還要駐點? 陳教授答 需求是不斷變動的 客戶公司隨時要變更某些畫面互動的情形或者軟體公司因技術因素想變更某畫面 這些都需駐點客戶一直駐點與程式師面對面溝通來快速解決 解決後他還要更新文件

一般型軟體的駐點客戶 軟體有客製型(如某公司銷售系統)或 一般型(如 Microsoft WORD) 前者:客戶要派出駐點客戶 後者:要指定市場調查者擔任駐點客戶 總之,駐點客戶要負責需求之釐清

駐點客戶代表多元使用者 駐點客戶必須反映不同使用者的不同使用習慣 例如: 手機操作常未考慮中老年人 手指遲緩 按不到小小的按鈕 駐點客戶必須反映不同使用者的不同使用習慣 例如: 手機操作常未考慮中老年人 手指遲緩 按不到小小的按鈕 近視老花眼 看不清小小的顯示 更常見軟體使用手冊寫的像程式,難閱讀

駐點客戶省錢又有效 有電信業界人士指出: 駐點客戶之薪資經費 應正式編入計畫預算 因為這經費比程式師開發需求文件的經費少, 而且有效多了 例子: 中研院生醫組聘駐點客戶(薪資三萬多) 遠勝於聘程式師寫需求文件(薪資五萬多) 而更有效! 例子: 某軟體公司七十人 其中三分之一駐點到客戶公司 這樣反向駐點也是可以的

逐步改善 以達極致 溝通要達極限極致(extreme) 絕非一步可達 要逐步改善文化及設施， 如 1) 同仁願交談 2) 設交誼區 逐步改善 以達極致 溝通要達極限極致(extreme) 絕非一步可達 要逐步改善文化及設施， 如 1) 同仁願交談 2) 設交誼區 如 1) 願做設計 2)願做單元測試 3) 安裝 JUnit

守破離–習武之極致 習武者一開始要遵守規則方法,有武功後可打破規則因時制宜,到大師級後可跳離規則自由揮灑,這是日本武道的: 守破離 (Shu Ha Ri) 它描述學藝三階段,軟體工藝的學習亦不例外 Alistair Cockburn 提此; Agile 2010 以此為主題 依此才能心平氣和從容自若,有專注力及決心

如何”守”? 實也 陳教授認為”守”是第一步 就是要”實” 心態務實 對事踏實 對人誠實 就對了 很多人思慮處事 虛而不實 則有漏洞 即Bugs 例子: 有研究生一直等別人(如補習班)餵食中文資料 拼一下填鴨後 應付考試 他英文很差又不查字典 這樣無法”確實”讀懂論文 虛而不實 如何研究創新?

到達極致卻失敗的例子 芬蘭NOKIA工程技術已達極致 (extreme), 但從手機霸主地位瞬間覆亡-何以致之 ? 因為平地冒出賈伯斯的 iPhone,顛覆了整個科技環境,使其極致優勢瞬間失效 要應付變動的環境,就要勇於拋棄及忘記以前的優勢及成功*,這正是 Agile 的精神! * 商業週刊1223期 2011.7.11.

基本溝通能力(口頭及文字)之外 ， 下面陳教授引用最新溝通學著作 Made to Stick, Heath, 2007. at www 基本溝通能力(口頭及文字)之外 ， 下面陳教授引用最新溝通學著作 Made to Stick, Heath, 2007. at www.madetostick.com 進一步探討溝通

人際溝通 擊節者實驗 1990 Stanford Univ. 心理學博士論文 擊節者拿到紙片上有25首常見歌曲(如生日快樂),任選一首,在桌上敲擊節奏給聽者,聽者則根據節奏來猜歌名 擊節者預測:猜中機率 50% (因他知旋律) 但聽者聽到一串敲擊聲,只猜中 2.5% 真相:擊節者很難想像聽者無旋律的知識， 敲得很累(腦中旋律震耳)也沒用，這形 成魔咒，阻絕溝通 (對方怎可能沒聽出??)

人際溝通 (Cont.) 從心理學觀點*:人際溝通有知識的魔咒 (上頁實驗) (The Curse of Knowledge) 以軟工而言：開發者在開發當下擁有知識，但無法想像維修者完全無知識的困境，開發者會誤以為維修者也擁有該知識 本法 myAgile 的 設計草圖 (design sketch)及虛擬碼 (pseudo code)即補捉開發者該知識,再傳播給維修者 * Made to Stick: Why Some Ideas Survive and Others Die), 中譯本：創意黏力學 (觀念溝通學 似為較佳譯名), 大塊文化, 2007, pp. 29-30.

人際溝通 (Cont.) 例子: 郵局行員問寄包裹顧客”要幾天的?” 顧客呆住，溝通失敗了! 正確的溝通是: “這包裹三天送到要一百元 ，七天送到要五十元，你要幾天的?” 原因: 行員每天講幾十次，誤以為顧客也擁有”三天送到要一百元 ，七天送到要五十元”的 知識，其實顧客是第一次聽到這事

標示溝通 (Cont.) 例子: 台北車站多鐵共構,大量users進出 各user腦海知識(knowledge)不同,因此設計標示(sign)使之快速與各種 user 溝通很重要 假設某user搭捷運到台北車站,要去微風food court,如其腦海知識有“微風在台鐵2F”知識而循台鐵標示前進,則輕鬆找到.如無此知識 則找不到 (因車站內無微風標示) 例子: 台北車站 要找高鐵登車處 user循高鐵標示前進 但到達高鐵售票處 氣死user 如何設計標示適時適切與 user 溝通 值得深思

文件溝通 (Cont.) 例子: 某工程師完成一報告，是用debugger查出的某程式的複雜的資料結構，但報告中無足夠文字說明，也無debugger操作簡例 所以讀此報告的另一工程師，無法順利依據此報告來維修軟體，例如增添一個簡單的資料欄位

破解知識的魔咒 人類聽故事 (story)時，不是被動的聽，而是會模擬地理位置，主動在腦海形成一幅圖畫，用視覺想像場景 (scenario) ，有誰在裡面，自己在那兒，想像的焦點是故事過程，而非結果 CRC(後敘)就是開發團隊一齊做上述的模擬 ，來溝通多個使用情境(scenarios) 這可能是O-O 的學理根據

破解知識的魔咒 (Cont.) 故事提供抽象文字裡缺乏的情境，所以講故事可破解知識的魔咒，而達成溝通 使用者的故事 (user story) 及 故事的情境 (scenario) 會成為敏捷方法及O-O中使用者與開發者的溝通利器，是有學理根據的 下列溝通六原則，就以 故事 總其成:

觀念溝通六原則 簡單 simple 核心 + 簡潔 意外 unexpected 吸引聽眾注意力 具體 concrete 使每位聽眾聽到同樣訊息 可信 credible 讓聽眾可查證 情緒 emotional 讓聽眾有感覺 故事 stories 讓聽眾心中模擬情境

觀念溝通 實例 1961 甘乃迪總統 提出下面與全美國溝通: 在十年內送人登陸月球 並讓他安全返回地球 這溝通吻合上述六原則 反之，若當時甘乃迪這樣說: 我們的目標是 靠著高度團結的創新 以及策略 指向的太空攻勢 成為太空工業的全球領導者 那麼溝通可能失敗，無法登月成功!

觀念溝通 實例 (Cont.) Nordstrom 百貨公司有兩套員工訓練簡報: 1) 超優的客戶服務是業務優勢之主要泉源 2) 有個員工免費給客戶包裝在 Macy (敵對的百貨公司)買的禮物 上述何者深植員工腦海? Ans: 2) 因為是一個簡單意外的故事

觀念溝通 新研究 XP 2010 Best Research Paper* 探討菁英團隊中,各人不懂他人領域下,如何溝通 Fagei用社會科學的 action research 研究組織如何導入 agile method.其論點是:要建立 redundant knowledge,各人才能溝通.其action是在 Scrum meeting 中用撲克牌做 team estimate of tasks 此 action 稍嫌簡單,但研究方法頗具啟發性 * T.E. Fagei, “Adoption of Team Estimation in a Specialist Organizational Environment”, XP 2010, Norway.

溝通 三小例 (1)某日陳教授看抄水錶員目視讀數以手持設備輸入 進步的溝通! (2)陳教授赴銀行匯款國外註冊費 手寫申請書 行員目視申請書再輸入電腦 但因”五百元“寫成”500元”重寫申請書 落後的溝通! (3)陳教授做使用介面測試 用setOut assertEqual寫“結束了\r\n”不能寫“結束了” 不順的溝通 (程式師易寫錯)

下面簡介 1 極限開發法 (ExtremeProgramming, XP) 12 實務 (practices) 5價值觀 3 Agile Method 源起 4 重視心理學的Agile 2011主旨演講

XP Practices 實務* 1. Fine scale feedback 細部回授 TestDrivenDevelopment via ProgrammerTests and CustomerTests (were UnitTests & AcceptanceTests) PlanningGame WholeTeam (was OnsiteCustomer) PairProgramming 2. Continuous process rather than batch 非批次流程 ContinuousIntegration DesignImprovement (was RefactorMercilessly) SmallReleases

XP Practices實務(Cont.) 3. Shared understanding 分享所知 SimpleDesign (DoSimpleThings, YouArentGonnaNeedIt, OnceAndOnlyOnce, SimplifyVigorously) SystemMetaphor CollectiveCodeOwnership CodingStandard or CodingConventions 4. Programmer welfare 員工福祉 SustainablePace (original name: FortyHourWeek) * http://c2.com/cgi/wiki?ExtremeProgrammingCorePractices

XP values價值觀[wikipedia] Extreme Programming initially recognized four values in 1999. A new value was added in the second edition of Extreme Programming Explained. The five values are: Communication 溝通 Simplicity 簡約 Feedback 回饋 Courage 勇氣 Respect 尊重 (see next page)

Respect 尊重 The respect value manifests in several ways. Team members respect each other because programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers. Members respect their work by always striving for high quality and seeking for the best design for the solution at hand through refactoring. Adopting four earlier values led to respect gained from others in team. Nobody on the team should feel unappreciated or ignored. This ensures high level of motivation and encourages loyalty toward the team, and the goal of the project. This value is very dependent upon the other values, and is very much oriented toward people in a team.

Fearlessness 無懼帶來 Aggressiveness 進取 Fearlessness (Aggressiveness) = Simplicity (do the simplest thing that could possibly work) + Communication (naming) + Testing (unit-test & acceptance-test)

Next, the NEW XP* proposes 13 primary practices, and 11 corollary practices. Totally, 24 new practices in 4 categories below. * Michele Marchesi, The New XP. [online]

Major Change 1. System Metaphor 2. Coding Standard. Note that 2 XP practices are NOT in the new XP practices: 1. System Metaphor 2. Coding Standard.

Major Change (Cont.) Project management is done by: Weekly cycle: both iteration and release are done in a week. Quarterly cycle: management reflection is done in a quarter.

Requirement Analysis and Planning • Stories: the functionalities of the system are described using stories, short descriptions of customer-visible functionalities. Stories also drive system development. • Weekly Cycle: software development is performed a week at a time. At the beginning of every week there is a meeting where the stories to develop in the week are chosen by the customer. • Quarterly Cycle: on a lager time scale, development is planned a quarter at a time. This is made up of reflections on the team, the project and the progress. • Slack: avoid to make promises you cannot fulfill. In any plan, include some tasks that can be dropped if you get behind. In this way, you will keep a security margin, to be used in the case of un-forecasted problems.

Team and Human Factors • Sit Together: development teams should work in an open space, able to host the whole team, to maximize communication. • Whole Team: the team should be composed of members with all the skills and the perspectives needed for the project to succeed. They must have a strong sense of belonging, and must help each others. • Informative Workspace: the workspace should be provided with informative posters and other stuff, giving information on the project status and on the tasks to be performed. • Energized Work:developers must be refreshed, so that they can focus on their job and be productive. Consequently, limit overtime working so everyone can spend time for his or her own private life. This practice in the old version of XP was called “sustainable pace” • Pair Programming: the code is always written by two programmers at one machine. This practice exits already in the original XP.

Design • Incremental Design: XP opposes producing a complete design up front. The development team produces the code as soon as possible in order to obtain feedback and improve the system continuously. Design is indispensable to obtain good code. The question is when to design. XP suggests to do it incrementally during coding. The way helpful to obtain this is to eliminate duplications in the code. • Test-First Programming: before updating and adding code, it is necessary to write tests in order to verify the code. This solves four problems: • Cowboy coding: It is easy to get carried away to program quickly and put everything in mind in the code. If we write tests and you have to run them, the tests help us focus on the problem at hand, and can prove that our design is correct. • Coupling and cohesion: if it isn't easy to write a test, this means that you have a problem of design, not of testing or coding. If your code is loosely coupled and highly cohesive, you can test it easily. • Trust: if you write code that works and you document it with automated tests, your teammates will trust you. • Rhythm: it is easy to get lost and wander for hours when you are coding. If you accustom yourself to the rhythm: test, code, refactor, test, code, refactor, it will not happen.

Software Coding and Releasing Ten-Minute Build: System should be built and all of the tests should be finished in ten minutes, in order to execute it often and obtain feedback. Continuous Integration: Developers should be integrating changes every two hours in order to ease integration headaches.

Corollary Practices Requirement Analysis and Planning: • Real Customer Involvement: people whose lives are affected by your system must became a part of the team and they can contribute to quarterly and weekly planning. • Incremental Deployment: when replacing a legacy system, start to replace some functionalities right away and gradually replace all system. Avoid the approach of “All or nothing.” .

• Negotiated Scope Contract: contracts for software development would have fixed time, costs, and quality, but the precise scope of the system would have to be negotiated during the same realization. Eventually it is better to have a sequence of short contracts in order to reduce risks. • Pay-Per-Use: customer usually pays for each release of the software. This creates a conflict between the supplier and the customer, who would want fewer releases each containing a lot of functionalities. Connecting money flow directly to software development provides accurate, timely information with which to drive improvement.

Team and Human Factors • Team Continuity: the development teams must remain the same in several projects. The relationship they share in a project are precious and they do not have to be dispersed. • Shrinking Teams: as the team becomes more capable and productive, keep its load constant but gradually reduce its size, send free members to form more teams.

Design • Root-Cause Analysis: every time you find a defect, eliminate it and its causes. In this way, not just you will eliminate the defect, but also you will prevent making the same mistake again.

Software Coding and Releasing • Code and Tests only code and tests are permanent artifacts and they have to be preserved. The other documents can be generated from code and tests. • Shared Code: anyone in the development team must be able to change any part of system at any time. This practice was called “collective code ownership” in the original XP. • Single Code Base: there is only one official version of system. You can develop a temporary branch, but it doesn't live longer than a few hours. • Daily Deployment: every night you must put new software into production. It is risky and costly to have a gap between the version of software released into production and ones you have in your computer

Agile 此詞源起 In 2001 in Utah, ”agile” was coined by the Agile Alliance to stress importance of: being able to respond to changing requirements within the project time frame. “Lightweight” was not adopted because it was regarded as too much of a reaction against something (“heavyweight”), and not enough of a belief in something.

Agile revisited 2001 Utah 盛會,17位大師簽署發表敏捷宣言 (Agile Manifesto),驚豔世人 倏忽十年,Agile 2011 conference 重返 Utah 舉行,其網站有大師感言 撼人心弦 Agile 2011 3 主旨演講 (keynote speeches) 談心理學, 請讀者注意此趨勢 下附簡介

Keynote 1 Fredrickson researches on how POSITIVE EMOTIONS help humans thrive and grow. Experiencing positive motions in a 3-to-1 ratio with negative ones leads people to a tipping point beyond which they naturally become more resilient to adversity and lead more agile, vibrant lives.

Keynote 2 Henney claims that CODE is the definition of the software, the realizer of business value, and the expression of understanding. In a broader sense, CODE refers to a set of conventions by which a group of people will govern themselves.

Keynote 3 Rising discusses the power of “agile mindset” that equates failure and problems with opportunities for learning, that believes that we can all improve over the time, and that our abilities are not fixed but evolve with effort. This mindset helps creativity and collaboration in and out of the workplace.

(Craftsmanship Manifesto) 從 敏捷宣言 (Agile Manifesto) 到 匠藝宣言 (Craftsmanship Manifesto)

軟體產業升級 Martin Fowler 在經典文章 The New Methodology 中回顧軟體產業升級歷史: 1) No methodology (code and fix) 2) monumental methodology (too much methodology) 3) agile methodology (BEST!) 產業要升級,台灣人不要做苦力,軟體產業升級絕非軟體園區樓房蓋的更高,專案人數更多,開發行數更多 而是要敏捷 高品質

敏捷宣言 1) 個人及互動 values Individual and interactions over 重於程序及工具 processes and tools. 2) 可用軟體 values Working software over 重於完整文件 comprehensive documentation. 3)與客戶合作 values Customer collaboration over 重於合約談判 contract negotiation. 4)因應變動 values Responding to change over重於遵循計畫 following a plan.

上面是著名的敏捷宣言 (Agile Manifesto) 標示敏捷時代的開始 下面是提高標準的 匠藝宣言 (Craftsmanship Manifesto) 此乃 Agile 2008 會後 專家討論出來的 乃精益求精 使敏捷度更高 軟體品質更高

匠藝宣言 1)Not only working software, but also well-crafted software. 2)Not only responding to change, but also steadily adding value. 3)Not only individuals and interactions, but also a community of professionals. 4)Not only customer collaboration, but also productive partnership.

匠藝宣言 不僅要 可用軟體 還要 精巧軟體 不僅要 回應變化 還要 穩定增值 不僅要 個人及互動 還要 專家群體 不僅要 與客戶合作 還要 有效夥伴

Craftsmanship Principles Uncle Bob Martin 在美國芝加哥催生 the 8th Light 軟體公司 該公司遵循匠藝宣言 厲行師徒制 養成軟體匠師(craftsman) 其軟體品質極佳 The 8th Light 依其實務經驗 為上述匠藝宣言的每項價值觀 整理出 3 條原則 (principles) 包括要做的事及不做的事 共 12 條原則如下

Well-Crafted Software We humbly demonstrate our expertise by delivering quality software. We do not inflate our abilities or claim expertise where we have none. We continually master a variety of technologies and techniques. We do not let unfamiliarity dissuade us from using the best tools. We take responsibility for the correctness of our code by testing it thoroughly. We do not tolerate preventable defects.

Steadily Adding Value We estimate with diligence. We do not let fear or pressure make us promise what we can’t deliver. We always apply our best efforts to complete our work. We do not make excuses. We work at a sustainable pace. We do not burn out.

A Community of Professionals We embrace differences of opinion and personality. We do not allow our current practice to impede improvement. We prefer open source tools that we can inspect, evaluate, and improve. We avoid proprietary products that lack transparency. We teach anyone with a willingness to learn. We do not hoard our knowledge or practices.

Productive Partnerships We show respect for our customers and fellow craftsmen. We do not act unprofessionally or unethically. We communicate our progress honestly and openly with our customers. We do not conceal or embellish. We partner with our customers to understand their business. We do not propose solutions until we are sure we have found the right problem.

Lean Development Lean development (瘦身精實的開發) 來自 Lean manufacturing 將瘦身製造業應用在軟體開發上 強調砍浪費 (eliminate waste) 包括不必要的開會 工作 文件 有一項浪費是 做以後會需要的東西 還要砍浪費的工作方式 如 multi-tasking 同時做多事 反而慢了

Lean Development (Cont.) 7 Principles: [wiki] 1 Eliminate waste 根除浪費 2 Amplify learning 大量學習 3 Decide as late as possible 盡晚決定 4 Deliver as fast as possible 盡早交貨 5 Empower the team 授權團隊 6 Build integrity in 整合思維 7 See the whole 眼觀全局

Lean Development (Cont.) Agile 強調從思維上進行人的改造 以新造之人組織嶄新軟體公司 是革命式的做法 Lean 強調從現有組織減去肥肉 除去浪費 是改善式的做法 在實務上二者很多雷同 印度的年度大會叫agile & lean 美國叫 agile 歐洲叫 XP WHEN YOU ARE AGILE, YOU GET LEAN. 敏捷之後 自然瘦身

下面，先解釋七個基本觀念 再以之建構出 溝通週期為基礎的 測 試 帶 動 法 陳教授的 myAgile 即是一套 具體可行的 測試帶動法

1.Pair Programming 雙人組開發 兩人配對即時溝通，有點像趣味賽兩人三腳； 加快開發及除錯速度，並激發創意 兩人快樂的肩並肩坐電腦前，同時注視螢幕，一人主導(drive)，另一人從不同角度思考，即時查核(review)，並可隨時交換角色 過程中隨時討論程式細節、做法，並藉由討論、爭辯，找到最佳程式寫法，隨時注意程式撰寫的小錯誤或邏輯錯誤，錯誤發生時則共同除錯， 以降低錯誤率和提高除錯效率 這樣可較快完成較佳成果(Better work in less time)， 會帶來工作驕傲感 (pride-in-work)

1.Pair Programming (Cont.) 1)工作驕傲感，即自慢(日語，慢者傲慢也)、自傲、自豪，有助培養強烈企圖心、不服輸鬥志、樂在工作中 在此”後工廠時代”，應揚棄下面工廠思維: 兩人做一事，人力成本太高 兩人整天交頭接耳，一定在混！ 此外要培養 2)公民意識(後敍)，3)敏銳注意週遭， 4)自發地行動 (act spontaneously)， 這四點可使團隊績效臻於顛峰 上述就是 群育，正是台灣教育的弱點之一 例子:[電視骨質藥廣告] 一老一少忙於佈置新店面，古董花瓶不小心被年青人撥倒，老人快步扶住，兩人相視一笑

1.Pair Programming (Cont.) 有程式師很自我 ego，不願與某人配對，應離職； 兩人互不願配對，兩人應離職 草莓族雖不耐操，但較不自私自大、反而較合群 例子:某路邊，中年人轎車亂停， 草莓族青年人機車反而都依照格子停 成員程度有高低，高高配、低低配可收切磋效果激發創意 而高低配則形同教學無切磋之效，但有管理之效 人其實不相等，二人行必有我師(三人行不精確) ，配對工作可促成團隊技術提升拉齊，每個回合(iteration)配不同人(輪調 rotation),大一計概開始做! 例子:某研究生團隊四人藉 pairing 由不懂到完成軟體! 大道至簡,溝通而已矣!

1.Pair Programming (Cont.) 如何深耕 pair programming? 陳教授認為要改變工作習慣 試想:遊玩時要有”玩伴”才愉快盡興,那麼學習時也要有”學伴”,兩人一齊在螢幕前複習教學投影片,才愉快有效 陳教授希望藉教學時推廣”學伴”,來厚植 pair programming 習慣

1. Pair programming (Cont.) 面對面溝通 效果最佳！ 1. 小張、老李 pair programs.(效果最佳) 2. 兩人用不同電腦，但肩併肩 (效果很好) 3. 兩人各據一角，背對背 4. 兩人在相鄰辦公室，有牆隔開 5. 兩人在不同樓層或相鄰大樓 6. 兩人在不同時區的城市 (效果差，有人加裝視訊設備， 叫 distributed pair programming， 效果並不好)

Pair Programming 好處 一個人的邏輯思考上常常會出現漏洞，兩個人的邏輯思考卻可以降低這樣的漏洞發生。Pair programming不僅可以提昇工作上的品質，更可以營造出融洽的工作氣氛，以往的programmer都是一個人撰寫一支程式，遇到問題才與同事間 相互討論的方式來解決，或是自己悶著頭上網找資料或想法；若是採用pair programming 的方式，兩個人可以在討論問題之餘穿插個閒話家常，這樣看似是在浪費時間，但是實際上是可以降低彼此腦部思考的壓力，因為一直想同一件事是容易想不通透的，那何不放下心情來降低腦中的壓力後再來思考，這樣對於事情的進展反而是更有幫助的。 [中央大學碩士 蘇友信 (Silver)]

Pair programming studies after adjusting, pairs produced code 15% more slowly than individuals... reference: http://qconsf.com/sf2008/file?path=/qcon-sanfran-2008/slides//NealFord_10_Ways_to_Improve_Your_Code.pdf

Pair programming studies ...with 15% fewer defects reference: http://qconsf.com/sf2008/file?path=/qcon-sanfran-2008/slides//NealFord_10_Ways_to_Improve_Your_Code.pdf

Reviewer vs. Supporter 一般 Reviewer 從不同角度思考,負責即時查核driver 工作,其工作量比 driver 少很多. 故可改為supporter.他除了以當Reviewer為主外,還負責:查API文件,局部程式的最佳化,測試不同API或不同演算法. Supporter須具備: 1)熟練的 Programming skill及 domain knowledge才能快速回應 driver 2)能隨時關注driver狀況,快速切換思考(不能像driver般,陷入深思) [中央大學碩士 王鈺歆 (Lala)]

Pair Rotation Rotation (輪調) 在 Pair Programming 中很重要 例如本次iteration 張三及李四一組 下次iteration 張三及王五一組 這使各人知識分散至其他所有人 可減低因人員流動而造成的知識流失 極有助於軟體演化(即軟體不斷維修)

More on Pair Programming Yes!動態,複雜,危險的工作常用之 如警察巡邏 Pair Programming 是否較耗人力? 不一定, 因 1 + 1 > 2 有相乘效果 且各人不能也不會混了

More on Pair Programming (Cont)

More on Pair Programming (Cont) 有人直覺的以為 Pair Programming 一案用兩個人做 耗費 人力 但其實不然 根據中央大學多年教學的經驗 兩人相互砥 礪 相當專注用心勞累但愉快 效果很好 反觀單人工作時 容 易恍神神遊 東摸西摸 而且心情悶悶的 不愉快 效果差 當然 職場上有主管指派一人做一案 以省人力 但如已建立 Pair Programming 文化 則做兩案的兩人也可不斷討論啊

Communal Table *共享餐桌 哲學家康德堅持不單獨用餐 而要三人以上九人以下共餐,故歐洲餐廳常有共享餐桌 反面例子是:常見六人入座餐廳寒喧後,各自玩 Face book - 這是偽社會網路 * 君子雜誌 Apr. 2012.

Collective Code Ownership 經過上述 Pair Programming 及 rotation 久而久之,團隊成員可大致了解他人寫的程式,甚至可維修他人程式-不畏員工流動了! 成員間信任感很高,重用(reuse)閱讀他人程式時,可快速主動改善之,而不必知會原作者或上級,使軟體在不知不覺中,不斷提升品質,再搭配測試碼把關,可確保品質 這形成程式碼不屬於原作者的共有制度 叫程式共有 collective code ownership

2. Re-factoring 重整 程式在保持原功能下 需不斷小幅改寫 以提升可讀性 (small behavior-preserving transformations)， 叫重整 需: 1.各人願意去改別人寫的程式；相對的， 高興自己程式被別人改進 (群育訓練) 2.程式人人易懂(設計草圖及虛擬碼解決此事) 3.程式修改後，要週密地重做測試 (test code,JUnit 解決此事) 重整後得新版本，存於版本控制系統 好處:interface不變時，因有測試碼保護，開發者勇於修改 舊程式(重整)，使軟體常新； 若interface改了，則要重做測試碼

Reuse 重用 vs. Refactor 重整 架構設計決定後,應盡量Reuse(重用)既有程式(不管是本公司別人寫的或未謀面的人寫的open source)以提高品質,且少耗力氣 另一更重要的是:程式要勇於 Refactor(重整),使程式脫胎換骨,品質爆增,有如地上醜醜人見人厭的蛹勇於蛻變,成了美麗飛翔人人欣羨的蝴蝶

3. Continuous Integration 持續整合 每個public method 寫完，用unit test code (後敘) 測完後，數小時內即整合進系統，不拖過夜 (隔夜就忘大半了) ，各個 method 是這樣持續地整合進去， 若某功能的 methods 都齊了，駐點客戶就手動測其驗收測試 這好處是: 以往痛苦的integration phase 不見了；現在，腦筋還記得當天寫該method 的細節，所以很容易整合

3. Continuous Integration (Cont.) Method 有其呼叫使用順序: 被呼叫者為下層 method 呼叫者為上層 method 最好先整合下層 method 進入系統 若先整合上層 method 則因其呼叫尚未在系統內的下層 method 會造成錯誤 這時應在系統內暫補 空的下層 method (它叫test stub)

3. Continuous Integration (Cont.) 傳統軟工的整合測試已在此巧妙完成了: 當各個 unit (method) 由下而上(bottom-up) 持續整合進系統時 (continuous integration), unit testing (單元測試) 也就成為 整合測試 (integration testing)了

4. Simple Design 簡約設計 簡約是任何設計的精髓* 透過CRC會議(後敘)的溝通，想出軟體系統中各class 及其之間的關係: 1) 各class 須呈現簡潔外觀 (interface)，與一致的格式 2) classes 之間的關係須: 簡潔(關係不可太多) 平衡(不可呈星狀結構) *設計簡約，質感出眾 [IKEA 桃園店標語] 反映北歐極簡、內斂風格 質感 > 品質 > > 質量

5. 交貨規劃(Release Planning) 由駐點客戶(後敘)主導的會議 (開發者必參加) 會中決定目前系統功能 (user stories) 要分幾次交貨(releases) 客戶需求不斷變動，故只第一個release (平均為兩個月)確定，往後releases，日後再修訂，這叫演化(evolve)；軟體不斷演化，不再有開發、維修之分，且演化使文件瞬間過時，故本法倡虛擬碼，隨時閱讀了解修改軟體

6. 回合規劃(Iteration Planning) 由開發者主導的會議 (駐點客戶必參加)會中決定”派工及時程”(工序四) 每個回合工作量不同，故其週數不固定，平均為三週*，這就是敏捷方法專案管理**。三週不長，故時程可嚴格控制，因而取信(甚至感動)客戶 * 石頭閒語網站認為:Ruby/PHP 生產力比Java 快5倍，可2-3天就推出release ** 傳統軟工專案管理常規劃一季(三個月)時程，軟體業一季中變動太大，專案經理通常無力控制時程

6. 回合規劃 (Cont.) 要在白板上精準寫出: 每個method 每個class 預定之工作天數 每天追蹤進度,才能依規劃完成該回合 之前交貨規劃時,會預估每個功能(user story)之工作週數 ,向客戶粗估時程, 這與上述精準控管不同

7. 站立日會* (daily stand-up meeting) 每個工作天，全體開發團隊成員 站著圍成一圈舉行每日會議，約十五分鐘 要站著，才可長話短說，使會議簡短 要全員，才使資訊直接傳達至每一人 要每日，才使溝通週期縮為一天 (昨日談的事，今日即可當面問) * 有專家認為既然團隊整天在一起,溝通已足夠,就不需此會議,但固定時間的日會可提醒大家溝通

Communication Cycle 溝通週期 不斷溝通、回饋、檢查、除錯、修改； 幫助人人成長、技術精進 回合規劃 站著 開日會 簡約設計 Pair Programming with On-site Customer 1..N Bugs CYCLE TIME 5 seconds 持續整合 重構 1..N Iterations 3 weeks 交貨規劃 1..N Increments 2 months 增量 增量加 上次交貨 測試碼保護中 1..N Methods 0.5day CYCLE TIME 1 day 喜好度調查 1..N Questions CYCLE TIME 5 seconds (Not in XP)

測試帶動的開發方法 (Test-driven development, TDD) 上面的溝通週期圖中，每個溝通圈走一圈(溝通要快而準)，就是一次測試，在週而復始的不斷測試中，優質軟體緩緩開發出來了! 例子: Pair Programming中，小張將 N-1寫成 N, 同伴老李馬上指正，這就是測試 例子: Pair Programming中, 駐點客戶 (on-site customer) 小王要求畫面字體加大，這也是測試 例子: 喜好度調查中，使用者小林回答對某功能喜好度(1至5,5表最愛)為: 1 (極不喜愛)，這也是測試

測試帶動的開發方法 (Cont.) Test-driven development (TDD) Test 原指狹義的: test case, test code, test tool 本法擴充 TDD 範圍，包含: 口頭確認 (check) 人工審查 (review) 等 廣義的 Test

測試帶動的開發方法 (Cont.) 某愛爾蘭軟體公司報導這種綿密測試，已使傳統軟工整合測試階段，幾消失無蹤，這得力於O-O，藉繼承及組合旣有class，嚴謹建構新的class 而且，本方法的專案不可能失敗，何也? 失敗專案乃是客戶在付出大筆金錢後，得不到預期效果，而失望、生氣、冒煙 … 而本方法兩個月後就要出貨，如客戶不滿意該貨，因只付出第一期款小錢，通常自認倒霉了事，不致冒煙

以上介紹 團隊溝通 也就是國外談的敏捷方法 以下簡短談談 個人思考及創意 這是陳教授補充敏捷方法的地方* * 有趣的是,Cockburn 以攀岩喻軟體開發時,同樣引用Csikszentmihalyi的flow(下頁)

專注的個人思考 Csikszentmihalyi [tʃɪ:k'sɛntmiha:ɪi] * 是創意研究大師，他說: 創意湧現 (Flow) 產生優質工作(good work) 此時工作極為專注，意志力集中，用心、堅持、獨持，思考深且密，將開發者個人思考推至極限 (extreme) * Csikszentmihalyi, Creativity: From Flow Experience to Good Work, 中大創意研討會, Nov. 29, 2006.

促成創意湧現 的三項條件 1. 全程各步驟目標明確 Clear goals in every step of the way. 促成創意湧現 的三項條件 1. 全程各步驟目標明確 Clear goals in every step of the way. 2. 行動有立即回饋 Immediate feedback to one’s action. (1)(2)正是測試帶動法的溝通週期 3. 挑戰與技能的平衡 (下圖) Balance between challenges and skills. (3)使開發者不斷長進(某員工由A,B,C,D 至 E)， 止於至善 E (flow zone)

高 D E 焦慮 (無安全感) 創意湧現 flow zone 創意湧現 挑戰 C A B 無聊(無成就感) 低 技能 高

Flow Zone 神馳狀態 Uncle Bob Martin 在其書 The Clean Coder 中 要大家不要進入神馳狀態 此時雙手快擊鍵盤 頗有風馳電制的快感 但日後可能需砍掉這些未深思熟慮的”垃圾” 在 myAgile 中 工序規定嚴格: coding 之前要先開發 pseudocode 且是 pair programming 所以不應有此現象

壓力的來源 自然醫學醫師指出,人的壓力的來源有二: 1) 無安全感 及 2)無成就感 * 與上圖不謀而合,要消除壓力,工作才有創意 所以軟體若要有創意,則員工不能有壓力 * 陳慕純 徐大智 身心舒壓好睡眠 聯合文學 2010.

優質工作 (Good work) 生產性活動(productive activity): 1.滿足工藝水準 (所謂craftmanship) (meet the requirements of the craft) 2.有益社會，且獲重視 (socially useful and valued) 3.本身獲益 (personally rewarding)

創意湧現 經驗一 專注幾個點 完全專注、全面投入 創意湧現 經驗一 專注幾個點 完全專注、全面投入 Attention is focused on a limited stimulus field. Full concentration and complete involvement. 例子: 某西洋棋士說: 專注有如呼吸，你從沒想到它 (Concentration is like breathing: you never think of it)；專注時，就算屋頂塌了，只要沒打到你，你甚至沒查覺到!

創意湧現 經驗二 不再擔心失敗了 There is freedom from worry about failure. 創意湧現 經驗二 不再擔心失敗了 There is freedom from worry about failure. 例子: 某自行車選手說: 你覺得..沒有東西可阻擋你。你已準備好應付任何事情。不怕任何可能發生的事，真令人振奮！

創意湧現 經驗三 對時間的感覺扭曲了 Sense of time distorted. 例子:某舞者說: 兩件事發生… 創意湧現 經驗三 對時間的感覺扭曲了 Sense of time distorted. 例子:某舞者說: 兩件事發生… (1)練舞後，時間似乎過得很快，時已凌晨一時，我說”喔，幾分鐘前才晚上八點 (2) 可是，當我練舞時，時間好像過得比真正時間來得慢

神清氣爽 才能專注 * 但若敷衍應付瞎忙八小時，則不適用此! 新XP準則叫它sustainablePace 可持久的步伐 神清氣爽 才能專注 極限開發法有一實務：不可加班 (No overtime) *，饒富啟發性: 創意工作要精神飽滿、愉快，才能工作專注，創意湧現，才獲高品質作品；如加班、熬夜，次日精神不濟，品質危矣！進而，週休二日應徜佯青山綠水或悠遊藝文活動，或好好睡到飽，充份休息，才能神清氣爽、從容自若 * 但若敷衍應付瞎忙八小時，則不適用此! 新XP準則叫它sustainablePace 可持久的步伐

創意的重要性 世界有可能從 資訊時代 進入 觀念時代 這時 創意 將是最重要的

創意學* 國內學者賴聲川以舞台劇**創作經驗, 研究創意學,他認為創意來自: 1) 深刻人生體驗帶來的洞察力 這方面叫:靈感 ,想像力 是感性工作 2) 工程方法(即軟工)的認真執行 並以適當形式呈現 這方面叫:製作 ,組合力 是理性工作 * 賴聲川,賴聲川的創意學,天下雜誌,2006. **舞台劇與軟體並非不相関，軟體常用的 scenario 即是舞台劇場景

實例 某舞台劇將三個靈感串成故事: 1) 台大醫院五號垂死病人講他的故事 2) 他去法國鄉下古堡看到一幅畫 畫中有中國女子 3) 他去中國上海找尋畫中女子

實例 (Cont.) 上面第二個靈感來自: 某次賴聲川到羅馬看畫展 看到一幅畫,畫中有畫 他當時記下小扎: 故事中可套著故事 這就是他的一個 人生體驗

實例 (Cont.) 各個人生體驗已分別儲存成腦海的檔案, 創作時,心自動找檔案串在一起,形成創意 但要慎防: 心受習性蒙敝,而無法串出創意 戲劇是人類 抽象思考 的精華[飛碟電台 2009春節] 而抽象思考正是軟工的首要工作,值得深思

軟體業例子 1) 小王某次看到某網頁呈現方式 日後用到他的作品 2) 老李讀到某論文的演算法 日後用到他的設計 3) 小林上網搜尋,找到某個API (application program interface) 日後他的程式呼叫之 上述皆基於各人的 人生體驗

人生體驗 例子 1)某人參加觀光團,走馬看花,遊歷多國,還留影為證,但毫無體驗 2)某學生很會應付考試,修課證照無數,但無深入理解體會,無法在工作上好好運用 3)因無英文課,某研究生自高三後很少唸英文,可見英文只是學分,與人生無關 4) 某人喜歡聽英文歌,很投入,所以聽懂歌詞且受感動,這就有了人生體驗

方法

試行團隊 國內軟體公司如有決心*、專注力，可組本 myAgile 方法試行團隊如下: 1. 一名駐點客戶 2. 四名軟體工程師，形成兩組(2 pairs) 3. 二名兼職工讀生 依前述辦公室佈置，run下面 myAgile 方法 甚至以創新創業起步團隊 申請國科會補助創業金 技術入股 創業板上櫃等等 * 依陳教授顧問經驗，老闆有心改變採用新方法，而開發者雖然認真聽課，但工作時還是用自己熟悉有把握的舊方法，沒有專注力及決心 拋棄過去的做法

myAgile 重點 需求工程 (Step 0, 1, 2 see next page) myAgile 由簡而繁寫多個 驗收cases 比傳統軟工只寫一個case 更為加強 架構設計 (Step 3, 4, 5, 6) myAgile 採用 XP 的 CRC 快速做架構設計 又用 逆向工程工具自動獲得設計圖 免畫圖. 細部設計 (Step 7, 8, 9, 10) myAgile 採用 design sketch, pseudo-code 相當細緻

myAgile 敏捷方法 myAgile 係陳教授運用上述觀念，補充極限開發法 (Extreme Programming, XP)所得 是高度理想性做法， 須與業界現行做法磨合，逐步改善-不妄求一次到位 這方法適用十人以內(含)小團隊，而全世界很多優質軟體，是小團隊完成的 又因為大型團隊(如100人)會做組織細分(organizational breakdown)，所以其底層也是小團隊(如10個10人團隊)，故亦適用之，而其上層則需其他簡易管理方法

myAgile 敏捷方法 (11道工序) + 0.探索需求 (Exploring requirements) * 1. 使用情節 (Scenario) * 2. 驗收測試案例及使用手冊 (Acceptance test case & User manual) 3.架構設計會議 (CRC session) + 4.逆向工程工具 (Reverse Engineering Tool) 5.派工及時程 (Dispatching and Scheduling) 6. 單元測試碼 (Unit test code) + 7.資料結構設計 (Data Structure Design) + 8. 演算法設計 (Algorithm Design) 含設計草圖及虛擬碼 9. 補上程式碼 (Coding) 10.單元及驗收測試 (Unit & Acceptance testing) (陳教授補充+工序, 加強*工序 ,另外即 Extreme Programming)

誠摯的叮嚀 myAgile 十一道工序都 似易實難， 因為其理念與台灣現行方法大不相同， 要扭轉思維、換腦袋，超難！ 尤其，若圖反敗為勝，立足國際， 更須用心做好，是難上加難！！ 我們絕非嘩眾取寵，已針對每道工序，設計實習課程，公佈於苗圃網站，敬供參考

myAgile 適用範圍 本法適用Java,C++,C#等傳统高階語言 不適用網路時代更高階語言 如標記語言 (mark-up language) 精準說: C/C++思維較舊,C#仿Java; Java已具O-O思維,進一步要提升至agent思維 - 計概應直接教 C 及 Java!

0.探索需求* (Exploring requirements) 客戶公司兩位資深人員做需求分析如下: 1.列出使用者名單， 如電梯資訊裝置案區分: 友善(如殘友) 不管(如文盲) 不友善(如強盜) 2.選取使用者樣本 3.觀察、訪談(2)，與之開會 4.開會要充份討論 - 腦力激盪(用左腦語文) 腦力繪圖(用右腦視覺) 以增加想法； 減少語意曖昧、投票過濾 以刪減想法 * Gause and Weinberg, Exploring requirements, 中譯本 從需求到設計, 2007.

0.探索需求 (Cont.) 5.會後得到功能清單，及相關特性、限制、偏好 例如:電梯資訊裝置案 功能 feature, user story (如:語音提示樓層) 特性 attribute (如:快速提示上述資訊) 限制 constraint(如:獲得該資訊要少於1.75秒) 偏好 preference(如:上述少於 1秒價值一百萬元， 也許使用者不喜歡語音提示太快 少於0.05秒價值二十萬元) 6.功能分次開發後，做喜好度調查

1.使用情節 (Scenario) 駐點客戶(on-site customer)(前工序兩人之一)逐步用文字寫軟體某功能 (user story) 的使用情節(scenario)，用A4紙以鉛筆記錄之，字跡工整可讀，不可鬼畫符；阿拉伯數字要慢寫清晰 探索找尋各種使用情節 - 由簡單而繁雜，由正常(normal)而異常(exceptional) 同類 scenarios 存放同file ，可用editor快速修改 例子: 遊戲軟體最簡單的 ”情節一”: 1.看到welcomeScreen (圖一)* ，輸入password 2. 看到 mainScreen (圖二)*，離開系統 * 在白板畫出各圖

1.使用情節 (Cont.) 傳統常做 流程圖 (Flow Chart) 它與虛擬碼 (pseudo code) 的抽象層次相同,只是表示法不同,而本法採用虛擬碼 一個虛擬碼會對應多個使用情節(雖抽象層次高很多) 例如虛擬碼中 if then else 對應兩個使用情節(分別執行then及else)

2. 驗收測試案例及使用手冊 (Acceptance test case & User Manual ) 上述每個使用情節, 加上輸入資料及預期輸出資料後,即做為測試該功能可否驗收之依據, 叫一個驗收測試案例 也就是依每個案例跑程式;如順利跑完，則該驗收測試案例(acceptance test case) 通過 例子: 遊戲軟體最簡單的”驗收測試一”: 看到 welcomeScreen，輸入password Chen123後， 看到 mainScreen，點選 Exit，離開系統 之後，整理驗收測試案例的重要畫面成使用手冊

User Manual 驗收測試案例稍加修改簡化 ,可輕易得到 User Manual (使用手冊) 記得:文件是動態的,驗收測試案例隨時變動,所以 User Manual 也是隨時變動的,也就是隨著程式碼不斷變動, User Manual 要跟著變動

3.架構設計會議 (CRC Session) 架構設計會議常使用CRC(Class,Responsibility, Collaborator)會議：五人以內圍坐(二人亦可，國內單人專案多無切割，兩人先溝通切割系統吧) ，執行驗收測試案例，推敲切割(partition)之, 找出物件(object)及物件互動(object interaction，即method)，須含下層隱藏物件(hidden objects),用小卡片(CRC card,可用A4紙)記錄: 1.Class name (C), 2.要做何事 Responsibility (R),(將轉為 method) 3.要誰合作(即需呼叫誰的 responsibility) 叫 Collaborator (C) 會議後所有 CRC cards 即系統架構(class interface)， CRC card 中 (1)(2) 找class encapsulation, (3) 找 class use relationship 此會議是群體智慧- 腦力激盪，快速溝通 真相: 大型軟體從未在架構師腦袋，而是多個程式師共同擁有

3.架構設計會議 (Cont.) 1. 對每個 accep. test case 由第一步驟出發，大家討論: 要有那個 object 執行那個 method，接著 又有那個 object 執行那個 method … 直到最後步驟 2. 討論中，用一張A4紙記錄一個class及其methods， 並指定專人扮演這class (即CRC) 3. 會後，檢視所有A4紙，並調整之(如某些classes 可合併) 即得 class interfaces (軟體架構) 4. 架構定案後，各 method 要寫好 header(寫入.java檔) (method description, parameters, return value, exceptions) 1.parameters 不超過 5 個 (magic 7 minus 2) 2.return value 是一個 object, 但寫出的是其 class 3.原則上禁用 global variables

3.架構設計會議 (Cont.) CRC集思廣益來切割(partition)驗收測試案例,並找出user看不到的下層隱藏物件(hidden objects) (紅色表示) 例如: 張三是位官兵 李四是個土匪 張三要用繩子捉拿李四** 李四問王五綁何處 (王五是位醫生) *一般英文書用John, Mary為物件名, 國人感受不深, 故用張三等 * 底線表class,object 粗體表method 斜體表parameter **直覺的說: 張三用繩子捉拿李四 但 O-O程式不是這樣執行的 method捉拿屬於土匪

3.架構設計會議(Cont.) 由上述 可得下列設計: class官兵{..} 官兵 張三; class土匪{.捉拿(工具)} 土匪 李四; class醫生{..綁何處 ( )} 醫生 王五; ..... 李四.捉拿(繩子); …… 綁處 = 王五.綁何處 ( );

3.架構設計會議(Cont.) 複習一下本例基本觀念: User Story (功能)是:張三捉人 Scenario 是:張三要用繩子捉拿李四 Use Case 是: (這文件併入架構設計文件) 張三要用繩子捉拿李四 李四問王五綁何處

張三捉李四的真相 的確是張三下令要捉李四,但張三沒動手 張三把繩子給了李四* 然後李四毫不猶豫執行捉拿動作** 而張三不知道動作細節(綁手或腳),執行後系統會回報結果給張三*** * The method gets one input argument. ** then, it executes the method, *** finally, it sends return value.

架構設計的重要性 專案如沒做好架構設計，將導至物件不吻合客戶觀念，即 O-O 失敗! 同時，無良好切割常有太大模組， 無法找到完整測試狀況 (test cases)，使品質差 模組切細後單元測試狀況可完備 而且重擔集中在寫大模組那一人，無法平衡分工teamwork 不良 架構設計切割出的class, public method 要寫class interface，再補充成標頭(header)

Class Interface 的好處 1. 藉精準命名 class names, method names 捕捉客戶觀念，以落實物件導向(O-O)開發；如客戶不懂這些 names，此時尚未開始寫程式，即已確定 O-O失敗! 2. 可依之分工，多人併行開發各 class， 以加速軟體交貨；高速度交貨很重要 Class interface 補充後成為 class header 內有 method headers

Class Interface 例子 /*稍後 data structure 在此 (目前不含)*/ Selection Sort 的class interface 如下: public class mySort { /*稍後 data structure 在此 (目前不含)*/ public mySort (int inputArray[]){ } public int [] sort ( ) { } } // end of mySort method interface

確認 物件 駐點客戶要確認: 物件是否吻合客戶觀念: 1. 將class names, public method names (英文)列一清單， 刪除底層電腦相關 names，如資料庫class 2.不加任何書面或口頭解釋，將清單給多位領域專家 3. 專家們逐一確認上述 names ： 如了解，則打勾；如不清楚，則打Ｘ 4. 統計打勾比例，如100 個 names 平均有 80 個打勾， 則 O-O 80% 成功！

為何要確認 物件? 軟體必須精準反映領域知識(domain knowledge) 才易不斷維修 軟體才活著 而領域知識就是領域專家們的知識 所以要確認軟體用詞吻合 領域專家們(domain experts)的用詞 例子: 會計軟體中 class Names 如 BalanceSheets, Accounts 等; object Name 如 sep09Account; method Names 如 debit 借, credit 貸

Interface and Header (標頭) Class interface and method interface 之前都需要文字說明, 以便維修者閱讀了解之 這文字說明就叫 Header (標頭)

標頭(header)的重要性 搜尋、閱讀 open source 的標頭，才能重用程式(reuse code)；與開發程式(developed code) 相較，它較優質，應優先採用：1)因大眾測試過(可信任)， 2)並有效能評估(Big O time estimate) 大量重用程式，小團隊(small project size, team size)能快速完成優質大軟體(big problem size) 開發程式行數(Line of code)無甚意義了

標頭的重要性 (Cont.) 標頭有點像程式碼的使用手冊，常見一般人使用電氣用品不讀使用手冊(有時因使用手冊艱澀難讀)，易把東西用壞，修幾次後就不能修了，只好丟棄，很不環保 標頭也像報紙標題，要能助讀者輕鬆讀報 標頭要寫好，程式碼才能易讀易修， 活得長長久久

Interface 的重要性 有次安裝冷氣機後,工人開冷氣開關,但是冷氣機不動,於是拆開冷氣機檢查,花了很大力氣,找不到冷氣機的問題,後來才發現是: 電氣總開關中,冷氣開關標示位置錯誤 對應到軟工領域:有次開發軟體時,軟體不動,於是工程師 debug source code,後來才發現是: API (application program interface) 的 header 寫錯了

Header(標頭)設計原則 Header要醒目易溝通[寫給大家的平面設計書,R. Williams原著,三言社,2006] 舉數原則: (後面有例子) 1.利用空白將相似項目放一起 形成視覺單元 2.每頁不超過五個單元 3.各單元要對齊 形成視覺聯貫性 4.要重複重點(如粗體字) 營造一致性風格 5.要強烈對比(如粗體字與標準字) 營造視覺焦點

Header(標頭) 兩例 /* method subString ---------------------------------------------- * A String object呼叫此 method，傳回介於兩個指定的 indexes 的子字串 * * @param beginIndex 子字串起始的 index (含此 index) * @param endIndex 子字串最後的 index (不含此 index) * @return 由 beginIndex 到 “endIndex 的前一個位置” 的子字串 * @throws IndexOutOfBoundsException – * if beginIndex 是負數 or * beginIndex 大於 endIndex or * endIndex 大於 length() * Time estimate : 演算法設計後，才獲此資訊，如 O (n) * Example: “helloworld”.subString(3,6) ; 傳回結果為 “low” -------------------------------------------------------------------------*/ public String subString (int beginIndex, int endIndex)

*------------------------------------*/ /* class EventDetectionThread ----------------------------------- * * 本 thread 產生 detector,它start後,每0.5秒(500 ms)到預設的./buffer資料夾抓取(fetch)一個event information(.xml)的path * 並通知observer (叫 event parser) 此path. * 如資料夾是空的, 則回傳null. * Example: * ./buffer資料夾有存進來的三個event information: * 091123153040000.xml (最早存進來) y09 m11 d23 ms0 * 091123153040500.xml y09 m11 d23 time1530 ms40500 * 091123153041000.xml (最晚存進來) * detector 依序抓取 091123153040000.xml 等等 *------------------------------------*/ 註:如寫detector=new EventDetectionThred();則不夠abstract

工序一至三片段例子 工序是前後聯貫的 例如: 1.Scenario: show finish message (msg) 2.Acceptance test case: show finish message (msg) “結束了” 3.Architectural design: /*------------------------------ show finish message “結束了” -------------------------------*/ public void showFinishMsg()

4. 逆向工程 工具 架構設計有時憑空而起(from the scratch) 但是大部分時候是維修既有軟體 軟體公司希望修改最少程式 來滿足驗收測試 這時要利用逆向工程工具 1.列印出既有架構 2.用鉛筆橡皮 反覆討論 修改架構 得新架構 3.逐一檢查驗收測試 確認新架構滿足之

4. 逆向工程 工具 利用逆向工程 工具 如 eUML2,AgileJ 可由程式碼(source file；不含 reused code) 動態產生 class diagram, sequence diagram 等設計圖文件，供了解軟體全貌、決定維修那個class 及 檢查相關classes (為了解軟體全貌，main program 之前也要有標頭:系統描述、重大決策) 這有可能敏捷達成 CMMI 一些 process areas 的 goals 從CRC工序後 即可隨時使用此工具產生設計圖

4. 逆向工程 工具 (Cont.) 一般人常直接 coding source code 這種 source code 輸入逆向工具後 產生的 class diagram 亂七八糟 慘不忍睹 反映出 軟體設計品質低落 的 真相 雖另有工整的 工具畫的 class diagram 但那與 source code 不符 造假的！

Class diagrams generated by tool

Sequence diagram generated by tool

傳統軟工設計 架構師(architect)花一段時間，完成 class diagram，用 unified modeling language (UML) 表示，用 Rational Rose 製出文件，局部組成關係如下圖: (輪胎是組成車子的一部分) 車子 輪胎

傳統軟工設計(Cont.) 如果去檢查程式，理應找到: class 輪胎{…} class 車子{輪胎 右前輪=new 輪胎(); …} 以對應上面的設計，但 真相是: 那 class diagram 只是架構師個人構想，與程式師想法不同，文件淪為 乩童道具! 基本動作已不確實，較複雜的 design pattern, component 如何落實?

例子:架構師畫的class diagram 吉普車繼承(inherite)車子;1人員使用(use)1吉普車 2 2 人員 吉普車 輪胎 車子

傳統軟工設計(Cont.) class 吉普車 extends 車子 { the extended data and methods} class 車子 {輪胎 右前輪=new 輪胎() …; int 哩程; public boolean 駕車 ( ) {…} } class 輪胎 {…} class 人員 {… } 小張=new 人員();老李=new 人員(); 吉普車 車1 = new 吉普車( );吉普車 車2 = new 吉普車( ); /*小張執行某method*/ ….. 車1.駕車 () ; /*老李執行某method*/ ….. 車2.駕車 () ; 依物件互動顯示 小張駕車1 老李駕車2 class diagram 應該只看到人員、吉普車兩個 classes 並非架構師畫的四個 classes:人員、吉普車 、車子、輪胎 敏捷軟工在此糾正傳統軟工的失誤!

傳統軟工設計(Cont.) 真相是:在開發吉普車時，搜尋標頭才發現可繼承之前的車子(inheritance);而之前開發車子時，利用組成關係(composition)，重用更早之前開發的輪胎;之後 用逆向工程工具則會看到四個 classes 所以,O-O設計時,一開始只有use, composition 關係 接著,才出現 inheritance 關係 進一步,一些 classes 可套用 design pattern

傳統軟工設計(Cont.) 例子: 兩個軟體工程師互誇: 小王: 我的O-O 程式有三層繼承 小林: 我的有四層! 誰應加薪? 真相: 通常軟體使用一段時間(如半年)後，客户才會要求延伸原軟體(即繼承) 當然，重用時修改旣有軟體，會有繼承，但不至於三、四層

傳統軟工設計(Cont.) 例子: 兩個軟體工程師風格迥異: 小王: 某程式寫二百行很快寫完 小林: 上網查API直接reuse 一行也沒寫 誰應加薪? 真相: 小林應加薪 因reused code不需測試 且日後永不需維修

傳統軟工設計(Cont.) 例子: 兩個軟體工程師風格迥異: 小王: 很快開發完20K的class 小林: 仔細推敲不同切割方式 最後完成 多個 2K 的小classes 誰應加薪? 真相: 小林應加薪,因為他完成 well-crafted software, 而小王只完成 working software

5.派工及時程 依上述軟體架構 (class interfaces)， 各個 class 由團隊成員”認領” 即為派工(真義是: 領工) 由認領本人依本身狀況，估計工作天數，乘公司經驗值寬放係數後，即為時程 本回合內每天嚴守時程，即可精準交貨，以執行力達成承諾 才能取信、感動客戶* *國興電視”全能住宅改造王”注重生態文化，工匠極致矣 下圖白板上顯示 Mary Ann 回合 的派工資訊

Cockburn, Agile Software Development, p.86, Addison-Wesley, 2002.

5.派工及時程 (Cont.) Release 交貨 vs.Iteration 回合 (有人叫疊代) 只對目前回合(二至四週，平均三週*) 做派工及時程規劃，回合可打出進攻節奏(pace)使團隊威猛快速 (strong heart-beat) 每回合後微調方法(methodology tune-up) 每一至四個月(平均二個月)交貨給客戶** *用Ruby/PHP(而非Java)可縮短時間；用組合語言，則增長 ** 不斷交貨(即演化 evolve)，已無開發、維修之分

Release交貨 Increment增量 Iteration 回合 約二個月 虛線表示：不確定、可變動 增量 1 增量 2 交貨 1 交貨1 +增量2 =交貨2 約三週 回合 (派工及時程)

6.單元測試碼 (Unit test code) 對某 class 的每個 public method (叫單元 unit)先想出多種測試狀況 (test cases)由簡而繁(最簡如 null input)由正常而異常 (異常exceptions 若 handle 不好，軟體將不好用) 每一狀況寫出輸入 (input) 及預期輸出 (expected output) 叫一個單元測試 (unit test case)；再改寫成測試碼 (test code) 相對於他國，國人工作文化較急燥，所以更需要做好單元測試碼 做為程式護身符 程式一有維修，即全面重跑測試碼，可確保品質

Test Code Example //Test Case 1：input {3,1,4,2} expected output：{1,2,3,4} public void testSort1() { 　/* input為待排序數列，expected為預期結果, result為實際結果*/　 int input[] = {3,1,4,2},expected[] = {1,2,3,4}; int result[]; /* new 一個 mySort的物件，傳入參數input */ mySort obj = new mySort(input); /*呼叫sort來排序*/ result = obj.sort(); /* assert實際結果與預期結果是否 equal */ assertEquals (toString(result), toString(expected)); }

Test Cases As Test Code Header //Test Case 1: input {3,1,4,2} expected output：{1,2,3,4} //Test Case 2: input {1,1,1,1} expected output：{1,1,1,1} //Test Case 3: input {3,2,4,2} expected output：{2,2,3,4} public void sortTest1() { /* input為待排序數列，expected為預期結果, result為實際結果*/ int input[] = {3,1,4,2},expected[] = {1,2,3,4}; int result[]; …….. public void sortTest2() { …… public void sortTest3() { ………

More on Test Cases O-O 程式呼叫為: o2 = o1.m1(p1,p2) * 本法找出不同 input parameters (p1,p2), output object (o2)的組合,每一組合為一待測試的狀況, 即 test case ** 但 o1 (object 1) 內也有多種組合,這需setter 設定 object 內 data value *嚴格講, 呼叫時傳入 arguments, method 本身則寫 parameters ** 若無參數 m1() 則只有一個 test case 就是 object 的 value

More on Test Cases (Cont.) 舉極簡例: 先開發 method interface: /*加 a,b,回傳其和*/public int add (int a,b) {} 1.a,b 各有正,零,負三狀況,共有九狀況: Case 1: a is 1, b is 2 (正,正) Case 2: a is 1, b is 0 (正,零) …… 2.將 9 test cases 寫成 test code 3.再開發 source code 即 { return a+b;} 4.最後用Junit跑test code測source code

Test-First Development (TFD) Agile 先開發 test code 再開發 source code 故又叫 test-first development 維修時 1)先依需求開發 test code 一開始它必須FAIL(因尚未維修source code) 2)再修改source code使test code PASS 這樣反覆做 就可以最簡單方式滿足需求 其中又不斷 re-factor source code 使之達到 simplicity 目的

7.資料結構設計 (Data Structure Design) 對每個 class，要設計這 class 所含的 public methods 共同要用的 data 儘可能設計出 high-level data structure 如tree 而非 low-level data structure 如array 這樣可簡化 演算法設計 使之易於思考

7.資料結構設計 (Cont.) 建議使用Java Collections Framework (JCF) * 含下列三種離散數學觀念及其 classes： 1.List如<1,2,3>: ArrayList, LinkedList 2.Set 如{3,1,2}: TreeSet, HashSet 3.Map 如{1->a,2->b,3->a}: TreeMap, HashMap (本例 1叫key, a叫value) 另有 PriorityQueuee JCF method 都有 Big O，使開發的 method 也有 Big O 例子: for each i 從1 到 N call TreeSet method with O(logN) end for 即得 O (N logN) * Collins,Data Structures and the Java Collections Framework, McGraw-Hill, 2005.

Class Interface & Data Strucure class Adjacency protected HashMap <Houses, LinkedList<NeighborDistances>> adjacencyMap; protected TreeMap <Houses, TreeMap<Houses, Double>> adjacencyMap; void showAllAdjacencies (Houses theHouse) void showNames (HouseList houseList) end Adjacency 上面藍色及紅色是兩種不同資料結構設計 TreeMap worst time O(logN) 較佳

adjacencyMap null 5 17 57 87 95 100 (to) (weight) (next) Don 20.0 Tara 15.0 null -303674281 Courtney null (hash) (key) (value) (next) 68899 Don null 2599292 Tara null Mark 10.0 Don 7.4 Courtney 15.0 null 72266597 Karen null 2390765 Mark null Tara 8.3 null

Sort 設計草圖 用紙、鉛筆、橡皮擦、尺描繪出設計草圖 首先從數列中 select 出 min（即 數值 1），並放到數列的第一個位置（即 索引 0）。 索引 數值 1 .. .. n-2 n-1 3 1 4 2 固定此數不再變動。 1 ( i ) .. .. n-2 n-1 1 3 4 2 再從剩餘數列中 select 出 min（即 數值 2），並放到剩餘數列（即 索引 i ~ n-1）的 第一個位置 （即 索引 1）。 1 ( i ) .. .. n-2 n-1 1 3 4 2 固定此數不再變動。 1 .. .. n-2 ( i ) n-1 1 2 4 3 依此方式直到走訪完， 走訪至數列倒數第二個數（即 索引 n-2）。 ： 1 .. .. n-2 n-1 1 2 3 4 即完成數列小到大sort

抽象精準的思考 Design sketch and pseudo-code 協助高階抽象精準的思考 利用這點可輕鬆 trace to bug 例如:從上面設計草圖可看到數列(反白)由大而小 由 0..n-1 到 n-2..n-1 左邊界線 由 0 到 n-2 這就確定pseudo-code的外迴圈 index 由 0 到 n-2

7.資料結構設計 (Cont.) 資料結構設計與演算法設計互有關連， 若前者高階 則後者精簡、品質高 目前很多人寫程式，不落實資料結構設計，直接進入演算法設計，甚至直接進入程式設計，其資料結構只用很多基本的陣列 (array)這使得演算法繁複，導致程式冗長，不易閱讀維修

7.資料結構設計 (Cont.) 有學生問: 如要存放一些資料到 array 那麼資料結構就用Java array就好了 何必用高階資料結構 ArrayList呢? 答: 用ArrayList 可auto-resize (自動擴充) 當長時間使用後 array資料滿了 這功能使系統不致 overflow 當然比用低階的 Java array 要維修程式擴充空間 好太多了

8.演算法設計 (Algorithm Design) 先依資料結構及單元測試，畫出設計草圖 (design sketch)並寫下當時的解題想法，再用英詞中句的虛擬碼 (pseudo code)寫出該想法，此即演算法設計 要依不同抽象層次 (abstraction levels) 由上而下逐層寫出虛擬碼 每層都要 trace test case來debug，即演算法設計 除錯 最下層虛擬碼即演算法，要做時間估算 (time estimate)， 若時間太長，如O(n3)，則重做資料結構設計 若演算法超過一個畫面，則分割出下層 private method， 這可使演算法清晰呈現 (若只有程式碼，無法呈現演算法) 演算法可投影牆上，做 團隊審查 (group review)

設計草圖

虛擬碼設計一 public Tokens[] getTheTokens ( ) //see youTube “compiler lab1 scanner” Tokens aToken // next token in the line String line //the current line being scanned   private skipBlanks () if (endOfLine) then do nothing else while (tokenBeginning points to a blank) increment both tokenBeginning & forward end while end if end skipBlanks()

1 open sourceFile 2. read first line into “line” 3. forward,tokenBeginning ← 0 4. while (not endOfFile) 1. call skipBlanks( ) 2. if (endOfLine) then 1.read next line into “line” 2.if (not endOfFile) then forward,tokenBeginning ← 0 end if else 1. get aToken (“tokenBeginning” to “forward-1”) 2. store aToken into theTokens 3. tokenBeginning ← forward; end while 5. return theTokens end getTheTokens()

改善虛擬碼 虛擬碼設計一的缺點: 1: skipBlank() 內不只跳過空白字 還要檢查 end of line 太複雜 2. 若把上述end of line 檢查移到上層calling program (getTheTokens) 發現 有兩次end of line 這須化簡 改善後 得到虛擬碼設計二

虛擬碼設計二 public Tokens[] getTheTokens ( ) //see youTube “compiler lab1 scanner” Tokens aToken // next token in the line String line //the current line being scanned private skipBlanks () while (tokenBeginning points to a blank) increment both tokenBeginning & forward end while end skipBlank ()

1 open sourceFile 2. read first line into “line” 3. forward,tokenBeginning ← 0 4. while (not endOfFile) if (endOfLine) then 1.read next line into “line” 2.if (not endOfFile) then forward,tokenBeginning ← 0 end if else 1. call skipBlanks( ) 2. get aToken (“tokenBeginning” to “forward-1”) 3. store aToken into theTokens 4. tokenBeginning ← forward; end while 5. return theTokens end getTheTokens()

Why 增加兩種文件? XP 常被批評文件不足，又斟酌台灣國情， 故增加兩種文件: 1. 設計草圖 (design sketch) 寫在白板或白紙，短暫儲存 重要草圖可貼入文字檔長久儲存 2. 虛擬碼 (pseudo code) 寫在文字檔(如Java file)可與程式融合， 長久儲存 它與流程圖(flow chart)語意相同

Why 增加兩種文件? (Cont.) 有研究生問: 網站看到美國程式 並無設計草圖虛擬碼 何以需要？ 答: 在美國鄉間小路 中間沒劃分隔黃線 但開車者心中有把尺 把路分兩半 車子開在右半 左半留於對向來車 這就不撞車了 在台灣 就需要有路面分隔黃線 才免於撞車 因為人的心中無法度 內在文化不夠 只好增加路面工程 另一正面思考是:這或許可使台灣軟體品質超過美國軟體

Design Sketch (Cont.) 畫design sketch 後 - 看圖說故事: 圖 即 design sketch 設計草圖(上頁左側)， 故事即 pseudo code 細部設計(上頁右側) Sketch 很人性化，開發者心神負擔 (cognitive load) 小，不易出錯，品質較高 兩人在白板前進行 design sketch， 可充份討論，品質較佳

Design Sketch (Cont.) 各種設計皆始於草圖(sketch)， 草圖要”草”(不精確描述 未確定部份)， 再逐步思考、決定，趨於精確描述， 可用 //TODO 或 //?? 表示未確定部分的圖 這樣避免率爾決定，才有深而密的思考 程式師常過早使用精確符號(如程式語言) 過早決定細節， 這就破壞了設計品質

Pseudo code 內文 Pseudo code 內文以英詞中句書寫 英詞 (English Term) 就是詞直接以英文表達 (如 class name、method name、variable name等)，要精準，須與程式內命名相同 至於「詞」組合成「句」，因國人英文造句能力較弱，故用中文句子(叫中句)，便於快速了解以維修之 例如下面中句含二英詞： 從array [i..N-1] 中找 min ， 並換到它的第一個位置

英詞 (English Term) 如果開發者以中文思考 且皆閱讀中文資料則其腦海不易訂出精準英詞 可是程式要以精準英文表達的 此時要找英文較好者 review 英詞 隨著pseudo code 逐步開發 英詞逐漸設計出來 (如 aTotalGrade) 此設計須遵守 (如不可擅自變為 aFinalGrade) 但是 只要不違反既有設計 可增加細部設計 (如增加其他變數)

英詞 命名 Class, object, variable 以名詞命名 class 用大寫開頭 最好複數 (如Desks) object 用單數 最好有冠詞 (如myDesk) 只有一個 object，不致混淆，則省冠詞 如 symbolTable 而非 aSymbolTable stingy 是形容詞 但比 stinginess (名詞)簡潔 多詞組成 rightChild DSindex //data structure (DS) Method 以動詞命名，並以參數區別之，如： buy (Desks myDesk) buy (Tables hisTable) 為不同 methods 多詞組成 rotateRight ( ) RBTinsert ( ) //red black tree (RBT) act 比 doAction 簡潔

英詞 命名 (Cont.) 測驗一: WT0820 Oleogg Crosmioft 英詞 要易了解，才記得住 (sticky 黏得緊不脫落 意即不忘記) 請用十秒鐘 默記下面英詞 再寫出： 測驗一: WT0820 Oleogg Crosmioft 測驗二: TW2008 Google Microsoft

英詞 命名 (Cont.) 上面的英詞 WT0820 TW2008 雖擁有相同字母 但因排列不同 其易記性 (stickiness) 品質差異甚大 TW2008 使讀者聯想到: 1. TAIWAN (TW) 2. 西元2008年 這兩個印象深刻的詞 易了解 因而易記 WT0820 則無此機制 讀者需死背字母順序 所以易忘 不易記得

Pseudo code 結構 1. Sequence 如: 2. Selection 如: 3. Iteration 如: 1.從 array[i..N-1] 中select出 min，且換到它的第一個位置 2.固定此數不再更動 只有1.無2. 時，不構成sequence，故不寫1. 2. Selection 如: if 第 j 個數比 min 所指的數小 then 叫它min else null end if 又如 case .. end case 3. Iteration 如: for j from i+1 upto N-1 if 第 j 個數比 min 所指的數小 then叫它min end if end for 又如 while .. end while loop ,,, end loop

Pseudo Code 關鍵詞 關鍵詞以外的英詞，必須是 data (或method) names 1. 2. …. if then else end if case end case while end while for each end for from upto downto by call null ← ( a←1 means “set a to 1”) //?? 存疑部分 //TODO 待補充部分 (有?或TODO時 不可coding) 關鍵詞以外的英詞，必須是 data (或method) names

Pseudo Code (Cont.) Pseudo Code 依據下面抽象層次 (abstraction levels) 逐層開發： 1. 抽象層次最高，接近人類思考敘述方式。 2. 抽象層次中等，一半程式一半人類方式。 3. 抽象層次最低，接近程式層次。 且逐層用 test case 手工 trace， 這就是 演算法設計 除錯

Pseudo Code 1. 最高抽象層次為： 2. 中等抽象層次為： 1. 首先從數列 中select出 min，放到它的第一個位置， 並固定此數不再更動 2. 再從剩餘數列中，select出 min，並且放到它的第一個位置 3. 依此方式(repeat)，直到(until) 走訪完數列 倒數第二個數 2. 中等抽象層次為： repeat 1. 從數列 (0 ..n-1)中select出 min， 放到它的第一個位置(即索引0) ，並固定此數不再更動。 2. 繼續走訪剩餘數列 (1 .. n-1) until 走訪到數列 倒數第二個數 (即索引 n-2)

Trace to Debug (演算法設計 除錯) Trace pseudo code 要精準 如無法trace 則表示pseudo code 有思考不週之處, 絕不可貿然進行 coding, 否則, source code 絕不會 work Trace 要心平氣和，從容自信，要優雅， 不慌亂粗糙，才能精準除錯 (Trace to Debug) source code 將無任何 BUG!

Trace to Debug (Cont.) 認知心理學家指出: 要放鬆(relax)、專注沉靜，不能焦慮不安，才能心智暢通，創意湧現(神經緊繃時，做不到這個的) 不妨泡杯好茶，戴耳機(不妨礙同事)聽音樂 在此 專注 情境下，才能查出： 軟體思考漏洞 (BUG!) 例子:某生 確實 trace Compiler Project 虛擬碼， 使 整個 project 程式無 BUG!

Trace to Debug (Cont.) 請回想: 上次找不到鑰匙的情形 愈著急、愈找不到，氣了一整天 …… 晚餐時，氣消了、認了、算了、放鬆了 突然間 - 想到了！鑰匙就放在 …… 放鬆而專注 (絕不是鬆懈) - 才能 創意湧現 (Flow)

Trace to Debug (Cont.) Trace不下去時，表示在那特定點思考不清，可即刻尋求他人協助那點 只要問題點明確，他人可快速解答之， 這種溝通甚為 簡短有效 若無 pseudo code，他人縱然有心協助， 也將陷入 source code 泥淖中, 這種溝通 耗時耗力、而無成效

8.演算法設計 (Cont.) 寫出完整虛擬碼，然後耐心地 trace to debug，這工作似易實難 因為:長年來工作習慣根深蒂固，要寫程式才能思考(趕工不放心時更是如此)；寫虛擬碼只是應付上級要求，不習慣在該階層思考。也不會封裝低階data 為高階class，以進行高階思考，當然無法有效做此事 一定要深信本方法威力，才能心平氣和、心思澄靜， 不只無錯，而且有創意、美感

8.演算法設計 (Cont.) 有人指出: 不需寫出虛擬碼 因為Java code 是高階語言 本身程式碼即具相當可讀性 但是 依陳教授經驗: 虛擬碼提升軟體的抽象層,可提供更簡潔,更高階的了解 有助日後維修 當然 虛擬碼的抽象層必須高於程式碼 絕不可重複程式碼

設計草圖 虛擬碼 例子 單元: public Entry findMin (root) 資料結構: binary search tree 單元測試: input 5; expected output 2 設計草圖: 5 3 6 2 4 虛擬碼 (演算法): 1.從 root 沿左邊走到底 2.return 該 entry的 element

資料結構 例子 三個方法開發findMin(): 找a,b,c等10000個 data elements 的最小值 1.資料結構如用array 則 findMin 演算法為: 1.令min為array第一個元素 2.for each array元素 if 它比min小 then 令min為它 end for 2.資料結構如用 min.heap 則 findMin 演算法更簡單: 令min為array第一個元素 3.如無資料結構,則無演算法: 1.令min為a 2.if b比min小 then 令min為b 3.if c比min小 then 令min為c 這要寫10000行程式 不可思議!

Design Sketch root subTree1 subTree2 Case 1: successor of root is the smallest of sub-tree 2 (go left to the end) Case 2: root is successor of the largest of sub-tree 1 (go right to the end)

Pseudo code protected Entry<E> successor (Entry<E> e) 1. if (e == null) return null; else if e 有 right child (Case 1 像圖中 50) e 往右下走一步 再往左下走到底 else e 沒有 right child (Case 2 像圖中 36) e 往左上走到底 再右上走一步 while (e.parent.right==e) e=e.parent; if (e.parent.left==e) e=e.parent; 2. return 找到的 entry end successor() 如無pseudo-code 則紅色的source code 多難讀懂啊

8. 演算法設計 (Cont.) 先上網找現成演算法，常可找到，可省下不少演算法設計時間 若從open source找到程式碼，那省下更多時間，如自行開發程式碼，因演算法常較差執行速度慢，且程式行數較多開發速度慢 因open source 通常他人用過，有bug會有人報告或訂正，通常不用做單元測試；但必要時，可把reused open source當unit，做 test code 英文要OK，才能讀清楚open source的標頭(當然有些寫不好)，正確呼叫使用，並與全球同好討論 一般人從大一起就直接寫程式 跳過演算法設計 這已是根深蒂固的惡習 要改正

演算法設計例子 public void showAllAdjacencies (Houses theHouse) /*------------------------------------------------------------------------------- * showAllAdjacencies 顯示所有與 theHouse相鄰 (不見得有路) 的人名 * * @param theHouse 某個人住的 house * Time estimate: O(n2) * 例: 若theHouse為小莉,相鄰的是 小華 阿偉(有路) 小明(沒有路) --------------------------------------------------------------------------------*/ public void showAllAdjacencies (Houses theHouse) 1. 找從 theHouse 可到的 toHousesList 如小華 阿偉 O(n) 2.顯示 toHousesList showNames(toHousesList) 3. 找可到 theHouse 的 fromHousesList 例 小明 O(n2) 4. 顯示 fromHousesList showNames(fromHousesList) 367

演算法設計例子(Cont.) private void showNames (HouseList houseList) /*-------------------------------------------------------- * showNames 顯示 houseList 各人名 * * @param houseList 例 小華 阿偉 * Time estimate: O(n) --------------------------------------------------------*/ private void showNames (HouseList houseList) loop 顯示 houseList 各元素所含的人名 end loop 368

9.補上程式碼 (Coding) 將虛擬碼改成註解 (加/* 及 */) 虛擬碼逐行補上對應之程式碼 儘量使程式碼隱蔽，不干擾虛擬碼之閱讀 (常見舊程式難讀、難維修，只好重寫) 本步驟虛擬碼針對 Java, C#,C 程式， 若用Ruby/PHP 程式本身即已易讀， 虛擬碼須寫得更高階

補上程式碼 例子 注意:要凸顯虛擬碼 隱藏程式碼 以利閱讀 當然 虛擬碼的抽象層要高於程式碼 /*-------------------------------------------------------- * showNames 顯示 houseList 各人名 * * @param houseList 例 小華 阿偉 * Time estimate: O(n) --------------------------------------------------------*/ private void showNames (HouseList houseList) /*loop 顯示 houseList 各元素所含的人名 end loop*/ for(i=0, i<=length(houseList-1), i++) println (houseList(i).name); 注意:要凸顯虛擬碼 隱藏程式碼 以利閱讀 當然 虛擬碼的抽象層要高於程式碼

Coding Coding 就是依照 pseudo-code 補上 code 有三方式: 1) 分隔式: code 補在整段 pseudo code 之後 二者分隔 2) 嵌入式: code嵌入一句pseudo code 之後 3) 混合式: 混合上述 (1) 及 (2)

分隔式 Coding for (int i = 0; i <= array.length-2; i++) /* sort: sort array 成由小而大的順序*/ sort ( ) { for i from 0 upto N-2 1.min指著array[i..N-1]的第一個位置(即i) 2.從 array[i..N-1] 中 select 出 min */ for j from i+1 upto N-1*/ if 第 j 個數比 min 所指的數小then叫它min end if end for 3.把 min 所指的數 swap 到 array[i..N-1]的第一個位置 end for */ for (int i = 0; i <= array.length-2; i++) { int min=i; for (int j = i + 1; j <= array.length-1; j++) if (array[j] < array[min]) min = j; swap (i,min); } }

嵌入式 Coding /* sort: sort array 成由小而大的順序*/ sort ( ) { /* for i from 0 upto N-2 */ for (int i = 0; i <= array.length-2; i++) { /*1.min指著array[i..N-1]的第一個位置(即i) */ int min=i; /*2.從 array[i..N-1] 中 select 出 min */ /* for j from i+1 upto N-1*/ for (int j = i + 1; j <= array.length-1; j++) /* if 第 j 個數比 min 所指的數小then叫它min end if*/ if (array[j] < array[min]) min = j; /* end for */ /*3.把 min 所指的數 swap 到 array[i..N-1]的第一個位置 */ swap (i,min); /*end for */ } }

混合式 Coding /* sort: sort array 成由小而大的順序*/ sort ( ) { for i from 0 upto N-2 1.min指著array[i..N-1]的第一個位置(即i) 2.從 array[i..N-1] 中 select 出 min */ for j from i+1 upto N-1*/ if 第 j 個數比 min 所指的數小then叫它min end if end for 3.把 min 所指的數 swap 到 array[i..N-1]的第一個位置 end for */ for (int i = 0; i <= array.length-2; i++) { int min=i; /*從 array[i..N-1] 中 select 出 min */ for (int j = i + 1; j <= array.length-1; j++) if (array[j] < array[min]) min = j; swap (i,min); } }

No over-documentation 例子 : 某經理要求每行程式都要註解 於是看到 load A to register 1 LD R1,A load B to register 2 LD R2,B add register 2 to register 1 ADR R1,R2 store register 1 to C ST R1, C 註解應抽象為 pseudo-code 如下 才易讀懂 C = A + B LD R1,A LD R2,B ADR R1,R2 ST R1,C

Coding 開發 Java source code 建構一個 Class 叫做 mySort，其 constructor所傳入的參數為 integer 的 input array public class MySort { /* data structure */ private int array []; /*constructor*/ public MySort (int inputArray[]) {/*this 存傳入的 input array*/ this = inputArray;} public int[ ] sort ( ){ } }// end of mySort

Coding (Cont.) 讀者閱讀的是 pseudo code，非 source code 所以 pseudo code 畫面呈現 及 其與source code 之對應 最是要緊 程式易於閱讀、了解、維修，才是活著， 活著! 活著！ 活著！

Coding (Cont.) 不是活著的程式無法閱讀、維修，叫： 垃圾，這專案已死掉了！有個嚴肅問題: 小林每月生產垃圾一千行；小王二千行 誰薪水應較高? 1.小王 因產量兩倍 故產值應為兩倍 2.小林 因垃圾量較少 故較環保 3.相同 反正都是垃圾

Coding (Cont.) “swap” method，因無涉解題邏輯，故不需pseudo-coding，可直接 coding 為 private method 又，private method 常重構，故不做 test code /*swap: 交換 i1, i2 所指的數*/ private void swap (int i1, int i2) {int temp = this.array[i1]; this.array[i1] = this.array[i2]; this.array[i2] = temp; }

10.單元測試 (Unit testing)及 驗收測試 (Acceptance testing) 待單元程式(unit, 如一個 Java public method source code) 完成後， 用工具(如JUnit)，自動執行 test code 測試該單元 (unit) 叫單元測試 某功能的單元都測試整合進系統後 駐點客戶依照驗收測試案例 逐一手動測試 這叫驗收測試

單元測試 例子

myAgile 經驗談 陳教授研一學生試用myAgile 做小軟體， 覺得 CRC, test code, pseudo code 很費時，不甚敏捷。反之傳统直接coding 快多了 重點: 1) CRC 使test code可行，確保了品質 2) pseudo code 使變動的需求帶來的重構(refactor) 得以敏捷地做；而在變動需求下，CMMI 大量文件瞬間過時無用 3) 民主溝通費時但品質高；獨裁快速但危險

myAgile 經驗談 (Cont.) 有一雙人組 (pair) 在一齊維修時 先讀 header 再讀 pseudo code 了解後再修改 Java code 這樣只花 15 分 若直接修改 Java code 時間拉長不少

myAgile 經驗談 (Cont) 讀者投書: 一般行業精密分工,使員工專業,引進流程,重視紀律,以掌握品質,平行作業,以壓縮時程,何以為敏捷而反其道而行? 要員工會寫程式,會設計,會測試,要改他人程式,還要大家同室,同桌,同電腦 陳教授回覆: 上述行業是一般工廠式行業 流程固定,變化少,創意少 但是,軟體業不是工廠,所以是大不相同的

myAgile 經驗談 (Cont) 陳教授授課敏捷方法一學期後,全班舉行 開發郵局ATM 模擬遊戲 意外發現:同學竟不知駐點客戶要做出大量 scenarios 及 acceptance test cases 文件 - 同學打從心裡不重視需求分析,難怪台灣軟體品質差!

Agile 經驗談 *中國中興通訊楊靜分享:1) 從小團隊 (7-15人)開始改變價值觀 標準化及規劃 控制都過時了 用agile因應變化有成績後 董座會看到 會要求全員跟進 2)全團隊每天都忙於救火時 可先組一小agile team 從容的工作 其他人則繼 續救火 並形成防火牆保護 agile team 以後大家輪流進防火牆當agile team 3) Method 要切割小 才能做好持續整合 4) Pair Programming 可一人寫程式碼 進行專注思考 另一人寫測試碼進行廣闊思考 這可互補之 Johnston from UNICON, USA 分享: How to introduce Agile: Small project with true believers to ensure success. * 2013 Agile Taiwan Int’ Conf., June 20, Taipei.

Agile 經驗談 James Shore 指出大多數使用Agile 的公司是用 SCRUM 的 但 SCRUM 只有管理實務 而無 XP 的工程實務 如 TDD, Pairing, Acceptance testing 造成 SCRUM 可以點出問題 但無法解決問題 這反而形成 Agile 顧問公司的一大商機 真是有趣 [James Shore web site, 2013]

範例

範例一 Selection Sort Test Code, Design Sketch, Pseudo Code, Maintenance. 本例闡釋: Test Case, Test Code, Design Sketch, Pseudo Code, Maintenance.

Test Case Creating unit test cases Post-condition：數列元素為自然數， 且由小到大排序。 Pre-condition：數列元素為自然數， 可能有以下情形： 1. 數列元素皆不同 2. 所有數列元素皆相同 3. 數列元素部分相同

Test Case (Cont.) 依據以上列舉情形，設計以下test cases： 1. 數列元素皆不同 Input：{3,1,4,2} Expected Output：{1,2,3,4} 2. 所有數列元素皆相同 Input：{1,1,1,1} Expected Output：{1,1,1,1} 3. 數列元素部分相同 Input：{2,2,3,1} Expected Output：{1,2,2,3}

Test Code 標頭 (header) /* testSort.java test case 1: {3,1,4,2} ->{1,2,3,4} test case 2: {1,1,1,1} ->{1,1,1,1} test case 3: {2,2,3,1}-> {1,2,2,3} */ 開發者寫標頭，再交工讀生補上 test code test code, source code 檔名要易記易用易管理

Test Code // Java Test Code (C# test code 請參閱附錄) import junit.framework.*; public class mySortTest extends TestCase { public mySortTest (String s) {super(s);} /*處理test cases前，需一致處理*/ protected void setUp (){} /*處理 test cases 後，需釋放記憶體*/protected void tearDown (){} /*改寫每個test case為public void 名稱為“testX” 的method */ public void sortTest1 () {} }

Test Code (Cont.) // Java Test Code //Test Case 1：input {3,1,4,2} expected output：{1,2,3,4} public void sortTest1() { 　/* input為待排序數列，expected為預期結果, result為實際結果*/　 int input[] = {3,1,4,2},expected[] = {1,2,3,4}; int result[]; /* new 一個 mySort的物件，傳入參數input */ mySort obj = new mySort(input); //此時呼叫尚未測試的程式(建構子) OK的!! /*呼叫sort來排序*/ result = obj.sort(); /* assert實際結果與預期結果是否 equal */ assertEquals (toString(result), toString(expected)); }

Test Code (Cont.) // Test Case 2：input {1,1,1,1} expected output：{1,1,1,1} public void sortTest2() { int input[] = {1,1,1,1}, expected[] = {1,1,1,1}, result[]; mySort obj = new mySort(input); result = obj.sort(); assertEquals (toString(result), toString(expected)); } 依此方式，寫出所有 Test Cases 的 Test Code

Test Code (Cont.) 開發test cases 要由簡而繁，且要測異常錯誤狀況，以一個 10行 source code unit (method) 來說，若有三個輸入參數，每個假設有四個狀況 (cases)，43=64 cases，每個case寫10行 test code， 即有 640 行 test code 所以test code 行數遠多於 source code

Design Sketch 設計草圖 利用紙、鉛筆、橡皮擦、尺描繪出design sketch 首先從數列中 select 出 min（即 數值 1），並放到數列的第一個位置（即 索引 0）。 索引 數值 1 .. .. n-2 n-1 3 1 4 2 固定此數不再變動。 1 ( i ) .. .. n-2 n-1 1 3 4 2 再從剩餘數列中 select 出 min（即 數值 2），並放到剩餘數列（即 索引 i ~ n-1）的 第一個位置 （即 索引 1）。 1 ( i ) .. .. n-2 n-1 1 3 4 2 固定此數不再變動。 1 .. .. n-2 ( i ) n-1 1 2 4 3 依此方式直到走訪完， 走訪至數列倒數第二個數（即 索引 n-2）。 ： 1 .. .. n-2 n-1 1 2 3 4 即完成數列小到大sort

Pseudo Code 1. 最高抽象層次為： 2. 中等抽象層次為： 1. 首先從數列 中select出 min，放到它的第一個位置， 並固定此數不再更動 2. 再從剩餘數列中，select出 min，並且放到它的第一個位置 3. 依此方式(repeat)，直到(until) 走訪完數列 倒數第二個數 2. 中等抽象層次為： repeat 1. 從數列 (0 ..n-1)中select出 min， 放到它的第一個位置(即索引0) ，並固定此數不再更動。 2. 繼續走訪剩餘數列 (1 .. n-1) until 走訪到數列 倒數第二個數 (即索引 n-2)

Pseudo Code (Cont.) 設計問題:數列與剩餘數列有何關係？ 挑戰！ 走訪 剩餘數列 就是array 索引 (i)的走訪， 所以改成 for loop : i為0時， array[0..N-1] 為數列 i不為0時，array[i..N-1] 為剩餘數列 由repeat until 改為 for each： //sort: sort array 成由小而大的順序 for i from 0 upto N-2 從 array[i..N-1] 中 select 出 min，且換到它的第一個位置 (i) end for

Pseudo Code (Cont.) 3. 最低抽象層次為: sort: sort array 成由小而大的順序 for i from 0 upto N-2 1.min指著array[i..N-1]的第一個位置(即i) 2.從 array[i..N-1] 中select出 min for j from i+1 upto N-1 if 第 j 個數比 min 所指的數小 then 叫它min end if end for 3.把 min 指的數 swap 到 array[i..N-1]的第一個位置

分隔式 Coding for (int i = 0; i <= array.length-2; i++) /* sort: sort array 成由小而大的順序*/ sort ( ) { for i from 0 upto N-2 1.min指著array[i..N-1]的第一個位置(即i) 2.從 array[i..N-1] 中 select 出 min */ for j from i+1 upto N-1*/ if 第 j 個數比 min 所指的數小then叫它min end if end for 3.把 min 所指的數 swap 到 array[i..N-1]的第一個位置 end for */ for (int i = 0; i <= array.length-2; i++) { int min=i; for (int j = i + 1; j <= array.length-1; j++) if (array[j] < array[min]) min = j; swap (i,min); } }

Unit Testing (Cont.) 用JUnit 其下載網址 http://www.junit.org/index.htm (a)把 source code: mySort.java test code: TestmySort.java 放同一目錄 (b)在命令列檔案所在目錄鍵入 javac *.java 編譯這兩個檔案

Unit Testing (Cont.) (c)鍵入 java junit.swingui.TestRunner TestmySort

Unit Testing (Cont.) (d) 結果如下： 所有 Test Cases 通過測試

Unit Testing (Cont.) 假設 test case1 改成： public void testSort1() { int input[] = {3,1,4,2}, expected[] = {2,1,3,4}; //錯了！應是1, 2, 3, 4 int result[]; mySort obj = new mySort(input); result = obj.sort(); assertEquals (toString(result), toString(expected)); }

Unit Testing (Cont.) 重編譯TestmySort，再執行Testing，結果如下: 實際結果是: 1,2,3,4 但 test case 1 中 預期結果是: 2,1,3,4， 比對結果，錯誤!

Unit Testing (Cont.) Test case 1 錯誤 Test case 2 正確 Test case 3 正確

Maintain 範例一 針對 Selection Sort 給予maintenance request : 改為由大排到小 1. 修改 test case code (如input 仍是3142,但 expected output 改為4321) 2.閱讀瞭解 pseudo code ， 3.修改 pseudo code 及 對應的 source code， 4. 用unit testing tool 做 testing

Maintained pseudo and source code /* sort: sort array 成由大而小的順序*/ sort ( ) { /* for i from 0 upto N-2 1.max指著array[i..N-1]的第一個位置(即i) 2.從 array[i..N-1] 中select出 max for j from i+1 upto N-1 if 第 j 個數比 max 所指的數大 then叫它max end if end for 3.把 max 所指的數 swap 到 array[i..N-1]的第一個位置(i) end for */ for (int i = 0; i < =array.length-2; i++) { int max=i; for (int j = i + 1; j <= array.length-1; j++) if (array[j] > array[max]) max = j; swap (i,max); }

範例二 Insertion Sort 及其擴充之 範例三 Shell Sort 這兩個範例 皆展示 design sketch, pseudo code, source code.

Insertion Sort Design Sketch 首先將待sort數列（數列 i ~ n-1）中第一個數（即 數值9），設為已soort數列。 Insertion Sort Design Sketch 由unsorted數列逐一將數值 insert 至其左的sorted數列 使之變大並保持 order，最後原數列變成sorted unsorted 9 6 3 4 1 2 0(i) … n-2 n-1 將 unsorted 數列( i..n-1）第一個數（6） Insert至sorted數列，並保持 order 數值 索引 sorted unsorted 9 6 3 4 1 2 1(i) … n-2 n-1 首先將 unsorted 數列（0..n-1） 第一個數（9) 設為sorted數列 Insert sorted unsorted 6 9 3 4 1 2 2(i) … n-2 n-1 ： 依此方式直到數列最後一個數（n-1） sorted 1 2 3 4 6 9 … n-2 n-1 到此即完成數列由小到大的sort

Insertion Sort Pseudo Code public int[] insertionSort() /* SORT integer array 張一二 2013.04.01 input unsorted integer array ouput sorted integer array */ 1.for i from 1 upto N-1，逐一將unsorted insert至其左sorted array， 使變大之 array[0..i] 保持order for j from i downto 1 if array[j]<其左邊元素 then swap else 已 insert 至定位，離開迴圈 end if end for 2.return array

Insertion Sort source code public int[] insertionSort() /* SORT integer array 張一二 2013.04.01 input unsorted array ouput sorted array */ 1.for i from 1 upto N-1，逐一將unsorted insert至其左sorted array， 使變大之 array[0..i] 保持order for j from i downto 1 if array[j]<其左邊元素 then swap else 已 insert 至定位，離開迴圈 end if end for 2.return array */ { for (int i=1; i<=array.length-1;i++) for (int j=i; j>=1;j--) if (array[j]<array[j-1]) swap(j,j-1); else break; return array; }

Shell Sort Design Sketch Shell sort 依increment將數列分成數個子數列，分別做insertion sort 從子數列第二個元素起，向右隔increment個元素，逐一insert至左邊sorted子數列 increment = 2 1 9 6 3 4 2 … n-2 n-1 餘數 數值 索引 increment(2) 將數列分成increment個子數列 1 6 3 4 9 2 … n-2 n-1 將第0子數列(灰色) 做 insertion sort (得 1, 3, 9) 1 2 3 4 9 6 … n-2 n-1 直到做完所有子數列 ： 遞減 increment 為 increment/2， 並依上述處理，直到increment為1 increment = 1 1 2 3 4 6 9 … n-2 n-1 到此即完成sort 數列

Shell Sort Design Sketch (cont.) (下面是開發者看到 design sketch 時的 內心思考，不寫出文件的) 1. increment 2 時，array分為兩個 子陣列: k=0: {9 3 1} k=1: {6 4 2} 分別做 insertion sort 2. 遞迴做 shell sort，每次increment 減半， 直到1 (即退化為 insertion sort)

Shell Sort pseudo code end for public int[] shellSort (int increment) /* 1.for 子陣列 k from 0 upto increment-1, 分別做insertion sort for i from 1+k upto N-1 by increment, 逐一插至左邊 array使之變大 array保持order for j from i downto 1+k by increment if array[j] <左邊元素 then swap二元素 else 已插至定位，離開迴圈 end if end for 2.遞迴做shell sort，每次increment 減半，直到1 3. return array */

Shell Sort source code { for (int k=0; k<=increment-1; k++) for (int i=1+k; i<=array.length-1; i=i+increment;) for (int j=i; j>=k+1; j=j-increment;) if (array[j]<array[j-increment]) swap(j,j-1); else break; if (increment >=1) array=shellSort(increment/2); return array; }

風平浪靜-台灣軟體業 藍海 揚帆！ 敏捷(agile)方法以測試帶動開發 (Test-driven development, TDD)軟體品質極佳 除國外重視的溝通 訓練，亦加強 國人不足的思考 (含創意)訓練 – 溝通 及 思考 乃深層基本功– 練功後人人紮實、軟體優質， 迎向創意時代，錢途光明！

附錄

SCRUM * Kate Oneal: What is SCRUM? at XProgramming.com SCRUM屬敏捷管理法 與XP敏捷工程法 可搭配互補 (前者專案管理 後者開發實務) 敏捷大師 Ron Jefferies 以風趣翔實的筆觸 藉 Kate Oneal 的對談 清楚闡釋SCRUM * 下面簡單摘要之 * Kate Oneal: What is SCRUM? at XProgramming.com

SCRUM 要身體力行 A diet won’t help people lose weight if they don’t live by it. SCRUM is a style for building products. A SCRUM team will be in a position to improve.

SCRUM 343 There are: 3 roles 4 meetings 3 artifacts in SCRUM.

3 Roles 1.The Product Owner who determines what the team will build in the next short interval or “Sprint”. 2. The Team who build it. 3. The Scrum Master who facilitates the process and makes sure that the process, and the people, continue to improve.

1. Product Owner The Product Owner (PO) is responsible for delivering the best possible product within time and budget. The team builds what she says to build, and her job is to get the best possible results. She can do this because the teams shows her real running product every Sprint (every couple of weeks, thirty days at most).

PO is the Manager? Not at all. A Scrum team need not have a manager at all. The team is ‘self-organizing’. They manage themselves.

2. The Team The team must have all the skills necessary to produce an increment of potentially shippable software in every Sprint. That means everything – developing, testing, and writing manuals.

Manual Do the team revise the manual every Sprint? Yes, they would. The team revises the actual software every Sprint. That’s actually harder to do than revising manuals. If they leave out a semicolon, the program won’t work.

Team Resource Scrum starts with giving the team everything they need, and set them loose with a budget. A wise project creator would fund his most important projects fully, then work down the list until he ran out of people or money. Starving all the projects can’t possibly be a good idea.

Inspect and Adapt The whole team inspect what happens, using day-to-day events, and Sprint-to-Sprint events, to see clearly how things are going. When they see opportunities to improve, they put improvements in place. Many organizations fail because they seem to forget this, instead just telling the team to soldier on.

3. SCRUM Master The SCRUM Master helps the PO do her job. He helps everyone understand how to create good backlog items, how to communicate them, how to plan an adjust in as dynamic an environment as most projects are, how to do all the things Agile teams need to do, and so on.

3. SCRUM Master (Cont.) He helps the team to do their job, coaching, leading, even teaching them how to do things. He ensures that impediments are removed. He works through the organization to help Scrum work. Best of all, he does this with no formal management authority.

4 Meetings to Inspect and Adapt 1.Sprint Meeting The Product Owner provides “backlog items”, the thing she wants, in the order she prefers them. The team considers these, and the technical means of accomplishing them. There can be some give and take. And, at the end of the meeting, the team all understand what will be undertaken, and how they plan to accomplish it.

1.Sprint Meeting (Cont.) The meeting is a negotiation, if you will. I prefer to think it is a conversation – with everyone on the same side. The team can’t do more than they can do, and it would be counter-productive if the Product Owner were to demand more.

1.Sprint Meeting (Cont.) The meeting would take a morning for a two-week Sprint. There are 2 meetings at the end of a Sprint. The first is the Sprint Demo. The second is the Sprint Retrospective.

2. Sprint Demo The team demonstrates to the Product Owner what they have accomplished. Here, we are inspecting the product and adapting our expectations of what is to come.

3. Sprint Retrospective Here we look at how we worked as a team and how our process and tools supported us. We brainstorm ways to improve, and agree to specific actions that we will take in the next Sprint to improve things.

4. Daily SCRUM Every team member says: 1) what they accomplished yesterday, 2) what they will accomplish before the next Scrum, and 3) what, if anything, is standing in the way. They don’t solve the issues in the meeting, but if there are issues, most teams meet together or in small groups to address them right after the Daily Scrum.

3 Artifacts: 1. Increment It is “What you have done for me lately”. At the end of each Sprint, we demonstrate an increment of software. This software is required to be “done”, by our then-current definition of “done”.

Definition of “Done” The definition of done might start out simple, such as “demo on development system”. But, over the course, it gets more and more stringent, such as “demo on the PO’s system”, “documented and demo on the production server”.

An Increment is “Done” when 1.All the PO’s defined acceptance tests run, 2.The system is fully integrated and running on the production servers, 3.All the manual pages are up to date, 4.The code is clean and well-factored, 5.All the programmer tests are running green.

When emergencies arise If we do have to rush out a defect fix, we are all committed just as much to fixing our process to make that unnecessary. It doesn’t take long until we are able to build increments that meet our definition of “Done” fully, nearly every time.

Inspection in Manufacturing Manufacturing people learned that inspecting earlier and more often meant that fewer products had to go back to be redone. Small inspections and small fix to process are immensely less costly than reworking the whole product item.

Similarly for Software… We save time and money by testing software at every level. We have automated unit-tests, and we run them all the time, and add to them all the time. The result is that things almost always go well, and we get very clear indications of where we have messed up when we do.

2. Product Backlog It is the Product Owner’s current list of things that she might want in the product someday. It is kept “ordered”. The PO and the team considers and defines the order.

3. Sprint Backlog It is just the list of things agreed to be done in the current Sprint and the plan for getting them done. You can have all the items on cards, and show them moving through whatever work stages they go through, so that we can see how many cards arrived at “Done” everyday.