如何在「衝刺0」建立產品待辦清單（一）

產品待辦清單（Product Backlog，也簡稱為Backlog），它是Scrum敏捷開發中的一項重要工件。在產品待辦清單中，列出的一個個項目則稱為「產品待辦項目」（Product Backlog Item， 也簡稱為Backlog Item，Item，或PBI）。

其實，產品待辦清單的概念很簡單，它主要包含了一般常見的功能性需求和非功能性需求；不過，比較特別的是，它還包含了技術團隊提出的需求，而不只是照顧到客戶的需求而已。也因此，Scrum敏捷開發特別採用了「產品待辦清單」的字眼，用來跟傳統只照顧客戶的系統需求，做字面上的分野。

不過，我們還是來看看著名的「Scrum聯盟」（Scrum Alliance）對於產品待辦清單的定義。這段英文定義參考自Scrum聯盟的網站，如下表1所示。

此處，我不打算翻譯這段英文定義，一方面讓你們有機會看到原汁原味，另一方便也避免我拙劣的翻譯讓這段定義失真了。不過，我個人對於這段定義的解讀，有幾點筆記想要跟你們分享，分述於下列的次小節中。

常見的待辦項目來源
產品待辦清單中，主要包含了一組設定了優先順序的「產品待辦項目」。請你看到圖1，常見的待辦項目來源有下列四項：



1. 功能性需求：至於，我們在前頭捕捉到的使用案例，正是此處的功能性需求。

2. 非功能性需求：如果是跟特定使用案例有關的非功能性需求，會編寫在使用案例敘述中。但是，倘若是攸關整個系統、而非特定使用案例的非功能性需求，通常不會編寫在使用案例敘述中。

3. 技術需求：傳統的需求文件中，比較少照顧到開發團隊所引發的技術需求。但是，在開發過程中，有些技術需求確實是需要花費一些時間，需要安排工時的。比方說，現行的架構中，基金系統的資料庫建置在Microsoft SQL Server 2000上頭；在新的架構中，我們打算將基金系統的資料庫搬到Microsoft SQL Server 2008上頭，諸如此類的需求比較偏向技術需求。

4. 除錯需求：另外，開發團隊還會引發修訂錯誤的需求，特別是比較嚴重、緊急或重要的錯誤。傳統在時程的壓力下，經常會忽略此類需求。

注意待辦項目的顆粒度
緊接著，我們再來看Scrum聯盟對於產品待辦項目的定義，看看是否有需要補充說明的地方，如表2所示。

從Scrum聯盟對產品待辦項目的定義，我們可以發現產品待辦項目的幾個要點，條列如下：

● 工作單元：每一個待辦項目都是一個「工作單元」（Work Unit），所以它要儘可能地明確、具體，而且執行結果最好是可以被評估的。

● 顆粒度：待辦項目的顆粒度，最好能夠掌握在一個「衝刺期」（Sprint）內可以做完。後面我們會介紹衝刺期的概念，現在你只需要知道一個衝刺期就是一個「反覆期」（Iteration），通常一個期間大約訂在2～6週左右。

● 任務：一個待辦項目可以被細分成數個「任務」（Task），由不同的成員角色所負責完成。比方說，常見會依照成員角色切分成四種任務，分別為：分析、設計、編碼、測試。

訂定優先順序
每一個產品待辦項目都會設定優先順序，而且通常由「產品負責人」負責設定。在Scrum敏捷開發中，提出了三個主要的角色，分別說明如下：

● 產品負責人（Product Owner）：其實，產品負責人這個角色有點像是客戶代表。他會站在比較接近客戶的立場，去設定產品待辦項目的優先順序，以及為團隊說明客戶的需求。

● Scrum教練（Scrum master）：顧名思義，Scrum教練必須熟知整個Scrum敏捷開發，以便能夠協助產品負責人和團隊的運作。

● 團隊（Team）：就是一般的開發團隊，通常是跨職能的組成，也就是團隊成員混合著架構師、分析師、設計師、程序員、測試員等等。

不過，如果不特別組成一個Scrum團隊，而是從傳統的團隊成員：專案經理、分析師、設計師、程序員，挑選出來兼任上述的產品負責人和Scrum教練的話，我個人的看法是：

● 分析師兼任產品負責人：分析師或許可以兼任產品負責人，主要是因為分析師最了解客戶的需求。特別是很多軟體公司是專案型的公司，而非產品型公司，在並沒有出產自家產品的情況下，很難有所謂真正熟悉產品需求的產品負責人。所以，針對這種專案型團隊，我會建議試著讓分析師兼任產品負責人。

● 專案經理兼任Scrum教練：專案經理也許可以兼任Scrum教練，或者尋找外面的顧問來扮演Scrum教練的角色。不過，專案經理若是打算自己兼任Scrum教練的話，在帶領團隊的心態上和作法上可能要有所轉變，不能再像過去只是想「管理」（manage）團隊，而是要換個角度來「協助」（assist）團隊。

衝刺待辦清單是子集
在前面的表2的最後一段，有提到：在「衝刺規劃會議」（Sprint Planning Meeting）中，會依照產品負責人所設定的優先順序，從產品待辦清單中挑選優先順序高的待辦項目，移入「衝刺期」中。

也就是說，衝刺待辦清單中的待辦項目，其實是產品待辦清單的子集。在每一次的衝刺規劃會議中，才會開會決定要處理哪些待辦項目，如圖2所示。


對了，特別注意的是，產品待辦清單中的待辦項目數量不是固定的，通常會有增減。比方說，一些重要的錯誤就不是專案一開始會出現的，經常是開發期間才會不預期地出現。當然，如果沒有特殊狀況的話，一般我們都會持續地挑選優先順序高的待辦項目，來優先處理。

對初次接觸Scrum敏捷開發的讀者，對於「衝刺期」（sprint）的概念會比較陌生。不過，如果你熟知物件導向開發中的「反覆式」（iterative）開發的概念話，就很容易懂得Scrum敏捷開發中的衝刺期了。其實，物件導向中的一個反覆，等同於Scrum敏捷開發中的一個衝刺。不過，我們在此盡量練習使用Scrum敏捷開發的術語：衝刺，少用物件導向開發的術語：反覆。


接著，我們還是來看Scrum聯盟對於「衝刺待辦清單」的定義，看看這些術語的源頭是怎麼定義，如表3所示。

從前面這份衝刺待辦清單的定義中，我們歸納了幾個要點，條列如下：

● 衝刺項目：得從產品待辦清單中，挑選出要放入衝刺期的衝刺項目。

● 衝刺目標：每一個衝刺期會設定一個主要的衝刺目標。

● 衝刺工作：衝刺待辦清單其實就是在制定衝刺期中，應該執行的工作項目。

當然，關於「衝刺」這個新朋友，我們還需要多多認識它，而後續也會有機會多多認識它的。不過，請你別著急躁、更別慌張，急躁不會讓學習效果提升的，穩扎穩打、逐步推進才會爬的高、跑的遠。好吧，就讓我們一起繼續前進吧！

案例：基金系統的產品待辦清單
還記得我們前面提到，產品待辦項目有四個主要來源，如圖3所示。但是，在專案一開始的期初，通常不會這麼快出現團隊所提出的技術需求或除錯需求。


產品待辦清單的基本欄位
而且，敏捷開發講求「增值」，重視在任何時刻下、執行的任何任務，都要對於客戶有具體且可以評量的價值。所以，我們採用基金系統的使用案例清單，做為期初的產品待辦清單，如表4所示。


產品待辦清單的細部欄位
此處，我們除了產生如表5的產品待辦清單基本表格外，還需要填寫一些細部資料，相關欄位如表6所示。

接著，我們先來解釋表6中新添加的欄位「優先順序」，其餘「初始估算」和「如何展示」則等到下一回文章繼續介紹。至於，表6中的序號和待辦項目名稱，都跟表5中的基本欄位一樣。



作者簡介：