服務過程中常被問到的問題之一，就是計畫，怎樣寫計畫書或者大綱結構之類的問題，專案計畫跟任何的企畫書一樣，目的都是為了溝通並確認達成專案目標的管道、步驟，因此，計劃書的資訊不宜過多或不足，這當中的分寸要怎樣拿捏呢？
以我初淺的經驗去看，我認為計畫一定要交代：人、事、時、地、物、數，
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年10月20日 星期一
UML Overview
學習 UML 過程中, 免不了要整理這些圖, UML Notations / Diagrams 是溝通的基礎, 即便是簡單的一張圖都代表了許多的意涵, 重點是解讀的人, 大家是否具備相同的認知基礎? 學習 UML Notation 的語意, 就像學了軟體世界的共通語言, 也像學習一般外語, "使用"才是真正的"學會"
這份文件也可以當做考 OCUP 認證的參考資訊, 但, 我要強調, 重點還是"用這個工具去溝通"
衍生閱讀：敏捷塑模
這份文件也可以當做考 OCUP 認證的參考資訊, 但, 我要強調, 重點還是"用這個工具去溝通"
衍生閱讀：敏捷塑模
2008年8月29日 星期五
2008年7月25日 星期五
eXtreme Programming
今天花了一個下午的時間, 總算把我經驗中的 XP 給整理好了, 個人認為, XP 是很務實也很實用的, 在我過往的專案有幾次的機會都有用到 XP, 不過, 大多都是民間專案, 政府標案則因為一堆的限制因素(要做一堆文件), 而無法拓展, 從經驗中, 最有效益的專案也大多都是採用類似 XP 的方式推展, 因此,
強烈建議正在推廣"節能減碳"的政府機關能夠換個思維, 採用 XP, 減少浪費
衍生閱讀：Test Driven Development(TDD)
相關資訊：Modifiability: Or is there Design in Agility?
2004年4月20日 星期二
PMP 認證準備過程
PMI Project Management Professional (PMP) 認證考試的準備過程
1. 資料準備
- 護照，有效期需超過半年
- 參加 PMI會員 ─取得原版 PMBOK 資料
- 取得相關題庫資料 ─
PMSTUDY 有免費的測驗，測驗方式很接近正式考試，建議在題庫演練時務必演練；
BOSON 有不錯的題庫，需要花點錢，我只有用試用版；
PMI提供的 SAMPLE 題庫，還算不錯；
RITA 常聽人提起，但我沒使用，所以不知道好壞
2. 研讀 PMBOK ~ (三週)
- 在中文考試制度未確認前，建議研讀英文版，可同時參閱中文版
- 理解為重─
本階段重點在了解各 process 之內涵，尤其是 程序之目的與相關工具、技術之用法 - 詳讀 Code of Conduct
3. 題庫演練 (一週)
- 確實理解問題之內涵─
題庫不會在正式考試中出現(以我的經驗只有 5/1000 的機率)，但問題背後的內涵(精神)會不斷出現 - 擅用 20/80 法則 ─
Pareto Diagram 標示不清楚或不能完全理解的問題，用 QC 裡談到的 Pareto Diagram 方式來彙整問題，通常問題會出在 PMBOK 沒詳談的技術或Knowledge，如：Management/Leading Style, Communication Method, Contract Type, TQC, Reporting method & timing …
4. 研讀輔助資料 (一週)
- Problem Solving ─
尋求解決問題之相關知識與支援，就小弟的經驗而言，網路是最佳的資料來源 - 記憶重點 ─
利用生活中的案例幫助記憶，思考問題之處置方式與PMBOK當中的對策
5. 報名 PMP 考試 (報名2 H，等確認 二～三週)
- 詳讀報名須知 PDC_PMPHandbook.pdf
- 線上報名 ─
注意報名時填寫的資料詳實度，會影響審查進度 - 等待確認信函，若超過三週請些寫信跟 PMI 確認進度
6. 再次閱讀PMBOK & 輔助資料 (兩週)
- 融會貫通 ─
Process Groups, Core Process & Facilitating Process 之間關聯性與先後次序 - 詳讀 輔助資料
- 詳讀 Code of Conduct
7. 題庫演練 (一週)
- 擅用 20/80 法則 ─ Pareto Diagram
- 時間控制 ─
本次演練過程除正確答題外，還要建立自己的答題技巧，尤其是時間的掌握，200題務必在三小時內完成 (正式考試時間為四小時)，如此在正式考試時才不會過度緊張 - 提高答題正確率 ─
目標 80 % 以上，我在參加正式測驗前自我檢驗的正確率約為 82.3 %
8. 預約正式考試場地與時間
- 電話預約 ─至少在考前一週完成預約，只能安排在週一~週五的下午考試
- 英文試題，作答時間只有四小時(含休息時間)
9. 迎接正式考試
- 前一天 ─
放鬆心情，只準備考試要帶的資料即可，如：護照、計算機、PMBOK 及相關資料，不用準備耳塞；不要再閱讀新的資料了 - 考試當天上午 ─
複習自己出錯機率較高的部份資料；一定要吃早餐 - 考前一小時 ─
詳讀 Code of Conduct or 需要背誦的資料 - 考試中 ─
15 分鐘的系統導覽前 15 分鐘是導覽，不列入正式時間計算，請充分利用這段時間平復心情，或抄錄剛背誦的資料 - 考試中 ─
英文試題作答時間只有四小時(含休息時間)專注，利用 3 小時的時間答完 200 題，稍作休息，利用剩餘的時間檢查 - 考試完 ─
有簡短的 Survey，完成後通知試場人員，離開前會拿到一份非正式的成績報告 Pass / Fail
10.通過PMP並等待正式書面文件
Q&A
Q1：試題內容－計算題多不多?
A1：計算題約有 15 題，分散在 Scheduling (6題)、EVM(4題)、PERT(2題)、Make-or-buy (1題)、Communication channel(1題)、另一題忘了
相關資料：PMP 課程
訂閱：
意見 (Atom)