Sprint会议和关键任务

昨天没写，是因为昨天的故事在今天才有个结果

昨天的晨会中有个框架调试的任务没有搞定，而这个任务的成果恰恰是多个工程师任务验证的一个依赖条件，因此，导致昨天乃至前天的部分任务没有能够验证。

今天的晨会，大家心情都很愉快，因为这个阻塞任务可以移到Done区域了，很多相关任务也都可以验证完成了，按照平均每天搞定6Day的任务计算，昨天阻塞任务Done后，今天晨会一下子转移了11Day的任务后。燃尽图的趋势向理想趋势靠拢，这无疑是让大家都比较开心的。

 

这里有两个反思

正如我在8.27的日志（点击链接《下一阶段任务分解》中所说的，是PM、DPM和工程师一个个分解需求、细化任务的，这样的好处是节约时间，每个人都可以把注意力集中在自己的任务中。效率更高。

然这样做工程师彼此之间的工作了解是不够的，我们也考虑到这方面的欠缺，不过我们从自身的经验出发，觉得PM、DPM对各模块间关联的具体情况非常了解，可以弥补工程师彼此间计划阶段沟通不充分所带来的风险，但从这次实践来看，我们的前提并没有达到。

这次的实际问题是某个框架调整任务没有按时完成，而其他很多任务的验证都是基于该框架调整完成的基础，计划的时候也考虑到这种依赖关系，但对于该任务需要消耗的时间估计比较乐观，没有设置buffer，而结果是此任务耽误了一天，相关的一堆任务在框架完成后都得到了验证通过，实际上，这次并没有出现什么资源浪费。

Scrum经典要求是Sprint计划要大家共同参与，我们明白这个道理，但还是把他裁剪成一个个沟通确认，这是我们认知上觉得这样可接受，值得让我高兴的事情，现在我们以最小的代价让Team接受Sprint一起开的重要性，真是塞翁失马焉知非福。

我们今天晨会达成一直，今后一个个讨论完任务后，集中花一段时间把所有需求和任务讲述一次，让所有项目人员来共同确认。

 

传统项目计划中，关键任务是很重要组成部分，由关键任务组成的关键路径是对项目周期估算的重要证据。

而在经典Scrum的任务看板上，从一个Sprint到下一个Sprint，虽然路线非常清晰，但在同一个Sprint内，虽然理论上所有任务都应该完成，所有Backlog都需要搞定，但我们未必真的能够理想的完成所有任务，在不能百分比完成的情况下我们要尽可能好的结果，也就是说我们需要定义一个Sprint中把最重要的任务，以确保这些任务获得更多的关注。
在《轻松Scrum之旅》这本书上的附页上，有一张任务板的实例图，这张纸加膜了，照相不清楚，干脆自己照原版的样子画了张

和经典Scrum看板不同的是，此图增加了“被阻塞”的任务，这可以更方便的让人关注，我无从得知所谓“被阻塞”的标准是什么，是否是超过预期天数的未完成任务（比如超过2天以上）？或者是被2个以上任务共同依赖的未完成任务？或者其它我想象不到的标准……

无论哪些标准，我觉得，被阻塞是一种事后加强补救的措施，能不能转化成事前加强预防的任务呢？

这个貌似比较难，我不确定在Scrum任务中，再增加彼此的依赖关系会不会违背敏捷原则，这个需要继续观察。

我现在可以继续尝试的，是在我们公认觉得被阻塞的任务上加上一个红色的圈圈，这样可以更醒目些，当然，前提是这些情况不要太多，不然的话这个Sprint基本上也失败了。