敏捷的需求管理

Scrum方法和傳統(tǒng)項(xiàng)目開發(fā)方法對(duì)待需求的方式不同，傳統(tǒng)項(xiàng)目開發(fā)中，需求是在項(xiàng)目一開始就盡早細(xì)化成文的，而且是不可輕易變更的。Scrum方法中，需求細(xì)節(jié)是在開發(fā)期間持續(xù)不斷的討論出來的，而且是等到團(tuán)隊(duì)開始開發(fā)功能的時(shí)候，及時(shí)、剛好地細(xì)化這需求就可以。傳統(tǒng)項(xiàng)目開發(fā)對(duì)待需求的方式跟制造業(yè)很像，它們是必需的、不可協(xié)商的需求規(guī)格說明書，產(chǎn)品必須與之相符。這些需求事先擬定并以高度詳盡的文檔形式呈現(xiàn)給開發(fā)組，開發(fā)組會(huì)按照這些詳細(xì)的需求來開發(fā)產(chǎn)品。

當(dāng)需求不得不變化時(shí)，必須通過正式的變更控制流程來管理。因?yàn)樽兏某杀就ǔ?huì)非常高。而Scrum方法可以自由掌握、靈活相應(yīng)，Scrum視需求為業(yè)務(wù)價(jià)值的載體，利用這個(gè)載體可以達(dá)成關(guān)鍵業(yè)務(wù)目標(biāo)。例如，如果缺乏時(shí)間或者資金，可以放棄低價(jià)值的需求。如果開發(fā)過程中，外界信息（客戶、用戶、軟件購(gòu)買者等的反饋）表明某個(gè)需求的成效比低于預(yù)期，則可以從產(chǎn)品待辦列表（可以理解為待處理的需求列表）中去掉。如果有新的高價(jià)值的需求涌現(xiàn)出來，可以通過置換的方式替換掉低價(jià)值的需求為它留出空間。

因此在Scrum方法中，不會(huì)在項(xiàng)目前期事無巨細(xì)的確定所有需求并形成格式化的需求文檔，除非你百分百確定需求不會(huì)變化且你在項(xiàng)目初期就百分百確定你要做的所有功能。否則Scrum方法中不會(huì)再前期就投入大量的時(shí)間和成本去完成一個(gè)極有可能變化的需求文檔，而是創(chuàng)建一個(gè)“產(chǎn)品待辦列表（Product Backlog）”，它里面每一項(xiàng)都是一個(gè)產(chǎn)品待辦列表項(xiàng)（Product Backlog Item），產(chǎn)品待辦列表項(xiàng)即PBI一般是以用戶故事來呈現(xiàn)，每個(gè)PBI代表一個(gè)業(yè)務(wù)價(jià)值。在項(xiàng)目開始的時(shí)候，PBI的個(gè)頭比較大，相關(guān)細(xì)節(jié)可能很少。隨著時(shí)間的推移，產(chǎn)品負(fù)責(zé)人即開發(fā)團(tuán)隊(duì)圍繞這些PBI進(jìn)行一系列討論，逐漸被細(xì)化并未開發(fā)人員提供線索。

綜上，Scrum的需求收集和管理是通過需求收集（可以采用訪談、標(biāo)桿對(duì)照等工具），進(jìn)而產(chǎn)生初始的產(chǎn)品待辦列表（包括優(yōu)先級(jí)的設(shè)置）。初始的產(chǎn)品待辦列表列舉最初所知的以及理解最透徹的需求，而后會(huì)隨著產(chǎn)品及其應(yīng)用環(huán)境的改變而演進(jìn)，需要持續(xù)更新以反映出產(chǎn)品需要有什么來保持其適用性和競(jìng)爭(zhēng)力。

敏捷開發(fā)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。