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專頁按讚並追蹤,也歡迎您幫我們分享出去,謝謝您的支持。

留言

Unknown寫道…
能否請教如果一件任務的時間超出迭代中的每一位成員所能負擔的時間,也無法再投入多的資源下去, 例如無法加班,看來得兩個迭代才能完成該任務, 請問該如何調整計劃?
能否等到第一個迭代結束後,再將任務調整至第二個迭代,繼續進行,謝謝。
isDavid寫道…
一般來說,超過一個迭代的Backlog應該要被細化,如果迭代是兩周,超過一個迭代表示這個Backlog一個人做兩周無法完成。顯然這個工作粒度太大了。

而如果因為其他原因(延遲、錯估、意外)導致工作無法在這個迭代完成,那就是失敗了,如果這是重要的backlog,下一個迭代當然要繼續。

這個網誌中的熱門文章

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

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

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

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

專業的價值...