产品待办列表的几个最佳实践
產(chǎn)品待辦列表是什么
產(chǎn)品待辦列表對應(yīng)的英文是project backlog,也有翻譯為“產(chǎn)品待辦事項(xiàng)列表”,是指為開發(fā)完善產(chǎn)品而待辦的事項(xiàng)列表。 在Scrum Guide中,產(chǎn)品待辦列表是一個(gè)排序的列表,包含所有產(chǎn)品需要的東西,也是產(chǎn)品需求變動(dòng)的唯一來源。產(chǎn)品負(fù)責(zé)人負(fù)責(zé)產(chǎn)品待辦事項(xiàng)列表的內(nèi)容、可用性和優(yōu)先級。產(chǎn)品待辦事項(xiàng)列表永遠(yuǎn)是不完全的,最初的版本只列出最初始的和眾所周知的需求。產(chǎn)品待辦事項(xiàng)列表根據(jù)產(chǎn)品和開發(fā)環(huán)境的變化而演進(jìn)。待辦事項(xiàng)列表是動(dòng)態(tài)的,它經(jīng)常發(fā)生變化以識(shí)別使產(chǎn)品合理、有競爭力和有用所必需的東西。只要產(chǎn)品存在,產(chǎn)品待辦事項(xiàng)列表就存在。產(chǎn)品待辦事項(xiàng)列表列出了所有的特性、功能、需求、改進(jìn)方法和修復(fù)等對未來發(fā)布產(chǎn)品進(jìn)行的改變。產(chǎn)品待辦事項(xiàng)列表?xiàng)l目包含描述、次序和估算的特征。
產(chǎn)品待辦列表里有什么?
產(chǎn)品待辦列表的另外一個(gè)翻譯產(chǎn)品待辦事項(xiàng)列表顯示產(chǎn)品待辦列表里應(yīng)當(dāng)包含待辦事項(xiàng)。待辦事項(xiàng)包括所有的特性、功能、需求、改進(jìn)方法和修復(fù)等對未來發(fā)布產(chǎn)品進(jìn)行的改變。常見的待辦事項(xiàng)是以用戶故事形式來表達(dá)的。
如何維護(hù)產(chǎn)品待辦列表?
在Scrum Guide中,產(chǎn)品待辦列表通常以價(jià)值、風(fēng)險(xiǎn)、優(yōu)先級和必須性排序。排在頂部的產(chǎn)品待辦列表?xiàng)l目需要立即進(jìn)行開發(fā)。排序越高,產(chǎn)品待辦列表?xiàng)l目越緊急,就越需要仔細(xì)斟酌,并且對其價(jià)值的意見越一致。排序越高的產(chǎn)品待辦列表?xiàng)l目比排序低的更清晰、更具體。根據(jù)更清晰的內(nèi)容和更詳盡的信息就能做出更準(zhǔn)確的估算。優(yōu)先級越低,細(xì)節(jié)信息越少。開發(fā)團(tuán)隊(duì)在接下來的Sprint?中將要進(jìn)行開發(fā)的產(chǎn)品待辦事項(xiàng)列表?xiàng)l目是細(xì)粒度的,已經(jīng)被分解過,因此,任何一個(gè)條目在?Sprint?的時(shí)間盒內(nèi)都可以被“完成”。開發(fā)團(tuán)隊(duì)在一個(gè)?Sprint?中可以“完成”的產(chǎn)品待辦列表?xiàng)l目被認(rèn)為是“準(zhǔn)備好的”或者“可執(zhí)行的”,能在?Sprint?計(jì)劃會(huì)議中被選擇。隨著產(chǎn)品的使用、價(jià)值的獲取以及市場的反饋,產(chǎn)品待辦列表變成了更大、更詳盡的列表。因?yàn)樾枨笥肋h(yuǎn)不會(huì)停止改變,所以產(chǎn)品待辦列表是個(gè)不斷更新的工件。業(yè)務(wù)需求、市場形勢和技術(shù)的變化都會(huì)引起產(chǎn)品待辦列表的變化。
若干個(gè)?Scrum?團(tuán)隊(duì)常常會(huì)一起開發(fā)某個(gè)產(chǎn)品。但描述下一步產(chǎn)品開發(fā)工作的產(chǎn)品待辦列表只能有一個(gè)。那么這就需要使用對產(chǎn)品待辦列表?xiàng)l目進(jìn)行分組的屬性。“產(chǎn)品代表事項(xiàng)列表優(yōu)化(英文原文是grooming)”是增添細(xì)節(jié)、估算和排序條目的舉動(dòng)。這是一個(gè)持續(xù)不斷的過程,產(chǎn)品負(fù)責(zé)人和開發(fā)團(tuán)隊(duì)協(xié)作討論產(chǎn)品代表事項(xiàng)列表?xiàng)l目的細(xì)節(jié)。在產(chǎn)品待辦事項(xiàng)列表優(yōu)化的時(shí)候,條目會(huì)被評審和修改。然而,產(chǎn)品負(fù)責(zé)人可以隨時(shí)更新產(chǎn)品待辦事項(xiàng)列表?xiàng)l目或酌情決定。
單列表的產(chǎn)品待辦列表有什么困難?
從以上文字可以推斷,Scrum Guide所說的產(chǎn)品待辦列表是一張列表,通過不斷維護(hù),排在頂部的待辦事項(xiàng)得到了分析,并拆分到足夠小的粒度,以便在一個(gè)Sprint中進(jìn)行開發(fā)。這樣做法有如下的兩大弊端: 1,早先的一個(gè)待辦事項(xiàng)可能分解成多個(gè)待辦事項(xiàng),其關(guān)聯(lián)信息難以維護(hù) 2,早先收集的信息在優(yōu)化和細(xì)化過程中可能在多次傳遞后失真樹形的產(chǎn)品待辦列表更具表現(xiàn)力
人們?yōu)榱丝朔瘟斜淼牟蛔?#xff0c;采用了樹形的產(chǎn)品待辦列表,常見形態(tài)如下: ? ? ? ?1原始需求或者史詩故事A ? ? ? ? ? ? ? ? ? ? ?1.1用戶故事或者用例A1 ? ? ? ? ? ? ? ? ? ? ?1.2用戶故事或者用例A2 ? ? ? ?2原始需求或者史詩故事B ? ? ? ? ? ? ? ? ? ? ?2.1用戶故事或者用例B1 ? ? ? ? ? ? ? ? ? ? ?2.2用戶故事或者用例B1 ? ? ? ? ? ? ? ? ? ? ? ? ?2.2.1 更細(xì)的用戶故事B11 ? ? ? ? ? ? ? ? ? ? ? ? ?2.2.2 更細(xì)的用戶故事B12這樣,原始的信息和關(guān)聯(lián)關(guān)系都得到了維護(hù)。
另外一種方式是有關(guān)聯(lián)關(guān)系的多列表,形式如下
| epic1 | userstory1 userstory2 userstory3 | 對應(yīng)于userstory1的細(xì)節(jié) 對應(yīng)于userstory2的細(xì)節(jié) 對應(yīng)于userstory3的細(xì)節(jié) |
| epic2 | userstory4 userstory5 userstory6 | ... |
| ...... | ... | ? |
長期運(yùn)維的產(chǎn)品待辦列表不再只包括待辦事項(xiàng)
對于已經(jīng)完成的待辦事項(xiàng)如何處理? 常見有兩種做法: 1,從產(chǎn)品待辦列表中移除,但是不能真的扔掉,為了產(chǎn)品的長期運(yùn)維,將其轉(zhuǎn)移組織到反映產(chǎn)品最新需求的文檔中,常見用wiki作為載體。? 2,保留在產(chǎn)品待辦列表中,進(jìn)行狀態(tài)和版本管理。第2種做法無須進(jìn)行轉(zhuǎn)移,利用條目化管理工具(比如VSTS,JIRA,Redmine,Polarion,Mantis,SharePoint等等)能方便的管理好狀態(tài)和版本。 當(dāng)某已經(jīng)完成事項(xiàng)需要修改增強(qiáng)升級時(shí),只需檢索到原條目,然后進(jìn)行修改,然后將其發(fā)布目標(biāo)版本設(shè)為最新的版本。較之第1種方法,無需搬移,而第1種方法的話,遇到修改增強(qiáng)升級時(shí),先從文檔中檢索到最新情況,然后根據(jù)最新情況撰寫待辦事項(xiàng)進(jìn)入到產(chǎn)品待辦列表,做完之后,從產(chǎn)品待辦列表中再搬移回文檔。
隨著工具的發(fā)展,第2種做法漸漸成為多數(shù)的選擇,在這種情況下,產(chǎn)品待辦列表的字面意思就不再恰當(dāng),也許改名為產(chǎn)品需求列表更為合適,或者說產(chǎn)品待辦列表是產(chǎn)品需求列表的一部分,對產(chǎn)品需求列表設(shè)立一個(gè)過濾器,查詢未完成的待辦事項(xiàng)就得到了“產(chǎn)品待辦列表”。
參考資料? 1,Scrum Guide 中文版 ?https://www.scrum.org/Scrum-Guide??
[本頁面的文字允許在知識(shí)共享 署名-相同方式共享 3.0協(xié)議和GNU自由文檔許可證下修改和再使用。]
總結(jié)
以上是生活随笔為你收集整理的产品待办列表的几个最佳实践的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 基于用例点来度量软件规模并管理进度 之结
- 下一篇: 说说软件需求说明