建構管理概念

建構管理 (Configuration Management) 概念

研發基本能力 <4>

怎樣擬定建構管理計畫呢？建議的做法是：
1. 了解需求
2. 進行系統架構規劃並完成一份系統發展計畫
3. 依據系統發展計畫思考並規劃符合本研發專案的建構管理作業方式

假設我們需要研發一套系統，系統本身必須處理客戶訂單、管理庫存與進出貨物，當需求交到研發單位後，我們依照經驗將系統架構切割成進貨管理、庫存管理與銷貨管理三個子系統(進、銷、存)，有了系統架構後，我們便以此資料擬訂建構管理計畫，透過建構計畫說明本研發專案建構管理準則，計畫內容包含：建構管理的目的、工作環境(工具)、人員權責、變更管理流程、建構項目(Configuration Item)、版本基線(Baseline)、建構稽核(Audit)與稽核報告格式等；

建構項目(Configuration Item)指的就是我們打算要管理的項目，例如：需求清單、專案計畫、系統分析文件、系統設計文件、原始程式碼、測試計劃、測試報告、使用者操作手冊…等，在本案例中，我們可以將全系統當作是一個大的建構項目，也可以將進、銷、存分成三個建構項目，甚至再往下繼續分割，分割方式端看怎樣管理比較有效率而定。在此，筆者建議各位，配合系統架構規劃建構項目是比較好的方式，本案例中，筆者為了說明方便把進、銷、存當作三個不同的建構項目來管理研發過程中的所有變動。

產品研發的參考基準就是所謂的基線(Baseline)，基線的概念有點類似拍照留念，基線的用意主要在彰顯產品研發過程的特定工作成果或里程碑，當研發單位完成重大階段性任務如：分析、設計、開發、測試、整合、上線…等，可以利用建構管理的版本管理機制，將各個工作成果統合起來並拉出一條參考基線，所有研發工程師便可以站在基線(巨人)的肩膀上看世界。

本案例的建構管理過程可以參考下圖，研發專案剛開始的時候，主要的工作內容在於收集與確認各項需求，一但需求明確定義後，我們就可以建立需求的參考基線(需求凍結)然後著手進行分析設計工作；分析設計完成並透過審查與追溯機制確認滿足需求後，我們就可以建立另一條基線－Design Baseline，作為後續開發與測試的基礎；完成研發、整合測試後，我們一樣也可以建立 Development Baseline、Test Baseline …；當產品研發完成並確認各項功能與相關文件都備齊後，我們就可以建立Product Baseline，這時不要忘了要大聲歡呼並恭喜老闆喔 ^_^。

還記得前一篇文章當中的變更管理機制？專案受理變更後，專案成員就必須執行變更任務並確認變更成果，結合建構管理的具體實行步驟如下：

1. 確認變更任務的內容，找出要變更的建構項目是哪一個
2. 簽出(Checkout)該建構項目，
簽出的動作就像預約KTV 的包廂一樣，其目的主要是要提醒其他專案成員你正在這一區施工，避免同時施做造成資源浪費。
3. 依照任務內容執行變更並確認變更成果符合需求。(開始唱歌)
4. 變更完成後，將工作成果簽入(Check-in)到建構管理環境中，簽入跟簽出是相對的動作，目的就是告訴其他專案成員你已經離開，簽入後建構管理工具會同時保留新舊版本的工作成果。(包廂空出來了，可以開放給其他人預約)

提醒各位，簽入的動作必須嚴謹，簽入前必須透過審查、檢驗或測試的方法來確認變更任務已經完成，而簽入時必須加入時戳、修改內容註解並維護工作成果之間的追溯性

建構管理不但是研發單位的重大基礎能力，更是公司智慧資產評估的重要工具，因為「凡走過必留下痕跡」將成為研發單位的知識管理基礎，人員可以透過前輩的案例學習、成長；「站在巨人的肩膀上看世界」，配合系統架構擬定的建構項目有更多的機會用在其他專案上，除了重複使用、節省成本的效益外，部分建構項目還可以申請智慧財產權與各項專利，成為公司永續發展的一環喔。

相信各位讀者都聽過「計劃永遠趕不上變化」這句話吧，或許有些讀者看到這句話還會在內心深處發出心有戚戚焉之感！我想這句話突顯的正是變化的事實，為了迎接變化我們需要更有效率的管理機制－建構管理。

衍生思考：
「計劃永遠趕不上變化」這句話突顯的正是變化的事實，但難道因為變化的存在我們就不需要計畫了嗎？關於這點，筆者聽過一位好朋友說過「計畫就是為了要迎接變化」，我個人滿認同這樣的觀點，因為這是認同變化並積極面對的思維，也是身為工程研發單位除了基本能力之外應具備的思維，因此研發一定要有計畫，而且計畫本身應積極迎接變化－與時俱進。