昨天那篇打太長了，本來想切成兩篇，但是我又認為整件事情又該一起說，所以就還是把整篇變的落落長。
今天就來講稍微可以切開的一些的部分，或是初始的一些設定的地方。
這裡就是一個讓你可以下Query的地方，讓你把整個Board的資訊，可以根據你的條件，做出你要的東西。看起來有一點無聊，但其實這功能可以做出來的花招非常的多，舉一個例子如下：
上圖我做了一個條件，就是我要把所有的Issue，而且還沒有Closed的部分篩選出來。管理目的可以看成，我想要有一個地方來確認，所有的還沒有被完成的討論。
然後，假設我們很注重所有的Issue，因此基於管理的需求，我們就把他放到wiki中，並且在專案首頁就呈現出來，就會如下：
這裡說一下Proccess，如同我之前所述，我們目前內部是選擇用Agile為基本來做專案管理，但其實既然叫做Proccess，那表示是包含所有workitem的流程的。
但既然是流程，每個企業都會有自己專屬的一個流程，這邊是一個很棒的功能，可以基於他現有的Base proccess 去建立自己的proccess。像下圖，就是我使用Agile proccess為基礎，開一個新的proccess，我們就用這一個來做一些客製。
我這次做的流程名稱叫做MyAgile，下面用這個流程來做一個客製化的user story。
每個組織都會有客製化的需求，這是很正常的。所以在不同的workitem中會有不同的欄位的需求，這也是可以做到的，例如下圖：
會發現這個user story 中新增了一個欄位，叫做測試內容與回報。這就可以根據每個組織對於表單內容是否要新增相關的欄位。
設定的方式就是在自己的proccess中，針對user story 的表單去進行客製化的動作，就可以定義出新的表單。
表單可以客製，狀態的項目也可以客製，目前User Story 預設狀態如下，其實基本上就不脫離起單->處理中->結束或移除。
那因為管理的考量，例如我們可以藉由更細節的狀態欄位來區別，我們就有可能在報表中更精準的呈現工作項目的整體資訊。下圖我就在我的user story新增一個叫做交付測試的狀態，分類就放在In Progress中。
如此一來，我們回到表單去看，就會發現state多了一個叫做交付測試的狀態可以選擇，而且所有的流程變更，都會被記錄下來。
這次在寫這篇文章，突然發現了Rule也是一個有趣的東西，如果管理上有需求，就可以考慮在這裡建立。這功能就是例如，一個工作項目要進入某狀態時，可以針對該表單做一些邏輯判斷，然後做出對應的判斷。
這次我做了一個假設，如果表單狀態要變更成Resolved，那測試內容與回報這個欄位，那個欄位一定要有資訊才可以。所以我作了以下設定：
好，在來到user story 表單中驗證看看，會發現狀態無法切換成resolved，上面還會出現警告字樣。
這個功能我目前可以想到用處就是，如果今天我們有一些必填的欄位，一定要在進入某狀態時，就要有資訊，這樣就可以有效的要求填寫者要完善這個欄位。
事前的需求與釐清，可以防止碼農作白工。完善的流程規劃，可以防止事後被稽核人員關切(應該啦）
iThome鐵人賽
看影片追技術