混合敏捷研發(fā)（二）敏捷開發(fā)中，ProductBacklog是否足以實現(xiàn)需求管理？

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

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

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

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

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

• 整個團隊完全致力于項目的開發(fā)是基本前提，一旦開發(fā)團隊的方向出現(xiàn)變化，會導(dǎo)致項目的崩潰，因為需求總在變化。

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

需求空間用來做什么？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

分享題目：混合敏捷研發(fā)（二）敏捷開發(fā)中，ProductBacklog是否足以實現(xiàn)需求管理？
路徑分享：http://www.muchs.cn/article22/ipppcc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計公司、網(wǎng)站設(shè)計、微信小程序、定制網(wǎng)站、關(guān)鍵詞優(yōu)化、品牌網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)