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. 建構管理

建構與變更管理課程後

講完建構與變更管理課程後, 我收到了以下回覆：「我們是一個 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)等工具，從諮詢服務與案例演練的過程中，我發現到，具備品質觀念的工作團隊加上適合的工具，就像關老爺遇到了赤兔馬一樣，一拍即合。



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

建構與變更管理[CodeBeamer]

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

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

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

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

JAVA 軟體開發基準

團隊合作就像參加一場盛會, 每個人都被賦予特殊任務, 也都要演活自己的角色, 但, 如果大家沒有相同的舞台, 這場戲要如何演下去?

基於團隊合作的需要, 建議開發團隊應該要有一套共通的作業基礎, 也就是遊戲規則, 你的團隊是否有一套遊戲規則呢? 如果沒有, 或許可以參考這裡!!!