说说我对于迭代过程中测出bug这件事的看法：先不论开发测试是不是独立团队，也不争论Scrum与看板方法（两者都是遵循精益思想），测出的bug分几种情况处理：
- 如果产品负责人/产品经理判断立刻要改，那么就是个阻塞项，贴红色标记，留在当前列里面不回流，不修好这个item不能称为完成
- 如果判断说根本不是bug，那么直接丢弃
- ROI不高的鸡肋，狠心丢弃（断舍离），实在太纠结就重新回到Product Backlog待办列表一列，待将来重新排期(虽然很可能再也不会改了)
为什么这么做？
“聚焦完成”，“最短时间内交付最大客户价值”的原则，而不是在看板墙上踢皮球—–交付/完成的不是功能需求，而是客户价值(流)。所以一切要以ROI及其他优先级排序因素做为指导。谁来决定排序？产品负责人PO（产品经理、业务负责人），但绝对不是开发或测试人员来排序。这也是Scrum的设计里面要明确唯一一个人来排序的原因，我想在看板方法的实践中，也一定会出现那么一个人的，不然走不下去了。
至于为什么反对再在板上加一列bug列(池)?
- 带来一个implicit backlog（LeSS框架中的说法）及Dark Task （这次在美国Scrum Gathering 2018和Jeff Sutherland新学的词），也可称为隐藏队列，是一种浪费，也是心智上的负担
- 不利于聚焦在最高客户价值的item，因为难以统一排序。
这2点都指向了empirical process的三大支柱之一: Transparency（这里透明的含义不仅是可视化，而是所有人对信息的统一共识）
最后再说两句，既然大型软件系统和人与人的协作都是复杂自适应系统（不承认这个前提的话就别聊了），那么用2维的板子（看板板、Scrum Board）来试图观察高维空间（一个组织就是一个小宇宙啊）的动态，都一定会存在观察限制和“维度坍塌”。所以，一个板子不够，就建立更多视角，或者，像管理3.0和Scrum所说的，抛回给团队，“让复杂应对复杂”吧。