服務過程中常被問到的問題之一，就是計畫，怎樣寫計畫書或者大綱結構之類的問題，專案計畫跟任何的企畫書一樣，目的都是為了溝通並確認達成專案目標的管道、步驟，因此，計劃書的資訊不宜過多或不足，這當中的分寸要怎樣拿捏呢？
以我初淺的經驗去看，我認為計畫一定要交代：人、事、時、地、物、數，
1. 人：專案組織圖，權責
2. 事：表達的重點是執行過程當中的任務，昨天提過用幾點去展開, 含：分析、設計、開發、測試、建置、移轉等基本任務
3. 時：以上這些任務要執行多久？時程安排
4. 地：除了我們認知的工作地點外，環境還代表了專案執行過程用到的設備，例如：開發環境、測試環境、版控環境
5. 物：專案執行過程中，會交付哪些成果給客戶？例：專案執行計畫、雛型系統、設計規格、使用手冊、原始程式碼。
6. 數：成本估算數字，簡單來說就是報價單
此外，再加上建議解決方案即可，除非客戶要求，絕對不要加上其他非必要資訊，以免失焦，反而造成溝通不良。
2008年12月3日 星期三
對 CMMI 量化指標的批判
今天收到了一份 CMMI 度量指標的清單，看過後，我馬上回信給發信人，也請各位慎思相關議題！
以下是小弟的初淺看法，還請各位不吝賜教：
Dear Sir，
首先，要謝謝您提供的CMMI量化指標資訊，關於MA，我的意見一定會得罪許多人，如果有得罪之處，還請包涵，但，我還是要扮演國王新衣故事裡頭的那個不知天高地厚的初生之犢
先講結論，這份MA對真正務實的軟體公司而言用處真的很低，原因羅列如下：
1. 資料收集的時機造成問題，許多數據都是專案晚期才完成，也就是說，多數的數據都是落後指標，如果是運做順利的專案，當然不成問題，但，如果是運作出問題的專案，已經問題重重、資源都不夠用了，專案還在這些度量問題上打轉，似乎有點緣木求魚。結果是，專案結束後補做這些度量，因此，工程師不知道公司要求做這些事的本意為何?甚至解讀為增加工程師負擔...產生負面效益，人員流動率上升。
2. 資料收集的用途，當中講到的度量目的完全不正確，很多度量都沒有清楚說明用途為何? 有點為了度量而度量的味道，似乎忽略了原始度量的本意，有用的數據是能夠對專案、組織或者企業找出問題與改進方向的。
3. 度量方向有點不合時宜，OO跟Functional Points、LOC這類的度量，在本質上不相容，而且LOC越多代表的意義是?程式邏輯很複雜亦或人員寫程式的功力很差?反之，LOC越少又代表啥意義?
以上報告，聽來多少有點刺耳，但，忠言逆耳阿...希望您能諒解
後語：
雖然這裡對目前的 MA有所批判，我還是要還給 CMMI 一個公道，如果我們能夠
1. 確認度量數據的實際用途、
2. 找到更適切的度量指標
3. 採用適當的做法或工具
4. 及早獲得相關數據
就可以充分發揮度量的效益，讓團隊更成熟、製程更穩健、專案成功機率更高...共勉之
關於MA，我必須採取更負責任的態度去說明各項度量可能被誤用的情形與日前我提出批判的理由，以工時預估誤差率為例，
理想是
1. 工時估算與實際差距不大，專案精準掌握成本
2. 投入皆能獲得相對的報酬
3. 累積經驗後，下次估算更精準
實際是
1. 估算當時，刻意壓低估算數字
2. 專案初期真的沒誤差，後期誤差越來越大
3. 為了縮短誤差，投入更多時間加班
原因是
1. 為了活下去，公司要求業務，業務則用低價搶案
2. 簡單的任務都完成了，剩下的都很困難
3. 工時都是人填的，虛報或浮報完全操之在我
對策是
1. 改用產能估算專案成本
2. 越困難的問題產能應該越高
3. 先處理高風險議題
4. 不把工時當作評定績效的唯一標準
其他度量項目，容小弟花點時間整理，屆時再向各位報告
以下是小弟的初淺看法，還請各位不吝賜教：
Dear Sir，
首先，要謝謝您提供的CMMI量化指標資訊，關於MA，我的意見一定會得罪許多人，如果有得罪之處，還請包涵，但，我還是要扮演國王新衣故事裡頭的那個不知天高地厚的初生之犢
先講結論，這份MA對真正務實的軟體公司而言用處真的很低，原因羅列如下：
1. 資料收集的時機造成問題，許多數據都是專案晚期才完成，也就是說，多數的數據都是落後指標，如果是運做順利的專案，當然不成問題，但，如果是運作出問題的專案，已經問題重重、資源都不夠用了，專案還在這些度量問題上打轉，似乎有點緣木求魚。結果是，專案結束後補做這些度量，因此，工程師不知道公司要求做這些事的本意為何?甚至解讀為增加工程師負擔...產生負面效益，人員流動率上升。
2. 資料收集的用途，當中講到的度量目的完全不正確，很多度量都沒有清楚說明用途為何? 有點為了度量而度量的味道，似乎忽略了原始度量的本意，有用的數據是能夠對專案、組織或者企業找出問題與改進方向的。
3. 度量方向有點不合時宜，OO跟Functional Points、LOC這類的度量，在本質上不相容，而且LOC越多代表的意義是?程式邏輯很複雜亦或人員寫程式的功力很差?反之，LOC越少又代表啥意義?
以上報告，聽來多少有點刺耳，但，忠言逆耳阿...希望您能諒解
後語：
雖然這裡對目前的 MA有所批判，我還是要還給 CMMI 一個公道，如果我們能夠
1. 確認度量數據的實際用途、
2. 找到更適切的度量指標
3. 採用適當的做法或工具
4. 及早獲得相關數據
就可以充分發揮度量的效益，讓團隊更成熟、製程更穩健、專案成功機率更高...共勉之
關於MA，我必須採取更負責任的態度去說明各項度量可能被誤用的情形與日前我提出批判的理由，以工時預估誤差率為例，
理想是
1. 工時估算與實際差距不大，專案精準掌握成本
2. 投入皆能獲得相對的報酬
3. 累積經驗後，下次估算更精準
實際是
1. 估算當時，刻意壓低估算數字
2. 專案初期真的沒誤差，後期誤差越來越大
3. 為了縮短誤差，投入更多時間加班
原因是
1. 為了活下去，公司要求業務，業務則用低價搶案
2. 簡單的任務都完成了，剩下的都很困難
3. 工時都是人填的，虛報或浮報完全操之在我
對策是
1. 改用產能估算專案成本
2. 越困難的問題產能應該越高
3. 先處理高風險議題
4. 不把工時當作評定績效的唯一標準
其他度量項目，容小弟花點時間整理，屆時再向各位報告
2008年11月17日 星期一
軟體加(+)減(-)法
忘記在哪篇討論教改的文章看過華人社會習慣減法，美系國家則習慣於加法計算方式，那篇文章說明了一種生活態度，也因為如此，國人在便利商店常會有買55元東西支付105元讓店員找錢的狀況，店員也習慣性地用減法計算然後找了50元給顧客，這種情況如果換到美系社會，肯定會造成困擾...之類的評論；我很認同那篇文章的部分觀點
小弟認為不論是加法、減法，這反映出來的不僅僅是一種現象，更是一種文化，這代表的是傳承的過程，也帶著點強迫的性質，文化的傳遞過程主要是老一輩怎麼說，我們就怎麼做，偶爾加點懷疑、衝突、創新，但日子久了，也就變成另一種約定成俗了；因為工作的關係，近來腦子裡不斷產生類似的疑問，這種加減法的文化背後代表的本質是？
從現象來看，加法文化下成長的小孩較有自信，相信是他們不斷鼓勵各種成就的原因吧；相對的，減法文化培養的小孩確是認為自己還有許多不足處，還有許多可以努力的空間，課後輔導、補習、明星學校...都因為這樣的文化而蓬勃，從這點看來，似乎加法文化比較好！
但是，加法無限擴張之後，大頭症就來了，認為沒有不可能，甚麼事都能做到(也的確做了很多豐功偉業)，但也造就了信用無限擴張與全球性金融風暴的重大危機；反觀華人社會的發展，因為從小的教育使然，總覺得做的不夠好，所以步步為營，採取的策略總是一步一腳印，站穩腳步才往前邁進，也因為如此，華人社會受到的衝擊相對較輕，深思熟慮的做事方法，也凸顯在危機處理的速度上...
講了這麼多，到底跟軟體有甚麼關係？主要是因為目前軟體工法有兩派爭論，一是CMMI之類的全面論點，認為可以透過 CMMI之類的方法去建立軟體工廠；另一派則是講人文，尊重人本的Agile方法論。這兩派方法論的支持者都能講出對方的優點與困難，也都很有道理，贊成CMMI的一方認為Agile過度簡化...，認同Agile的一方則認覺得CMMI過度要求...。
我認為，Agile 就像加法文化，能獲得多少，是累積上去的，因此有許多發展的可能性；而CMMI也可以類比成減法文化，需要透過很多努力去實踐，以達成組織設定的目標，這兩者的優劣，請各握透過加減法的觀點去分析，或許能有新的見解產生喔 ^_^
無論採取加法或減法，提醒各位【勿忘初衷】，先想想專案需要甚麼？然後才思考要採取何種解決方案吧！
小弟認為不論是加法、減法，這反映出來的不僅僅是一種現象，更是一種文化，這代表的是傳承的過程，也帶著點強迫的性質，文化的傳遞過程主要是老一輩怎麼說，我們就怎麼做，偶爾加點懷疑、衝突、創新，但日子久了，也就變成另一種約定成俗了；因為工作的關係，近來腦子裡不斷產生類似的疑問，這種加減法的文化背後代表的本質是？
從現象來看，加法文化下成長的小孩較有自信，相信是他們不斷鼓勵各種成就的原因吧；相對的，減法文化培養的小孩確是認為自己還有許多不足處，還有許多可以努力的空間，課後輔導、補習、明星學校...都因為這樣的文化而蓬勃，從這點看來，似乎加法文化比較好！
但是，加法無限擴張之後，大頭症就來了，認為沒有不可能，甚麼事都能做到(也的確做了很多豐功偉業)，但也造就了信用無限擴張與全球性金融風暴的重大危機；反觀華人社會的發展，因為從小的教育使然，總覺得做的不夠好，所以步步為營，採取的策略總是一步一腳印，站穩腳步才往前邁進，也因為如此，華人社會受到的衝擊相對較輕，深思熟慮的做事方法，也凸顯在危機處理的速度上...
講了這麼多，到底跟軟體有甚麼關係？主要是因為目前軟體工法有兩派爭論，一是CMMI之類的全面論點，認為可以透過 CMMI之類的方法去建立軟體工廠；另一派則是講人文，尊重人本的Agile方法論。這兩派方法論的支持者都能講出對方的優點與困難，也都很有道理，贊成CMMI的一方認為Agile過度簡化...，認同Agile的一方則認覺得CMMI過度要求...。
我認為，Agile 就像加法文化，能獲得多少，是累積上去的，因此有許多發展的可能性；而CMMI也可以類比成減法文化，需要透過很多努力去實踐，以達成組織設定的目標，這兩者的優劣，請各握透過加減法的觀點去分析，或許能有新的見解產生喔 ^_^
無論採取加法或減法，提醒各位【勿忘初衷】，先想想專案需要甚麼？然後才思考要採取何種解決方案吧！
2008年11月11日 星期二
測試方法與案例
單元測試是確保成果的基礎，沒有完成單元測試的軟體只是把風險移轉給使用者，這是一種鴕鳥心態，也是驗證莫非定律的不良示範，凡映出來的結果將是更多的客訴，投入更多資源去除錯，成本增加，驗收困難，工作負荷增加...，這些都是沒有妥善執行測試的現象；反之，如果為了品質而過度測試，這當中的資源浪費又要算在誰的頭上呢？
因此，測試必須執行，但也要避免過度，怎樣找出平衡點？軟體開發者必須累積經驗並從中獲得真正適合該組織的知識...歡迎加入討論
衍生閱讀：Test Driven Development(TDD)
因此，測試必須執行，但也要避免過度，怎樣找出平衡點？軟體開發者必須累積經驗並從中獲得真正適合該組織的知識...歡迎加入討論
衍生閱讀：Test Driven Development(TDD)
2008年11月5日 星期三
CMMI or AGILE
最近有很多類似的題目，CMMI 很完備，Agile 很輕量，中間的差異似乎非常大，軟體公司到底要採用哪一種方法?
CMMI 當中有許多環節是 Agile 沒有提到的，熟悉 CMMI 的人應該都清楚它的背景 & 立意，因此，從健全系統發展的觀點去看，我會把 CMMI 當成類似字典的工具書，這種工具，讓我在碰到問題的時候，可以從更多元的角度去思考，但，決不照單全收。
Agile 很輕量，實務上也非常貼近現實，因此，我完全支持 "Agile 的立意"，可視的結果是我們需要的，否則為啥要做專案? 消化預算 or 浪費生命?
然而，各位奮力擁抱 Agile 之前，請各位注意以下議題：
1. agile 當初成立的大堆頭是哪些人?
2. 這些人的背景是? 他們曾經歷過哪些?
3. 怎樣的演變過程才有 agile 產生?
4. 我們是否有同樣的基礎去實施 agile ?
結論是，CMMI or Agile 都適合也都不合適...因為，我們不曾想過自己真正 "需要" 什麼，貴專案真的需要是啥? 成員是否有面對改變的共識?
後語：有人問我 Agile 不適合的原因，以下是我的答覆
Agile不適合的原因?如果用原因這個詞，感覺有點強制，因此我改用不適合的可能狀況
1.跨地區開發，如果沒有良好的配套/溝通橋樑，可能會造成溝通瓶頸，訊息流通速度慢－因為要跑許多流程...，或者訊息沒有被好好地解讀，或許大家會有opensource來當反例，但我要問的是，這些參加opensource開發者的工作心態是怎樣的積極，你清楚嗎? 跨地區的團隊是否有相同的態度呢?
2.工作基準不一致，如果連團隊協同合作的基礎都沒建立，怎樣實施Agile?
3.客戶屬性，如果你碰到的客戶工作要求是僵化的waterfall基準，而且不能說服，公司又一定要賺這筆錢?你可以完全適用Agile?
4.對測試驅動的認知&實務
5.團隊屬性...
太多可能狀況了，但我要強調的是，Agile真的很好用，客戶很喜歡我們採用類似Agile的做法
衍生閱讀：
1. 軟體設計思維
2. 建構管理
CMMI 當中有許多環節是 Agile 沒有提到的，熟悉 CMMI 的人應該都清楚它的背景 & 立意，因此，從健全系統發展的觀點去看，我會把 CMMI 當成類似字典的工具書，這種工具，讓我在碰到問題的時候，可以從更多元的角度去思考，但，決不照單全收。
Agile 很輕量，實務上也非常貼近現實，因此，我完全支持 "Agile 的立意"，可視的結果是我們需要的，否則為啥要做專案? 消化預算 or 浪費生命?
然而，各位奮力擁抱 Agile 之前，請各位注意以下議題：
1. agile 當初成立的大堆頭是哪些人?
2. 這些人的背景是? 他們曾經歷過哪些?
3. 怎樣的演變過程才有 agile 產生?
4. 我們是否有同樣的基礎去實施 agile ?
結論是，CMMI or Agile 都適合也都不合適...因為，我們不曾想過自己真正 "需要" 什麼，貴專案真的需要是啥? 成員是否有面對改變的共識?
後語：有人問我 Agile 不適合的原因，以下是我的答覆
Agile不適合的原因?如果用原因這個詞，感覺有點強制，因此我改用不適合的可能狀況
1.跨地區開發，如果沒有良好的配套/溝通橋樑，可能會造成溝通瓶頸，訊息流通速度慢－因為要跑許多流程...，或者訊息沒有被好好地解讀，或許大家會有opensource來當反例，但我要問的是，這些參加opensource開發者的工作心態是怎樣的積極，你清楚嗎? 跨地區的團隊是否有相同的態度呢?
2.工作基準不一致，如果連團隊協同合作的基礎都沒建立，怎樣實施Agile?
3.客戶屬性，如果你碰到的客戶工作要求是僵化的waterfall基準，而且不能說服，公司又一定要賺這筆錢?你可以完全適用Agile?
4.對測試驅動的認知&實務
5.團隊屬性...
太多可能狀況了，但我要強調的是，Agile真的很好用，客戶很喜歡我們採用類似Agile的做法
衍生閱讀：
1. 軟體設計思維
2. 建構管理
2008年10月14日 星期二
建構與變更管理課程後
講完建構與變更管理課程後, 我收到了以下回覆：「我們是一個 embedded 系統廠，每個案子的變數都相當的多，有硬體，軟體，客人臨時要求 .... 這種不同的變數。我想上課的內容的確給了許多觀念與想法，可以讓我們在執行時多想想的。...軟體初開發時，哪些事情是要注意的，在開發過程中，哪些資料需要建立，還有面臨變化時，怎麼樣可以把問題降低，解決。讓PM可以把工作控制的更安全。這是我們希望能學到的。」
很謝謝你的回饋, 關於你信件中提到的問題, 我盡可能回覆如下：
案子成立之初
1. 初步決定系統規格 (機構, 硬體, 軟體, 韌體...)
2. 釐清設計限制 (空間, 容量, CPU 等級)
3. 確立遊戲規則, 例如: 用 Issue Tracking 記錄與處理各方需求的流程
軟體開發過程...面臨變化時，怎麼樣可以把問題降低，解決
1. 確認規格 -> 設計具彈性的軟體架構, 例如引用 design patterns
2. 確認軟體架構的相依性, 先做底層部分, 例如：採購, 銷售與庫存, 最底層的部分應該是"庫存"
3. 逐步開發 -> 測試(一定要寫測試個案) -> 確認完成後 -> Check In (Commit 記得要加註記, 若使用 CodeBeamer 將可看到相關資訊, 知道問題的處理進展)
4. 持續整合 -> 測試並驗證各項問題已經被處理
5. 如果有其他需求, 回到步驟 1 (可能會需要調整設計)
以上說明, 若有任何意見, 歡迎隨時來信
衍生閱讀:
1. JAVA 軟體開發基準
2. 建構與變更管理
很謝謝你的回饋, 關於你信件中提到的問題, 我盡可能回覆如下：
案子成立之初
1. 初步決定系統規格 (機構, 硬體, 軟體, 韌體...)
2. 釐清設計限制 (空間, 容量, CPU 等級)
3. 確立遊戲規則, 例如: 用 Issue Tracking 記錄與處理各方需求的流程
軟體開發過程...面臨變化時，怎麼樣可以把問題降低，解決
1. 確認規格 -> 設計具彈性的軟體架構, 例如引用 design patterns
2. 確認軟體架構的相依性, 先做底層部分, 例如：採購, 銷售與庫存, 最底層的部分應該是"庫存"
3. 逐步開發 -> 測試(一定要寫測試個案) -> 確認完成後 -> Check In (Commit 記得要加註記, 若使用 CodeBeamer 將可看到相關資訊, 知道問題的處理進展)
4. 持續整合 -> 測試並驗證各項問題已經被處理
5. 如果有其他需求, 回到步驟 1 (可能會需要調整設計)
以上說明, 若有任何意見, 歡迎隨時來信
衍生閱讀:
1. JAVA 軟體開發基準
2. 建構與變更管理
2008年8月6日 星期三
反思：品質與度量?
關於品質的想法
測試要測哪些?對應的測試項目與規格?
測試人員與時間是否充分?
測試人員的素質?
測試人員該怎樣發揮?(提問的藝術)
問答過程能不能找到問題背後的原因?
問答過程能否釐清可能的解決方案?
問答過程都可以有效地追蹤與管理?
我是一個知識工作者?反思：問題應該修正成『身為一位知識工作者，我應該多做些甚麼?』
觀點：問對問題比較重要
該怎樣提問呢?
重要性如何決定?
練習提問的藝術
換個角度思考，例如：工作管理，工作涉及到的人員、任務與進度該怎樣管理比較恰當?是否有其他可能方案?
任務 | |||
人員 | 待處理 | 執行中 | 已解決 |
張三 | … | ||
李四 | … | ||
王五 | … | ||
典型的工作分配表
任務 | |||
人員 | 待處理 | 執行中 | 已解決 |
張三 | … | ||
李四 | |||
王五 | |||
換個角度思考之後的分配表
追問：兩個方案的優缺點分別為何?兩方案分別適用怎樣的情況?有無假設與前提?
問：IT 專案可以度量的項目為何?好處與缺點?
很多地方都會提到的基本度量如時間、成本、範疇、品質。
直覺看到的是時間、投入、產出、瑕疵(defects) 等輸出，但真的只是這樣?還有沒有其他可能性?
反思：以上這些量化資訊是在怎樣的假設或者前提之下建立的?
反思：這些資訊的真正用途為何?只為了取得認證?
有的度量可以很多，通常都會包括非常多的衍生性數據，差異就是很有用的資訊，例如：投入與產出的差異、規劃與實際的差異、需求改變的次數…
反思：為了量化所投入的成本是否值得?
反思：真正適合公司/組織的核心指標為何?
觀點：如何評估真正的baseline?
2007年1月13日 星期六
是否該導入 CMMI？
上回的觀點中，筆者簡單說明了自己對於CMMI的認知，同時也為剛剛入門的朋友簡介了一下CMMI (能力成熟度模型) 的四大流程領域與能力成熟度觀點。
這回我們將觸及朋友們經常提出的第一個問題，是否該導入 CMMI？導入 CMMI 真的也那麼大的好處？換句話說就是投資報酬率的問題？
如果回答這問題的是CMMI輔導顧問，那麼多數顧問將引用許多的數據告訴你CMMI是多麼地好，能降低公司經營成本、改善公司體質…等等。真的可以單純地相信顧問們提出的數據？如果是降，為什麼通過 CMMI 三級認證的公司，做出來的ＸＸ系統還是會不斷遭受客戶質疑！系統的壓力耐受度是如此地脆弱嗎？
除了從顧問們提供給的數據看到佐證外，我必須誠實地回答各位，CMMI 的精神是好的，不論從品質、成本、專案與風險管理的角度去看，他都有存在的價值與效益；但CMMI 是否能產生實質效益卻是事在「人為」，參與者用怎樣的心態去面對，絕對影響整件事情的發展，沽名釣譽者可以通過認證，苦幹實幹者也可以通過認證，但時間絕對會證明一切，剛剛說的ＸＸ售票系統不就是最佳的反例？
看到這現象，筆者體會到「哀矜勿喜」的真正意涵，台灣的軟體產業真的如此不堪一擊？我們必須停下腳步，不要一味地說是大環境不好或者CMMI制度不適用於台灣的環境，因此抹殺前人的功勞！取而代之的應該是徹底檢討，到底問題出在什麼地方？我們在這個過程中學習到什麼？
反省、檢討、改善並獲得所謂的Lessons Learned，不就是 CMMI 當中決策分析與解決方案(DAR: Decision Analysis and Resolution)反饋回流程管理領域 (Processes Management－組織流程焦點、組織流程定義、組織層級教育訓練…等)過程嗎？
懂得檢討才能累積經驗(Lessons Learned)並達到持續改善的真諦。
因此筆者認為各位應該關注的議題不是導入 CMMI 與否，或者一味地抗拒 CMMI，真正要提出的問題應該是：
1. 組織/公司目前碰到了怎樣的難題？
是控制不易、溝通不良、品質不佳、無法累積實力…什麼問題最嚴重？什麼問題做最急迫？輕重緩急？
2. 公司的現況、遠景？
有無實際可行的計畫與支持團隊？打算腳踏實地、突破創新還是繼續沽名釣譽？
以上問題雖然嚴肅，但卻是真正值得深思的，有些朋友會告訴我，這些是公司老闆們應該顧慮的問題，不是我這種層級該管的，我了解不在其位不謀其政的想法，但是，山不轉路轉…，或許你可以轉寄一些資料給上司、同事，不論你是否考慮導入 CMMI，我都希望這篇文章能讓大家凝聚共識；大家逐步達成共識，就是進步～
各位朋友們，無論將來職場如何發展，自己也可以累積一套Lessons Learned，反省、學習、累積與成長是進步的動力，如果能進而分享將可得到更多回饋。
這回我們將觸及朋友們經常提出的第一個問題，是否該導入 CMMI？導入 CMMI 真的也那麼大的好處？換句話說就是投資報酬率的問題？
如果回答這問題的是CMMI輔導顧問，那麼多數顧問將引用許多的數據告訴你CMMI是多麼地好，能降低公司經營成本、改善公司體質…等等。真的可以單純地相信顧問們提出的數據？如果是降，為什麼通過 CMMI 三級認證的公司，做出來的ＸＸ系統還是會不斷遭受客戶質疑！系統的壓力耐受度是如此地脆弱嗎？
除了從顧問們提供給的數據看到佐證外，我必須誠實地回答各位，CMMI 的精神是好的，不論從品質、成本、專案與風險管理的角度去看，他都有存在的價值與效益；但CMMI 是否能產生實質效益卻是事在「人為」，參與者用怎樣的心態去面對，絕對影響整件事情的發展，沽名釣譽者可以通過認證，苦幹實幹者也可以通過認證，但時間絕對會證明一切，剛剛說的ＸＸ售票系統不就是最佳的反例？
看到這現象，筆者體會到「哀矜勿喜」的真正意涵，台灣的軟體產業真的如此不堪一擊？我們必須停下腳步，不要一味地說是大環境不好或者CMMI制度不適用於台灣的環境，因此抹殺前人的功勞！取而代之的應該是徹底檢討，到底問題出在什麼地方？我們在這個過程中學習到什麼？
反省、檢討、改善並獲得所謂的Lessons Learned，不就是 CMMI 當中決策分析與解決方案(DAR: Decision Analysis and Resolution)反饋回流程管理領域 (Processes Management－組織流程焦點、組織流程定義、組織層級教育訓練…等)過程嗎？
懂得檢討才能累積經驗(Lessons Learned)並達到持續改善的真諦。
因此筆者認為各位應該關注的議題不是導入 CMMI 與否，或者一味地抗拒 CMMI，真正要提出的問題應該是：
1. 組織/公司目前碰到了怎樣的難題？
是控制不易、溝通不良、品質不佳、無法累積實力…什麼問題最嚴重？什麼問題做最急迫？輕重緩急？
2. 公司的現況、遠景？
有無實際可行的計畫與支持團隊？打算腳踏實地、突破創新還是繼續沽名釣譽？
以上問題雖然嚴肅，但卻是真正值得深思的，有些朋友會告訴我，這些是公司老闆們應該顧慮的問題，不是我這種層級該管的，我了解不在其位不謀其政的想法，但是，山不轉路轉…，或許你可以轉寄一些資料給上司、同事，不論你是否考慮導入 CMMI，我都希望這篇文章能讓大家凝聚共識；大家逐步達成共識，就是進步～
各位朋友們，無論將來職場如何發展，自己也可以累積一套Lessons Learned，反省、學習、累積與成長是進步的動力，如果能進而分享將可得到更多回饋。
2007年1月7日 星期日
CMMI 觀念 & 流程領域
看到很多人在討論 CMMI , 我認為是喜憂參半的狀況, 喜的是越來越多人重視公司內部的能力成熟度培養, 但也擔心良好的制度會被曲解成只有大型專案適用或者制度無效...的論述.
我要說明的是
1. CMMI 本身並不是一套標準作業流程, RUP 才是流程定義, 然而 CMMI 主要是定義流程應該達成的目標 (Goals), 因此, 公司內部可以定義自己的一套流程, 也可以採用類似 RUP 的規範, 但重點是 流程是適合貴公司的, 而且流程可以達到某些 Goals. 這就是為什麼我會建議引進 CMMI 的公司能夠先掌握公司的組織的目標, 並定義出一套能夠滿足組織目標並能夠落實的流程. 不要為了 CMMI 而 CMMI
2. 小型專案也適用 CMMI, 但流程絕對不跟大型專案相同, 這就是 CMMI 裡頭談到的調適原則 (Tailoring Guide), 會說小型專案不適用的人, 大多數的情況是公司沒有一套所謂的調適原則, 我就見過三個人的專案也採用 CMMI 的規範, 文件不多, 但一樣可以滿足 CMMI 的 Goals , 舉例來說: 用 CVS 管控專案 -> 滿足 Configuration Management, 用 Use Case -> Analysis Model -> Design Model -> Code -> 滿足 Requirement Management, 用 MS-Project 追蹤與報告專案進度 -> 滿足 PP, PMC ... 其實制度是看人如何用它, 掌握制度的精隨不要以偏概全是比較重要的. ISO 也是好的規範, 只是被濫用了
對筆者來說，CMMI 就像是一本字典或者說是SI產業的百科全書，這書裡充滿了可活用的資訊，分別從工程流程、後勤支援、專案管理、流程管理等四大流程領域闡述其內涵，四大流程領域涵蓋的內容如下：
1. 工程流程領域 (Engineering Processes)，包括了需求管理、需求發展、技術解決方案、產品整合、驗證(Verification)、確認(Validation) 等；對筆者而言工程流程領域就是系統整合或軟體發展公司的價值鏈，如同一間工廠從接單、生產、品管、出貨、收款的過程，算得上是公司的命脈所繫，因此價值鏈必須受到重視，有了良好且穩定的生產作業後，產品品質才會穩定、信譽才能廣佈，之後才能厚實客戶群，從而發展精進，進而提升公司的競爭門檻（這才是能力成熟度的基本意義）。
2. 後勤支援流程 (Supporting Processes)，包括了度量分析、流程與產品品質保證、建構管理、決策分析與解決方案、跨界整合性組織環境、成因分析與解決方案等；後勤支援體系就像作戰一樣，是前線作戰的堅實後盾，這當中包括了情報收集、知識累積與經驗傳承，這些都是組織知識形成的過程。也是中高階領導人應該關注的重點之ㄧ。
3. 專案管理流程 (Project Management Processes)，包括了專案規劃、專案監控、供應商協議管理、風險管理、整合性專案管理、整合性供應商管理、整合性專案團隊、量化專案管理等；整體來看，專案管理流程領域是專案履約過程的整體規劃與管制作業，也是客戶、協力廠商、公司主管及專案團隊的協同合作基礎，履約過程中發生的各種狀況、意見與衝突，都需要妥善地溝通、協調與處置，除了充分履約與達成使命之外，更重要的是團隊成長與經驗分享，這才是專案管理應該滿足的重點。
4. 流程管理領域 (Processes Management)，包括了組織流程焦點、組織流程定義、組織層級教育訓練、組織流程效能、組織創新與落實等；一旦工程流程、後勤支援、專案管理…等落實後，公司便會累積出一些重要的資產，這些資產包括了作業方法、文件樣板、經驗分享與決策過程…，如果這些資產分散各地甚至因人而流失，對公司或者相關同仁而言都是一大損失，因此，我們需要管理這些組織資產，並在這些基礎上不斷改善與創新。
我要說明的是
1. CMMI 本身並不是一套標準作業流程, RUP 才是流程定義, 然而 CMMI 主要是定義流程應該達成的目標 (Goals), 因此, 公司內部可以定義自己的一套流程, 也可以採用類似 RUP 的規範, 但重點是 流程是適合貴公司的, 而且流程可以達到某些 Goals. 這就是為什麼我會建議引進 CMMI 的公司能夠先掌握公司的組織的目標, 並定義出一套能夠滿足組織目標並能夠落實的流程. 不要為了 CMMI 而 CMMI
2. 小型專案也適用 CMMI, 但流程絕對不跟大型專案相同, 這就是 CMMI 裡頭談到的調適原則 (Tailoring Guide), 會說小型專案不適用的人, 大多數的情況是公司沒有一套所謂的調適原則, 我就見過三個人的專案也採用 CMMI 的規範, 文件不多, 但一樣可以滿足 CMMI 的 Goals , 舉例來說: 用 CVS 管控專案 -> 滿足 Configuration Management, 用 Use Case -> Analysis Model -> Design Model -> Code -> 滿足 Requirement Management, 用 MS-Project 追蹤與報告專案進度 -> 滿足 PP, PMC ... 其實制度是看人如何用它, 掌握制度的精隨不要以偏概全是比較重要的. ISO 也是好的規範, 只是被濫用了
對筆者來說，CMMI 就像是一本字典或者說是SI產業的百科全書，這書裡充滿了可活用的資訊，分別從工程流程、後勤支援、專案管理、流程管理等四大流程領域闡述其內涵，四大流程領域涵蓋的內容如下：
1. 工程流程領域 (Engineering Processes)，包括了需求管理、需求發展、技術解決方案、產品整合、驗證(Verification)、確認(Validation) 等；對筆者而言工程流程領域就是系統整合或軟體發展公司的價值鏈，如同一間工廠從接單、生產、品管、出貨、收款的過程，算得上是公司的命脈所繫，因此價值鏈必須受到重視，有了良好且穩定的生產作業後，產品品質才會穩定、信譽才能廣佈，之後才能厚實客戶群，從而發展精進，進而提升公司的競爭門檻（這才是能力成熟度的基本意義）。
2. 後勤支援流程 (Supporting Processes)，包括了度量分析、流程與產品品質保證、建構管理、決策分析與解決方案、跨界整合性組織環境、成因分析與解決方案等；後勤支援體系就像作戰一樣，是前線作戰的堅實後盾，這當中包括了情報收集、知識累積與經驗傳承，這些都是組織知識形成的過程。也是中高階領導人應該關注的重點之ㄧ。
3. 專案管理流程 (Project Management Processes)，包括了專案規劃、專案監控、供應商協議管理、風險管理、整合性專案管理、整合性供應商管理、整合性專案團隊、量化專案管理等；整體來看，專案管理流程領域是專案履約過程的整體規劃與管制作業，也是客戶、協力廠商、公司主管及專案團隊的協同合作基礎，履約過程中發生的各種狀況、意見與衝突，都需要妥善地溝通、協調與處置，除了充分履約與達成使命之外，更重要的是團隊成長與經驗分享，這才是專案管理應該滿足的重點。
4. 流程管理領域 (Processes Management)，包括了組織流程焦點、組織流程定義、組織層級教育訓練、組織流程效能、組織創新與落實等；一旦工程流程、後勤支援、專案管理…等落實後，公司便會累積出一些重要的資產，這些資產包括了作業方法、文件樣板、經驗分享與決策過程…，如果這些資產分散各地甚至因人而流失，對公司或者相關同仁而言都是一大損失，因此，我們需要管理這些組織資產，並在這些基礎上不斷改善與創新。
訂閱：
意見 (Atom)