轉自：http://blog.csdn.net/coolbacon/article/details/6326017
中國的中小型公司，一般因爲創業者關注到某個市場特殊的需求，幾個人拉着風投就幹起來了。大都在盈利模式或市場上有過人之處。公司的老闆將大部分注意力放在盈利模式和市場的維持與拓展上，關注內部的管理相對較少。道理也顯而易見：盈利模式或市場是“開源”，而內部管理其實是“節流”。比如說，一個互聯網公司，管理很糟糕，但是由於盈利模式新，還是可以賺大錢。而一個玩具工廠，管理非常好，但處於產業鏈低端。人民幣一升值，關稅一提高，全部完蛋。從某種程度上講，關注盈利模式沒有錯，但管理爲盈利模式提供一個強有力的支撐，可以實現良性循環。所以小公司變強大，管理是必須要走得路。
然而小公司團隊的項目管理的確不好做,資源少且軟環境較差。有種百廢待興的感覺。管理成份多了，體現不出船小好掉頭的優勢，浪費許多成本，老闆看得心疼；管理成份少了，項目又不可控，風險頻出，質量度量預測不可信。如果上CMMI，用不了多久就會發現：過程域多，每個過程域裏的特殊實踐多。對工程域裁剪不裁剪，對特殊實踐裁剪不裁剪，的確是很難把握。大多數時候，我們身邊沒有CMMI的專家，很難把握項目的規模與CMMI裁剪的分寸；動不動就同行評審，會發現團隊裏有價值的專家時間全部被評審佔完了，根本沒時間去做別的事情。
那行，咱不用CMMI，用敏捷。XP編程，TDD開發……發現噩夢纔開始。比如說XP編程，兩個人相互結對編程。
“能保證100%的堵住問題嗎？”——Boss
“呃……不能……”——我
“那你爲什麼浪費一個人幹這個事情？”——Boss
“……”——我
結對編程的主要目的是加強同行評審，將同行評審引入過程。兩個人編程也是相互學習加深理解的過程。同時結對編程基於對需求的正確理解上，而對需求的正確理解，又依賴一個人的知識和其他因素。如果一個強勢的人和一個弱勢的人在一起結對編程，恐怕是要一邊倒吧。國外簡單的問題，到國內來，就問題頻出。曾仕強老先生的《中國式管理》實在是太有道理了。
再談TDD編程，測試驅動開發的想法很好。但測試用例設計的有效性怎麼保證？特別是單元測試，與最終的結果無法對應起來。並且需求變動後，內部的接口也要發生變化，那麼自然測試用例也要發生變化，需要重新設計。然而設計依賴於編程人員本身的素質，如果設計的不好的話，帶來的項目變更的成本還不如CMMI那種節約。
國內缺乏一些實施的土壤。PC編程的門檻很低，很便宜的工資可以招來一個人來幹活，也能把事情做出來(質量低)。老闆認爲，PC編程本身就是廉價的，沒必要高工資養着人，過兩年，新員工變老員工，裁掉換一批新的便宜的。這個思路使得項目管理工作陷入一個萬劫不復的無底深淵。恰逢中國這個市場，又是一個什麼檔次產品都有市場的地方……總有那麼一部分人喜歡廉價產品，總是砍價砍得別人生存空間都沒了，所以纔有了染色饅頭、工業醋酸勾兌的醋……實際上是一個劣弊驅良行的過程。敏捷對人員的初始素質要求是較高的，中小企業裏實施100%的敏捷，我覺得是不太符合國情的。
中小公司的項目管理純用CMMI、敏捷等方法都是不合適的。那麼怎麼辦呢？過程是人、方法、技術、工具的四者有機結合。小公司的資源不足，軟環境不好，說白了，人的問題可能更突出一些。沒有完善的公司制度、沒有健全的企業文化。不能爲項目管理提供有效的支撐。小公司靠哥們義氣，中型公司靠制度，大公司靠文化。 所以對項目管理者的個人能力要求就比較高了。和員工走得太近，容易背離組織和企業的價值目標；不和員工走得太近，又會使得團隊沒有凝聚力，人員流動率變高，需要項目管理者處處權衡。
穩定團隊可以使得技術解決方案、業務遞進有一致的延續性, 有延續性才能談提高、創新。團隊的穩定一是要靠項目管理者的個人魅力（或關係）；二是要靠公司所處行業好；三，技術人員一般尋求以下2個目標：1.技術/能力的成長；2.待遇的增長。通過項目的鍛鍊，挑選出有能力的人做相關模塊的專家。這些專家輪流培訓組內成員。同時，給予一定的物質獎勵，形成良性循環。
項目的生命週期中的需求、計劃、實施、收尾四個四個階段有四個階段的交付物，如需求、概要/詳細設計、產品、測試用例、測試報告等。項目的過程也會產生組織資產，也會產生項目的最終交付物。只要在20%的事情上，投入80%的精力，可以達到一個80%的效果。所以，應把主要的精力放在需求的收集定義以及測試用例的設計上。
需求是條河流的源頭，如果污染了，下游就肯定會遭殃。然而需求的管理是非常複雜的。這個沒什麼捷徑可走，我覺得只能是苦練內功，並且將這些內功練好的人作爲企業的專家養起來。CMMI在需求管理PA的幾個SP是非常有意義的。但實踐中做到是比較困難，特別是需求跟蹤矩陣(RTM)，對項目的風險控制及其最終的交付都有着非常大的意義，項目越大，意義越大。DOORS
就是這樣的一個跟蹤工具，這個工具比較早了，有點不太好用。一些UML工具擴展了UML2.0的語法，可以支持需求建模，也支持RTM，如EA等。如果團隊有比較高的素質，使用這個工具可以大幅度的提高風險應對控制能力。
測試是對我們結果的複覈，檢查我們的工作是否滿足我們的要求(需求說明書)。測試時應控制好版本對測試的影響，把每個測試用例分級，嚴重級別的Bug一定要出問題分析報告，普通級的Bug和輕微級別的Bug按一定的比例隨機抽取一些，也要分析問題，給出報告。所有測試和錯誤報告必須有書面文檔，最好使用集成化的研發管理環境，便於查找翻閱。這個會作爲組織過程資產，可能被下個項目所利用。用來培訓員工，提高整個團隊的業務素質是非常有幫助的。
相對需求和測試，中間的過程相對來講可以稍微“放縱”些。至於詳細/概要設計，主要看項目的實施者，
如果他是個經驗豐富的工程師，只要求他將一些接口，一些重要的業務模型用UML建模，其他不強求。如果是個新人，要求全部建模，然後一點點評審，直到全部通過。需求如果發生更改，對於老鳥，只要求需求、測試用例以及用戶說明書更改，簡單的更改，設計只是口頭定義；複雜的更改，需要給出更改的模型。對於菜鳥，不管簡單複雜，都要求對UML模型更改。設計的時候要做白板講解，不妨讓所有人都來聽聽，讓大家提提都有什麼問題(識別風險，同行評審)。形成一個意見書或會議記錄，在實施的過程中形成指導。我的感覺是，一個人在感覺他能影響組織和結果的時候才願意擔負責任。對於提出有建設性意見的人給予一些物質獎勵，大家都願意爲項目最終的成功交付而努力。每週或兩週舉行一次這樣的會議，對項目進行良性刺激。
在團隊空閒時，可召集團隊的老人、新人一起研究公司的各個業務模型，抽象出一些公共的部分形成標準代碼庫。像我的團隊對產品的一些通信協議抽象，形成標準協議庫。對業務模型抽象，形成一個業務模型代碼庫。並進行嚴格的單元測試和集成測試。經過多年的努力，一些重要的項目，公共代碼庫已經佔到了項目代碼量的70%以上。在開發項目時，儘量複用這些公共代碼庫，減少風險，提高最終的交付質量並大幅度減少交付週期。我們響應客戶的需求有原來的2~3個月縮短到了1~2周。
在整個項目實施的過程中，可以適當的引入一些CMMI、敏捷的工程實踐。如代碼評審，每天抽一個小時，大家都來看代碼。分析哪裏寫得好，哪裏寫得不好。堅持一段時間，代碼的撰寫質量會大幅度的提高，也會積累相當的文檔，用於培訓新人(滿足技術人的第一個目標)。同時結合一些自動化的代碼評審工具，如IAR中的MISRA的標準審查，cpptest等代碼靜態測試工具等。會達到一個更好的效果。