信息系統(tǒng)項(xiàng)目管理師范圍管理論文論點(diǎn)論述部分范文

項(xiàng)目范圍管理是項(xiàng)目管理中至關(guān)重要的管理知識(shí)領(lǐng)域，項(xiàng)目范圍管理主要包括：收集需求，定義范圍，制定WBS，范圍確定，范圍控制等過(guò)程。因本次嵌入式軟件委托開(kāi)發(fā)項(xiàng)目的研發(fā)規(guī)模大，項(xiàng)目建設(shè)期長(zhǎng)，需要總公司和中國(guó)受委托開(kāi)發(fā)團(tuán)隊(duì)之間的協(xié)同開(kāi)發(fā)，作為中國(guó)受托開(kāi)發(fā)的虛擬團(tuán)隊(duì)，于是就有了下面三個(gè)在范圍管理上的比較有代表性的困難。其一，在無(wú)法直接與客戶進(jìn)行F2F溝通，需求曖昧。其二，各個(gè)設(shè)計(jì)需求之間范圍影響不同，難免會(huì)產(chǎn)生前后矛盾。其三，該項(xiàng)目成果物繁多，為范圍確認(rèn)與逐一驗(yàn)收帶來(lái)了阻礙。

針對(duì)上面三個(gè)困難，在本項(xiàng)目的范圍管理各個(gè)過(guò)程中，我主要做了以下的工作。

1． 收集需求和范圍定義

因本次新追加了功能都已經(jīng)在XXXX上實(shí)現(xiàn)，其他小功能也均在從其他不同的產(chǎn)品線上實(shí)現(xiàn)功能，所以需求就是一句話，讓我們參照既有產(chǎn)品功能，然后將功能全部移植到XXXX上。但XX和XXXX機(jī)屬不同的代碼基線庫(kù)，且原理的不同，所以是無(wú)法做到100%功能移植的。這就給我方收集需求上帶來(lái)了困難。

針對(duì)上面所說(shuō)的需求分析的困難，我采取了分析產(chǎn)品，系統(tǒng)交互圖，引導(dǎo)式研討會(huì)等技術(shù)獲取和確認(rèn)需求。我從公司項(xiàng)目資產(chǎn)庫(kù)中調(diào)取了XXXX機(jī)參照功能的機(jī)能說(shuō)明書，結(jié)合測(cè)試報(bào)告書。分析完現(xiàn)有的文件后，調(diào)來(lái)了實(shí)機(jī)，和團(tuán)隊(duì)成員一起根據(jù)測(cè)試報(bào)告書，一起在實(shí)機(jī)上動(dòng)作了一下需要移植的功能，在充分理解機(jī)能以后，使用UML測(cè)試用例圖對(duì)功能進(jìn)行了建模，同時(shí)也要求對(duì)每張圖都要明確系統(tǒng)輸入和輸出。在團(tuán)隊(duì)內(nèi)部評(píng)審后，我便根據(jù)干系人登記冊(cè)的內(nèi)容，逐個(gè)功能與干洗人召開(kāi)需求討論會(huì)，在用例圖的基礎(chǔ)上討論定義的機(jī)能需求。同時(shí)重點(diǎn)說(shuō)明了經(jīng)過(guò)我方可行性分析后，因框架的差異無(wú)法移植實(shí)現(xiàn)的需求。在視頻會(huì)議上引導(dǎo)干系人聽(tīng)取我方的意見(jiàn)后，得到了干系人關(guān)于需求的詳細(xì)反饋。在稍作修改后，各個(gè)功能的需求逐漸清晰，在UML用例圖的基礎(chǔ)上，做成了需求文件列表，然后進(jìn)行了范圍定義，做成了范圍定義說(shuō)明書。在發(fā)給干系人得到了承認(rèn)后，收集需求和范圍定義的工作圓滿結(jié)束。

2． 創(chuàng)建WBS(工作分解結(jié)構(gòu))和變更設(shè)計(jì)TM

創(chuàng)建工作分解結(jié)構(gòu)是把項(xiàng)目可交付成果物和項(xiàng)目工作分解成較小的，更加易于管理的組件的過(guò)程。因本項(xiàng)目建設(shè)規(guī)模大，樹(shù)形結(jié)構(gòu)的WBS不能很好的使用，所以需求的分解使用了列表形WBS。根據(jù)項(xiàng)目的特殊性和每個(gè)需求的特點(diǎn)，我和團(tuán)隊(duì)成員一起在分解需求的同時(shí)，加上了每個(gè)需求的背景和理由并把這些內(nèi)容一并寫入并作為了項(xiàng)目的范圍基準(zhǔn)。正式進(jìn)入開(kāi)發(fā)階段后發(fā)現(xiàn)了一個(gè)問(wèn)題，各個(gè)設(shè)計(jì)需求之間范圍影響不同，有些需求在考慮設(shè)計(jì)實(shí)現(xiàn)的過(guò)程中，會(huì)產(chǎn)生前后矛盾的情況。一般情況下如果確認(rèn)了一個(gè)變更點(diǎn)之后馬上修改代碼，這樣就很可能會(huì)沒(méi)有注意到模塊之間的相互影響和對(duì)產(chǎn)品現(xiàn)有功能的影響，而造成返工。針對(duì)這個(gè)問(wèn)題，我引入了XDDP派生開(kāi)發(fā)中的變更設(shè)計(jì)TM來(lái)解決。

變更設(shè)計(jì)TM是XDDP派生開(kāi)發(fā)的重要可交付成果物，它的格式類似于需求跟蹤矩陣，每一行登陸分解后的樹(shù)狀結(jié)構(gòu)WBS，與根據(jù)矩陣不同的是每一列登陸所需要修改的源代碼文件的名字。它要求針對(duì)每一個(gè)變更內(nèi)容，不要馬上進(jìn)行修改，首先將要修改的思路根據(jù)將要修改的源文件的不同寫入到變更設(shè)計(jì)TM里面，通過(guò)自我評(píng)審和團(tuán)隊(duì)內(nèi)部評(píng)審來(lái)充分分析變更設(shè)計(jì)所產(chǎn)生的對(duì)現(xiàn)有代碼的影響范圍，在變更設(shè)計(jì)TM的做成過(guò)程中，出現(xiàn)了多個(gè)需求改同一個(gè)C源文件甚至是同一個(gè)函數(shù)的情況，通過(guò)作成變更設(shè)計(jì)TM，在未進(jìn)入編碼階段前，就清楚地看到了各需求之間相互影響，與現(xiàn)有功能的沖突部分，因?yàn)橛梅纸夂蟮腤BS定義了變更設(shè)計(jì)TM，且用該文件也較好地跟蹤了需求的實(shí)現(xiàn)情況，各個(gè)設(shè)計(jì)需求之間范圍影響而導(dǎo)致質(zhì)量下降的問(wèn)題并未出現(xiàn)在本項(xiàng)目中。

3.范圍確認(rèn)和控制

因?yàn)轫?xiàng)目周期長(zhǎng)，規(guī)模大待實(shí)現(xiàn)的功能和需要交付的成果物繁多，變更需求小而多，如果不能妥善安排項(xiàng)目的驗(yàn)收確認(rèn)過(guò)程，將會(huì)在項(xiàng)目收尾時(shí)出現(xiàn)混亂情況。針對(duì)這個(gè)問(wèn)題，我使用變更設(shè)計(jì)TM來(lái)完成需求實(shí)施情況跟蹤的同時(shí)，采用三段式驗(yàn)收方法，即阿爾法版，貝塔版和最終版來(lái)實(shí)施成果物的驗(yàn)收。因?yàn)槊總€(gè)需求變更對(duì)應(yīng)一張JIRA票，于是每完成一個(gè)需求，在將成果物記到JIRA后，要求客戶方負(fù)責(zé)人在一周內(nèi)確認(rèn)驗(yàn)收。驗(yàn)收有問(wèn)題通過(guò)JIRA聯(lián)絡(luò)。驗(yàn)收完再JIRA上打上標(biāo)簽以便日后查找。使在各個(gè)子需求子功能順利驗(yàn)收后，更新變更設(shè)計(jì)TM。然后在關(guān)鍵里程碑上再次核對(duì)成果物采取聯(lián)合驗(yàn)收，為最終項(xiàng)目的驗(yàn)收提供有效保障。

在范圍的控制上，我使用JIRA票來(lái)管理變更。將實(shí)施變更管理流程的過(guò)程和結(jié)果都分批次反映到JIRA票上。我將變更分成了三類，新增功能，既有功能變更，完善性變更(代碼重構(gòu))，并在JIRA上定義優(yōu)先級(jí)，根據(jù)優(yōu)先級(jí)高低，決定阿爾法版驗(yàn)收時(shí)間，同時(shí)在JIRA票上定義好子需求驗(yàn)收的方式。有些完善性的內(nèi)部變更，因?yàn)榭紤]到項(xiàng)目整體情況范圍蔓延和質(zhì)量鍍金等因素，和客戶方協(xié)調(diào)后更改為了次機(jī)種檢討項(xiàng)目。