用資料管理過程(1) 以資料「感知」專案狀況

2021-09-09 03:10:34 字數 2657 閱讀 1489

摘要:

用資料說話,這是當前很流行的話題,本文將資料管理過程劃分成4個層次,並闡述企業如何達到這四個層次。

1.初級量化管理:以資料「感知」專案的狀況(相當於cmmi2級)

2.中級量化管理:通過經驗值來管理專案(相當於cmmi3級)

3.高階量化管理:用pcb進行專案管理(相當於cmmi4級)

4.超級量化管理:持續優化的量化管理(相當於cmmi5級)

1. 前言

量化方面相關資料、理論非常多,如:六西格瑪、統計過程控制(spc)、過程能力基線(pcb)、軟體度量、功能點法、軟體估算等等。關於量化方面文章,大家可能難以把各文章的內容在腦袋中組織成一面知識網,主要因為各文章按照各自的角度闡述問題。我們需要乙個統一的角度來描述這些事情,這裡我們就以cmmi的為參考標準,對所有的量化理論進行「格式化」。

為了闡述方便,這裡我們把與量化有關的內容,全部統稱為「量化管理」,量化管理大致可以分為以下四個級別:

1)初級量化管理-感知級,相當於cmmi2級。

2)中級量化管理-經驗級,相當於cmmi3級。

3)高階量化管理-可**級,相當於cmmi4級。

4)超級量化管理-持續優化級,相當於cmmi5級。

高階別的量化管理,必滿足所有低級別量化管理特點,例如高階量化管理,它具備初級量化管理、中級量化管理的特點,又具備本身的特點。

2. 量化管理的第一基本法則

我們為什麼要用「功能點法」來估計專案的規模?

我們為什麼要度量專案的工時、費用?

我們為什麼要做量化管理?

如果我們不用量化管理的方式,也能達到量化管理的效果,而且成本更低,那還要不要進行量化管理?

當我們面對鋪天蓋地的量化理論的時候,當我們要考慮要做量化管理的時候,首先要問自己的問題就是:為什麼要做量化管理?

我們回答一下這個問題:為什麼要用「功能點法」來估計專案的規模?

如果老闆想這樣做,估計他感覺到專案的估算不是很準,他希望通過一些量化的辦法,讓專案的估算做得更準。所以,他的要進行量化管理的目的是:提高估算的準確率。

這就是老闆的完整目標嗎?如果員工們不計成本地把功能點法做好了,估算偏差提高到不超過5%,但估算工作需要的時間由原來的5天增加到50天,這樣老闆會接受嗎?其實老闆還有隱含的約束條件,就是不能太花成本。

如果把老闆的目標再完整表達一下,應該是:在一定的時間成本要求內,提高估算的準確率。

無論我們做什麼量化的工作,都必須先明確:

量化管理第一基本法則:明確量化管理的目的及約束條件。

「功能點」法是比較複雜而且難掌握的軟體規模度量辦法,有可能在研究使用的過程中,才發現不值得用「功能點」法,大家再反過來看看目標:在一定的時間成本要求內,提供估算的準確率,而不是:在一定的時間成本要求內,用功能點法提高估算的準確率。這時,大家可以選用別的辦法,或者對「功能點」法進行改造。在制定目標的時候,不要把具體的方法寫進去,目標是很高層次的,把辦法寫進去,也就是相當於限制了思路。

有人可能會說,「在一定的時間成本要求內,提高估算的準確率」,這個目標太虛了吧,寫了等於沒寫。其實正是因為沒有明確這個「虛」的目標,很多量化管理的工作變成就是為了量化管理而量化管理。其實六西格瑪、統計過程控制(spc)、過程能力基線(pcb)等量化管理辦法,都要有很明確的目的。

如果企業對量化管理的目標都不明確的話,那就非常不好意思了,連初級水平都不是,是屬於「無級別」的水平。

3. 初級量化管理-感知級

例:進度報告(節選)

在軟體測試中,會記錄各類缺陷的情況,並且在測試報告中報告缺陷的一些資料。專案組會根據缺陷方面的資料,分析軟體的質量,並考慮後續的改進措施。

例:測試報告(節選):

總缺陷數量:50

建議:需要在後續版本中修復沒有解決的缺陷。

「感知級」的企業,有這樣的一些特點:

1)有明確的度量目的。

2)有度量值的比較基準,如例子中的計畫完成時間與實際完成時間的對比。

3)被度量物件的屬性定義得比較清楚,如上例中缺陷的屬性。

4)對度量的結果進行分析,並且要考慮改進措施。

「感知級」的企業,應該滿足cmmi2級中ma(度量)這個pa的要求的(請參考cmmi相關標準)。

但下面這種情況,算不算「感知級」呢?

在專案總結報告中,統計專案進度、成本等情況,分析與計畫比較的差異,提出對以後有用的改進意見。

如果只在專案總結報告的時候,才進行度量的話,是不能算「感知級」的,度量的結果要能用於專案管理,而不是專案結束後了統計出到一些數字,儘管這些數字可以用來改善以後的工作,但對該專案本身工作的改善已經沒有任何作用了。

達到初級量化管理的企業,能明確量化管理的目標,通過合適的度量辦法,「感知」專案的各類引數,並根據各度量指標的實際數值,採取改善專案行為的措施。

請看下文……

創新工場創業課堂講師

軟體研發管理資深顧問

cmmi首席專家

《火球——uml大戰需求分析》作者

www.umlonline.org 創始人

Docker容器資料管理1

容器的持久化資料如何儲存 這篇講得非常清楚 還可以參考這兩篇 然後就是官網 docker的檔案系統 映象是read only layers 容器啟動後在映象層之上新增read write layer 對於映象層檔案的修改動作是將其拷貝至read write layer進行,並hide原檔案 當容器被...

專案管理過程 工作績效資料,資訊和報告

工作績效資料 是在專案管理過程中,一邊執行一邊收集起來的,未經任何加工整理的原始資料,用於 真實,完整地記錄工作的執 況。它是指導與管理專案工作過程的輸出。是專案監控 時用來與計畫要求做比較實際的實際資料。專案集績效資訊 是對工作績效資料進行加工整理後得到的,是各基層區域性監控過程的輸出。並成為整個...

主資料管理專案建設經驗分享

一 主資料建設的術法道 隨著企業資訊化系統建設逐漸增多,領導 業務部門對資訊系統支撐決策 管控 業務執行難度也隨之提高,導致解決業務系統間的互動困難和資料多頭管理不一致等問題成為資訊化建設的難點和重點。借鑑業界成熟的資訊化建設思路,建設步驟分為三步 立標準通過資料標準化建設,達到關鍵主資料的管理制度...