終於訪談結束了，最近的幾個月，進行了備受煎熬的cmmi 認證活動，起初對這個東西非常的陌生，也沒有很多的資料可供參考，經過幾個月的摸索，也掌握了 cmmi 認證的一些道道，其實現在說來倒是覺得cmmi 認證沒有想象的那麼複雜，但如果起初沒有足夠的經驗可供參考，那麼摸索的過程是很痛苦的，趁著現在頭腦還比較熱，把自己的一些體會分享出來，給後來人留個參考，我以後肯定是不會再玩這個了
首先我覺得進行評估的企業要明白一點，不能太「實在」，如果真的按照整個cmmi 的流程來，專案很容易被拖垮，是否值得真的按cmmi 流程來做專案先不討論，這裡僅僅討論如何以最小的成本去通過這個認證。
那麼我還是想最通俗的解釋一下cmmi ，就是定義了一些流程，你要是想過這個東西，你就得去滿足這些過程，這些過程需要企業有乙個專門的組織去維護這個東西，這裡的維護指的就是改進，但這些改進都是小打小鬧，大的過程不會變，這個過程就是標準過程，維護這個標準過程的組織就是epg。現在標準過程有了，是乙個總的提綱，那麼做專案的時候就按照這個提綱來，所以專案中的一切東西你都要往標準過程上扯，這樣就說明你做事是有依據的，不是拍腦袋的，說明你的企業的流程不混亂，都是按照一套統一的標準來的。
下面我們談談最主要的乙個環節-------------訪談。
偶們來看看訪談需要知道哪些東西，我覺得單純的背問題沒有多大意義，自己把專案的過程梳理清楚才是王道，因為這樣隨便lv怎麼問，你都不會離開你的主線，lv問你問題也不是亂問的，他是每個點問你乙個，基本每個點都會問到，其實單純的回答這些點相當的簡單，但，難就難在你的這些點需要相互呼應，不能自相矛盾。 偶們就這些點需要注意的地方來一一清理一下，按照由簡到難的順序
偏差：這個寫個偏差表就可以了，找1-2個時間點出現偏差即可，再寫個解決措施就可以，沒啥好說的
風險：按照風險庫裡面風險在專案出奇識別出來，寫到風險跟蹤表裡面的，注意說一下，在每個里程碑重新識別了風險即可
度量：通過收集相關人員的個人週報的資料彙總出來的，所以個人週報需要填寫個人的進度和工作量之類的，注意時間點可偏差表對應起來即可，專案結束的時候把這個資料在提交給epg，然後他在去改進標準過程，和pm沒啥關係了。
專案進展，這個就是體現出對專案的跟蹤，每個里程碑匯報給專案組的人以及高層，注意進展報告的內容要體現出相關干係人和資料管理，這個沒啥好說的，相關干係人就是每個階段有什麼人參與了，比如需求階段看看需求人員有沒有介入，你就說全介入了，並羅列上去。資料管理就說誰誰誰借了本，並且上個階段誰誰誰借了個什麼資料，並且如期歸還了，每個階段寫1個可以了。
需求：這個地方最難理解的就是介面需求的管理，其他的也沒啥好說的，介面需求其實沒有乙個硬性規定，隨你怎麼寫，你只要做了這件事就可以了。按我的理解就是內部介面，你就說你的專案需要分成開發，有統一的dao介面，還有專案需各個模組之間通過service相互通訊，還有就是後台**可以和前台以 html的方式互動，dao可以支援多個資料庫，白痴吧？。外部介面我寫的是需要有外部的rss訂閱功能，有呼叫豆瓣api的需求，有超級鏈結可以鏈結到其他什麼**，就寫那麼多完全可以了。不過需要注意，你最後的概要設計和詳細設計需要體現出來，比如設計了dao、service層、設計的orm支援隨意切換資料庫（當然你說你框架幫你做的）、設計了rss讀寫模組，設計了jsp，等等。需求完了你就需要寫個總結報告，識別哪些是關鍵的、哪些是可以接受的、哪些是不建議實現的，你就都說可以就完了。
下面最容易出漏洞的是前期的計畫、估算之類的，這個對於很多人來說就是一筆糊塗賬，整個過程如下：
第一步：立項，召開立項會，確定哪些人參與，依據就是拍腦門，說得好聽點是群體決策的方式，這樣哪些人確定了，乘以工資，這樣你的人力成本的估算出來了
第二步：制定專案過程定義書，這個是個啥東西？就是專案做專案要按照epg維護的那個標準過程來，不是你隨意所欲的想怎麼定義就怎麼定義，這裡涉及到乙個裁剪問題，其實這個裁剪也沒啥好裁的，因為你裁多了就不符合標準過程了，就不滿足cmmi 的流程了，然後你就過不了了，我前面也說了就是一些小打小鬧，真正的過程應該是，依據裁剪指南，裁剪指南裡面規定了，根據專案的簽單額或者參與的人數等等有那麼幾套大同小異的過程，你選一套就可以，具體是怎麼裁剪的，那是epg的事，好了，專案的過程中的東西有了，那麼這個過程的順序是什麼樣子的呢？所以還有乙個生命週期模型選用指南，還是依據那幾條，盡量選瀑布模型，因為簡單。最後按照這麼2點就制定出過程定義書了，裡面有我該寫哪些文件，生命週期是啥樣子的，然後更具週期制定里程碑，時間點暫時可以不要，因為專案的工期還沒有估算出來。
第三步：估算表。前面的專案過程定義數已經定義了要寫哪些文件，然後人員你有了，你就安排這些人去寫這些文件，乙個人寫某個文件需要花幾天，這個是你拍腦門想出來的，說的好聽點，叫做專家決策法，這樣一累加，你的總工作量就出來了，單位就按人日來吧。好，下面偶們來看看工時的估算，意思就是我每個階段要花多少時間，這個注意和工作量區別開來，這個是純時間問題，因為你在做估算的時候，需求也在進行中，或者說大致的需求出來了，因為沒有乙個大致的需求去做估算說出來鬼才信！這些大致的需求的就是功能點，然後你在想辦法把這些功能點轉換成**行，你就隨便搜乙個演算法一乘一加就可以了，注意這個方法需要有 epg寫在估算指南裡面，到時候你就說你是選用估算指南裡面的方法。這樣**行出來了，然後在尋在組織的度量庫-----就是你每次做完專案都會向組織提交你的本次專案的度量資料，然後epg把每次的彙總成乙個庫供你參考，裡面肯定要記乙個人均**行數，然後你一除，你得到了你開發階段需要多少時間，其他階段咋辦？還是尋找組織度量庫，裡面肯定還有這麼一項，每個階段所佔整個工期的比例，現在開發階段有了，你在推斷出其他階段的，這麼簡單的數學公式我就不多說了。還有資源的估算就是按人手來的，並且是參考了組織級的工作環境標準，其他的幾項估算就比較簡單啦，不說了
第四步：專案計畫，把以上的結果彙總進來就ok了
下面我們談談另外乙個環節-------------文件，剛開始我們並不知道要寫啥文件，文件裡面該寫啥內容，我的建議是一開始花半個月就寫piid表，然後根據pidds錶花乙個半月補文件，再花乙個月準備訪談，這樣3個月就搞定了。
總體感覺cmmi 評估很龐雜而已，但並沒有想象的那麼複雜，以上是我所知道的一些比較重要的地方，具體的細節可以單獨進行討論
如何快速通過CMMI評估
終於訪談結束了，最近的幾個月，進行了備受煎熬的cmmi認證活動，起初對這個東西非常的陌生，也沒有很多的資料可供參考，經過幾個月的摸索，也掌握了 cmmi認證的一些道道，其實現在說來倒是覺得cmmi認證沒有想象的那麼複雜，但如果起初沒有足夠的經驗可供參考，那麼摸索的過程是很痛苦的，趁著現在頭腦還比較熱...
CMMI評估及兼職翻譯有感
真的是很辛苦，終於完成了clo的評估。這次的準備很充分，我充分做好了筆記，跟之前相比 8年前的翻譯培訓 這次是真正做到了逐字逐句的推敲翻譯。本次真的學到許多，有做人方面的，有讀書方面的，有外語方面的，也有最重要的cmmi方面的 準備面試的文件 準備面試的問題 建立訪談小組 培訓訪談小組 受訪人員的挑...
快速Redis容量評估
前言 1 jemalloc記憶體分配規則 jemalloc是一種通用的記憶體管理方法，著重於減少記憶體碎片和支援可伸縮的併發性，我們部門的redis版本中就引入了jemalloc，做redis容量評估前必須對jemalloc的記憶體分配規則有一定了解。jemalloc基於申請記憶體的大小把記憶體分配...