談開發質量和過程管控
這里站在甲方信息化部門的角度談下對開發廠商質量和過程的管控話題。
在構建企業私有云paas平臺的時候,里面有一個重要的內容就是應用開發框架,這個應用開發框架可以理解為包含了應用技術架構(分層架構,開源組件選擇等)和各種規范約束(編碼規范,接口調用規范,UI規范)的一個空框架。各個開發廠商都必須遵循同樣的一套技術架構來開發應用,這個不僅僅是解決開發的應用能夠部署到paas平臺的問題,更多的是解決后期的運維和管理問題,也進一步加強了各個開發廠商之間的可替代性。在傳統的應用軟件招標中往往我們只強調了開發語言和數據庫使用什么,而實際應用內部的技術架構,采用的技術組件仍然由開發商控制,對于甲方來說完全是一個黑盒,不利于后期的質量和過程管控。
在paas平臺搭建到一定程度后,可以看到企業內部可以復用的各種IT能力逐步成型,這既包括了各種技術服務能力,也包括了業務服務能力。形成了一個很多的可共享的服務能力支撐庫。而新的應用系統必須要基于已有的各種IT能力資產進行開發,加強復用,降低重復開發。這也是我們說的后續應用系統開發能夠快捷反應,逐步降低開發成本的一個原因。但是很多時候面對開發廠商固有的模式,推動上往往必須有強大的執行力。
平臺+應用,一方面是通過平臺實現敏捷性和成本降低,一方面是通過平臺約束上層應用采用統一的開發框架,技術架構和標準規范,從而加強后續對應用的質量和過程管控能力。
對于開發廠商的研發過程,給出一個最簡單的基于CMMI思路的一個研發過程圖如下:
那么站在甲方的思路,要加強開發過程和質量管控的最好的方式就是加強對需求方案和驗收發布兩端的強管控能力,對于研發過程中加強里程碑評審的能力。對于項目管理而言則加強PMO對項目群管理的能力。在支撐域中最基本的配置管理和變更管理是必須的,要注意到甲方對配置管理的層面往往高于單個應用,往往涉及到的是更加全局跨系統的配置和變更管理能力,端到端的需求全程跟蹤和閉環管理能力。
對于甲方驅動的研發過程管控能力,可以總結為三大類,具體如下:
可固化:主要是指規范,流程和相關工具的制定和采用。
可管控:主要是值項目管控過程中的評審,決策,溝通匯報,問題風險管理和監控預警機制。
可量化:主要是指研發管理中的基礎度量和KPI指標體系的建立
可以講做好上面三個方面的內容是甲方逐步深入研發過程管控的一個基礎。甲方的研發質量和過程管控不是要替代單個應用開發商的研發項目管理和質量管理,而更多的目的是類似CMMI三級一樣形成一個適合甲方管理的組織級的過程和管控機制,從單個應用廠商本身的成熟還不足夠,更加重要的是組織級的基線和成熟度。
對開發廠商的管控逐步打開內部的黑盒,但是要注意不是完全接管,而是加強關鍵點的里程碑評審和結構化決策機制?;谶@個思路,另外再提下研發過程管控的一些關鍵點。
對于需求層面,我們要注意往往不是簡單的統一需求方案,特別是涉及到跨多個應用系統的方案制定的時候,需要的不僅僅是需求方案,同時包括了技術方案。這個方案會約束高層的的一些總體架構設計和實現思路方面的內容,以防止后續各個應用在實現過程中走偏。
加強對兩端的管理,包括需求方案和驗收發布兩端的管理,而弱化對廠商開發內部的管理,對于開發廠商內部的過程管控只需要加強里程碑監控和評審即可。以做到最基本的閉環管理。對于開發商內部的研發過程重點是制定相應的標準規范和約束,加強QA管控。
配置管理要形成企業級的配置管理庫,各個廠商最終的研發過程資產都必須入庫,要加強各種配置審計工作,同時源代碼配置管理也需要逐步深入管理,方便后續的統一發布和部署流程的對接。而取代原因的開發廠商在驗收的時候才一并提交驗收資產的模式。
在縱向團隊的基礎上,可以考慮形成各種橫向的聯合性質的虛擬團隊。包括易用性團隊,性能優化團隊,技術專家團隊,業務專家團隊等,以專家團隊的方式來解決各個應用可能存在的共享問題,并且在解決后逐步上升到企業知識庫中。形成組織級的度量和KPI體系,切實用數據說話,通過數據分析形成持續改進機制。這一點往往是最難的,但是又必須執行,至少需要做到定性+定量的開發商考核和評估機制。
文章來源:人月神話(新浪博客)
- 目前還沒評論,等你發揮!