2017年3月19日 星期日

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
本網站不放廣告、完全免費。若這篇文章對您有所幫助,請點選這裡加入FaceBook專頁按讚並追蹤,也歡迎您幫我們分享出去,謝謝您的支持。

沒有留言: