2. 我們如何紀錄產品的Backlog
產品的backlog是整個Scrum中的核心，也是所有東西的起源。
嗯，不，產品 backlog 並不是起源。一個好的產品開始於客戶的需求，以及如何解決它的願景。產品的 backlog 是將願景提煉成具體交付項目的結果。這個從願景轉換成 backlog 的旅程，是相當複雜的，需要用到許多技巧來填補這個差距。像是使用者故事地圖(唸一下 Jeff Patton的書，非常棒!)，精實用戶體驗，影響地圖等等。但是不要因此藉故，要做大規模的事前設計! 讓產品 backlog 像其他東西一樣，逐漸地被浮現出來。
基本上來說，它是由需求、故事或是功能等，所組成的一個依重要性排列的列表。它裡面是用客戶的術語，來描述客戶所想要的東西。
我們稱這些叫做故事(Stories)，有時候也叫做backlog項目。
我們的故事包含以下欄位：
• 編號(ID) – 一個唯一的識別號碼，號碼會自動增加。若是我們之後改變故事名稱，它可以避免我們找不到。
• 名稱(Name) – 由簡潔、有敘述性的句子來表示故事。例如： “查看交易的歷史紀錄”。它必須要夠清楚，才能讓程式設計師和產品負責人，大致了解我們講的東西是什麼，並且也可清楚區分和其它故事的差別。正常來說，大約是由2~10字所組成。
• 重要性(Importance) – 產品負責人評估故事的重要性。例如：10或是150，數字越高代表越重要。
o 企圖避免使用"優先順序(Priority)"這個說法。通常1代表最高優先順序，可是後來如果有其它更重要的事情，那它的優先順序應該要是什麼？ 要給0或是-1？
• 初始估算(Initial estimate) – 只是團隊最初對它的估算。認為與其它故事相比，完成這個故事所需要付出的代價為何。最小單位是用故事點數(story point)來表示。通常會用多少人天來約略估算。
o “如果有適當的人員來開發這個故事(不會太多也不會太少，通常是兩位)，並且把他們關到一間房間，有很多食物，然後沒有打攪。那需要幾天才能交出一個完整、可以展示、並且已經經過驗證的、可以交付的實作結果呢？”如果答案是“把三個人關在一起，大約需要4天”，則故事點數的初估值就是12。
o 重要的是，這裡並不是絕對值(也就是2個故事點數就是代表要花兩天)，而是一個相對值。(也就是說，2個故事點數所要花的時間，會是4個故事點數的一半)。
• 如何展示 (How to demo) –大略描述這個故事，在Sprint的展示會議上要如何被展示。它基本上是一個簡單的測試規格書。“先做這個，再做那個，然後這個功能就完成”。
o 如果你有實作測試驅動的開發方式(TDD) ，那麼這段說明就可以變成你驗收測試程式的虛擬碼(pseudo code) 。
• 註解(Noes) – 其他相關的資訊、解釋、參考資料等等， 一般來說都很簡短。
我們嘗試過很多欄位，但是最後發現，上面這六個欄位，是我們實際上有一直採用下去。
有兩件事情我現在幾乎以不同方式來進行。首先,沒有”重要性”這個欄位。取而代之的，我只對這個清單排序。所有的 backlog 管理工具都有拖拉排序的功能。(即使Excel和 Google 電子表格都有這功能，只要你知道它神秘的加速鍵為何) 這樣比較簡單又快速。其次，沒有人天。評估是用故事點數, 或是T-shirt size (S/M/L)來表示，或是都不做評估。但是後者比較多。
通常我們會把它存放在共享的Excel中 (這樣可以多個使用者，同時去編輯它)。依官方說法，產品負責人擁有和負責這份文件，但是我們並不想讓其他人不能接觸它。因為很多時候，測試開發人員需要查詢這份文件，以釐清一些事情，或是改變原先的估算。
同理，我們並沒有把它放在版本控制工具的資料庫中。相反的，我們把它放到共用的檔案夾中。這樣是最簡單方法，可以避免在同時編輯下，造成lock或是merge的問題。
但是，大部分其他文件，我們都有還是有保留在版本控制工具的資料庫中。
Excel，哈? 喔，那已經是過去的日子了。我現在已經不會再考慮使用 Excel 來管理 backlog，除非它是一個不確定的版本。產品 backlog 需要以線上文件的方式存在，好讓每個人可以同時存取和容易修改。可以從眾多的 backlog 管理工具中找個來用 (Trello， LeanKit 和 Jira 都很流行)，或者 Google 的電子表單也可以 (非常務實！)。
故事中其他的欄位
有時候我們會使用其他欄位，方便讓產品負責人來判斷優先順序。
• 軌道(Track) – 對這故事的簡單分類，像是：“後端系統”、或是“最佳化”。產品負責人可以容易過濾出，屬於“最佳化”種類的故事出來，然後把他們的優先順序設定比較低。
• 元件(Components) – 通常會利用Excel中的checkboxes來實現。例如：“database，server，client”。這裡整個團隊或是產品負責人，可以標示哪個技術元件可以用來實作這個故事。當你有多個Scrum團隊時，這是非常有用的一個技巧。像是，後端系統的團隊，客戶端系統的團隊，可以很方便讓每個團隊知道，他們需要實作哪些故事。
• 請求者 (Requestor) – 產品負責人可以記錄，起初是哪個客戶，或是關係厲害人提出這項需求，以方便日後回報目前處理的進度。
• 錯誤追蹤代碼 (Bug tracking ID) – 如果你有錯誤追蹤系統，像是我們用Jira一樣，方便讓你追蹤故事和錯誤案例之間的關連。
如何讓我們的產品Backlog保留在商業應用層次
如果產品負責人有技術的背景，那他可以添加一個故事：“把Event表格增加索引”。為什麼他需要這個呢？背後真正的原因，可能是希望在後端系統中，加快搜尋事件表單的反應速度。
但也有可能完全並不是那麼回事，表單變慢的瓶頸不見得是索引的問題。所以產品負責人還是只關注在商業的需求上面，而開發團隊才是解決這些技術問題的合適人選。
當我看到一些技術導向的故事出現，我一般都會問產品負責人，一些“但是為什麼呢？(but why)”的問題，直到我們真正了解潛在的目地為止。然後才用真正的目的，來改寫這個故事(加快後端系統中，搜尋事件表單的反應速度)。原先技術導向的敘述只會放在註解中以供參考 ("對event表格增加索引可能會解決這個問題")。
有一個古老但是行之有年的樣板：”身為 X 角色，我想要 Y，所以 Z。”例如“身為一個購物者，我想要儲存我的購物車內容，所以我明天可以繼續購物。”我很驚訝我在 2007 年時沒有知道這個！如果有知道就太方便了。是的，現今已經有很多精心設計的樣板，但是這個簡易的做法是一個很好起始點，特別是當團隊還對敏捷不熟悉時。這個樣板可以迫使你問些正確的問題，並且減少你陷在技術細節的風險裡。
全站熱搜
留言列表
