今天因故晚1小时上班，到公司先问SQA MM今天情况如何，答：“你自己去看吧，会吓你一跳”，看表情一定不是坏事，赶紧去看下。
!@#$%，今天的看板格外干净啊，不对吧。全体工程师打了鸡血了？还是我一觉睡了三天，居然把所有的任务都干掉了？

回到座位上，一片狐疑，问SQA MM“他们把任务条吃了？怎么我感觉和昨天的对不上啊。”
SQA MM：“你看出什么没有问题了吗？”，嗯，不至于考洒家吧，洒家看不出，不过俺每天拍照可不是为了耍宝，查下。

我晕，还真吃任务啊。

现在，大家知道我为什么要先放广告了吧

赶紧问来龙去脉，原因有二
1、原来之前某需求希望通过某第三方SDK来实现，该需求的任务分解也是基于此实现方向而定的，第一个任务就是SDK研究，并验证可行性。21日工程师确认这个方向行不通，因此，一系列相关任务被Cancel。
2、新的实现方向需要另外研究，由此派生的一些任务纳入到看板的“Next”部分。

敢情做减法效果这么明显，看来这个Sprint目标岂不是可以提前搞定了，貌似剩下的大部分都是测试任务了。

“嗯，开发工程师不应该没有任务啊，他们貌似都没有闲着啊，我相信他们一定在忙什么，只是我们没有标识出来，这不对吧”，我有些疑问
SQA MM回答：“有些人在改Bug，有些人需要安排Codereview、有些人在做新派生出的任务，在‘Unplannd’区域啊”
我觉得我发现新问题了：“对啊，接下来的大部分事情应该是测试，然后开发改bug，那这些活动在看板上怎么体现？Fix Gug占用的工作量并不会少啊”

SQA MM：“每个工程师一定会有一些bug要修复的，不可能没有bug，所以，我觉得可以预先计划需要花几天来修改bug，然后作为任务贴在看板上，这样做完所有开发任务时，就可以把‘fix bug’的任务移动到‘checked Out’区域。”

我觉得不妥：“但是，事实上在计划的时候我们并不知道有哪些bug，也就是说，我们对这个任务的范围、所需要的时间等等信息都不可知，我们不能把不可知的东西当作任务吧？这不符合Scrum框架中对任务的定义吧。”

SQA MM反驳：“看‘硝烟中的Scrum和XP‘的图示上有一个Fix的活动在UnPlanned区域，说明Fix Bug活动本身是可以做任务的，既然可以作为未计划的任务，那我们事先计划岂不是更符合现实要求，而且每个工程师都一定会有修改bug的时间，这已经是一个常识了，我们没有理由视而不见。”

我晕，“我没有视而不见，我只是认为每一个任务都有一个质量目标，Fix Bug的时间应该被包含在每一个开发任务中，我们之前经常陷入fix Bug的时间黑洞，然后Team陷入没完没了的加班和bug的讨价还价中。这是一种常态而非常识，但常态不一定是对的，也许我们能够逐渐提高fix bug活动的透明度，减少这个时间黑洞对Team的影响。”

SQA MM：“我的建议也是考虑到这个时间黑洞，从现在的情况看，指望通过每个任务的确认来保证质量，这种想法目前超越我们的整体能力的，我们可以把工程师预先估计的Fix Bug时间看做是工程师做的一个可以衡量的质量承诺。”

我对SQA清晰的观点比较赞赏，但是我还是有我其它方面的疑虑：“我不太希望给工程师留这个明显的buffer，这样，或许暗示工程师他的工作还有更多的时间，这样会影响他对于任务质量的自我要求。”

我们彼此认可对方的思考方式和描述重点，不过到底怎么实践，我们都没有完全放弃自己的观点。恰好，PM貌似有时间，于是邀请PM和我们一起讨论下。

PM认同SQA MM的实践建议，“毕竟，这种操作更容易，我们在下一个Sprint做一下尝试，不行再想办法呗，不实践也不能推导出结果。”，好吧，二比一，我接受她们的实践建议，把fix Bug当作任务贴墙上。

但是我还有一个问题：“我们还需要讨论下Fix Bug任务怎么分割？”
SQA MM：“我觉得每个用户故事，对应一个Fix Bug的任务比较合适。因为在系统中，也希望每个bug对应一个需求。”
PM的方案：“我觉得这样有点粗放，我倒是觉得跟随测试任务比较合适，也就是一个测试任务关联到一个Fix Bug。这样可以彼此验证，一方面验证测试任务是否覆盖了需求的测试，另一方面，测试－发现bug－通知开发－修改－再验证－确认是一个循环，这两个任务一定是一起关闭的”

嗯，我们都觉得PM的方案更好些，那就这样了，针对测试任务增加Fix Bug的任务。