这是《落叶》文集里第 95 片落叶，希望你能喜欢，不为别的，只为这份坚持。
When practicing Scrum, we can make the sprint backlog visible by putting it on a Scrum task board. Team members update the task board continuously throughout the sprint; if someone thinks of a new task (“Test the snark code on Windows 8.1”), she writes a new card and puts it on the wall.
为什么先引用 Task Board 的原文解释呢？因为很多名词的释义在被翻译成中文之后，要么比较晦涩，要么就有偏差，通过原文能更精准地理解这个 Scrum 里重要的工件之一。
今天我这个老兵来理论结合实践的说说 TB 在 Scrum 里到底有什么用，后续会结合更深入的学习实践继续改进更新。
1、TB 就是指通过各种类型的载体，将 Scrum 过程中的各项事务放大并进行可视化展示，可以是物理载体，比如白板，也可以是电子实体，比如 Rally、Tower 等在线系统；
2、如上图，TB 通常包含几个状态列：
Story：当前 Sprint 需要完成的 User Story；
To-Do：已经计划并认领过的 Task，但还处于未开始状态；
In-Process：已经开始，正在进行中的任务；
To-Verify：已经完成开发工作，等待 PO 验收的任务；
Done：PO 已经完成验收，处于已完成状态的任务；
团队成员会将自己的任务便签贴在对应的状态列里，这也是每天站会前，大家同步会做的一件事；
3、我建议更新任务状态这件事，一定要由每个人自己去做，而不要由 SM 代劳。因为在做更新这个动作的时候，每个人自己对自己的进度会有一个直观上的感受，领先与别人，还是落后与别人了，这种成就感或紧迫感，如果不是亲身感受，效果会大打折扣；
4、有些团队觉得使用 TB 很麻烦，就会省略掉，我个人认为使用 TB 有几点好处，特别是使用物理白板：
透明性：
每个人的任务量和进度对整个团队都是透明的，而不会仅仅局限在部分特定的团队成员中，因为不管是什么角色的人，如果想要了解你们这个 Sprint 的状态时，只要来看一下你们的 TB 就可以了；
鞭策性：
因为任务和进度的透明化，无形中就会给每个人增加了压力，有来自内部的驱动力，当你看到自己的进度落后于人时，你会自我反省，查找原因，然后尝试改进自己的做事方法或者策略，力争将进度赶上去。也有外部压力，你也不想你的领导或其他同事每次在路过你们的 TB 时，都看到你大部分的 Task 都在 To do 和 In process 列吧。所以，物理白板能鞭策每个人提高自管理能力，做到持续改进；
5、也有些 Scrum 团队的 Task Board 会有跟本文中提及的状态列有所不同的，如下：
Story Test-Driven Development：故事测试驱动开发，指的是在开始写 User Story 的代码之前，先完成测试用例的设计，然后每部分代码，只有在通过了故事测试之后，才算完成；
Acceptance Test-Driven Development：验收测试驱动开发，指的是在开始写 User Story 的代码之前，先完成验收测试点的设计，然后每部分代码，只有在通过了验收测试之后，才算完成；
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
