过程改进日记之学习Scrum2010-9-15：你了解自己的任务吗？

今天早上，往公司赶的时候，收到PM的短信。说有事要晚点来。
立会的时候，看看貌似DPM还没到，老大在门口说了下，DPM临时有事请假了，一群人都有点发愣。

“好吧，那我们就开始吧，谁先上？”既然Scrum倡导自治，向大家汇报，PM和DPM都不到，刚好让大家适应下。
每个人挨个回答三个问题，PM、DPM不在，感觉疑问也少了些，大家听过算数。节奏比平常快些。

轮到某工程师MM，拿起一个任务：“今天做这个，‘切换设备，调整当前UI’”，
按照惯例，为了方便把任务信息登记到禅道中，一旦任务开始，我们会按照估算确定结束日期，我看这个任务写着1Day，习惯性和工程师确认下，“这个明天早上能展示的吧。”

通常工程师会说“尽量”、“如果顺利的话”、“应该可以”等等，这都不是问题，不过今天MM说：“不知道啊，我得先想想看这是什么意思”

这个有点晕了，理论上，经过需求分解成任务后，尽管有些人乐观过头，但大致工程师应该知道任务的目标了，可能工程师没有去看具体会涉及到哪些代码，或者里面有需要确认下的技术难点，但不太会说不知道任务是什么意思。

我看着看板，突然看到另外一个模块也有类似的任务，还在Not Check Out区域，我问负责该模块的小伙子，“你这个和她的类似，你知道什么意思吗？”
小伙子沉吟了会。说，“我觉得还是比较容易理解的，不就是在打开当前页的时候，如果把连接设备换掉，UI要提示，指引用户操作”
嗯，好像是对的，那岂不是有很多模块会面临这些场景，到底PM和DPM他们认为的到底是不是这个呢？
我继续问：“你确定指的是这个？你猜的，还是PM、或者DPM的确这样和你解释过？”
小伙子：“也没有，不过看这个意思，我有80％的把握确定是这样的。”

我很是怀疑，他至少不能确定另外20%，刚才的MM只是比他保守、或者说是严谨而已，小伙子是新员工，没有因为需求不清重新来过的悲惨体验，在我看来，属于无知者无畏的革命气概。

我回过头问所有工程师，“如果这是个实际场景的话，你们有没有人曾经听PM或DPM针对这个场景有过描述？”，大家大眼瞪小眼的互相看了下，缓缓摇头。

有点问题，我选了个比较资深的老员工，你知道具体这个场景有哪些逻辑吗？，“不太清楚”他摇摇头回答。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－

这下，问题出来了。

不管怎么样，这个都得等PM或DPM回来再确认下了，于是大家例行程序，把前天完成的任务演示后，散会。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

回来，我仔细的想了下，以前立会，有些任务，工程师通常会用最简单的，看是陈述句，实在疑问句地和PM或DPM说下，比如“这个我怎么怎么做，就可以了吧”、“工作还是比较的，就XXXXX，是不是。”
而PM、DPM还是主要的提问者，解答者，信息发布者，这样我就有个问题了
“需求故事实在执行任务的时候才明确，还是在分解任务的时候就应该已经明确了？”

回忆Sprint3计划会，以前之前的讨论，Team的做法是PM先选择需求，而后PM、DPM和工程师分解成任务，而工程师再根据任务做估算，看起来工程师参与了，但实际上，工程师在需求定义和任务分解过程中有可能仅仅是被动的信息接受者。
也就是说，可能我们做的依然是自上而下的任务布置，尤其是经验欠缺的工程师，更没有时间真正了解需求以及需求所对应的场景。因为他们不习惯在PM、DPM面前反复问问题，所以导致他们对任务也不甚了了。又觉得可能是自己没有领悟，于是他们会把思考明白的时间后延到做任务的时候。

这样显然是有问题的。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

下午，发现ＰＭ不知道啥时候到公司了，我说需要和PM沟通了，SQA MM在边上随口应了下，“刚才，PM回来过一下，就又走了，我已经把上午那个事情当面和她说了”。

“啊，为啥没叫我一起讨论啊”，我叹息。

“我看你忙着写日志啊，这个问题PM说会找那工程师MM，确保MM明确了解PM的意图。”

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

唉，这个问题的价值被低估了，我想和PM说更多，不过考虑到不具备新闻性了，也就失去了做教材的价值，只好作罢:)

 

下一次的确要考虑用户故事，哪怕把场景讲出来也好。