本文写作目的
本文是为了给使用TFS看板的团队一个全局的、概览式的了解，如何快速、高效地定制合适的看板才是团队最紧急的工作；因为如果不对TFS看板的基本要素、原理及其功能不充分了解，对看板的过度定制只能是越走越偏，事倍功半。
TFS看板的分类
准确的说，TFS看板（关于看板，有2本好书推荐《精益开发实战--用看板管理大型项目》、《看板实践》）依附于其所采用的模板， TFS默认提供3种团队项目创建模板：Scrum， Agile及CMMI。团队用户可以先不用纠结于使用哪套模板，因为这3套模板的基本元素类别差不太多（即指工作项的种类，稍许有点差异而已，可以类比JIRA或者其他一些开源项目管理工具的Issue类别，可参考官网的3套流程图，基本都会覆盖为软件生命周期的所有的关注项：需求、开发任务、测试等。
另外，我们可以看名而思意，就可以了解到这3种的典型特点，CMMI模板不用说，是更适合CMMI模型的；Scrum是严格按照Scrum流程来执行的，它的工作项的属性 和工作项的流程都比较简洁；第3种就是我常用的，介于Scrum极简流程和CMMI较为复杂流程中间的那一款，且来自微软自身的经验总结（不要跟我说现在MS的研发流程落后了，现在Google和Facebook宣传上的一些研发上好的作法都来自微软，不信可参见《Microsoft Secrets》一书做比对；随着时代的变迁，市场的讯息万变，一个爆款的产品就可以带来一个公司的繁荣，反之也是有可能的;所以好的研发实践是一个IT公司永远红和成功的必要条件，但不是充分条件）。
TFS Agile看板中的需求、Bug和任务的流程分析及应用
工作项及其工作流简介
在TFS2015的Agile看板中，需求是分多层的，一般是3层（关于标准的“用户故事地图”用法，请学习《用户故事地图》一书；关于这3层需求的名称的叫法也有多种：Epic史诗故事、User tasks用户任务、User activities用户活动；Epic史诗故事、Themes主题故事、User Story用户故事等等），这样做的目标是为了啥呢？看一下下面这张大家都非常熟悉的敏捷流程图就一目了然了，是为了达成从业务目标到产品实现需求的一致性和关联。
而在微软的这套Agile模板中，这三层需求分别叫做Epic长篇故事/史诗故事、Feature特性 和 User Story用户情景/用户故事，依据上面的链接我们可以看到，Epic、Feature和User Story这3个工作项的默认工作流状态是 一样的，有4个工作状态“新建”,"活动","已解决","关闭"，外加一个“移除”状态。而Bug的默认工作流也有4个工作状态“新建”、“活动”，“已解决”，“关闭”，有的团队可能会因为测试团队的习惯会增加一些状态“延期”、“拒绝”等。
对于这些工作流及其流转状态，即使不使用看板，使用TFS Web Accesss的查询功能视图，也能很方便为团队提供所有工作项的展示和统计，比如“本周延期的bug”有多少个，针对时间、状态延期和工作项类别为bug的3个条件就能查出来结果，甚至导出到excel表格中，以供分析查看。
看板的理论及介绍
根据前面的介绍可以了解到Agile模板里的Epic、Feature、User Story、Task和Bug都有自己的工作流状态，并且可以方便地通过查询视图来了解这些工作项里的团队的数据的一个情况，那么再加上“Kanban”功能，这是为什么呢？
这里不得不说一下看板的起源和作用（可参考解析精益产品开发（一）—— 看板开发方法）,有了下图这样的看板，你是不是觉得一下子就一目了然了？是不是觉得整个项目我们有信心把控了，因为我们清清楚楚、明明白白可以看清楚了：
因此看板的最大作用是使得团队工作可视化，将信息散播给看到的每一个人，同时帮团队看到
- 谁在干什么
- 每个人在处理的工作
- 进行中的工作数量
但是看板不是胡乱用的，在微软首席讲师李智桦老师的《Scrum原汁原味》中就讲到,如果不遵循任何约束，就是如下图所示的胡作非为，最终实践出来是一定达不到敏捷效果的！
TFS看板的实践
在“TFS 2015 敏捷开发实践 – 看板的使用”实践分享中，可以看到TFS看板的第三层需求看板，即“用户故事”（有的翻译成“用户情景”）看板最终实现了，上文段落中介绍的对于一个有价值的看板所基于的3个原则：
- 可视化
- 限制在制品
- 管理流动
对于前2条，我们很容易明白，也能从看板的齿轮图标处进行设定(具体可参见上文)，而对于第3条，如何是合适的“管理流动”，我倾向于不牺牲需求、Bug工作项的流程状态定义，仅仅在“用户故事”看板进行定制即可，可参见下面两组看板图的对比（在这里，Bug工作项被视为和“用户故事/用户情景”一级的，它可以拆解成 开发任务，而不是和任务一级的）：
-
第1种映射方式：
用工作项的状态一一映射看板的列
用工作流程定义看板列
优点：
毫无疑问，就是看板的每一列都对应着 看板上 需求工作项(这里是“用户情景/用户故事”)、Bug工作项的状态，并且可以通过查询视图去查询出来。
缺点：
如果要一一对应状态，那么需求工作项和Bug工作项的状态必须完全一致了，可是测试团队对于Bug的流程定义真的是和 需求工作项的流程定义是一致的吗？显然不是，因为在开发阶段下，进入分阶段“开发执行”和“开发完成”阶段，Bug的真正状态就是一个未解决状态---即“活动”状态，给Bug的状态增加“开发执行”和“开发完成”这2个状态是毫无意义可言的；
-
第2种映射方式：
根据阶段来创建看板的列，保留所有工作项的所有原始状态
用看板的列来梳理阶段
优点
根据上面的阐述，可见这样的映射方式可以最大的保留工作项的原始状态，并结合整个研发过程的阶段进行流程管理；还可以和物理看板能保持最大的一致性；我们还可以去wiki百科看“Kanban (development)”的标准定义，也是在整个开发流程的角度来定义看板的列。
缺点
这样的看板列如同物理看板一样，将工作项视为一张张黄色小便签条一样随着工作流程的进展，而进入不同的看板列，因此理论上是不会留下任何痕迹，因此如果想要把处于“开发”阶段下，子列“开发执行”里的Bug工作项通过查询视图方式 ，展示在主页上，是做不到的，因为对于Bug工作项来说，它的流程本来就是这样子的。
但对于团队而言，这样的敏捷可定制的看板已经是可以完全替代物理看板的功能，并且对于看板本身而言，要注重的是前面阐述的三条基本原则，而不是将注意力放在统一各个分团队的分流程上。因为我们要实现的是
- 需求团队关注需求流程及需求的状态
- 测试团队关注测试流程及bug的状态
- 看板提供整个团队的可视化流程，识别在交付过程中的阻碍，加快整个团队交付的流转速度！
当然对于第二种方式，是有一种补救措施的，即运用从TFS2013起就有的对工作项打标签的功能。参加下面示例，在查询条件中增加对标记的查询:
就可以实时展现数据:
结尾感谢
本文感谢微信公众号DevOps 和 心智工作箱，提供可靠信息资源，并激发了小编写作的灵感，由于周末时间有限，如有纰漏之处，后续改正。
