专注昆明网站建设,南宁电商网络推广,自己创建网站教程,县城做网站的多么Eric Willeke在思考#xff1a;任务看板上的那些没有通过测试的用户故事#xff0c;该怎么处理呢#xff1f;应该把它回退到“开发”状态#xff0c;还是保留“测试中”的状态#xff1f;他提出了一些不同的方案#xff1a;● 一个方法是把开发和测试状态合并为“完成”状…Eric Willeke在思考任务看板上的那些没有通过测试的用户故事该怎么处理呢应该把它回退到“开发”状态还是保留“测试中”的状态他提出了一些不同的方案● 一个方法是把开发和测试状态合并为“完成”状态这样就不存在状态变化了。团队通过协作分解出一系列小到能分配给单个开发人员/测试人员的子任务但直到每个人都同意所有子任务都完成了这个用户故事才算完成。● 另外一种方法是把故事移到测试状态需要的话再移回去如此反复。如果这就是你日常工作中的真实情况那么你应该以此建立模型。● 还有一种方法是在某项上放置一个“缺陷”标志(或者缺陷卡片)但是在测试过程中当开发人员来帮忙修复缺陷的时候标志还会一直放在那里直到所有问题都被修复。如果这种情况更符合你的实际工作你更应该以这种方式建立模型。Thierry Henrio提出了不同的方案他从精益制造行业借鉴过来了“红卡箱”(red bins)的概念我是这么做的● 每个状态栏都准备一个专用的红卡箱 放在看板的底部靠上方● 当某个状态栏的任务出现了问题就把红卡箱移过去● 我们有30分钟解决问题消灭红卡箱这套机制对于鼓励团队高效处理问题还是很有效的。但当问题出现在上游工序那么30分钟就不够了这种方法的效果也大打折扣。专用的红卡箱相比红色标志有更加强烈的可视化效果。Ron Jeffries举了一个例子解释了在任务板上什么时候任务卡片应该流转回上游工序[...]如果任务又回到了原来的那位本应该搞定它的负责人的手上那么把任务回退到前一步工序是一个不错的建立工作模型的方法。 不管你用哪种方法Adam Sroka认为你的看板应该反映现实情况而不是一些理想状态我们要为正在采用的步骤建立模型而不是去给设想中的步骤建模这一观点是很微妙的却也非常重要。对我来说这是今年夏天我参加了David主讲的研 讨会后对看板最深刻的理解。可视化你在做的事情随后引入清晰的WIP限制不断改进等等。 对我而言看板很适用。我也有XP的背景我把流动可视化(visualizing flow)看成一种委婉的引入改变的方式。我过去常常在第一天就想做很多改变现在我意识到我可以通过帮助大家诚实地面对他们正在做的事情来轻松地做到 这一点。
