[M] 為什么CMM管理模式對小項目可能不適合呢？CMM在國內(nèi)的實施過程中，有人提到了裁減問題。對此你是怎么看的。

[L] 其實這個問題怎么回答呢！因為我對CMM不是很了解，我覺得企業(yè)在實施CMM的過程中不能全部照搬，如果全部照搬肯定不會適合自己的企業(yè)而且也會造成浪費的。我覺得我們公司的CMM執(zhí)行是，大家在一起學(xué)習(xí)一些CMM的思想，一起根據(jù)CMM的規(guī)則、流程制定一些適合公司自己的CMM的規(guī)則，公司按照制定的規(guī)則做事情。然后讓CMM的評估機構(gòu)來驗證，看公司的事情是否是按照CMM的規(guī)則做的。這是我個人的感覺，因為我也沒有參加CMM的培訓(xùn)、公司流程的制定，所以我也不是很清楚，只能按照個人的一些想法來回答你的問題了。

[M] 那你從一個公司普通職員的角度來看，這種“localize”的CMM制度，在公司內(nèi)部的實施效果如何呢？

[L] 應(yīng)該說localize的制度是符合公司的實際情況的，是根據(jù)公司的實際需要來做的。在實施的效果上應(yīng)該是比照抄照搬的效果好一些的。但是CMM畢竟是一個很費精力和時間的東西，況且公司現(xiàn)在剛剛實施，因此大家難免會有做得不好的地方，或者抵觸的情緒。不過相信隨著時間的推移，隨著大家意識的提高，應(yīng)該會做得越來越好的。

[M] 對于一項制度，在其真正實施的過程中，總會有走樣的可能。比如，你所在的公司在項目管理方面所推出的一些制度。對此，你有何看法。

[L] 我覺得制度是死的，人是活的。我們可能不需要完全按照制度執(zhí)行，但是關(guān)鍵點應(yīng)該保證。對于特定的項目可能制定的制度并不完全適合，所以我們要摘取恰當(dāng)?shù)牟糠�，要靈活運用。比如一個很復(fù)雜的系統(tǒng)按照公司制定的流程可能從管理、資源、質(zhì)量等都能夠得到控制。但是如果系統(tǒng)本身很小，比如我剛剛接觸的一個項目，功能很簡單，如果完全按照公司的整套流程走的話，我估計效果不會很好，而且可能勞民傷財，還得不到預(yù)期的效果。所以對制度的執(zhí)行要靈活，某些時候關(guān)鍵的內(nèi)容作出來了，其他的邊邊角角我覺得可以不用深究，而且公司有時確實也是這么做的。有些項目不完全按照CMM做，因為太浪費資源了。

[M] 能對前面提到的 SQA，SCM做一下解釋嗎？

[L] SQA是CMM中的軟件質(zhì)量保證的意思，SCM是CMM中的軟件配置管理的意思。軟件配置管理，是指在CMM中，軟件開發(fā)過程存在3個庫：基線庫、生產(chǎn)庫、產(chǎn)品庫。基線庫是在軟件開發(fā)的初期建立起來的，比如需求、項目進度、計劃等等，以后的軟件開發(fā)以它為基礎(chǔ)。并不是說不允許更改，但是更改的話需要走變更流程，需要先申請，后審核，審核通過了才允許補充進入基線庫。生產(chǎn)庫是項目開發(fā)過程中存在的庫，產(chǎn)品庫是項目開發(fā)完畢后的了，庫中存放的大概是一些文檔、代碼等等。當(dāng)然你可以使用clear case來作為媒介，也可以使用source safe，這要視公司的具體情況而定。

[文檔]

[M] 你對程序員進行文檔的組織、編寫、維護工作持什么樣的態(tài)度呢？這是否會影響coding呢？尤其是在來自客戶和市場的壓力十分嚴峻的時候。這是一個很現(xiàn)實的問題。

[L] 其實我們大家都不止一次的提到，在做項目的過程中大部分時間都是用來組織編寫文檔，真正coding的時間在整個項目的生命周期中占的時間是很少的，一個真正的項目也不是以coding作為結(jié)束標志的，因為項目結(jié)束后還有維護或者二期甚至三期，所以文檔的積累對于項目來說是至關(guān)重要的事情。作為項目結(jié)果之一的代碼，我們不能只讓寫這段代碼的人知道，這無異于賭博，而且經(jīng)過一段時間之后誰也不可能保證自己對自己曾經(jīng)寫過的代碼一清二楚。我們要讓所有的人知道某段代碼應(yīng)該實現(xiàn)什么功能，包含什么邏輯，是一個什么樣的思路，這樣項目轉(zhuǎn)接工作才能做得更好。客戶和市場的壓力十分嚴峻的原因是什么，不可能因為程序員寫文檔造成的。相反如果文檔寫的好反而在coding階段會節(jié)省很多的時間，因為思路、算法在文檔中已經(jīng)得到很具體的體現(xiàn)。如果真的客戶和市場的壓力十分嚴峻至少在項目結(jié)束后應(yīng)該把文檔補齊。如果只是項目經(jīng)理寫文檔，那么他的思路、設(shè)計，在程序員身上很難得到體現(xiàn)。因此我建議程序員要參與到概設(shè)、詳設(shè)的文檔編寫中來。其實，摩托羅拉是很好的例子，他們不會因為某個程序員或項目經(jīng)理走了，來接替他的人需要花費大量的時間來熟悉這個系統(tǒng)，相反他們可以從文檔著手，很好的理解整個項目。我們公司有很失敗的例子，在給HP做的電子商務(wù)系統(tǒng)中，到現(xiàn)在某個頁面可能被5－6個人更改過，但是基本的概要設(shè)計連第一版本的內(nèi)容都沒有，因此現(xiàn)在維護相當(dāng)?shù)馁M勁，幾乎沒有人愿意接觸這個項目，一點小小的改動，都要研究半天的代碼。血的教訓(xùn)啊。

[M] 對于項目文檔的準確，完整，應(yīng)該如何去把握呢？

[L] 項目文檔的準確，完整的定義可能很模糊，而且判斷起來也很困難，但是我想基本的應(yīng)該是：項目初期應(yīng)該把項目涉及到的內(nèi)容全部寫入文檔，項目進行中可能某個思路不能得到實現(xiàn)需要更改，代碼更改了但是文檔一定要跟著更改，否則失去了文檔本來的意義。所以我想項目經(jīng)理在做計劃時是否每周要留出半天甚至的時間來修改文檔？

[M] 項目文檔化過程中，文檔撰寫者需要將思路精確無誤的表達出來，并且階段性地保持文檔和代碼的一致性。這對文檔撰寫者提出了一定要求。在你的公司里，當(dāng)客戶和市場的壓力十分嚴峻時，又是如何保證這些的。對此你有什么看法或心得，你認為程序員需要具備什么額外素質(zhì)嗎？

[L] 其實寫文檔是一個整理思路的途徑，所謂的完整或許不需要面面俱到，但是重點的流程，關(guān)鍵的思路等都需要描述出來啊。其實對于文檔的撰寫，不要覺得是個很復(fù)雜的事情，文檔的意義在于它記錄了項目的完成過程，在于便于以后項目的維護。當(dāng)客戶和市場的壓力十分嚴峻時，我們的精力可能集中于項目的真正coding，專注于項目的按期完工。但是在項目結(jié)束之后項目文檔一定要補全。現(xiàn)在國內(nèi)的情況是程序員大部分是本科出身，因此程序員本身的素質(zhì)決定了他不止可以承擔(dān)coding的任務(wù)，因此項目經(jīng)理要適當(dāng)?shù)慕o予他們一些其他的額外工作。

[M] 文檔具體包含哪些類型？每種文檔針對何種閱讀者？

[L] 文檔包括：需求分析說明書，概要設(shè)計說明書，詳細設(shè)計說明書（許多數(shù)據(jù)流圖都作為文檔的附件的），等等吧，現(xiàn)在我手上也沒有很全的文檔列表。

[M] 在你的公司，有沒有類似程序設(shè)計說明這樣的文檔，若有，對于這類文檔，撰寫者若表述不清則會使閱讀者難于理解。實際中是否存在這樣的問題？

[L] 其實我覺得象概要設(shè)計說明書，詳細設(shè)計說明書不知是否屬于程序設(shè)計的文檔，不過我覺得應(yīng)該是吧。其實象這種文檔如果撰寫者表述不清對于閱讀者的理解程度會有很大的差別的。我們公司也一直在討論如何制定一個切實可行的規(guī)范，以利于大家把文檔寫的詳細、清楚，我們現(xiàn)在的模板有時對于某些項目來說真的不適合。但是很長時間以來仍然找不到一個可以避免的方式。在現(xiàn)實的工作中，我認為是存在表達不清的，只不過我暫時沒有遇到過，或許我從需求階段一直跟到驗收，所以對系統(tǒng)很了解，所以可能沒有遇到不好理解的地方吧。而且現(xiàn)在公司的形式是每個人負責(zé)寫一塊的概要設(shè)計和詳細設(shè)計，因此這份文檔對于這個人來說很明白，但是沒有人對整體文檔的把握，雖然我們要做概要設(shè)計和詳細設(shè)計的評審，但是由于大多數(shù)情況下時間不允許，因此項目成員寫完以后，項目經(jīng)理組織到一起也完事了。

[M] 文檔的意義或作用除了記錄項目完成過程外，還有其他嗎？

[L] 或許文檔的意義重要的在于項目的"repeatable"，"repeatable"前幾天剛剛從項目管理部經(jīng)理哪里聽來的新詞，具體的含義我想大家可以討論。或許文檔可以幫助我們總結(jié)經(jīng)驗教訓(xùn)，記錄我們突然間的思想的火花，遇到同樣的項目可以提供經(jīng)驗。