輕鬆談軟工

今天上課前突然想到一個故事，稍作改變後用來跟學生講解流程改善。 某公司聘用一個員工上種樹，他需要鋤頭挖洞，將樹植下，最後再用鏟子把地鏟平。以他的速度一天只能種十顆樹，比老闆預期的進度差太多，於是老闆又聘了兩個人來幫忙，速度提昇了兩倍。 [from work harder to work smarter] 但是這樣的速度還是不夠快，而成本又太高已經沒有經費在聘用員工，只好想辦法進行流程改善。他仔細觀察三個員工的工作方式，發現花在工具的抽換花了太多的時間。於是他重新更換了三個人的工作：A 只做挖洞的動作，B 隨後將樹植下, C 隨後在將地鏟平。這樣的工作模式可以省去更換工具的時間，更棒的是，每個人更能夠把自己的工作做的專精，效率又提高了兩成。 [但，小心成為官僚流程] 這樣的流程跑了很久，員工來來去去換了許多次，但都保持一定的高效率。一天，老闆去看工地，發現A 挖玩洞後，C 緊接著把洞補起來填平，老闆生氣的說：『你們在做什麼？B君呢？』 『喔，他今天請假了』A 說。 最後這個笑點看似誇張，但在企業流程卻常見。許多人習慣了只知道follow 流程去做，卻不之所以然，所以很容易鬧出笑話。另一方面企業也常常不重視流程的教育訓練，所以常常空有好流程卻無法發揮最大的效用。

去年12月初去參加在北京舉行的 Asia Pacific Software Engineering Conference， Ivar Jacobson  (UML的開發者之一)的Keynote Speech令我印象深刻，推薦大家到  APSEC 2008  的網站下載他的演講投影片。 摘錄幾句他對Process的觀點： Every process tries to be complete. – As a consequence every successful process will grow until it dies under its own weight. • Every process usually becomes just shelf-ware. – Law of Nature: People don’t read process descriptions. • The process is out of sync with what the team does… – …and the project – process gap get wider and wider • The project has to adopt an entire process. – No-one uses an entire process or limits themselves to practices from one process. It’s no wonder no-one likes process. Jacobson認為practice比process重要： Practices are First Class Citizens. Process is just a package of practices. 什麼是practice? A practice provides a way to systematically address a particular aspect of a process. Practices focus on the essentials. It is the key things to do and the key things to produce. 個人的感想是： 沒有一個process是特別好的，包括CMMI。 真正...

CMMI(Capability Maturity Model Integration) 將軟體開發流程視為一種工程 ( 製造 ) 流程，利用控制、量測、改善 (control, measure, and improve) 等循序漸進的方法，達到軟體流程改善的一個框架。 CMMI 是在美國國防部 DoD 以及國防工業協會 (NDIA) 的支持下， CMU 的軟體工程學院 (Software Engineering Institute, SEI) 發展出來的模型。 CMMI 中許多的概念與原理來自於創立 SEI 軟體流程計畫 (software process program) ，並曾任職於 IBM 、領導大型系統軟體開發的 Watts Humphrey 。根據 IBM 與 SEI 的經驗， Humphrey 將廣泛運用在製造流程中的統計流程控管 (Statistical process control, SPC) 的概念，加以修正、擴充後運用於軟體流程管理中。 在一方面，定義軟體開發流程中的各種活動與其彼此間的關係，是將軟體開發流程視為一種製造流程，並實施量化控制的前提之一。在另一方面，由於這些活動相當繁多、複雜且彼此牽動，故唯有在軟體開發活動結構定義清楚之後，方能找出可量測事物，並根據其關連性推論量測值的意義。 CMMI 將軟體開發相關活動的實務作法分為 25 個流程領域 (process area, PA) ，定義其需管理的項目，含一般目標、特定目標、具體作法等，並找出其彼此間的關連性。 依性質來分，這些 PA 分屬於流程管理、專案管理、工程、與支援等四大類 流程管理 ： CMMI 的目的是流程改善，因此流程的定義、維護、修正等均為重要活動。 專案管理 ：因為軟體開發、維護均以專案為單位，以便在專案進行前進行人力、資源、時間、經費計算以及專案進行中管控，如需求變更、進度監控等。 工程 ：軟體開發實質上涵蓋許多軟體工程的原理與具體作法，如需求發展、分析、應用設計、系統設計、實作、測試、部署、維護等相關活動，這些活動需要加以管理。 支援 ：支持前三類活動進行之環境與工具之支援活動等，例如提供產出物與組態管控、議題追蹤等活動。 CMMI 有連續式 (continuous) 與階段 (staged) 式兩種表示法。採用連續表示法...

軟體工程有許多觀念是比較抽象的，也因此有許多生動有趣的故事孕育而生，用來闡述這些生澀的觀念。這個部落格既然名為『輕鬆談軟工』，我覺得也適合談一些小故事。 有一個樵夫靠砍材為生，砍材的斧頭就是他主要的生財工具，也是所有家人的依靠。隨著小孩子一個個的出生，樵夫的經濟壓力越來越大，於是他越勤勞的工作，工作的時間越來越長。日子久了，斧頭生鏽越來越嚴重，木頭都砍不下去了，路過的人好奇的問：『老樵夫啊，斧頭都生鏽了，怎麼都不磨一磨？』 『開什麼玩笑？砍材都來不及了，哪來的時間磨斧頭？』老樵夫頭也沒抬的說。 這個故事主要談的是 流程改善 。許多軟體工程師每天都像樵夫一般勤奮的工作，可是工具、方法錯了，勤奮的工作並沒有帶來相對的報酬。他們或許感覺需要停下來改善工作的流程，例如規範需求變更的流程、設計版本控管的機制、研究專案成本的估算方法，無奈手頭上的案子每個都是十萬火急，只好暫時把流程改善的工作丟到一旁。這一丟可能就是好幾年，也丟掉可能成功的契機。 如何解決？我想組織必須要有 長痛不如短痛 的決心，另一方面，高階主管的鼓勵、決心與半壓迫的魄力也很需要。沒有決心，每個經理人都是以專案為重 - 能砍多少材是多少材吧，很難做長遠的規劃。