變更管理

實施變更管理的一個更重要且更有意義的作用就是對變更進行度量分析。 3.變更管理是項目管理中的一個重要過程,但也只是一個過程。 CQ是變更管理工具的一個標竿,沒有人懷疑過CQ的功能。

變更管理

目錄

概述 變更‍ 變更的流程 變更管理工具‍
  • 對變更管理工具的要求‍
  • 幾種變更管理工具介紹
  • 概述 變更‍ 變更的流程 變更管理工具‍
  • 對變更管理工具的要求‍
  • 幾種變更管理工具介紹
  • 展開

    編輯本段概述

    變更管理 即Managerment of change(MOC):有變更的需求就要有變更的控制和管理。 它的主要任務包括: 1.分析變更的必要性和合理性,確定是否實施變更; 2.記錄變更信息,填寫變更控制單; 3. 做出更改,並交上級審批; 4.修改相應的軟體配置項(基線),確立新的版本; 5.評審後發布新版本。 軟體生存周期內全部的軟體配置是軟體產品的真正代表,必須使其保持精確。軟體工程過程中某一階段的變更,均要引起軟體配置的變更,這種變更必須嚴格加以控制和管理,保持修改信息,並把精確、清晰的信息傳遞到軟體工程過程的下一步驟。軟體變更管理包括建立控制點和建立報告與審查制度。

    編輯本段變更‍

    變更(CR,Change request)管理是項目管理中的最重要過程之一。 一個項目,從開始就處於不停的變化中。用戶需求變了需要調整計畫或者設計;測試發現了問題需要對錯誤代碼進行變更;甚至人員流失了,也需要項目進行一定的調整以適應這種情況。Bug管理,需求管理,風險控制等本質上都是項目變更的一種。它們都是為了保證項目在變化過程中始終處於可控狀態,並隨時可跟蹤回溯到某個歷史狀態。 孤立的看單個變更(CR)的生命周期,那么它是比較簡單的,大致就是提出-審核-修改這么一個過程。但變更管理並不是單純的一個資料庫記錄,做個備忘而已。在這么一個簡單的流程中,變更管理要能體現出它的兩個重要用途,一個是控制變更,保證項目可控;一個是變更度量分析,幫助組織提供自己的開發能力。 為了保證項目可控,項目管理者要充分了解變更的信息,衡量變更實施對項目的衝擊,才能決定是否要修改。比如問題是否嚴重必須馬上得到修改,問題的修改是否很複雜,是否會牽扯到很多方面。這些信息,大致可以歸為倆類,一類是變更的自身信息,比如復現步驟等;一類是關聯信息,比如某個功能變更實施後,對項目其它模組的影響分析,這類信息通常不可能由變更提出人來提供,而需要變更審核者結合多方面信息進行分析。 實施變更管理的一個更重要且更有意義的作用就是對變更進行度量分析。在項目進行過程中,對變更進行分析,可以很好的了解項目當前質量狀態(如果你承認統計學有它的科學性,那么你就會承認,項目各階段的合理變更發展情況是有確定的分布形態的);定時進行項目復盤,分析組織中變更的產生原因和解決方法‍,及時了解組織中常見錯誤並有針對性的改正,才能促使組織的開發能力不斷得到提高。

    編輯本段變更的流程

    我們看下變更生命周期中的幾個主要過程和這些過程的要求 : 提出:記錄變更的詳細信息,相當於一個備忘。需要記錄的信息可能根據不同組織和不同項目的規定而不同。要點在於變更提出者能簡明扼要的記錄下有價值的信息,比如缺陷發生時的環境,要變更的功能……。 變更管理工具不僅要能方便的記錄信息,而且要給記錄者一些記錄的提示信息,幫助記錄者準確的記錄變更。 審核:審核者首先要確認變更意義,確認是否要修改;其次審核者要確認變更可能產生的影響,根據影響分析決定是否要修改下變更的內容以及對項目其它方面做同步改變;最後就是指派項目成員實施該變更。 在這裡,關鍵是審核者要能對變更的相關影響有清楚的認識,這認識並不是說如何修改變更,而是如果修改了該變更,有可能帶來什麼影響,是否值得修改。很顯然,這些信息不是變更提出者在記錄時會給出的,而應該是審核者自己輔助其它系統或者工具進行判斷。 實施修改:根據變更要求進行修改。 首先要保證修改實施是完全而徹底的,比如提了一個需求變更,不能只改了需求文檔而不改代碼或者用戶文檔。在組織分工情況下,如何協調多個小組的同步變更保證工作產品一致性正成為一個很嚴峻的問題。 實現變更的一個初始目的就是為了項目的跟蹤回溯,那么,針對變更而做的修改也應該被記錄下來並被和變更關聯起來,實現why、what的雙向跟蹤。 確認:確認驗證變更確實得到了確實實施(或者拒絕變更的理由是合理的)。 查詢和度量分析:項目管理者需要了解項目中各個變更的當前狀態,根據變更狀態做出各種管理決定;度量分析變更數據,了解項目質量狀況;定期進行復盤,尋找變更根源,進行有針對性,甚至是制度化的改進。 這兒的關鍵是要確定要分析哪些數據,如何分析。

    編輯本段變更管理工具‍

    對變更管理工具的要求‍

    通過對變更流程的觀察,為了實現變更的目的,我們認為一個良好的變更管理工具至少應該具備如下技術特徵。 1.對變更管理工具的最基本要求是一個信息記錄功能,起到備忘以及交流的功能。 2.考慮到度量的複雜性,尤其是要適應不同項目特徵、度量目的和度量統計理論,那么工具需要提供一個靈活,且方便使用的的查詢統計機制,方便針對各種度量數據進行報表定製。 3.變更管理是項目管理中的一個重要過程,但也只是一個過程。一個良好運作的項目,並不只有變更管理。那么變更管理系統應該要能和其它過程管理部分相配合,實現整個項目的有機管理和系統使用,而不至於造成信息孤島。

    幾種變更管理工具介紹

    現在能見的變更管理工具有無數,我們重點查看其中幾個主要的:ClearQuestDSTPmantisBugFreeClearQuest: CQ是變更管理工具的一個標竿,沒有人懷疑過CQ的功能。 CQ提供了強大的定製功能,一個CQ,就是一個開發平台。 強大的查詢和報表定製功能,為變更度量分析提供。 和ClearCase無縫集成,實現了變更的完全跟蹤。 除了支持WEB訪問,還提供桌面客戶端。 CQ的缺點除了昂貴的收費,還有一個秉承IBM廣為人詬病的毛病,龐大且使用維護困難! DSTP: DSTP是一個集成的項目協作平台,其中變更管理功能有如下優點: 1.可自定義變更屬性內容,通過變更屬性不同,來統一管理多種變更,如Bug管理,需求變更,風險管理等。 2.就像CQ和CC的集成一樣,DSTP和SVN緊密集成。用戶在SVN上提交修改時,自動關聯DSTP中的變更(任務)做為修改說明。查看變更時,能直接查看該變更關聯修改了哪些檔案,以及修改內容! 3.提供了完善的變更同步功能,提出了系統變更蹤階段概念,使得所有工作產品的一致性得到流程保障!所謂的系統變更跟蹤是指這么一個情況:當用戶提出一個需求變更後,系統工程師修改完需求文檔後,該變更並沒真正結束。系統自動轉入到變更跟蹤階段,只有和該需求有關聯的代碼,用戶文檔等都被修改完成後,該變更才會結束跟蹤階段,走入確認關閉階段。 4.和DSTP的工作產品管理配合:為變更影響分析提供有力支持;變更和需求,測試計畫等直接關聯,方便多向跟蹤追溯。

    相關搜尋

    熱門詞條

    聯絡我們