淘系技术团队的看板实践

本节所说淘系技术团队的的看板更多的是基于物理或数字的看板，在敏捷Scrum团队中，看板的使用是非常频繁的，整个淘系技术团队与看板可以说是形影不离。

从价值层面来说，看板主要是保障价值交付、提升可视化及保障过程透明，相信在Scrum模型下工作的淘系技术团队，都会有一个典型的Sprint Backlog（迭代待办事项），上面列着TO DO、DOING、DONE，如下图

需求看板示意图

Backlog里面一个典型的问题就是上面只有任务，任务除了表示谁在做什么之外，是无法提供更多信息的。那么这里就会带来如下几个问题。

（1）纯粹的交付任务无法直接体现价值

上文中曾提到过，需求是交付价值的最小单元，而需求又会包含一个或多个开发任务，因此如果在看板中仅体现开发任务，则可以明确的是，开发任务是无法直接作用于业务价值的，所以更多的应该是关注需求而不是关注任务。

（2）任务之间的耦合等待，会导致交付效率低下

淘系技术团队各个角色应该跳出自己的任务视角，更多地关注需求，通过需求交付来对齐任务之间的耦合关系，从而有效地减少任务之间的等待。这样的改变，可以让淘系技术团队关注真正的价值，即产品需求，而不是任务。但是，需求的交付需要经过从产品设计、开发到测试的完整过程，需求项目真正进行到了哪里，是否有阻塞，上下游应该在哪个时候对齐等问题依然存在。

要想解决问题，首先得看见问题，否则需求交付各阶段的各个职能之间就像是盲人摸象一样，这时候淘系技术团队需要看到需求的全貌。

全局看板可以打拉通各职能之间的协作，让彼此看得见。将需求从“选择”到“发布”几个阶段串起来，通过看板看清需求端到端的交付过程，每张卡片代表一个需求。这就像一幅作战地图一样（如下图所示），整个需求交付淘系技术团队有了一个整体的视角。淘系技术团队可以看到需求项目进行到了哪里，出现了什么问题，是什么原因导致需求阻塞不前，等等。

作战地图

接下来，针对上图中的看板做一些解释。

1）从“已选择”到“已发布”是一个需求的完整生命周期，从“开发中”到“已发布”属于需求的交付周期。

2）已选择：由业务方和淘系技术团队开发团队代表共同完成，明确要解决的问题和达到的目标之后，通过需求分析按优先级将需求放入该队列。

3）就绪待开发：开发、测试和产品共同澄清需求，并明确定义交互过程和澄清标准。

4）待测试：对于所有移交测试的需求，开发人员对照冒烟用例验收标准进行自测并通过Show Case演示环节。

5）已发布：按照业务规划和版本计划上线。