快速高效地运用TFS2015的看板功能

本文写作目的

本文是为了给使用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用户故事等等），这样做的目标是为了啥呢？看一下下面这张大家都非常熟悉的敏捷流程图就一目了然了，是为了达成从业务目标到产品实现需求的一致性和关联。

看板
因此看板的最大作用是使得团队工作可视化，将信息散播给看到的每一个人，同时帮团队看到

• 谁在干什么
• 每个人在处理的工作
• 进行中的工作数量

但是看板不是胡乱用的，在微软首席讲师李智桦老师的《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 和 心智工作箱，提供可靠信息资源，并激发了小编写作的灵感，由于周末时间有限，如有纰漏之处，后续改正。