導入CMMI是否對創意造成妨礙？這是這一期資訊傳真的社論。導入CMMI的公司不妨來談一談你們的感受！

----------------
引文:

個人的看法：
http://www.csqa.org.tw/datacenter/Newsletters/datacenter/0012-01.htm

----------------
引文:

中華網龍繳了一堂二億四千萬的學費

一個由高手開發一年，也通過測試的遊戲大作，為什麼一上市就讓中華網龍慘賠？

「魔鬼都在細節裡」，這句鴻海董事長郭台銘的名言，聽在中華網龍總經理陳奎平的耳中，從來沒有這麼有感覺。

因為，今年中華網龍就是忽略了一個細節，而付出二億四千萬元的慘痛代價，相當於三分之一的資本額。

成立四年的中華網龍，靠著成功自製遊戲，營收從第一年的二百四十九萬成長到第三年的六億六千萬，成長了二百六十五倍，二○○二年甚至創下每股獲利十七•八五元的紀錄。去年年底上櫃後，更曾在今年初創下每股一百一十四．五元的高價，成為智冠科技的金雞母。

然而，今年，中華網龍營運狀況卻直線下墜。十月十八日，中華網龍宣布調降財測，盈餘目標從三億降至六千萬元，每股盈餘○•七九元，降幅高達八成，蒸發了二億四千萬；若與去年每股盈餘八•六五元的成績相較，每股獲利能力衰退九成。陳奎平承認，毛利滑落的主因，還是因為忽略細節，讓一款原本能成為獲利引擎的遊戲根本無法正常營運，才導致高額毛利就此蒸發。

因為今年，中華網龍推出年度大作「東方傳說」，並沒有按照軟體開發的一般流程進行。

為了試用效果更好的新技術，又要趕進度，研發團隊寫程式時，每寫完一部分程式，就直接加進遊戲裡，並沒有按照原訂流程，把程式結構和規格交代清楚。這個沒有人知道全部細節的龐大程式，慢慢的一部分一部分完成，在通過基本測試、封閉測試之後，看來沒問題的產品，一上市卻變成中華網龍的最大夢魘。
「程式安裝後，畫面竟然一片黑」，連職業玩家都覺得安裝困難。於是，即使投入三千萬元大作廣告，今年初「東方傳說」上線之後，最高同時在線人數僅一千多人，遠低於預期的兩萬名以上，甚至比一些已下市的網路遊戲還少。

陳奎平說，這就是忽略細節的後果。因為，一個省掉開發紀錄過程的程式，雖然能通過各種品質測試，但等到正式上線之後，卻因為沒有人知道程式究竟是怎麼設計的，等到要配合玩家需求修改時，一修改就問題百出，最後變得無法可救。

更要命的是，「東方傳說」用新技術開發，過去用來解決緊急狀況的標準作法也派不上用場，只能眼睜睜看著辛苦付諸東流。

年底還要再推出另一款新作「金庸群俠傳二」，這一堂課，教會了中華網龍什麼？

「就是要嚴格執行標準作業程序」，陳奎平說。現在中華網龍不但程式要按照標準程序完成，也開始要求其他開發工作也要建立標準作業程序。未來，大型作品甚至會像韓國，花三年時間仔細研發一款遊戲。

兩億元的學費，如果能夠因此抓出細節裡的魔鬼，誠實面對失敗，將是中華網龍化危機為轉機的關鍵。


轉載自商業週刊 Vol. 884 Mon, 1 Nov, 2004

“CMMI扼殺創新”在許多人的答案是肯定的，他們對CMMI都有相當程度的認知或經驗，特別是有實際導入CMMI的組織，不論是自行研讀SEI所提供的CMMI相關資料或由顧問協助而進行CMMI的導入，以期能對組織軟體開發的品質有所助益，對此都抱有很高的期望，希望導入CMMI後，王子與公主從此過著幸福快樂的生活，組織所有軟體開發所遇到的問體都可迎刃而解。

但是許多導入個案卻發現，大家把CMMI專案的驗收標準認知為通過“評鑑”，大家就思考如何通過評鑑為目標，評鑑的檢驗標準為何? 答案很清楚，SEI對通過CMMI評鑑有定義不同的PA ( Process Areas )，只要滿足各個PA的要求就可通過評鑑，於是大家開始以參加聯考的精神猛讀CMMI的PA，組織讀書會，大家分工了解PA，再以各個PA的要求制定程序，要求組織依循按這些程序進行軟體開發，可能也因此通過CMMI的評鑑，通過後，留下來的是許多定義嚴謹(或說呆板)的程序書，因為大家認為這才是CMMI的要求，一定要按程序書的規範才能滿足，沒有人敢去挑戰，從此大家就生活在這些框框中，或許這就是大家會對“CMMI扼殺創新 ?”答案是肯定的原因吧。

其實這個問題得關鍵點在於大家對CMMI的誤解，導入CMMI的原因應是對品質有所要求，希望改善軟體開發的成本、時間、掌握需求、累積開發經驗、改善後續軟體開發的問題，而不是陷入對CMMI的條文的解釋及認知，若對CMMI有正確的認知及依序來導入，CMMI與創新都是為了改善組織軟體開發的效能，就不會有“CMMI扼殺創新”的問題了，以上淺見請各位先進指教。

台灣應用軟件公司 張芳銘

CMMI其實是鼓勵改善與創意的。

　　真正創意的殺手不在於CMMI模型本身，而在於導入CMMI的公司，對於CMMI本質並沒有深入了解，當然，這似乎也凸顯出國內軟體工程與工程管理教育上的問題。

　　我們的軟體工程教育也好，系統工程教育(這個名詞在國內過去十年來，我似乎沒有聽過有人在談，容我孤陋寡聞！)沒有去談到所謂營運情境演進這類的事，有的話，也只是談到了現行系統或作業如何轉化為新的系統或作業，在我過去所受的軟體工程教育中，這件工作在為資訊系統的設計奠基礎。但這是不夠的，對於一個長於創新的產品需求分析與設計者而言，他會在發展與設計的工作當中，去思考怎樣可以做得更好、更有新意，這其實也是工程工作中的最佳常規，但事實上，由於專案時程緊迫，分析設計人員並未被鼓勵多做這些思考，專案經理乃至於老闆其實也並不熱衷於此，他們關心的是如期結案，如期收款，至於是否滿足合約要求，那是另外一回事，因為就算不符合合約的要求，總會找到其他的門路解決問題。

　　回到我所談到的常規，CMMI所看的或訂定的，其實並沒有脫離軟體工程、系統工程的要求，沒有任何新的東西或新的觀念存在，這樣的說法，大家如果有任何疑，個人建議可以看看美國軍規，例如 MIL-STD-499、MIL-STD-498、DoD-Std-2167A、MIL-STD-1521、MIL-STD-973、MIL-HDBK-61......，這些軍規雖然多數已經廢止，但是其觀念及精神仍被傳承，在業界標準(IEEE Std 12207、IEEE Std 1012、IEEE Std 1028.....)、國際標準(ISO/IEC 12207、ISO/IEC 15288........)等都還是可以看得到，要求也從來沒有因為有CMMI而有所不同，或者被強調得更為嚴苛。

　　對於創意，從CMMI模型或者一般的工程常規來看，都有所謂以演化方式發展 Operational concept and scenarios，這是TS SP 1.2。一個有經驗的發展團隊，對於此點應該會有所體會與理解才對，其實，這就是創意的切入點，CMMI正是在鼓勵工程發展的從業人員去創新與改善產品，因為，當operational concept與scenarios被演化了，那麼設計就會發生變動，而變動有可能是好的，有可能是負面的，當然，這還需要一些決策上的輔助，如果需要的話，亦需要採用所謂價值工程(value engineering)的常規。

　　CMMI透過模型的要求，希望匡正大家在工程上的不作為(不做Operational concept and scenarios的演化，不去產生多個alternatives 供評估與決策)，但不幸的是，大家在沒有認清此一內涵之前，即認為CMMI的導入有礙創意，而極力去反對導入CMMI，這將對於產業發展造成負面的衝擊，在此建議仍執此種觀點者，能夠對CMMI做更深入探討。

　　另外，筆者曾經聽聞某些通過CMMI評鑑的組織單位，在進行專案時會去討論：「本專案是否採用CMMI常規執行？」筆者認為這是件非常滑稽的事情，也顯然對於CMMI這個模型有非常錯誤的認知，既然導入且通過了CMMI某個等級的評鑑，執行所有的專案時就得遵循不可，如果可以討論「是不是要遵循」，顯然這個導入是一種浪費，或者說通過評鑑這件事根本是笑話一場，對於客戶來說也是一種傷害。因此，建議發生過這種情形的評鑑通過組織，應加強制度的內部教育訓練，以便能夠確實遵循自己的制度，制度不完善者也能夠持續改善，CMMI追求的不就是如此嗎？---軟體過程的持續改善！

----------------
引文: