筆者因工作之便, 拜訪過國內許多軟體開發團隊, 其中也有許多是導入 CMMI 的, 今天早上從業務口中得知某家在推導 CMMI 的公司仍在使用 Paper Work 進行建構管理與變更管理流程, 原因是工程師不願意學習工具, 或是工具具有學習門檻, 這已經是筆者看到第二家公司推導CMMI的做法, 而且他們都很順利通過 CMMI Level 2 的認證.

筆者並不是強調通過 CMMI 一定要使用相關資訊化系統, 但是筆者比較過國內許多在推導 CMMI 的團隊與 OpenSource 的團隊, 發現到 OpenSource 的開發團隊因為開發成員散落在世界各地, OpenSource 的專案利用E化系統來協同開發的成熟度確比公司內部的成熟度高許多. 如果讀者有從 SourceForge or Freshmeat 下載過 Opensource 會發現, Opensource 的專案都有專屬的--
1. Defect/Bug tracking
2. Change Request tracking
3. Requirement tracking
4. Document Management
5. SCM (CVS or SubVersion )
6. Project Forum or Help Desk
7. Daily Build status

在筆者的觀點, OpenSource 的專案開發團隊比起許多 CMMI Level 2 的團隊成熟度高出許多, 這是我想提出值得省思與討論的觀點.

PS. OpenSource 專案, 筆者可以建議看 Apache , MySQL , SubVersion ... etc. 這些專案在品質上都有一定的水準, 而且穫得業界廣汎的使用.

jeffery，

在你的敘述中，把「通過 CMMI 評鑑的公司」和「通過 CMMI 評鑑的軟體開發團隊」混為一談，但「通過 CMMI 評鑑的軟體開發團隊」≠「通過 CMMI 評鑑的公司」，因為目前國內大部份對外吹噓「通過 CMMI 評鑑的公司」，其實都只是其內部某個部門或某個軟體開發團隊通過 CMMI 評鑑而以，有無可能你所觀察的軟體開發團隊其實還沒有通過CMMI 評鑑，因此造成了你的誤會，甚至產生對 CMMI 評鑑的質疑呢 ?

OpenSource開發團隊較CMMI ML2的團隊成熟度要高出許多？不知道Jeffery兄所要表達的是什麼？其實，就誠如alexyin兄曾經述及的經驗，在國外許多高成熟度的公司，其工作成員只會知道他們的日常有很多工作在執行，而且就只知道每件事都是那樣做的，根本不會知道自己做的是CMMI裡所要求的一些practices，甚至於對於CMMI這件事一點概念也沒有。
所以，在對於其背景完全不了解時，就說Opensource的專案開發團隊比起許多CMMI Level 2的團隊成熟度高，也許那個團隊的CMMI 成熟度更高呢！

我想要表達的是一種國內公司導CMMI現像,而不是在批評CMMI Level 2不好,當我看一些CMMI Level 2的公司在用Paper work做變更管理與建構管理,再比較OpenSource開發社群使用的資訊化系統(例如SourceForge,JavaForge etc )兩者相互比較讓我不禁感慨這好像一個是在拿鋤頭打仗一個是用先進的武器在做戰,我相信並不是所有的CMMI Level 2 公司都是如此,不過這種現像在國內確實存在.
Forrester有寫一篇研究報告Applying Open Source Processes in Corporate Development
http://www.forrester.com/Research/Document/Excerpt/0,7211,34466,00.html
很可惜這篇報告是要付費的,我非常鼓勵所有在推行CMMI的公司或顧問來看這篇研究報告,再來想想現在號稱已經過CMMI Level 2的公司的實施狀況,如果CMMI的目的是要追求高品質與高生產力的團隊,這篇文章會給您有別於CMMI的另一種見解與解決方案

對於政府採購合約，政府角度是站在Product Orientation（此中、美皆然），因此專案發生過程各階段的產出物，諸如SRS、SDDD、ICD等文件，政府端在現有合約皆會要求乙方提供紙本與電子檔，所以這是來自於甲方的要求。前者是屬於Service類型的乙方，對於屬於Product類型的乙方，因為僅需要提供終端產品與使用手冊給一般User，所以是否要使用紙版文件以完成所有專案過程，屬於各企業團體的Style，但使用Paper Work與CM Tool二者與成熟度完全無關。

以美國政府國家檔案及文件總署2003年合約即規定執行Change Request的事項如下：Furnishes the CO with any requests for change, deviation, or waiver (whether generated by Government personnel or Contractor personnel), including all supporting paperwork in connection with such change, deviation, or waiver。歷來之DoD-STD-2167A、MIL-STD-498、IEEE/EIA-12207、MIL-STD-497等標準文件皆不會規範到要不要使用紙本或電子檔，純粹由合約決定。

我參與過計劃的軟體細部設計文件(SDDD)，總計約有1200頁的紙本，整個系統相關介面裝備超過20項（每一項的SDDD文件也有100-200頁左右）以上，要我全部看電子檔進行審查，可能必需先能夠在桌面擺上5-9台電腦。因此即便是美國現今發展的最先進JSF戰機，仍免除不了要使用紙本進行各項審查與變更管理，但我確定的是拿鋤頭打仗的美國是可以製造出諸如JSF的先進的武器，且我與該公司主管與員工聊天時，也確定這家公司的大部分主管與員工並不知道何謂CMM或CMMI（該部門於2002年為SW/CMM-Level 3），他們的觀念是CMMI是屬於Process Improvement交由EPG Group去修訂Procedure，工程單位照修訂後的Procedure即可，但他們都了解IEEE/EIA-12207、MIL-STD-498、MIL-STD-973、…，手邊也有此等文件。

所以執行Configuration Management，使用Paper Work與否與CMMI無關，也與成熟度無關。如果你的公司已通過CMMI Level-2/3/5，不妨上網公佈共享舉行CCB的經驗，就可知道Paper Work與Electronic Media對於CM/CCB的差異性了。