内容简介：说说我对于迭代过程中测出bug这件事的看法：先不论开发测试是不是独立团队，也不争论Scrum与看板方法（两者都是遵循精益思想），测出的bug分几种情况处理：为什么这么做？“聚焦完成”，“最短时间内交付最大客户价值”的原则，而不是在看板墙上踢皮球—–交付/完成的不是功能需求，而是客户价值(流)。所以一切要以ROI及其他优先级排序因素做为指导。谁来决定排序？产品负责人PO（产品经理、业务负责人），但绝对不是开发或测试人员来排序。这也是Scrum的设计里面要明确唯一一个人来排序的原因，我想在看板方法的实践中，也
说说我对于迭代过程中测出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所说的，抛回给团队，“让复杂应对复杂”吧。
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
- 迭代器萃取与反向迭代器
- 浅谈python可迭代对象，迭代器
- 可迭代对象，迭代器(对象)，生成器(对象)
- 终于把动态规划与策略迭代、值迭代讲清楚了
- 终于把动态规划与策略迭代、值迭代讲清楚了
- 搞清楚 Python 的迭代器、可迭代对象、生成器
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
JSON 在线解析
在线 JSON 格式化工具
HTML 编码/解码
HTML 编码/解码