建構與變更管理課程後

講完建構與變更管理課程後, 我收到了以下回覆：「我們是一個 embedded 系統廠，每個案子的變數都相當的多，有硬體，軟體，客人臨時要求 .... 這種不同的變數。我想上課的內容的確給了許多觀念與想法，可以讓我們在執行時多想想的。...軟體初開發時，哪些事情是要注意的，在開發過程中，哪些資料需要建立，還有面臨變化時，怎麼樣可以把問題降低，解決。讓PM可以把工作控制的更安全。這是我們希望能學到的。」

很謝謝你的回饋, 關於你信件中提到的問題, 我盡可能回覆如下：
案子成立之初
1. 初步決定系統規格 (機構, 硬體, 軟體, 韌體...)
2. 釐清設計限制 (空間, 容量, CPU 等級)
3. 確立遊戲規則, 例如: 用 Issue Tracking 記錄與處理各方需求的流程

軟體開發過程...面臨變化時，怎麼樣可以把問題降低，解決
1. 確認規格 -> 設計具彈性的軟體架構, 例如引用 design patterns
2. 確認軟體架構的相依性, 先做底層部分, 例如：採購, 銷售與庫存, 最底層的部分應該是"庫存"
3. 逐步開發 -> 測試(一定要寫測試個案) -> 確認完成後 -> Check In (Commit 記得要加註記, 若使用 CodeBeamer 將可看到相關資訊, 知道問題的處理進展)
4. 持續整合 -> 測試並驗證各項問題已經被處理
5. 如果有其他需求, 回到步驟 1 (可能會需要調整設計)

以上說明, 若有任何意見, 歡迎隨時來信

衍生閱讀:
1. JAVA 軟體開發基準
2. 建構與變更管理

整合性開發環境

軟體系統開發過程需要用到的各項工具，如何整合到一個環境中讓開發團隊可以輕鬆上手，管理者能夠精準掌握進度，組織的智慧財產能夠有效累積呢?

整合性開發環境結合了專案團隊協同作業需要的基礎元件，透過簡單的內規(SOP)，讓整體作業能夠更加順暢；以下案例是筆者最近提供的諮詢服務之一，本案例整合了開發工具(ECLIPSE IDE)、軟體建構管理工具(SUBVERSION)、議題追蹤管理工具(CODEBEAMER)等工具，從諮詢服務與案例演練的過程中，我發現到，具備品質觀念的工作團隊加上適合的工具，就像關老爺遇到了赤兔馬一樣，一拍即合。



能夠為顧客提供適切的服務，是最愉快的事業了...真慶幸自己可以從事這種性質的工作 ^_^

建構與變更管理案例 [Subversion]

近來講了幾回建構管理實際案例[Subversion]的課程, 發現大家都有使用類似的建構管理(版本管控)環境,但卻很少人注意到這個工具可以為團隊工作帶來的其他好處, 多數工程師都認為這工具有用助於分工合作, 也有少數工程師認為建構管理帶來某些困擾, 例如: 修正好的程式一定要逐一簽入(check in)嗎? 能不能整批一塊做?

先看看以下案例吧!!

建構與變更管理[CodeBeamer]

關於建構管理的理論與實務, 如果各位有興趣, 可以看看這份簡報, 其中有談到議題追蹤管理的相關資訊,

當我提到:議題是有生命的, 有些人會覺得納悶...
當我提到:議題的年齡時, 就更搞不懂了...

以上議題我不多說, 大夥可以用毒奶事件這個議題, 好好思索一下囉!!

對筆者而言, 基礎很重要, Know-How 也很重要, 但更重要的是, "馬上去做"...不要再拖了

有趣：軟體 Bug 的起源

軟體運行中因為程式本身有錯誤而造成的功能異常、當機...等現象統稱為臭蟲 (Bug), 這名詞是怎樣來的?

Software Bug 一詞起源於1945年後期，當時還是真空管電腦的時代，9月9日當天哈佛大學實驗室內的計算機出現了問題，Hopper 女士仔細地檢查過 Mark II 計算機後，發現繼電器上有一隻蛾貼附在上頭，後來他們將這隻蛾拿掉後，貼在工作日誌上頭，此後，我們就開始指稱電腦系統異常為 Bug 了。

以下是原文的片段
In 1946, when Hopper was released from active duty, she joined the Harvard Faculty at the Computation Laboratory where she continued her work on the Mark II and Mark III. Operators traced an error in the Mark II to a moth trapped in a relay, coining the term bug. This bug was carefully removed and taped to the log book September 9th 1945 [sic]. Stemming from the first bug, today we call errors or glitches [sic] in a program a bug


^_^ 真有趣

相關文章：品質與度量

問題追蹤與處理流程<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>

需求改變是專案的常態，專案執行過程中一定會有許多的議題發生，如果置之不理那麼議題不但不會自動消失，還可能累積成災，所以我們需要一套妥善的議題追蹤與處理機制，除了消極的紀錄議題，更要積極的掌握與處理、解決各項議題。

管理與追蹤在專案開發與維護過程中發生的各議題（如：瑕疵、衍生需求、任務與改進等）是專案管理的基礎，但很少有團隊可以做的很好。透過Issue Tracking 工具提供的各項功能，讓問題追蹤管理根專案管理變得更容易上手，而且，工具本身提供的流程彈性與報表擴充性，也讓專案管理資訊系統(PMIS, Project Management Information System) 更趨於完善。

一套比較完整Issue Tracking 工具，必須考慮到專案初始、規劃、執行、監控、結案過程中的各項需要，尤其是客戶、高階主管、專案經理、開發團隊、測試團隊、分析設計團隊…利害關係人的需要，如此才能讓工具本身發揮應有的效果。

1. 客戶、高階主管
依據Issue Tracking 工具提供的各項數據，準確地了解專案狀態、專案品質水準與團隊工作效率；一般而言，工具本身都會提供問題數、瑕疵密度、問題發展趨勢…等各種統計數據，讓高階主管可以更客觀地評估專案與團隊表現。

2. 專案經理
追蹤Issue Tracking 工具所列的各項問題，評估並指派任務給團隊同仁，同時可以根據工具本身提供的相關報表理解專案進展與同仁的工作情況，適時介入並提供任務相關的各項協助，提早發現並處理各項議題，讓議題不至於成為專案的重大風險。

3. 開發團隊、分析設計團隊
依據 Issue Tracking 工具所列的工作項目清單執行各項任務，團隊同仁可以聚焦於各項任務、解決問題，讓工作效率更加提升。在解決問題的過程中，各種問題的處理與解決方案也可以被妥善地記錄於工具中，日後更有機會累積並整理成為組織的知識庫(Knowledge Base)。

4. 測試團隊
執行問題結案之前的測試作業，並確實反應(紀錄)測試結果，讓專案經理與開發團隊能夠執行後續的跟催作業。

上圖為常見的議題追蹤與處理流程，步驟說明如下：

1. 問題發起－專案的所有利害關係人(客戶、專案經理、團隊成員、專案高階主管) 都可以提出問題單。
2. 問題審議－專案經理初步審議各項問題，若議題涉及層面較大，則召開相關會議，邀請與會人員審議該項議題，並決定議題的後續處理原則同時紀錄理由，如：拒絕、暫緩、受理等過程。
3. 受理並指派負責人－經過審議並確認處理原則後，問題單需指派給一位主要負責窗口，負責執行各項任務並妥善處理該項問題。
4. 領案並解決問題－負責人收到任務指派後，負責規劃、執行、追蹤問題的處理過程，同時記錄問題的處理方式與處理結果。
5. 結案審議－專案經理與問題發起人將初步審議各項問題是否獲得解決並同意結案，若議題涉及層面較大，則召開相關會議審議；結案審議過程若發現問題未被解決或者產生新的問題，可回到步驟1另行建立問題單或重啟問題單。