本文寫作目的

本文是為了給使用TFS看板的團(tuán)隊(duì)一個全局的、概覽式的了解，如何快速、高效地定制合適的看板才是團(tuán)隊(duì)最緊急的工作；因?yàn)槿绻粚FS看板的基本要素、原理及其功能不充分了解，對看板的過度定制只能是越走越偏，事倍功半。

TFS看板的分類

準(zhǔn)確的說，TFS看板（關(guān)于看板，有2本好書推薦《精益開發(fā)實(shí)戰(zhàn)--用看板管理大型項(xiàng)目》、《看板實(shí)踐》）依附于其所采用的模板， TFS默認(rèn)提供3種團(tuán)隊(duì)項(xiàng)目創(chuàng)建模板：Scrum， Agile及CMMI。團(tuán)隊(duì)用戶可以先不用糾結(jié)于使用哪套模板，因?yàn)檫@3套模板的基本元素類別差不太多（即指工作項(xiàng)的種類，稍許有點(diǎn)差異而已，可以類比JIRA或者其他一些開源項(xiàng)目管理工具的Issue類別，可參考官網(wǎng)的3套流程圖，基本都會覆蓋為軟件生命周期的所有的關(guān)注項(xiàng)：需求、開發(fā)任務(wù)、測試等。

另外，我們可以看名而思意，就可以了解到這3種的典型特點(diǎn)，CMMI模板不用說，是更適合CMMI模型的；Scrum是嚴(yán)格按照Scrum流程來執(zhí)行的，它的工作項(xiàng)的屬性 和工作項(xiàng)的流程都比較簡潔；第3種就是我常用的，介于Scrum極簡流程和CMMI較為復(fù)雜流程中間的那一款，且來自微軟自身的經(jīng)驗(yàn)總結(jié)（不要跟我說現(xiàn)在MS的研發(fā)流程落后了，現(xiàn)在Google和Facebook宣傳上的一些研發(fā)上好的作法都來自微軟，不信可參見《Microsoft Secrets》一書做比對；隨著時代的變遷，市場的訊息萬變，一個爆款的產(chǎn)品就可以帶來一個公司的繁榮，反之也是有可能的;所以好的研發(fā)實(shí)踐是一個IT公司永遠(yuǎn)紅和成功的必要條件，但不是充分條件）。

TFS Agile看板中的需求、Bug和任務(wù)的流程分析及應(yīng)用

工作項(xiàng)及其工作流簡介

在TFS2015的Agile看板中，需求是分多層的，一般是3層（關(guān)于標(biāo)準(zhǔn)的“用戶故事地圖”用法，請學(xué)習(xí)《用戶故事地圖》一書；關(guān)于這3層需求的名稱的叫法也有多種：Epic史詩故事、User tasks用戶任務(wù)、User activities用戶活動；Epic史詩故事、Themes主題故事、User Story用戶故事等等），這樣做的目標(biāo)是為了啥呢？看一下下面這張大家都非常熟悉的敏捷流程圖就一目了然了，是為了達(dá)成從業(yè)務(wù)目標(biāo)到產(chǎn)品實(shí)現(xiàn)需求的一致性和關(guān)聯(lián)。

敏捷開發(fā)流程圖

看板的理論及介紹

根據(jù)前面的介紹可以了解到Agile模板里的Epic、Feature、User Story、Task和Bug都有自己的工作流狀態(tài)，并且可以方便地通過查詢視圖來了解這些工作項(xiàng)里的團(tuán)隊(duì)的數(shù)據(jù)的一個情況，那么再加上“Kanban”功能，這是為什么呢？
這里不得不說一下看板的起源和作用（可參考解析精益產(chǎn)品開發(fā)（一）—— 看板開發(fā)方法）,有了下圖這樣的看板，你是不是覺得一下子就一目了然了？是不是覺得整個項(xiàng)目我們有信心把控了，因?yàn)槲覀兦迩宄⒚髅靼装卓梢钥辞宄耍?/p>

看板

• 誰在干什么
• 每個人在處理的工作
• 進(jìn)行中的工作數(shù)量

但是看板不是胡亂用的，在微軟首席講師李智樺老師的《Scrum原汁原味》中就講到,如果不遵循任何約束，就是如下圖所示的胡作非為，最終實(shí)踐出來是一定達(dá)不到敏捷效果的！

胡作非為

TFS看板的實(shí)踐

在“TFS 2015 敏捷開發(fā)實(shí)踐 – 看板的使用”實(shí)踐分享中，可以看到TFS看板的第三層需求看板，即“用戶故事”（有的翻譯成“用戶情景”）看板最終實(shí)現(xiàn)了，上文段落中介紹的對于一個有價值的看板所基于的3個原則：

• 可視化
• 限制在制品
• 管理流動

對于前2條，我們很容易明白，也能從看板的齒輪圖標(biāo)處進(jìn)行設(shè)定(具體可參見上文)，而對于第3條，如何是合適的“管理流動”，我傾向于不犧牲需求、Bug工作項(xiàng)的流程狀態(tài)定義，僅僅在“用戶故事”看板進(jìn)行定制即可，可參見下面兩組看板圖的對比（在這里，Bug工作項(xiàng)被視為和“用戶故事/用戶情景”一級的，它可以拆解成 開發(fā)任務(wù)，而不是和任務(wù)一級的）：

• 第1種映射方式：
  用工作項(xiàng)的狀態(tài)一一映射看板的列

  
  
  

  用工作流程定義看板列

優(yōu)點(diǎn)：
毫無疑問，就是看板的每一列都對應(yīng)著 看板上 需求工作項(xiàng)(這里是“用戶情景/用戶故事”)、Bug工作項(xiàng)的狀態(tài)，并且可以通過查詢視圖去查詢出來。

缺點(diǎn)：
如果要一一對應(yīng)狀態(tài)，那么需求工作項(xiàng)和Bug工作項(xiàng)的狀態(tài)必須完全一致了，可是測試團(tuán)隊(duì)對于Bug的流程定義真的是和 需求工作項(xiàng)的流程定義是一致的嗎？顯然不是，因?yàn)樵陂_發(fā)階段下，進(jìn)入分階段“開發(fā)執(zhí)行”和“開發(fā)完成”階段，Bug的真正狀態(tài)就是一個未解決狀態(tài)---即“活動”狀態(tài)，給Bug的狀態(tài)增加“開發(fā)執(zhí)行”和“開發(fā)完成”這2個狀態(tài)是毫無意義可言的；

• 第2種映射方式：
  根據(jù)階段來創(chuàng)建看板的列，保留所有工作項(xiàng)的所有原始狀態(tài)

  
  
  

  用看板的列來梳理階段

優(yōu)點(diǎn)
根據(jù)上面的闡述，可見這樣的映射方式可以最大的保留工作項(xiàng)的原始狀態(tài)，并結(jié)合整個研發(fā)過程的階段進(jìn)行流程管理；還可以和物理看板能保持最大的一致性；我們還可以去wiki百科看“Kanban (development)”的標(biāo)準(zhǔn)定義，也是在整個開發(fā)流程的角度來定義看板的列。

缺點(diǎn)
這樣的看板列如同物理看板一樣，將工作項(xiàng)視為一張張黃色小便簽條一樣隨著工作流程的進(jìn)展，而進(jìn)入不同的看板列，因此理論上是不會留下任何痕跡，因此如果想要把處于“開發(fā)”階段下，子列“開發(fā)執(zhí)行”里的Bug工作項(xiàng)通過查詢視圖方式 ，展示在主頁上，是做不到的，因?yàn)閷τ贐ug工作項(xiàng)來說，它的流程本來就是這樣子的。

• 需求團(tuán)隊(duì)關(guān)注需求流程及需求的狀態(tài)
• 測試團(tuán)隊(duì)關(guān)注測試流程及bug的狀態(tài)
• 看板提供整個團(tuán)隊(duì)的可視化流程，識別在交付過程中的阻礙，加快整個團(tuán)隊(duì)交付的流轉(zhuǎn)速度！

當(dāng)然對于第二種方式，是有一種補(bǔ)救措施的，即運(yùn)用從TFS2013起就有的對工作項(xiàng)打標(biāo)簽的功能。參加下面示例，在查詢條件中增加對標(biāo)記的查詢:

就可以實(shí)時展現(xiàn)數(shù)據(jù):

結(jié)尾感謝

本文感謝微信公眾號DevOps 和 心智工作箱，提供可靠信息資源，并激發(fā)了小編寫作的靈感，由于周末時間有限，如有紕漏之處，后續(xù)改正。