很多企業基於cmmi
建立過程體系後,大家普遍反應太複雜,編寫的文件太多,複雜的體系可能就無法貫徹執行下去,無法成為企業的文化。因此需要敏捷化,當我們對過程進行敏捷化時,是基於實效的目的而不是基於評估的目的。如何將乙個規範的過程體系敏捷化呢,下文將針對軟體企業反應突出
cmmi
中的dar
過程域為例,說明敏捷化的方法。
首先,看看在
cmmi
體系中對
dar的要求:
sp1.1
建立決策分析指南
sp1.2
建立評價準則
sp1.3
識別候選方案
sp1.4
選擇評價方法
sp1.5
評價候選方案
sp1.6
選擇候選方案
假如根據上述的要求,已經建立了企業的決策分析過程,具體的規範過程我們不去贅述。以下是敏捷化該流程的示例:
1整個過程的目的是什麼?目的是最根本的要求,實現目的的方法有各種各樣的。
選擇最優的解決方案,減少將來返工的工作量。
2整個過程的目的是否可以打折扣?判斷最初的目的是否合適?是否經濟?
快速地選擇合適地解決方案,盡可能減少返工的工作量。
3整個過程做事的最重要的原則是什麼?實現目的的最重要的要點是什麼?
多識別候選方案,避免思維盲區;所以要頭腦風暴,多人參與決策。
全面客觀評價候選方案,避免遺漏或片面或錯誤的評價候選方案;所以要頭腦風暴,多人參與決策,並通過一些原型等方式驗證方案。
4整個過程給客戶的交付物是什麼?客戶交付物的最簡單的表達方式是什麼?
交付物:決策結論
交付物的最簡單的表達方式:決策結論、候選的方案、各方案的優缺點。可以體現在會議紀要中。
5整個過程的活動是否有可以簡化的?簡化了以後是否是對目標的達成有影響?整個過程的中間產品是什麼?是否是必須的?如果是必須的,最簡單的表達方式是什麼?
可以簡化的活動:選擇決策準則與決策方法。
中間產品:決策的準則、決策的步驟、決策的方法描述
是否是必須的:在決策時一定會有評價的指標、有決策的方法、有決策的步驟,評價的指標應該是文件化的,決策的步驟、決策的方法可能是去做了,但是未必是文件化的。
最簡單的表達方式:在編寫決策結論時,比較各方案的優缺點時,對各個評價指標進行優缺點分析。
6如果減少了中間產品,有什麼手段可以保證缺少文件的負面後果?
可以在組織級定義常用的決策步驟與決策方法。
可以在進行決策前,在決策會議上先進行決策方法的討論。
7簡化後的過程是否有什麼前提條件?
參與決策的人員有成功決策的經驗。
8如何及時發現精簡後的過程的輸出的缺陷?
形成的決策在後續的開發過程中實時(每天、每階段)評價其有效性,一旦發現有問題,則在團隊內部再次進行評價。
例解 如何將規範的過程敏捷化?
很多企業基於cmmi建立過程體系後,大家普遍反應太複雜,編寫的文件太多,複雜的體系可能就無法貫徹執行下去,無法成為企業的文化。因此需要敏捷化,當我們對過程進行敏捷化時,是基於實效的目的而不是基於評估的目的。如何將乙個規範的過程體系敏捷化呢,下文將針對軟體企業反應突出cmmi中的dar過程域為例,說明...
如何將部署靜態資源到nginx上,超詳細解決
cd etc nginx conf.d 進入conf.d包下 建議copu乙個default.conf 檔案,如果修改壞了就麻煩了 vi copy出來的.conf 修改server name後的伺服器位址 也就是 location中的 例項如下 檔案位址如下c windows system32 dr...
如何將測試規範滲透到日常的工作中
往往在測試中,大家覺得來了測試任務就測試,時間久了,反而忘記了還有什麼規範?也就慢慢忽略了規範!規範的軟體測試流程有助於需求條理化,將測試工作模組化,一切跟著計畫走比通過腦袋記憶要更加的有條理。有的時候,工作任務比較繁瑣,腦袋記憶力容易出現亂成一鍋粥的情況,特別這個時候,軟體測試計畫就更加重要。下面...