敏捷開(kāi)發(fā)中，Product Backlog 是否足以實(shí)現(xiàn)需求管理？

 敏捷方法指導(dǎo)團(tuán)隊(duì)將產(chǎn)品需求置于Product Backlog中管理，并按照優(yōu)先級(jí)對(duì)每個(gè)產(chǎn)品需求進(jìn)行必要的排列。在計(jì)劃會(huì)(Planning Meeting)之前，由Product Owner從Product Backlog中挑選迭代周期準(zhǔn)備開(kāi)發(fā)的意向表（Willing List）進(jìn)行總體介紹，然后分配到Sprint研發(fā)過(guò)程中。以Scrum為代表的純敏捷方法，認(rèn)為首先不需要對(duì)需求做分析，因?yàn)樾枨笠恢痹谧?。所以提出了Story的概念，認(rèn)為需求就該是對(duì)需求的一種類似講故事的方式來(lái)表達(dá)的，這樣便于讓原始客戶比較清晰的對(duì)需求進(jìn)行表達(dá)，同樣開(kāi)發(fā)和測(cè)試也會(huì)逐漸以客戶的需求思維來(lái)思考自己的工作。使得大家都能在需求的層面上，進(jìn)行大腦思維。

創(chuàng)新互聯(lián)公司主打移動(dòng)網(wǎng)站、網(wǎng)站設(shè)計(jì)制作、成都做網(wǎng)站、網(wǎng)站改版、網(wǎng)絡(luò)推廣、網(wǎng)站維護(hù)、申請(qǐng)域名、等互聯(lián)網(wǎng)信息服務(wù)，為各行業(yè)提供服務(wù)。在技術(shù)實(shí)力的保障下，我們?yōu)榭蛻舫兄Z穩(wěn)定，放心的服務(wù)，根據(jù)網(wǎng)站的內(nèi)容與功能再?zèng)Q定采用什么樣的設(shè)計(jì)。最后，要實(shí)現(xiàn)符合網(wǎng)站需求的內(nèi)容、功能與設(shè)計(jì)，我們還會(huì)規(guī)劃穩(wěn)定安全的技術(shù)方案做保障。

但是敏捷方法的普遍使用中，又發(fā)現(xiàn)了純敏捷方法的局限性：

• 無(wú)法支持需求驅(qū)動(dòng)下完整的可追溯性；

• 整個(gè)團(tuán)隊(duì)完全致力于項(xiàng)目的開(kāi)發(fā)是基本前提，一旦開(kāi)發(fā)團(tuán)隊(duì)的方向出現(xiàn)變化，會(huì)導(dǎo)致項(xiàng)目的崩潰，因?yàn)樾枨罂傇谧兓?/p>

    實(shí)踐調(diào)查發(fā)現(xiàn)更多大型項(xiàng)目的成功，依賴于通過(guò)需求工作流、需求分析、和需求可追溯性的管理，在需求層面上進(jìn)行整體的項(xiàng)目規(guī)劃和控制。敏捷過(guò)程中，僅用Product Backlog，不足以滿足需求的管理。通常，一個(gè)項(xiàng)目的研發(fā)過(guò)程，通過(guò)三個(gè)空間來(lái)進(jìn)行表達(dá)：需求空間、研發(fā)空間和QA測(cè)試空間。三個(gè)空間相互間應(yīng)當(dāng)是完全整合的，使得整個(gè)團(tuán)隊(duì)的不同職能工作能夠相互協(xié)作。今天我們首先探討需求空間！

需求空間用來(lái)做什么？

    SpecDD模型中，用戶需求，在需求空間中被錄入登記。敏捷提倡客戶價(jià)值導(dǎo)向，應(yīng)當(dāng)從客戶價(jià)值角度描述，就是描述客戶如何使用，而不是描述技術(shù)層面如何實(shí)現(xiàn)。我們喜歡Story的用戶需求表達(dá)方式，但這不代表用戶需求的管理就是雜亂、隨意和無(wú)序的。產(chǎn)品負(fù)責(zé)人需要借助需求工作流、需求分析和需求可追溯性的管理，進(jìn)行產(chǎn)品需求的提煉、條目化、優(yōu)先級(jí)排序等。通過(guò)需求空間，對(duì)用戶需求形成細(xì)化和量化的SPEC。

    需求和SPEC之間常常存在多對(duì)多的關(guān)系，即一個(gè)需求可能拆分出多個(gè)SPEC，一個(gè)SPEC可能來(lái)源于多個(gè)原始的用戶需求。而實(shí)際的開(kāi)發(fā)任務(wù)和測(cè)試任務(wù)，又常常需要基于具體的SPEC來(lái)分解和分配。這樣的話，借助于需求空間的系統(tǒng)化管理，項(xiàng)目負(fù)責(zé)人能更好的對(duì)需求相關(guān)聯(lián)的產(chǎn)品功能、用戶需求、開(kāi)發(fā)任務(wù)、測(cè)試用例、產(chǎn)品缺陷等進(jìn)行全程跟蹤，實(shí)現(xiàn)需求可追溯性管理。

有了需求空間后，Product Backlog 是否被取代？在實(shí)踐中應(yīng)當(dāng)如何使用？

可以明確的回答，有了需求空間后，我們?nèi)匀恍枰狿roduct Backlog，并且Product Backlog仍將繼續(xù)扮演重要的角色。首先我們明確Product Backlog 存放的是給開(kāi)發(fā)團(tuán)隊(duì)用的需求，更多服務(wù)于開(kāi)發(fā)團(tuán)隊(duì)。如何來(lái)理解這點(diǎn)？你可能會(huì)說(shuō)，給開(kāi)發(fā)團(tuán)隊(duì)的需求當(dāng)然應(yīng)該放在Product Backlog里了。但實(shí)際項(xiàng)目進(jìn)展中，常常會(huì)遇到以下兩個(gè)實(shí)際問(wèn)題。

問(wèn)題一：需求還在設(shè)計(jì)中或整理完畢，但還未決定讓開(kāi)發(fā)團(tuán)隊(duì)去實(shí)現(xiàn)，這些需求是否需要存放在Product Backlog來(lái)管理？

回答：當(dāng)然可以，放置在Product Backlog來(lái)管理，通過(guò)特定字段或者標(biāo)題標(biāo)識(shí)加以區(qū)分就好。

評(píng)論：這樣的處理辦法，您依然可以使用Excel來(lái)管理產(chǎn)品Backlog。但隨著用戶需求的增加，或者當(dāng)項(xiàng)目很龐大的時(shí)候，您勢(shì)必會(huì)需要一臺(tái)47寸顯示器和一雙鷹般銳利的眼睛來(lái)管理Product Backlog 列表。

    SpecDD認(rèn)為，只有當(dāng)需求決定要開(kāi)發(fā)的時(shí)候，才需要有分配；有了分配后，才需要放到Backlog中。否則當(dāng)一個(gè)需求還在設(shè)計(jì)階段，或者還沒(méi)有決定是否需要開(kāi)始實(shí)施的時(shí)候，甚至都可以對(duì)開(kāi)發(fā)部門和測(cè)試部門進(jìn)行隱藏。有了這樣的改進(jìn)，能更好的控制、管理Product Backlog列表。需求一旦分配到開(kāi)發(fā)團(tuán)隊(duì)后，也就從Backlog中移除了。新的以及設(shè)計(jì)完畢的部分，可分派到開(kāi)發(fā)團(tuán)隊(duì)的待處理需求，繼而從需求空間進(jìn)入到 Product Backlog中。這樣的改進(jìn)，既能讓Product Backlog實(shí)現(xiàn)了Scrum最早的思想，又能幫助項(xiàng)目經(jīng)理從茫茫海洋中快速定位急待開(kāi)發(fā)的任務(wù)。

問(wèn)題二：一個(gè)需求包含的開(kāi)發(fā)工作較大，Sprint 1 開(kāi)始的時(shí)候，需求從Product Backlog分配出去但是在Sprint 2中，同一個(gè)需求需要繼續(xù)迭×××發(fā)，但該需求已經(jīng)不存在于Product Backlog中了，該怎么辦？

產(chǎn)品負(fù)責(zé)人：從Sprint 1中將之前的需求move到Sprint 2中？

項(xiàng)目經(jīng)理：那Sprint 1的歷史工作記錄不就失真破壞了么？

產(chǎn)品負(fù)責(zé)人：或者在ProductBacklog建立一個(gè)相同的需求，再分配到Sprint 2中？

項(xiàng)目經(jīng)理：那不就出現(xiàn)重復(fù)的需求條目了么？

     顯然這兩種想法都不是好辦法。針對(duì)這個(gè)問(wèn)題，SpecDD做了現(xiàn)實(shí)解答。SpecDD認(rèn)為，Product backlog和需求空間是相互整合的，只不過(guò)需求（Epic/Spec）并不直接從需求空間被分配到 Product Backlog或Sprint中，當(dāng)產(chǎn)品負(fù)責(zé)人決定要實(shí)現(xiàn)的時(shí)候，需求以Story的形式分配到Product Backlog中。Story是需求的一次實(shí)現(xiàn)分配。

SpecDD模型認(rèn)為，Product Backlog中不需要直接存放用戶需求，否則會(huì)使得Backlog中的任務(wù)隊(duì)列越來(lái)越多，反而影響了對(duì)于任務(wù)優(yōu)先級(jí)的排列。Backlog中的內(nèi)容應(yīng)該盡可能保持在比較少的狀態(tài)，以此避免直接把需求放到Backlog中，而是把Story和Task放到Backlog中更好。Story一旦被分配，也就從Product Backlog中移除了。一個(gè)需求，如果工作量較大，需要通過(guò)多次迭×××發(fā)，或多個(gè)團(tuán)隊(duì)共同協(xié)作來(lái)完成的話，那么就可以根據(jù)開(kāi)發(fā)情況，生成多個(gè)Story來(lái)進(jìn)行分配。當(dāng)然，您也可以把Story理解為一個(gè)指向需求的指針，即通過(guò)Story，開(kāi)發(fā)團(tuán)隊(duì)能直接查看到具體Epic/SPEC的描述信息，獲得上下游需求。分配到開(kāi)發(fā)團(tuán)隊(duì)的Story，可包含一組已分類的開(kāi)發(fā)任務(wù)，所有這些關(guān)聯(lián)派生的Story以及拆分的任務(wù)，在需求空間上，又全都能夠在Epic/SPEC條目上進(jìn)行全程跟蹤和追溯管理。從而讓項(xiàng)目負(fù)責(zé)人和管理組從需求層面上，牢牢掌控、規(guī)劃項(xiàng)目的進(jìn)度和質(zhì)量。

     通過(guò)上面一系列的討論，我們就會(huì)發(fā)現(xiàn)單純的Product Backlog 不足以實(shí)現(xiàn)需求管理。通過(guò)引入需求空間，重新定位Product Backlog的作用以及Story概念的定義等系統(tǒng)化地需求管理，將有助于團(tuán)隊(duì)決定產(chǎn)品功能的取舍，且能直接從軟件產(chǎn)品結(jié)果中進(jìn)行追蹤，也提高了可執(zhí)行產(chǎn)品的交付正確性。高效、靈活地保證了可執(zhí)行產(chǎn)品的交付，也就能讓用戶更早提出修改意見(jiàn)，從而使得項(xiàng)目整體保持良好的進(jìn)展健康度，管理層也無(wú)需擔(dān)憂由于團(tuán)隊(duì)人員變動(dòng)和流失，而讓企業(yè)找不回當(dāng)初創(chuàng)造產(chǎn)品功能時(shí)所經(jīng)歷過(guò)的團(tuán)隊(duì)討論與決定過(guò)程。