驚濤駭浪！台灣軟體業的險境 台灣工廠外移，國力所繫的代工產業 危在旦夕，舉國寄望軟體業勃然興起， 但真相是：軟體業乩童*亂舞、神壇遍佈，

Presentation on theme: "驚濤駭浪！台灣軟體業的險境 台灣工廠外移，國力所繫的代工產業 危在旦夕，舉國寄望軟體業勃然興起， 但真相是：軟體業乩童*亂舞、神壇遍佈，"— Presentation transcript:

1

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

3

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

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

6 教材結構 p. 7 觀念 泛談 軟體觀念 p.10 文化 p.18 溝通 p.190思考 p.206 方法 擴充 極限開發法 (極致工藝法) (eXtreme Programming, XP) 而得的十一道工序,叫 myAgile p.298 範例 myAgile 的 Java 開發例子 p.333 附錄 安裝C#單元測試工具

7 觀念

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

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

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

11 軟體業 文化最重要 (Cont.) Bossavit 指出某軟體公司的文化是: 熱情 (passion) 大膽 (daring) 華麗 (glamour) 這不是好的文化 因熱情,大膽 並不等同 勇氣 (courage) 軟體外表華麗 也不等同 程式品質 如抽象層次 模組程度 等

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

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

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

15 軟工是軟體業基礎 但不是產業 軟體工程(軟工)是任何軟體業都需的工作文化,是軟體業基礎,但軟工本身不是產業 國內資訊教育要加強此點 例子: 電信軟體是電信領域的軟體業的產品,當某開發團隊做某電信軟體專案時,該團隊的工作方式,特別是溝通方式,就是該專案的軟工

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

31 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.

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

33 CMMI and 敏捷方法 (Cont.) 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.

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

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

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

37 Agile Method vs. Agile Process
Method 指的是軟工使用的符號 如 Object-oriented (O-O) Method Process 則是執行 method 的方式 如 面對面方式 所以，嚴格說 Agile Process* 才對 但大家習慣稱 Agile Method 本教材也依此 * 歐洲知名的 XP 200X conference 就叫 Agile Processes in Software Engineering and eXtreme Programming.

38 先進軟體公司 的五個敏捷點 愈接近這五點，團隊溝通愈敏捷: 1.開發者同處一室 (可面對面溝通) (一室最多十人)
2.有駐點使用專家 (口頭溝通需求) 3.一個月交貨一次 (以產品與用戶溝通) 4.全自動的迴歸測試(一有變動全面重測) 5.有經驗的開發者 (人的素質最重要)

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

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

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

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

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

44 兩家軟體公司的省思 要進步，就須改變；如本國公司因工程品質差而業務外包他國，吃虧的還是本國畢業生的工作權!
因工資高，台灣自豪的工廠外移低工資國度[劉維公，風格社會，天下雜誌，2006]，我叫它: 後工廠時代,留下的要升級,不要代工,埋頭拼命，處處省錢cost down；要cost up, value up,豪氣做時尚精品；要敏捷工作，心平氣和，慢活，慢食，深眠 拼命文化 要提升為 敏捷文化

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

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

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

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

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

50 軟體公司 佈置 (Cont.)

51 下面介紹最新的 kanban (看板) 觀念,主要取材自 XP 2010 in Norway 看板源自 Toyata 生產線上顯示各站現況的白板, 它可使各人知道其他人動態而機動調整, 進而達到全線最高效率

52 A call for craftsmanship *
當壓力變大，developers 會做較少測試 此導致更多錯誤，帶來更大壓力，接著做更少測試，如此生出更多 bugs… 這樣反覆的惡性循環 It’s time to SLOW down! * Ketil Jensen, Improving software quality with Kanban, XP 2010. *

53 Slow down to go FAST – limit work in progress
在工作中自然發現問題，並試著去解決 限制同時處理的工作數量，而減少在工作間轉換的負擔 鬆弛緊張的神經，讓團隊成員能平穩踏實的工作 處理工作時能平均分散各個流程的負擔 最大化的產出才是真正目標，並非是讓人員隨時處於 100% 的勞累狀態

54 Why introduced 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.

55 Experiences and recommendations about introducing kanban
團隊 leader 可了解 what, why, how the team is doing, 能隨時並持續改善任何事情，呈現舒適的工作環境 Kanban 對使用 waterfall 或 scrum 的團隊都適應良好，很快就看見 transparency 提升的成果 It’s all about COMMUNICATIONS! --- 主動並定期地與客戶溝通，幫助他們了解我們為他們工作的狀況（否則客戶可能經常催促工作進度、增加需優先處理的工作等）

56 From Chaos to Kanban, via Scrum*
Agile 開發方式，可有效改善軟體開發過程，從一團混亂（陷入不斷debug的漩渦）到功能符合客戶需求的最小功能集，不做多餘開發，更能將客戶需求功能的品質，不斷檢視，達到高品質的軟體。 Kanban 能有效將團隊注意力集中，讓整個開發團隊掌握全局，並清楚明白， 目前做到哪裡，現在需要做甚麼，哪些是需要立即開發，並能檢視各個 unit 是否能達到讓客戶與內部團隊接受的品質，有效的品管所生產的軟體。 以下實例說明結合 agile method 與 kanban 對於開發流程與品質的改善： Paul Shannon, Kevin Rutherford, Craig Judson and Neil Kidd, XP From Chaos to Kanban, via Scrum,available at:

57 From Chaos to Kanban, via Scrum
Not Started In Development Done Not In Done Internal Customer Live Started Development acceptance acceptance Not Started In Development Done Customer acceptance

58 Google Culture Ideal for Agile & Kanban? *
Run Agile for 2 years  recently take some kanbans Google階級制度沒有正式階級(depend on skill) 提供食物誘因 讓 Engineers 一起工作(team-based) 20% 時間用在自己興趣的領域(passion)創新的來源 以上造成推行 Kanban 時，會非常順利 (平坦的挑戰) * Susan Hunter ,Google Culture Ideal For Agile & Kanban,XP2010 video.

59 Google Culture Ideal for Agile & Kanban?
阻礙 Agile 或 lean practices： 一直詢問現況 單獨奮戰 思維老舊 天真的想法 沒有遵照既定的程序 Kanban 效益： 透明化(尊重且了解他人作業) 提高預測未來作業程序 提高輸出效率 調整工作 queue

60 軟體設計原則 傳統軟工依傳統工程設計原則* 力求以 最少資源產出最大價值之產品 但大部分軟體不易維修 很多在短期內成昂貴廢棄物
傳統軟工依傳統工程設計原則* 力求以 最少資源產出最大價值之產品 但大部分軟體不易維修 很多在短期內成昂貴廢棄物 新思維應是生態設計原則** 使軟體易演化(evolve) 生生不息 無廢棄垃圾*** * 合理的設計原則, 漢寶德譯, 1972, The Discipline of Design, by Roe,Soulis,and Handa. ** 從搖籃到搖籃, 野人出版, 2008, Cradle to Cradle, by McDonough and Braungart. *** 2009哥本哈根氣候變遷大會後,節能減碳成主流,2010世博可見此,而軟體業是免能源的!

61 軟體設計原則 (Cont.) 環境保護與人體保護(中醫)是異曲同工的: 最大限度利用與激發物件(環境或 人體內)的自我循環與調節系統;
最小限度介入與破壞這自足的系統* 著重人與自然,社會,自身的互動關係及循環體系,即天人合一. 軟體開發也要依此”道 非重外在規範,而重團隊互動來演化軟體 * 蕭宏慈,醫行天下(上),橡實文化,2010,pp

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

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

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

65 軟體公司招募什麼人才? 台灣學生從小獨自做作業，禁與同學討論，故群育不彰，不善清晰精準溝通(口頭及文字)、集思廣益；美育也無，無美感、時尚感，難成就精品 例子: 巴黎街頭人人衣著搭色和諧 ， 有色感！ 例子:廣達林百里幼年住香港中環， 培養了美感 台灣智育重視填鴨應付考試,以分數定高下，考試中不做思考、只是快速作答；因此，沒有平心靜氣仔細思考的習慣，不重內在修鍊,故做不出精品 例子: 90分鐘考30題，每題若3分鐘解不出，放棄！ 軟體開發本是團隊合作的工作方式及生活方式，人才首重 群育 ；尤其是-忌招乩童

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

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

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

69 開發團隊 公民意識 (群育) 依 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 注意:無擅長交友，順從他人等，要勇於表達自我， 包容異見，服装自由，特立獨行 例子:聯發科需要在兩人擇一時，不用絕頂聰明的人，而用可跟別人合作的人 [中國時報, ]

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

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

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

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

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

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

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

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

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

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

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

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

82 解答一 (Cont.) 陳教授認為資訊系(資工及資管)低年級(大一大二)應著重上述基礎軟體教學 這樣,基礎紮實了,高年級(大三大四)及研究所(碩一碩二)尖端課程才有可能落實於軟體業,醞釀出優質產品

83 解答一 (Cont.) MIT CSAI Lab 主任 Victor 舒 * 指出:
雲端來了! 台灣硬體代工(甚至電機)思維要改變為:以軟體為中心的思維-系統化的軟體開發應用(陳教授認為這就是上述軟體教學缺失之處),要重視 operating system, security, compiler 等,否則十年內產業消失 2010 廣達佈局中國雲端五城市試點** 令人振奮 * 遠見, ** 今週刊,

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

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

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

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

88 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

89 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); if (reader.readLine().equals (“我要X”)) x = new X(); // x points to an object of class X else (reader.readLine().equals (“我要Y”)) x = new Y(); // x points to an object of class Y System.out.println (x.whatIAm());//dynamic binding } // end of main

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

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

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

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

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

95 台灣產業文化的省思 (Cont.) 鴻海死對頭–中國比亞迪王傳福2009成中國首富,財富396億人民幣*中國已學會台灣生產線技術;但馬步不穩,其手機充電器召回,股價暴跌** 且吃不到蘋果訂單*** 2010王跌至12名,飲料大王哇哈哈宗慶后以人民幣800億元居首**** 上海世博展現中國升級了,富士康跳樓事件使中國的工資大幅升級了,台商當年趾高氣昂,今天黯然撤離中國(或去開發西北),台商不應再流浪了,應返台升級或轉型 * 旺報, ** 今週刊, *** 非凡周刊, **** 聯合報

96 台灣文化的省思 台灣人被評價為呆胞,指的是見識不足,不精準,不確實,看來呆呆的同胞.台灣人一般單純熱情愛錢,只知生活上省錢,工作上拼命,到處找撇步,急就章 “慶菜”貪小便宜(塑化劑應運而生),因陋就簡,沾沾自喜,自滿自大;卻沒有大方向,不大器,不求開闊視野,不提昇境界,不投資升級台灣 台灣人不自認呆,不自知自省,可悲!

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

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

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

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

101 台灣產業文化的省思 (Cont.) 陳教授 2010 九月遊中國西安法門寺,發現其硬體建築極其浩大宏偉, 遊客如織 (門票不便宜,120人民幣合台幣600元), 但不見僧人禪修, 只見不少”假僧人”心不在焉的在場看顧,軟體蕩然無存矣! 趨勢大師奈思比可能未見及此事

102 台灣產業文化的省思 (Cont.) 2010 陳教授觀察: 中國大建高速公路鐵路,青藏鐵路已完成,新疆高鐵將動工,新疆最西的喀什將建經濟特區,各都市高樓林立,國力驚人,雄心萬丈,世人應正視借鏡之 但同時塞車頻傳, 一塞數小時, 可見其軟體管理面尚薄弱

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

104 台灣產業文化的省思 (Cont.) 2011夏 陳教授壯遊中國北疆喀納斯湖 賽里木湖 馳馬那拉提 巴音布魯克 飛車穿天山 又訪漢化中的南疆喀什 親睹維漢種族緊張 洽薩古城沒落 東門巴扎人潮中不見漢人 有維吾爾族歌舞表演的知名餐廳竟然消失了 原來是改建成了百貨公司大樓 中國或將擴充經濟實力至中亞 重現大唐雄風

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

106 台灣產業文化的省思(Cont.) 例子: 電影海角七號震撼市場,創下台幣4.6億空前產值;這應歸功於優秀的編劇導演 演活台灣多元文化及族群,激發市場共鳴, 掌握了行銷面 但是,因為細節處理(如服裝考據)不夠精準 即工程面不夠嚴謹 ,無法獲金馬獎評審青睞 終未獲選最佳影片 接著,艋舺,雞排英雄也創佳績,賽德克巴萊更進軍威尼斯 令人振奮

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

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

109 台灣產業文化的省思 (Cont.) 晶華潘思亮不重視土地等有形資產,反而重視品牌等無形資產
二十年前,晶華年付百萬美元品牌權利金給麗晶(Regent), 今天買下麗晶品牌後, 每年固定可收不少權利金* 潘說:要重文化要說故事,北市中山區巷弄內就有不少故事,引人流連** * 遠見, , pp ** 經濟日報,

110 台灣產業文化的省思 (Cont.) 台灣的連鎖休閒服務業,如超商,飲料店,快餐店的密度世界第一,因此競爭激烈,創新度高 85度C在中國展店順利,即為成功例子 * 遠見, , pp

111 台灣產業文化的省思 (Cont.) 在新北市泰山區一片鐵皮屋工業區,都是傳統鐵工廠也有顯示器廠的當中,很神奇的有家餐廳叫”香草花緣” (Herb Garden),大樹成蔭,花木扶疏,生意鼎盛,客人悠閒愉悅,還有店員吹氣球做成帽子給小孩子玩,一客海陸餐賣750元,營收應不錯 拼命的傳統工廠提昇為悠閒的庭園餐廳,感覺蠻不錯的!

112 台灣產業文化的省思(Cont.) 有軟體公司員工因怕上級責難 而做假文件 應付上級 要有不責難的企業文化 不責難下屬遵行錯誤、落後、無法遵行的規條，以去除造假的存在必要 信任開發團隊會以最有智慧與效率的方法完成任務 不以績效考核逼迫做無意義的事 [中華電信 童欣仁 (Chris)]

113 台灣產業文化的省思(Cont.) 有軟體公司外行領導內行: 不懂技術只會管理的主管，沒有能力帶領開發團隊
管理階層做後盾，依開發團隊的需要全力支援之，而不是高高在上，訂定並要求無法遵守的規條 在彈性中尋求制度，在制度中仍保有彈性: 以彈性敏捷方法開始，遇共通規律性問題才訂指引，但指引中仍保留實際執行的彈性 [中華電信 童欣仁 (Chris)]

114 台灣產業文化的省思(Cont.) 金融海嘯後,張忠謀重掌台積電,由資訊電子轉向太陽能,即:
IT (information technology) 轉向 ET (energy technology), 並全面進行綠建築* 台積電勇於研發薄膜太陽能電池**,可能再創高峰,台灣產業可能因而再有活路 * 文茜世界週報, ** 非凡新聞,

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

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

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

118 產業失敗例子 (Cont.) 有一些台灣軟體公司在軟體程式碼開發完成之後,才補寫文件,甚至另外找人(非原開發者)來寫文件, 這是典型應付考試心態(可能是應付某 process 標準的要求,如CMMI),真是匪夷所思! 難怪產業不振!

119 產業例子 遊戲軟體公司智冠王俊博*說:台灣產品上市讓人眼睛一亮,十萬人上線,但人數遞減; 中國產品則擴充速度快,上市後很快可擴充功能,使上線人數遞增 陳教授猜測可能中國軟體 O-O 設計(切割)較佳,使軟體較易延伸擴充 * 商業周刊,

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

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

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

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

124 產業成功例子 (Cont.) 宏達電率先脫離較舊的微軟平台,跨入新的 android 手機平台, 並以1100萬歐元併購法國手機軟體公司, 這是軟體創新思維, 勝過聯發科的山寨機低價思維, 當然,股價也反映此點 * 商業週刊, , p.44.

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

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

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

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

129 團隊組織 傳統三層: 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

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

131 團隊組織 (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. *** 龍應台, 大江大海一九四九,天下,

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

133 駐點使用專家 (On-site usage expert)
駐點使用專家(或叫駐點客户 on-site customer 由客户長期派駐團隊工作。它顛覆傳統，問號很多: 使用者怎願到現場幫我們開發? 使用者程度很低，怎懂電腦，如何一起工作? 但，開發者直接面對使用者，需求瓶頸 消除了！ 他只要懂需求，不用懂電腦 開發時，駐點專家整天與開發者在一起，可確保需求精準落實於程式中(尤其是氣氛，美感，情調等美學價值) 實務上，part time(非full time)亦可，但要 補足溝通功能，如多用 ,手機(含簡訊)等

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

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

136 駐點使用專家 (Cont.) 使用專家必須反映各種不同使用者的不同使用習慣 例如: 手機操作常未考慮中老年人 手指遲緩 按不到小小的按鈕
使用專家必須反映各種不同使用者的不同使用習慣 例如: 手機操作常未考慮中老年人 手指遲緩 按不到小小的按鈕 近視老花眼 看不清小小的顯示 更常見軟體使用手冊寫的像程式,難閱讀

137 駐點使用專家 (Cont.) 有電信業界人士指出: 駐點使用專家之薪資經費 應正式編入計畫預算 因為這經費比程式師開發需求文件的經費少,而且有效多了

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

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

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

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

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

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

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

145 人際溝通 (Cont.) 例子: 台北車站多鐵共構,大量users中各user腦海知識(knowledge)不同,因此設計標示(sign)使之快速與各種 user 溝通很重要 假設:某user搭捷運到台北車站,要去微風food court,如其腦海知識有: “微風在台鐵2F”知識 而循台鐵標示前進,則會輕鬆找到. 反之,因無微風標示, 則會找的很累 如何用標示 (sign) 適時提供適切知識 值得深思

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

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

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

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

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

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

152 觀念溝通 新研究 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.

153 下面，簡介極限開發法 Extreme Programming (XP) 及 Agile Method 源起及重視點

154 XP Core Practice 核心實務* 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

155 XP Core Practices (Cont.)
3. Shared understanding 分享所知 SimpleDesign (DoSimpleThings, YouArentGonnaNeedIt, OnceAndOnlyOnce, SimplifyVigorously) SystemMetaphor CollectiveCodeOwnership CodingStandard or CodingConventions 4. Programmer welfare 員工福祉 SustainablePace (original name: FortyHourWeek) *

156 XP values價值觀[wikipedia]
Extreme Programming initially recognized four values in 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)

157 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.

158 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.

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

160 Agile2011 Keynote 1 Dr. 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.

161 Agile 2011 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.

162 Agile 2011 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 time, and that our abilities are not fixed but evolve with effort. This mindset helps creativity and collaboration in and out of the workplace.

163 Agile Method 重視點 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.

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

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

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

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

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

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

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

171 pair programming studies
after adjusting, pairs produced code 15% more slowly than individuals... reference:

172 pair programming studies
...with 15% fewer defects reference:

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

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

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

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

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

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

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

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

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

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

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

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

185 7. 站著開日會* (daily stand-up meeting)
每個工作天，全體開發團隊成員要 站著、圍成一圈，舉行每日會議 要站著，才可長話短說，使會議簡短 要全員，才使資訊直接傳達至每一人 要每日，才使溝通週期縮為一天 (昨日談的事，今日即可當面問) * 有專家認為:既然團隊整天在一起,溝通已足夠,就不需此會議,各公司自行斟酌吧

186 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)

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

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

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

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

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

192 促成創意湧現 的三項條件 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, extreme)

193 高 D E 焦慮 創意湧現 創意湧現 挑戰 C A 無聊 B 低 技能 高

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

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

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

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

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

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

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

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

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

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

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

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

206 方法

207 試行團隊 國內軟體公司如有決心*、意志力、專注力，可組本 myAgile 方法試行團隊如下: 1. 一名駐點使用專家
2. 四名軟體工程師，形成兩組(2 pairs) 3. 二名兼職工讀生 依前述辦公室佈置，run下面 myAgile 方法 * 依陳教授顧問經驗，老闆有心改變採用新方法，而開發者雖然認真聽課，但工作時還是用自己熟悉有把握的舊方法，沒有專注力及決心 拋棄過去的做法

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

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

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

211 myAgile 適用範圍 本法適用Java,C++,C#等傳统高階語言
不適用網路時代更高階語言 如標記語言 (mark-up language) 寫出的 ontology, agent 精準的說:C/C++思維較舊,C#仿Java;Java具O-O思維,並擴展至agent(語意網路semanticWeb)思維-計概應直接教Java!

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

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

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

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

216 2.驗收測試 案例 (Acceptance test case)
上述每個使用情節, 加上輸入資料及預期輸出資料後,即做為測試該功能可否驗收之依據, 叫一個驗收測試案例 也就是， 依每個案例跑程式; 如順利跑完，則該驗收測試案例 (acceptance test case) 通過 例子: 遊戲軟體最簡單的”驗收測試一”: 看到 welcomeScreen，輸入password JFK2008*後， 看到 mainScreen，點選 Exit，離開系統 *JFK2008 是 exact data，”情節一”無此 data , 又, 此data常是龐大的data file.

217 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 interfaces)，(1)(2) 找class encapsulation, (3) 找 class use relationship 此會議是群體智慧- 腦力激盪，快速溝通 真相: 大型軟體從未在架構師腦袋，而是多個程式師共同擁有

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

219 3.架構設計會議 (Cont.) CRC集思廣益來切割(partition)驗收測試案例,並找出user看不到的下層隱藏物件(hidden objects,紅色表示) 例如: 張三是位軍人 李四是個土匪 某日二人狹路相逢* 張三要李四用刀殺了他自己** 李四問王五殺何處 (王五是位醫生) 張三看著惨死的李四 想起兩人恩怨情仇 不禁流下熱淚 *一般英文書用John, Mary為物件名, 國人感受不深, 故用張三等 * Scenario中細字表示未實作部分 底線表class,object 粗體表method 斜體表parameter **直覺的說: 張三用刀殺了李四 但 O-O程式不是這樣執行的 method殺 屬於土匪

220 3.架構設計會議(Cont.) class軍人{..}; 軍人 張三; class土匪{..殺(武器,被殺者)};土匪 李四;
由上述 可得下列設計: class軍人{..}; 軍人 張三; class土匪{..殺(武器,被殺者)};土匪 李四; class醫生{..殺何處 ( )}; 醫生 王五 ; ..... 李四.殺 (刀, 李四); …… 王五.殺何處 ( );

221 3.架構設計會議(Cont.) 複習一下本例基本觀念: User Story (功能)是:張三殺人 Scenario 是: 張三要李四用刀殺了他自己 Use Case 是: (這文件併入架構設計文件) 張三要李四用刀殺了他自己 李四問王五殺何處

222 張三殺李四的真相 的確是張三下令要殺李四,但張三沒動手
張三把刀給了李四,並指示李四:被殺者正是李四自己* 然後李四毫不猶豫執行自殺動作** 而張三不知道動作細節(如刺心臟或砍脖子),執行後系統會回報結果給張三*** * The method gets two input arguments. ** then, it executes the method, *** finally, it sends return value.

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

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

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

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

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

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

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

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

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

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

233 Header(標頭) 兩例 /* method subString * A String object呼叫此 method，傳回介於兩個指定的 indexes 的子字串 * beginIndex 子字串起始的 index (含此 index) endIndex 子字串最後的 index (不含此 index) 由 beginIndex 到 “endIndex 的前一個位置” 的子字串 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)

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

235 文件簡化 上述 1)scenario, 2)acceptance test case, 3) 架構設計 三種文件可簡化合一(如下頁)
此文件還可當 4) 維修指引(maintenance guide):維修時依acceptance test case執行軟體，可找到呼叫的 method ，再找到source code file中該method的header及pseudo-code，了解後才去修改source code

236 同類 accep. test cases 由簡單而複雜 存同一檔案 最簡單case如下: method 1 (source code file) method 2 (source code file) 最複雜case如下: method 11 (source code file) method (source code file) method 12 (source code file)

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

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

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

240 傳統設計方式 (Cont.) class 吉普車 extends 車子 { the extended data and methods} class 車子 {輪胎 右前輪=new 輪胎() …; int 哩程; public boolean 發動 (… ) {…} } class 輪胎 {…} class 人員 {private boolean 車子狀況; public void 駕車 (吉普車 車號) {/*發動該車*/車子狀況 = 車號.發動 (… ); … } 小張=new 人員();老李=new 人員(); 吉普車 車1 = new 吉普車( );吉普車 車2 = new 吉普車( ); 小張.駕車 (車1) ;老李.駕車 (車2) 依物件互動，class diagram 只看到人員、吉普車兩個 classes 並非架構師畫的四個 classes:人員、吉普車 、車子、輪胎

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

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

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

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

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

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

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

248 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)); }

249 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 testSort1() { /* input為待排序數列，expected為預期結果, result為實際結果*/ int input[] = {3,1,4,2},expected[] = {1,2,3,4}; int result[]; …….. public void testSort2() { …… public void testSort3() { ………

250 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

251 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

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

253 6.資料結構設計 (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 另有 Heap, PriorityQueue (以後可能有 Network) 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.

254 An Example 例: 從小明家有單行道十公里到小英家 本頁是問題描述 下頁才是設計草圖

255 adjacencyMap 100 17 29 57 85 95 null hash key value next 68899 小華 小莉
29 57 85 95 null hash key value next 68899 小華 小莉 小明 小英 阿偉 15.0 8.3 20.0 14.2 10.0 7.4 to distance next

256 設計草圖轉成 Java data structure
protected HashMap <Houses, LinkedList <NeighborDistances>> adjacencyMap; protected Houses 小明; protected NeighborDistances 小明小莉14.2;

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

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

259 Why 增加兩種文件? XP 常被批評文件不足，又斟酌台灣國情， 故增加兩種文件: 1. 設計草圖 (design sketch)
寫在白板或白紙，短暫儲存 (目前軟工環境不佳，圖難與程式融合於電子檔) 2. 虛擬碼 (pseudo code) 寫在文字檔 (如Java file) 與程式融合， 長久儲存 與流程圖(flow chart)語意相同

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

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

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

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

264 英詞 (English Term) 如果開發者以中文思考 且皆閱讀中文資料則其腦海不易訂出精準英詞 可是程式要以精準英文表達的
此時要找英文較好者 review 英詞

265 英詞 命名 Class, object, variable 以名詞命名 class 用大寫開頭 最好複數 (如Desks)
object 用單數 最好有冠詞 (如myDesk) 只有一個 object，不致混淆，則省冠詞 如 symbolTable 而非 aSymbolTable Method 以動詞命名，並以參數區別之，如： boolean buy (Desks myDesk) boolean buy (Tables hisTable) 為不同 methods

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

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

268 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

269 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

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

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

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

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

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

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

276 7.演算法設計 (Cont.) 有人指出: 不需寫出虛擬碼 因為Java code 是高階語言 本身即具可讀性 但是 依陳教授經驗:
虛擬碼可提供更簡潔 更高階的了解 可讀性更提升 更有助日後維修

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

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

279

280 Pseudo code protected Entry<E> successor (Entry<E> e) {
1. if (e == null) return null; else if e 有 right child, 像 50 右下走一步 再往左下方走到底 else e 沒有 right child, 像 36 往左上方走到底 再右上走一步 2. return 找到的 entry } // end of successor

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

282 7. 演算法設計 (Cont.) 一般人從大一起就直接寫程式 跳過演算法設計 這已是根深蒂固的惡習 要改正 注意:
並非整個系統的演算法都設計好了 才寫程式 否則又陷入傳統 waterfall 模式了

283 Class Interface & Data Strucure
class Adjacency protected HashMap <Houses, LinkedList<NeighborDistances>> adjacencyMap; void showAllAdjacencies (Houses theHouse) void showNames (HouseList houseList)

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

285 演算法設計例子(Cont.) private void showNames (HouseList houseList)
/* * showNames 顯示 houseList 各人名 * houseList 例 小華 阿偉 * Time estimate: O(n) */ private void showNames (HouseList houseList) for i from 0 upto houseList的元素個數-1 顯示 houseList 第 i 個元素所含的人名 end for 285

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

287 補上程式碼 例子 注意:要凸顯虛擬碼 隱藏程式碼 以利閱讀
/* * showNames 顯示 houseList 各人名 * houseList 例 小華 阿偉 * Time estimate: O(n) */ private void showNames (HouseList houseList) /*for i from 0 upto houseList 的元素個數 -1 */ for(i=0, i<=length(houseList-1), i++); /*顯示 houseList 第 i 個元素所含的人名*/println houseList(i).name); /*end for */ 注意:要凸顯虛擬碼 隱藏程式碼 以利閱讀

288 9.單元測試 (Unit testing) 待單元程式(unit, 如一個 Java public
method source code) 完成後， 用工具(如JUnit)，自動執行 test code 測試該單元 (unit) 叫單元測試

289 單元測試 例子

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

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

292 Class diagrams generated by tool

293 Sequence diagram generated by tool

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

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

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

297 myAgile 經驗談 (Cont) 陳教授授課敏捷方法一學期後,全班舉行 開發郵局ATM 模擬遊戲 各人接力說故事,說明如何依myAgile開發 意外的是:同學竟不知駐點使用專家要獨力做出大量 scenarios 及 acceptance test cases 文件 - 同學打從心裡不重視需求分析,難怪台灣軟體品質差!

298 範例

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

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

301 Test Case (Cont.) 依據以上列舉情形，設計以下test cases： 1. 數列元素皆不同 2. 所有數列元素皆相同
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}

302 Test Code 標頭 (header) /* test code: testMySort.java
source code: mySort.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 檔名要易記易用易管理

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

304 Test Code (Cont.) // Java Test Code
//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)); }

305 Test Code (Cont.) // Test Case 2：input {1,1,1,1} expected output：{1,1,1,1} public void testSort2() { 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

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

307 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)

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

309 Pseudo Code (Cont.) 3. 最低抽象層次為: sort: sort array 成由小而大的順序
for i from 0 upto N-2 1.min(最小數的索引)指著array[i..N-1]的第一個數 (即arry[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 所指的數換到 array[i..N-1]的第一個位置

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

311 Coding (Cont.) /* 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]的第一個數 (即array[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 所指的數換到 array[i..N-1]的第一個位置 (即array[i])*/ swap (i,min);}

312 活著！ 活著！ Coding (Cont.) Coding 就是逐行在 pseudo code 後面， 補上對應的 source code
故source code要隱蔽 (以後有工具 PseudoCoder ) 不可阻礙 pseudo code 之畫面呈現 程式才易於閱讀、了解、維修，才是活著， 活著！ 活著！

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

314 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; }

315 Unit Testing (Cont.) 用JUnit 其下載網址 http://www.junit.org/index.htm
　(a)把 source code: mySort.java test code: TestmySort.java 放同一目錄 (b)在命令列檔案所在目錄鍵入　javac *.java 編譯這兩個檔案 　　　 若編譯正確，不會出現錯誤訊息

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

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

318 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)); }

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

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

321 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

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

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

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

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

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

327 Shell Sort Design Sketch
Shell sort 依increment將數列分成數個子數列，分別做insertion sort 從子數列第二個元素起，向右隔increment個元素，逐一insert至左邊已sort之子數列 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 數列

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

329 Shell Sort pseudo code end for public int[] shellSort (int increment)
1.for 子陣列 k from 1 upto increment, 分別做insertion sort for i from 1+k upto N-1 by increment, 逐一插至左邊 array使變大之 array保持已sort 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

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

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

332

333 附錄

334 C# Unit Testing // C# test code using NUnit.Framework;
/*建立一個TestmySort Class為測試的Class*/ [TestFixture] public class TestmySort { /*改寫每一個TestCase為一個public method，並加上[Test]*/ [Test] public void testCase1(){} }

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

336 C# Unit Testing (Cont.) Test Case 2：input {1,1,1,1} expected output：{1,1,1,1} [Test] public void testCase2(){ int[] input={1,1,1,1}; int[] excepted={1,1,1,1}; int[] result=new int[4]; mySort obj= new mySort(input); result=obj.Sort(); Assert.AreEqual(result,excepted);} 依此方式寫出所有 Test Cases 的 Test Code

337 C# Unit Testing (Cont.) 取得與安裝UltraEdit
下載點： 下載完後得到cuedit920a.exe檔，執行該檔案進行安裝

338 C# Unit Testing (Cont.) 安裝完成後執行UltraEdit，點選輸入授權號碼
使用者名稱輸入 Universal User 授權碼輸入

339 C# Unit Testing (Cont.) Testing (使用NUnit) 下載網址： (a)設定 UltraEdit 環境 選擇 進階>工具組態 指令列輸入csc /t:library /r:(安裝路徑)\bin\nunit.framework.dll %n%e 工作目錄輸入 %p 名稱輸入 NUnitC#

340 C# Unit Testing (Cont.) (b)將mySort與TestmySort編輯在同一個檔案中(mySort.cs)，
並選擇 進階>NUnitC#，進行編譯，產生mySort.dll檔案

341 C# Unit Testing (Cont.) (c)開啟NUnit圖形介面，並選擇File>open 開啟mySort.dll檔案
TestmySort class 中包含的 TestCases

342 C# Unit Testing (Cont.) (d)選擇TestmySort ，並點選Run執行Testing 綠色表示測試通過

343 C# Unit Testing (Cont.) 如果將TestCase改寫產生錯誤，會顯示紅色，並產生錯誤訊息