the DevOps journey (6) - 安排與設定專案的迭代

當專案啟動後，我們會用VSTS來管理專案中的每一個Features/work items，以及source code。

Source code管理的部分我猜大多數的開發人員比較熟悉，畢竟版控這幾乎是開發人員吃飯的工具，我們就暫且先不說了，主要是因為有用過TFS的開發人員肯定知道怎麼用，而VSTS在版控上的操作完全相同，因此不需贅言。

但由於最近幾次的改版之後，VSTS除了過去支援的TFVC，現在還支援GIT，因此似乎也必須稍微整理一下，如果以後有機會我再補齊，讀者可參考後面的篇幅。

因此，這一個部份我們先focus在work items在iterations中的處理。

回顧先前所提過的，敏捷開發的核心精神之一，就是把開發周期縮短成多個iterations，在Scrum中我們叫做Sprint。(其實想一想，我覺得不管是不是敏捷開發，只是要面對需求快速變更的近代軟體開發專案，都應該盡可能的切分出iterations)

前面曾經說過，這個Sprint可能是 1-4 周，一般來說我自己喜歡用2周。但這個長度完全取決於你希望專案有多透明，衝刺有多密集。

經驗上來說，2周是一個比較舒服愉快的周期，1周多半意味著Team Members和PO/PO, Stakeholders都得要上緊發條；但 3 or 4周我自己覺得有些鬆散了，比較適合人數比較多、或是整個專案時程預估會超過一年以上的開發團隊，或是長期抗戰永無休止日的軟體產品開發團隊。

要在VSTS當中設置iterations相當容易，你會發現當一個新的專案被建立起來之後，就已經建立好了預設的迭代了，只是系統還沒有幫你安上迭代的時間日期:

當你點選專案主選單的『Work』選項(上圖1)之後，會發現初始建立的專案已經有預設的Sprint1-6(上圖2)。但每一個Sprint的日期則還沒設定(上圖3)，而中央黃色區域的地方則是輸入工作項目的位置(上圖5)。

這別請特別留意，上面的『Sprint 1』這個名稱，是依照你選的流程版型Scrum而定，如果一開始你選的是Agile或CMMI，則Sprint會變成Iteration

原則上每一個迭代(Sprint)的週期應該一樣長，當專案建立好之後，你其實可以直接修改預設已經存在的迭代名稱和日期區間:

動作很簡單，請依照上圖的操作順序，最後點選(1)的Set dates，即可出現底下畫面:

在上圖中你也可以修改迭代的名稱，但重點其實是迭代的起始日期和結束日期。

如果你的迭代是兩周，開始日期可以設定周一，結束日期則設定為下周五，如上圖一般。最後按下儲存即可。

你可以點選每一個迭代，透過同樣的方式，逐一設定其日期區間:

如果你想增加迭代，或是一次性的設定多個迭代，也可以直接進入專案的管理畫面。

請在專案(注意，不是整個站台，因為一個站台可以建立多個專案)畫面的右上角，找到設定的圖示:

請點選Work頁標籤，你會發現這個畫面可以讓用戶設置每一個Sprint的週期，如同我們前面說的，可以是1-4周，而VSTS也很聰明，你設置完第一個之後，後面的Sprint在設置時，只需要設置開始時間就會幫你算出結束時間。

設置好了之後，可以點選專案名稱旁的Work選單，你會發現我們規劃好的Sprint已經出現在畫面當中了，後面接著我們就可以新增Backlog囉。

嘗試新增第一個backlogs

我們後面會再詳細一點的說明Backlogs的概念，不過我們剛建立好迭代，可以先試著建立一個Backlogs玩玩看，你會很清楚的看到迭代的價值。

想像你要做一個健康管理的醫療系統，其中有一些基本的功能，例如…透過身高體重計算BMI值、允許用戶登入、申請帳號…等。

你可以把蒐集到的需求，填寫到系統當中作為Product Backlog items，類似底下這樣:

先點選上圖中的(1)，Product Backlog Items意指開發團隊所有要進行的開發工項，接著，在上圖的(2)的位置，輸入你蒐集到的工項(需求)名稱，按下Add你即可新增，完成後類似上圖(4)。

我們前面說過，之所以要切分迭代，有很多的意義，目前我們輸入的Product Backlogs，屬於準備要做的需求，待PO/PM與客戶把優先序排定，並且梳理過每一個Backlog items的粒度大小之後，我們就可以把最優先的items用拖曳的方式放入第一個Sprint :

雖然你可能很疑惑，一個Product backlog應該要切到多細? 如何估算開發時程? Backlogs裡面要怎麼寫具體的需求? 先別急，這些我們稍後再說明，我們先來看Product Backlogs與迭代會帶來的效果。

當你把某一個Product Backlog拖曳到某一個迭代中之後，這代表著該Backlog已經交派給團隊，準備在這個迭代中進行實際的開發。這時，團隊可以在進入該迭代後，於Planning Meeting中，把該需求做工作項目(Task)的細分：

可以點選上圖(1)的地方進入某一個迭代，系統會列出屬於該迭代中的Backlogs，你可以點選上圖(2)的+符號，會跳出底下的視窗，可將該Backlog切分為更具體的工作項目(Task):

在跳出的對話視窗中，(1)的部分是輸入該Task的名稱，(2)的部分可輸入該Task的預估工時(日後可作為燃盡圖繪製的資料來源)，(3)的部分則可以視需要填寫該工項的說明。

有趣的部分來了。

將每一個工項填寫完畢之後，我們可以將這些工項(tasks)指派給開發人員(或由開發人員認領)，在指派前，請先設定該Sprint開發人員的Capacity:

可點選上圖中(1)的位置，即可進入設定Capacity的畫面，在該畫面中，您可以設定這個迭代中，您的Team Member在這個專案每天可用的開發時數(上圖2)，我們設定的是實際可用的開發時數(而非每天的工時)，因此，一般來說應該介於4-6小時之間。

一但您設定的工時，就會出現上圖(3)Work Details的長條圖，明確的顯示出了整個團隊本迭代還有多少可用時數，以及本迭代中所有預計的開發時數(也就是您剛才設置的Tasks的Hours)。

接著，請回到Backlogs的畫面，這時你可以用拖曳的方式，把tasks拖曳指派給特定的開發人員，你會發現，當你進行指派之後，不僅tasks的owner會被設定，也會看到每一位team member以集團對整體的工時狀況:

如果預估工作時數太高，團隊成員或團隊無法負荷，也會以紅色的長條圖來顯示:

是不是很吸引人?

一目了然的看到此迭代中整體專案的狀況，是一件相當賞心悅目的事情。

------------------------------
本系列文章索引位於 http://studyhost.blogspot.tw/2017/02/the-devops-journey-index.html
相關教育訓練: http://www.studyhost.tw/NewCourses/ALM 
若這篇文章對您有所幫助，請點選這裡加入FaceBook專頁按讚並追蹤，也歡迎您幫我們分享出去，謝謝您的支持。