最近久其軟件通過CMMI2.0五級評估，從2002年第一次CMM評估算起，這是久其第五次評估了。作為一家技術型的企業，久其一直致力于提升自已的技術水平和研發能力。公司在成立早期，在只有數十人的時候，就接觸到CMM先進的管理思想，逐步將CMM和后來的CMMI模型實踐踐行到產品開發和項目管理過程中，可以說，CMMI體系和久其的幾代軟件平臺彼此見證，又相互促進。
在CMMI實踐中，久其也走了一些彎路，但是在摸索中我們走出了自己的路，讓CMMI在久其研發模式下落地。雖然還存在各種問題和挑戰，但我們今天取得的成就驗證了CMMI的價值。
久其軟件的研發模式特征
今天的北京久其軟件股份有限公司（股票簡稱：久其軟件；股票代碼：002279）已經是一家中國領先的管理軟件供應商。主要面向政府部門和大型企業集團提供電子政務、集團管控、大數據、互聯網等綜合信息服務及行業解決方案。
可以說久其面向的客戶都是信息化應用程度較高的群體，具備如下特點：客戶項目基本都是“產品研發+大規模定制”的模式，一般70%的產品功能是相對標準化、可復制的模塊，30%需要根據客戶的行業特點、業務特征、管理風格、應用系統運行生產環境等因素進行客戶化定制。項目要面臨復雜的生產運行環境，需要具有多種環境適用性、兼容性，同時還要面對復雜的應用集成，實現與客戶現有系統或其他應用開發商的第三方系統集成等等。基于上述情況，公司在研發管理上基本采取的是產品型或平臺型研發和客戶化定制研發兩種方式，客戶化定制開發項目也是基于內部的產品平臺面向具體客戶開展的定制開發。這兩類項目分別由不同的研發團隊來承擔，即產品或平臺研發團隊和客戶化定制交付團隊，因此需要在兩個團隊之間建立例行化、規范化的溝通機制，而資源的長期緊缺又要求公司從戰略角度精簡研發過程以提高效率，比如從強化產品總體設計、簡化功能詳細設計、簡化文檔模板和某些要素等方面。
久其軟件研發過程改進成果
結合公司業務模式的不斷變化，多年來研發過程也在CMMI的多次改進、評估輪回中不斷改進，體系的不斷完善也為久其帶來了可喜的變化。結合當前研發特點，CMMI特別是2.0的導入給我們帶來下面八個方面的變化：1）培養了公司研發團隊和客戶化定制交付團隊的規范意識，加深了研發團隊、客戶化定制交付團隊對標準化研發過程流程和相關項目管理知識的理解；2）統一了研發團隊之間、研發團隊與客戶化定制交付團隊之間溝通的交流語言（術語、文檔模板、內容表述和事項分解的粒度等）；3）基于CMMI的過程改進，以及CMMI過程體系相關的工程規范、管理架構，為久其軟件引入其他的管理體系（如ISO9000、ISO20000、ISO27001等）及其他行業相關規范（如安全集成、安全開發等資質標準）提供了一個全面的、標準化的框架體系和藍圖。對于這些體系和行業規范，公司不是另起一套流程、文檔和規范體系，而是想方設法將其融入到CMMI過程和規范體系中，成為不斷探索細化CMMI過程改進體系藍圖的“佐料”；4）過程改進資產和最佳實踐庫是進行CMMI過程改進留給我們的一大財富，加速公司內部知識的分享和傳播，特別是，我們將應用系統開發過程形成的組件、技術預研的成果等也視為最佳實踐庫的一部分，并著手專門建設公共組件和共用技術研究成果制件庫，將之融入公司內部的研發平臺中，大大提高了公司內部成果復用比率，降低了研發成本；5）通過規范需求采集和客戶化定制交付團隊與產品研發團隊的溝通渠道，在過程改進外部咨詢顧問的指導下，我們將敏捷開發模式引入研發過程中，成功建立起敏捷開發與CMMI流程框架融會貫通的研發體系，并且在產品開發團隊實踐了“特征驅動的敏捷開發”的理念，使整個產品研發交付更具計劃性、更有節奏和組織性，大大提高研發管理過程的效率，也改變了研發團隊之前認為CMMI過程改進只是“一整套規范的文檔體系”的陳舊認知，認識到過程改進不是套給研發團隊的約束和枷鎖，而是有效研發實踐的有益參照；6）通過過程改進活動，我們在公司的研發團隊與培訓部門之間建立了有效的溝通機制，將過程改進流程框架、工程規范、最佳實踐范例等知識的培訓推廣納入到公司培訓部門的年度例行工作計劃中，通過跨部門的溝通機制，研發團隊也可以就當前流行的、與產品研發管理有關的技術、業務和管理專題與培訓部門提前溝通，由培訓部門組織專人準備相關的培訓材料對產品研發團隊與客戶化定制交付團隊進行更有針對性的培訓；7）通過公司內部EIP系統的建設，我們將基于CMMI過程體系的研發項目管理框架融入整個公司的管理過程中，實現了與公司的年度經營計劃、預算與績效管理、財務核算與成本管理、組織培訓與人力資源管理有效銜接，建立了研發管理與公司高層的信息溝通渠道，從而補全了公司高層對公司全面經營狀況的信息拼圖，也為研發項目及研發過程改進提供了必要的數據基礎； 8）通過內部DevOps體系的建設，我們建立一整套規范的CI/CD流水線體系、自動化測試體系、版本分支與合并管理體系、配置管理體系等研發過程的基礎設施和工程規范，比如在產品線內以及產品線之間復用CI/CD流水線、建立基于通用測試用例庫（如安全性、兼容性（數據庫、操作系統、中間件、瀏覽器等）、性能和負載、底層平臺接口測試等）之上的自動化測試，等等，使普通研發人員不用關心應用系統版本的構建、打包、集成、多運行環境適配和基準水平的代碼規范檢查、安全性構建和基本功能的測試等內部大量重復的、繁瑣的事務性工作，能夠更專注于應用功能的交付和客戶價值的實現，大大提高了內部工作效率，減少了低級錯誤出現的概率。
久其的CMMI之旅是一場知行合一的實踐，模型不是過程、不是標準，讓它能夠真正發揮作用不是一件容易的事。我們的體會可以總結成12個字：一切的管理體系只是提供一個過程框架，其豐富的內涵必須自己在實踐中探索（正如德魯克所言，管理是一種實踐，其本質不在于知而在于行，其驗證不在于邏輯，而在于成果）。例如：我們在對CMMI的DAR（決策分析與評估）這個實踐域的理解之前就沒有深入，只是表面的理解為在過程管理中有會議決策或者電子審批單這種形式的決策審批流程，滿足監管公司經營和研發各個環節的目標即可。但其實在深入進行CMMI2.0過程改進期間，我們發現之前公司經營管理和研發過程管理的角色、決策權限、崗位職責都沒有定義的特別清晰，沒有明確各相關方應該執行的動作，導致在研發過程的決策評估環節降低了效率并增加了研發成本。通過2.0的實施改進，我們把DAR的活動集成到所有決策分析與評估過程當中，對各職能以及研發部門的角色劃分、崗位職責及權限分配進行了全面改進和優化，由點到面，建立起體系化、標準化的決策評估體系，降低了經營過程中的風險和成本，提升了研發效率。
過程改進沒有唯一正確答案，必須結合實際情況具體分析、具體確定最佳實踐，真正實現基于業務價值來驅動過程。比如敏捷開發，之前有研發團隊片面理解Sprint模型設定兩個星期迭代周期的建議，不管大產品小產品、大團隊小團隊死板地設定兩個星期的迭代周期，由于團隊規模很大、某些業務需求難度復雜度較高、階段目標短時間難以理清等問題，造成研發團隊內部花大量時間溝通澄清問題、測試團隊頻繁做重復測試、交付團隊覺得每次發布的版本基本不可用，從而產生大量的內部扯皮和抱怨。后來根據不同產品的特征，設置不同的迭代周期，比如對于團隊規模大、復雜度高的產品設置兩個月一個迭代周期，對于團隊規模較小、功能邊界清晰的產品設置一個月一個迭代周期，并配套相應版本分支和合并策略，從而大大緩解了團隊內部緊張局面，使研發工作組織更為從容。工欲善其事必先利其器，持續有效的過程改進一定要有好的工具和方法，方能事半功倍，打造出優秀的產品。比如針對BI產品數據分析展現應用場景多、復雜度高帶來的測試復雜和工作量大的問題，我們就建設了BI產品線自動化測試用例庫，基于對用戶的數據分析展現場景，進行抽象和全面化，梳理出約2300個測試用例，并且自研測試工具，實現測試腳本的自動執行，可以快速直觀給出測試結果，大大提高測試效率，保證了數據正確性。這樣的例子還有很多，比如EIP內部信息化管理平臺功能的不斷完善、基于Jenkins流水線管理等等，這些都為我們的過程改進和產品質量提供了可靠保障。 今天久其軟件面臨著新的挑戰，為了客戶，我們會不斷學習、創新，我們會持續過程改進，會讓我們的客戶在每個改進中受益。
轉發自久其過程改進小組 老叢講桌
滬公網安備 31010502000282號