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』

留言

這個網誌中的熱門文章

使用 Airtable 在小型需求上取代傳統資料庫

使用Semantic Kernel 建立自然語言請假系統

精彩(且驚人)的Semantic Kernel入門範例

在 LINE Bot 開發中使用Semantic Kernel建立自然語言請假系統

專業的價值...