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

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

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

1． 收集需求和范圍定義

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

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

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

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

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

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

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

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