Azure DevOps in Action - 使用看板管理你的需求

敏捷的概念讓我們拋開了以前複雜的規格書、以及用Word、Excel（我甚至還有看過用Power Point的），來蒐集和撰寫需求的作法。

而是把初期訪談的需求先寫成很簡單的Backlogs(可能就只有幾行文字描述的User Story)，然後就先放著，和用戶一起排好優先順序(這比較重要)，等到差不多準備開發（也就是快要將Backlog移入Approved這個Column變成SBI）的那一刻前，才跟用戶確認具體的需求內容與規格細節。

搭配Azure DevOps的看板，可以一目了然的看到當前的工作項與開發狀況：

這一篇我們來看在Azure DevOps的環境中，如何建立Backlogs來記錄需求。

在系統中，我推薦兩個地方來建立Backlogs。

第一個是底下這個畫面，他適合一次輸入大量Backlogs。我自己會讓PO，在專案啟動時，一開始跟用戶談需求的時候，用Azure DevOps底下的這個介面：

這是主選單中Boards分類裡面的『Backlogs』功能，第一次點選時，點選後會出現上面這個畫面，然後你可以選擇『+New Work Item』來建立新的工作項目，由於我們正在跟用戶蒐集新的需求，所以我們選擇『Product Backlog item』即可(上圖1)。

然後把用戶想要的功能(Wish)，填入到畫面中的文字方塊(上圖2，我知道，只有一行…而不是一大塊區塊)，然後按下『Add to Top』按鈕(上圖3)。

That’s it.

用戶可能會告訴你他需要很多功能，你就一筆一筆敲到畫面上，不需要逐筆討論細節，就先輸入進去，我們只是框一個範圍。你如果真的操作，會發現這個畫面有個好處，你直接在下圖的欄位中，輸入完用戶提的需求，直接按下Enter，又可以輸入下一筆：

不久之後，你大概可以蒐集到上百個項目(item)，或許每一個項目的顆粒度大小並不一致，先別擔心，我們後面還有時間可以整理。如此這般，我們先把每一個需求列進來即可。

如果某一個需求你真的有必要記錄一些細節，你還是可以Double-Click它，將backlog item開啟進行編輯：

在Description這個欄位(上圖1)中，你可以輸入跟這個需求有關的一些說明，可以輸入文字、貼上圖片、或是超連結…。我們後面會在更仔細地談談Backlogs的輸入，先知道這些已經足夠。

現在，我們去談需求時，只管需要把筆電帶著，到客戶端的時候，投影出來，不再用什麼Excel/Word/PowerPoint，而是與用戶面對面訪談時，直接開啟Azure DevOps上面這個畫面，並且把需求逐一輸入進去。

我知道，要你忍住不去談需求的細節，可能會有點難受。甚至你也會擔心用戶是否覺得你不夠專業(相信我，不會，只要他看到你談需求時，輸入了每一個他在意的項目。也因此，我常常用投影直接一邊談一邊輸入。)，我得再次提醒你，你必須把需求的不確定性放在心裡，現在這樣做，並非不在意用戶的需求，恰恰相反，我們在意他真正要做的需求、我們在意系統真正要實現的價值。

過去，我們蒐集了看似豐富、完整的需求，撰寫了漂亮的規格書，最後呢?規格書上的每一個需求都變了(還有一大堆是根本用不到的功能)，歷史已經證明了過去的作法不可行。敏捷用迭代面對需求的不確定性，我們先把用戶的wish list整理出來，然後跟用戶一起排好優先序，當優先序確定了，我們認真地、專注地、仔細地，跟用戶好好把接下來這一兩個迭代要開發的需求談清楚(後面我們還會介紹Acceptance Critirial)，這才是專業的表現。

對了，我剛才說還有另一個地方也可以輸入Backlogs：

你可以從主選單的Boards進入該功能，他是看板檢視模式，在看板模式中，一樣可以輸入新的Backlogs。只不過這個畫面更適合管理Backlogs的生命週期(New—>Approved—>Committed—>Done)，用來作為輸入有一點不夠便利(因為不適合連續輸入，但很適合在專案開始後，作為Demo Meeting的展示畫面，以及和用戶對談需求的顯示畫面)。

---------------------------
相關課程：http://www.studyhost.tw/NewCourses/ALM
節錄自『Azure DevOps in Action』