任務指派

好，終於可以要來指派工作了。如果是敏捷式開發團隊，通常每天早上都會有很快速的「站立會議（standing up meeting）」，這個時間點其實就很適合打開sprints 的功能來進行任務的分派。

這個看板可以讓每天的主持人來進行任務的分派，但如同筆者先前所說，我所屬的組織並不是一個敏捷式組織，通常就是校長兼撞鐘還要倒茶水掃廁所，所以這邊也只能讓我們直觀的看到User story 以及其所屬的Task而已。

現在我們就鎖定User Story #18 身為一個顧客，我想要可以維護電話號碼，我先把狀態切換成Active之後，打開該work item看看內容如下，可以看到他右下有被做了一些有關的工作，包含了Parent的Feature #16，還有子項目的#23 #22 #21，以及一個Test By #24。 測試的部分在後面驗證階段會說明到，我們先進入Task的部分，這次我們鎖定 #22，也就是修正後端API。

目前我把Task #22 已經切換到Active的狀態，因此代表這份工作指派給我，而且我今天準備開始著手進行這個項目的開發。

另外補充一下，看板會變成下面狀態，會直觀的看到Task #22 進入Active狀態。

開始工作前，請先開一個Feature branch

動手寫程式前，請先把repo clone一份到你的電腦上。

當我們的程式用Git抓下來後，首先要先做的事情就是要先開一個Feature branch。就如同第八天的文章說的，我們的Branch Policy策略是保護Develop 以及Main，而Develop 是面對測試環境，提供給使用者驗證的。

因此，我們現在獲得的Task #22，是需要基於Develop 進行開發，所以我們在Develop branch head 建立一個Feature Branch，來進行我們要做的開發動作。

到目前為止，真的可以開始工作了。

寫程式的Commit 與 Task 之間的關係

我們目前是打算把Task #22 進行開發的作業，當開發到一個階段的時候，我們都會進行Commit的動作。這邊有一件事情提醒，那就是在做Commit 的時候，要記得你的Message 最前面要把#22 給打上去。這是為了可以直接跟work item進行自動的關聯，這樣子在Task #22 上面就會直接秀出你為了這份工作的努力。

所以，所有的工作項目，都可以根據這個Commit的方式，把你的努力一份份的都刻在Task上面。

那當然最後，記得把這個Work item 狀態切換到Closed，然後就可以繼續撿下一個Task繼續進行。

寫完程式了，我們要如何讓我們的小小的努力交付給使用者測試呢？