另外，就是所謂的 Extension Point ，從圖例當中可以知道，在特定情況下會需要用到擴充的用例，如金流授權處理是信用卡付款方式的擴充。
強力推薦：敏捷溯模(Agile Modeling)
2007年5月11日 星期五
UML 案例 <1> UseCase
本電子商務用例展示了簡易版的電子商務使用情境，當中可以看到有三個主要的 Actors 分別是 Guest, Administrator 與 Payment GW，這邊特別要說明的是，Payment GW 並不代表特定角色的人，Payment GW 指的是提供金流授權服務的外部系統(例如:信用卡刷卡機)。
另外，就是所謂的 Extension Point ，從圖例當中可以知道，在特定情況下會需要用到擴充的用例，如金流授權處理是信用卡付款方式的擴充。
強力推薦：敏捷溯模(Agile Modeling)
另外，就是所謂的 Extension Point ，從圖例當中可以知道，在特定情況下會需要用到擴充的用例，如金流授權處理是信用卡付款方式的擴充。
強力推薦：敏捷溯模(Agile Modeling)
2007年4月23日 星期一
問題追蹤與處理流程<2>
議題(Issues) 可能來自於瑕疵、衍生需求、任務與改進的需要…等，每一個議題都需要被妥善地管理，因此，記錄的資訊是否完整將會影響到整體問題追蹤與處理流程的執行成效，筆者建議紀錄的資訊如下：
1. 議題所屬專案－紀錄議題是屬於那一個專案，便於日後追蹤各專案的進展。
2. 議題類型(Type)－例如：瑕疵、衍生需求、任務與改進的需要…
3. 摘要說明
4. 議題描述－說明議題發生的原因、流程、步驟…資訊，便於判讀各項議題。
5. 環境說明－紀錄與本議題相關的各項元件(系統、子系統、元件)、版本、執行環境…等資訊。
6. 優先等級－紀錄議題的優先等級，通常是工作次序安排的重要依據，常見的優先等級有關鍵議題(Critical)、主要議題(Major)、次要議題(Minor)、一般議題(Trivial)…等。
7. 議題發起人
8. 議題負責人
9. 變更歷程－紀錄各項議題的狀態移轉過程、發生時間等歷史，透過各項統計分析技術，讓所有利害關係人能充分掌握所需的相關資訊。
10. 議題解決方式－紀錄該項議題最後獲得解決的方式，
坊間有許多的工具支持議題處理的應用過程，包括 BugZilla, Track+, JIRA, Mantis, Request Tracker, CodeBeamer…等工具，這些工具都有一致或類似的問題追蹤機制，問題單狀態的移轉過程也很類似 (請參閱下圖：問題單的狀態移轉過程)。
透過工具的輔助將讓專案在議題追蹤與處理上達到事半功倍的成效；然而，筆者必須強調，工具絕非萬能，它僅能輔助我們妥善地管理議題，但議題不會自動消失，專案團隊必須積極、主動合作面對問題所帶來的挑戰。
1. 議題所屬專案－紀錄議題是屬於那一個專案，便於日後追蹤各專案的進展。
2. 議題類型(Type)－例如：瑕疵、衍生需求、任務與改進的需要…
3. 摘要說明
4. 議題描述－說明議題發生的原因、流程、步驟…資訊，便於判讀各項議題。
5. 環境說明－紀錄與本議題相關的各項元件(系統、子系統、元件)、版本、執行環境…等資訊。
6. 優先等級－紀錄議題的優先等級，通常是工作次序安排的重要依據，常見的優先等級有關鍵議題(Critical)、主要議題(Major)、次要議題(Minor)、一般議題(Trivial)…等。
7. 議題發起人
8. 議題負責人
9. 變更歷程－紀錄各項議題的狀態移轉過程、發生時間等歷史，透過各項統計分析技術，讓所有利害關係人能充分掌握所需的相關資訊。
10. 議題解決方式－紀錄該項議題最後獲得解決的方式，
坊間有許多的工具支持議題處理的應用過程，包括 BugZilla, Track+, JIRA, Mantis, Request Tracker, CodeBeamer…等工具，這些工具都有一致或類似的問題追蹤機制，問題單狀態的移轉過程也很類似 (請參閱下圖：問題單的狀態移轉過程)。
透過工具的輔助將讓專案在議題追蹤與處理上達到事半功倍的成效；然而，筆者必須強調，工具絕非萬能，它僅能輔助我們妥善地管理議題，但議題不會自動消失，專案團隊必須積極、主動合作面對問題所帶來的挑戰。
問題追蹤與處理流程<1>
需求改變是專案的常態，專案執行過程中一定會有許多的議題發生，如果置之不理那麼議題不但不會自動消失，還可能累積成災，所以我們需要一套妥善的議題追蹤與處理機制，除了消極的紀錄議題，更要積極的掌握與處理、解決各項議題。
管理與追蹤在專案開發與維護過程中發生的各議題（如：瑕疵、衍生需求、任務與改進等）是專案管理的基礎，但很少有團隊可以做的很好。透過Issue Tracking 工具提供的各項功能，讓問題追蹤管理根專案管理變得更容易上手，而且，工具本身提供的流程彈性與報表擴充性，也讓專案管理資訊系統(PMIS, Project Management Information System) 更趨於完善。
一套比較完整Issue Tracking 工具，必須考慮到專案初始、規劃、執行、監控、結案過程中的各項需要，尤其是客戶、高階主管、專案經理、開發團隊、測試團隊、分析設計團隊…利害關係人的需要，如此才能讓工具本身發揮應有的效果。
1. 客戶、高階主管
依據Issue Tracking 工具提供的各項數據，準確地了解專案狀態、專案品質水準與團隊工作效率；一般而言，工具本身都會提供問題數、瑕疵密度、問題發展趨勢…等各種統計數據，讓高階主管可以更客觀地評估專案與團隊表現。
2. 專案經理
追蹤Issue Tracking 工具所列的各項問題，評估並指派任務給團隊同仁，同時可以根據工具本身提供的相關報表理解專案進展與同仁的工作情況，適時介入並提供任務相關的各項協助，提早發現並處理各項議題，讓議題不至於成為專案的重大風險。
3. 開發團隊、分析設計團隊
依據 Issue Tracking 工具所列的工作項目清單執行各項任務，團隊同仁可以聚焦於各項任務、解決問題，讓工作效率更加提升。在解決問題的過程中，各種問題的處理與解決方案也可以被妥善地記錄於工具中，日後更有機會累積並整理成為組織的知識庫(Knowledge Base)。
4. 測試團隊
執行問題結案之前的測試作業，並確實反應(紀錄)測試結果，讓專案經理與開發團隊能夠執行後續的跟催作業。
管理與追蹤在專案開發與維護過程中發生的各議題（如：瑕疵、衍生需求、任務與改進等）是專案管理的基礎，但很少有團隊可以做的很好。透過Issue Tracking 工具提供的各項功能，讓問題追蹤管理根專案管理變得更容易上手，而且，工具本身提供的流程彈性與報表擴充性，也讓專案管理資訊系統(PMIS, Project Management Information System) 更趨於完善。
一套比較完整Issue Tracking 工具，必須考慮到專案初始、規劃、執行、監控、結案過程中的各項需要，尤其是客戶、高階主管、專案經理、開發團隊、測試團隊、分析設計團隊…利害關係人的需要，如此才能讓工具本身發揮應有的效果。
1. 客戶、高階主管
依據Issue Tracking 工具提供的各項數據，準確地了解專案狀態、專案品質水準與團隊工作效率；一般而言，工具本身都會提供問題數、瑕疵密度、問題發展趨勢…等各種統計數據，讓高階主管可以更客觀地評估專案與團隊表現。
2. 專案經理
追蹤Issue Tracking 工具所列的各項問題，評估並指派任務給團隊同仁，同時可以根據工具本身提供的相關報表理解專案進展與同仁的工作情況，適時介入並提供任務相關的各項協助，提早發現並處理各項議題，讓議題不至於成為專案的重大風險。
3. 開發團隊、分析設計團隊
依據 Issue Tracking 工具所列的工作項目清單執行各項任務，團隊同仁可以聚焦於各項任務、解決問題，讓工作效率更加提升。在解決問題的過程中，各種問題的處理與解決方案也可以被妥善地記錄於工具中，日後更有機會累積並整理成為組織的知識庫(Knowledge Base)。
4. 測試團隊
執行問題結案之前的測試作業，並確實反應(紀錄)測試結果，讓專案經理與開發團隊能夠執行後續的跟催作業。
上圖為常見的議題追蹤與處理流程，步驟說明如下：
- 問題發起－專案的所有利害關係人(客戶、專案經理、團隊成員、專案高階主管) 都可以提出問題單。
- 問題審議－專案經理初步審議各項問題，若議題涉及層面較大，則召開相關會議，邀請與會人員審議該項議題，並決定議題的後續處理原則同時紀錄理由，如：拒絕、暫緩、受理等過程。
- 受理並指派負責人－經過審議並確認處理原則後，問題單需指派給一位主要負責窗口，負責執行各項任務並妥善處理該項問題。
- 領案並解決問題－負責人收到任務指派後，負責規劃、執行、追蹤問題的處理過程，同時記錄問題的處理方式與處理結果。
- 結案審議－專案經理與問題發起人將初步審議各項問題是否獲得解決並同意結案，若議題涉及層面較大，則召開相關會議審議；結案審議過程若發現問題未被解決或者產生新的問題，可回到步驟1另行建立問題單或重啟問題單。
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)