敏捷项目迭代过程中测出缺陷要不要在看板加一列Bug List?

说说我对于迭代过程中测出bug这件事的看法:先不论开发测试是不是独立团队,也不争论Scrum与看板方法(两者都是遵循精益思想),测出的bug分几种情况处理:

  1. 如果产品负责人/产品经理判断立刻要改,那么就是个阻塞项,贴红色标记,留在当前列里面不回流,不修好这个item不能称为完成
  2. 如果判断说根本不是bug,那么直接丢弃
  3. ROI不高的鸡肋,狠心丢弃(断舍离),实在太纠结就重新回到Product Backlog待办列表一列,待将来重新排期(虽然很可能再也不会改了)

为什么这么做?

“聚焦完成”,“最短时间内交付最大客户价值”的原则,而不是在看板墙上踢皮球—–交付/完成的不是功能需求,而是客户价值(流)。所以一切要以ROI及其他优先级排序因素做为指导。谁来决定排序?产品负责人PO(产品经理、业务负责人),但绝对不是开发或测试人员来排序。这也是Scrum的设计里面要明确唯一一个人来排序的原因,我想在看板方法的实践中,也一定会出现那么一个人的,不然走不下去了。

至于为什么反对再在板上加一列bug列(池)?

  1. 带来一个implicit backlog(LeSS框架中的说法)及Dark Task (这次在美国Scrum Gathering 2018和Jeff Sutherland新学的词),也可称为隐藏队列,是一种浪费,也是心智上的负担
  2. 不利于聚焦在最高客户价值的item,因为难以统一排序。

这2点都指向了empirical process的三大支柱之一: Transparency(这里透明的含义不仅是可视化,而是所有人对信息的统一共识)

最后再说两句,既然大型软件系统和人与人的协作都是复杂自适应系统(不承认这个前提的话就别聊了),那么用2维的板子(看板板、Scrum Board)来试图观察高维空间(一个组织就是一个小宇宙啊)的动态,都一定会存在观察限制和“维度坍塌”。所以,一个板子不够,就建立更多视角,或者,像管理3.0和Scrum所说的,抛回给团队,“让复杂应对复杂”吧。


觉得本文有帮助,长按二维码进行微信打赏