日志
过程改进日记之学习Scrum2010-8-20：下周任务细分和老大的乌鸦嘴
热度 5 ||
今日晨会，从部门会议室移到老大办公室隔壁的小房间了（以后用我就称之为作战室了），里面有几张沙发，座位有限，所以剩下的人只能站着了，我没等来他们自己主动觉悟，倒是座位不够了，他们也就站着了。原来他们已经做到臀下有座位，心中无座位了，哈哈。
晨会中对这墙上的空白模版，PM讲了下大概的要求，后面我们的SQA MM（她上周休假，第一次参加Team晨会）补充了一些关于Sprint看板以及燃尽图方面的知识。
PM希望今天能够把下周所有任务都讨论、明确，更新到禅道系统中，考虑到第一次使用看板管理，本应由所有工程师自己整理任务即时帖，这次由DPM整理禅道系统中的任务，并将任务抄录到即时帖上。紧张忙碌的任务分解活动我就不表述了。
正在我遣词造句补充昨天的日志时，老大走过来，说“你再给我讲讲看板怎么用的”，晕了，随时随刻的考验又来了，这个小菜一碟，于是我们一起走到作战室，我对着墙上的模版侃侃而谈，我很是自信来着，感觉很有参谋长报告的味道。
老大质疑“我觉得我们还是少了点什么”
这也行？！这当然不行，这么经典的看板管理模式，是多少大拿卓越的实践而来的，我们多一分就是画蛇添足，少一分就是邯郸学步。当然，这种话只好先在肚子里说。我张口结舌等老大的高见。
老大一个个问：
1、“如果check Out的任务没有按期完成，Delay了，在这里能否看得到？”
2、“如果前一天的任务没有完成，那本来应该次日做的任务要不要按照计划移到 Checked Out栏”
3、“如果Checked Out栏目的工作量超出工程师能投入的时间，是把来不及做的移回 Not Checked Out，还是就始终放在Checked Out栏”
我一一回答
1、“如果Delay，目前的确看不到，我们主要看这一周能否完成。当然，如果确实需要，我们可以考虑在任务帖上加上‘Checked out Date’信息，或者用其他方法标识出来，但这样会不会违背敏捷的宗旨”
2、“如果任务没有完成，次日要看新任务和积欠的任务是否来得及在当日完成，如果来不及的话，那即使Checkout来没用的，搞不好会让Team集体焦虑。”
3、“一旦移到Checked Out栏目，无论如何都不应该移回Not Checked Out栏目，不应该有出现一个任务可以多次Check Out的情况。”
经典的东西，很多人想改，但很多人改了之后发现未必是有效的，我本着这样的想法，觉得最好什么都不要添，包括Daley的信息，或者checkout的日期。
“还是慢慢实践，慢慢观察吧，任何调整都基于对工程师行为的观察。”我搞了句真理出来对付下。
和老大达成一致，以为考验结束了。
“我们来预测下，到周末这个看板会是怎么样的”
经过细致的分工，周一有一个很好看的开局
可能
“通过N天的工作，发现有些工作延误了，又插入了若干任务，因此很多工作来不及开始，就迎来了周末。”
“这个，硝烟中的XP和Scrum已经说到的，所有可能的坏结果都被枚举到了，难道不觉得有可能Team会很好的在周五完成周一的预期？”
“这是一个预测而已……”
“好吧，其实我想的和你一样”，走出作战室的时候，我赶紧补上一句“没有一种方法是万能的，重要的是我们得去尝试，改进他。
对啊，也许在Delay的任务上画一个红点是个很不错的方法呢。不过我还是观察阵子再说吧。
有点小纠结。
PS2：写到现在，应该已经一周了，颇有些小成就感，原来的行文方式有些古板，而且看起来很是枯燥。尝试改变形式，加入些精练过的对话来说明问题。
