10.1 變更管理的理念
需求變更的根源無非兩種：第一種是我們錯(cuò)了比原，捕獲的信息不全面插佛，分析結(jié)果不正確等。第二種是業(yè)務(wù)變化了量窘。因此我們應(yīng)該盡可能避免犯錯(cuò)雇寇，同時(shí)加強(qiáng)預(yù)測(cè)。但需求變更最終還是無法避免的蚌铜。
》變更管理的目標(biāo)是控制變更锨侯，而不是避免變更。
》控制變更的目的冬殃，則是減少變更對(duì)開發(fā)工作的影響囚痴。
想要對(duì)變更進(jìn)行有效地控制，最重要的就是兩個(gè)方面：
》統(tǒng)一渠道审葬。如果對(duì)變更沒有集中處理深滚，那么想對(duì)其進(jìn)行有效的控制就根本無從談起。針對(duì)同一渠道涣觉，大部分做法是CCB成箫。
》統(tǒng)一平臺(tái)。如果所有變更都沒有有效的記錄旨枯，分析蹬昌，那么就很難對(duì)其進(jìn)行合理的分析。正對(duì)統(tǒng)一平臺(tái)攀隔，大部分做法是“變更管理系統(tǒng)”皂贩。
10.2 統(tǒng)一渠道
統(tǒng)一渠道的兩個(gè)主要原因：
》變更可能是相互沖突的。如果變更渠道不統(tǒng)一昆汹，可能會(huì)引發(fā)新的問題明刷。
》變更量無法引起重視。統(tǒng)一渠道能更好的統(tǒng)計(jì)變更工作量满粗，讓客戶意識(shí)到變更的成本辈末，減少來路不正的變更。
10.2.1 CCB背后的道理
10.2.1.1 正確認(rèn)識(shí)CCB
CCB的核心成員只有兩個(gè)，分別代表用戶團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)挤聘，其他組成人員都是協(xié)作者和決策者轰枝。因?yàn)閷?duì)于所有變更而言，這兩位并非都能做出最終的決定组去。
10.2.1.2 使CCB稱為真正的統(tǒng)一渠道
很多情況下鞍陨，客戶代表并不把需求提交給CCB，而是直接提交給開發(fā)團(tuán)隊(duì)从隆，從而是CCB形同虛設(shè)诚撵。其背后的原因，主要是客戶對(duì)溝通成本理解的問題键闺。
10.2.2 變更處理過程
(對(duì)于變更處理過程寿烟，PMP的變更處理流程或許更完善。)
10.2.2.1 值得關(guān)注的問題是辛燥，變更是否能夠打破基線筛武。
通常來說，變更都是不允許打破基線的购桑。但也有一些例外情況：
》出現(xiàn)了影響生產(chǎn)的需求，或者需求變更項(xiàng)的優(yōu)先級(jí)比基線內(nèi)優(yōu)先級(jí)更高時(shí)氏淑，通常都是使用置換法勃蜘，從基線中換回一個(gè)工作量相當(dāng)?shù)娜蝿?wù)，將其放到下一輪迭代中假残。
》出現(xiàn)了對(duì)前面假設(shè)有巨大影響的變更：暫停迭代缭贡，重新考慮基線。
》工作量較小辉懒，重要性或者跟基線內(nèi)需求的關(guān)聯(lián)性非常強(qiáng)：直接加入基線阳惹。
10.3 統(tǒng)一平臺(tái)
10.3.1 變更管理平臺(tái)的選擇
在選擇變更管理平臺(tái)時(shí)，有以下幾個(gè)方面的功能是很重要的：
》支持變更的生命周期管理眶俩，即從提出莹汤，評(píng)估，接受颠印，實(shí)現(xiàn)纲岭，到驗(yàn)證，實(shí)現(xiàn)全過程的管理和跟蹤线罕，還應(yīng)該支持重新激活等止潮。
》有效的權(quán)限管理體系，讓需求變更的提出者钞楼，評(píng)價(jià)者喇闸，實(shí)現(xiàn)者能在同一平臺(tái)中各取所需。
》分類和分析功能。能對(duì)變更進(jìn)行自定義分類燃乍，在此基礎(chǔ)上提供相應(yīng)的查詢分析功能唆樊。
這里推薦的平臺(tái)包括：Rational的ClearQuest，開源的Mantis橘沥，免費(fèi)的BugFree等窗轩。
10.3.2 變更管理平臺(tái)的應(yīng)用要點(diǎn)
千萬不要談及變更就說變更數(shù)量，更重要的是對(duì)變更進(jìn)行分類座咆，統(tǒng)計(jì)痢艺，分析。(這也是快速軟件開發(fā)中非常強(qiáng)調(diào)的點(diǎn))
