跌跌撞撞地敏捷之路——Story重要程度的作用

      日期：2009.03.24

      晚上加班，在不禁意间看了下背后白板上的燃尽图，这个礼拜六就要进行第二个sprint的验收演示了，可燃尽图只燃了差不多一半，而这个sprint预定要完成的增删改刷以及应用功能，目前只完成了查询与刷新。不知为什么，我突然冒出这么一句：“为什么我们的效率那么低呢？”，然后就有了下面的一段我与scrum master的对话（下面的ME就是我，SM就是scrum master，对话内容稍做了修饰，因为只记得大概）。
SM：第一个礼拜，由于公司要举办任职资格考试，大家花了不少时间在准备考试上了。
ME：嗯，那第二个礼拜呢，从严格意义上来说，我们是没有被其它突发事件打扰的，可以说算的上是一个完整的礼拜，我们做了些什么呢？
SM：查询功能。
ME：还有其它的吗？这样确实效率太低了。
SM：（走到白板旁边）让我想想。
ME：（眼睛随着SM的移动，扫到了燃尽图旁边贴着的小便签，上面写着“组件包自动部署”）啊！我还做了组件包自动部署和按实例鉴权。
SM：没错。
ME：啊！我知道原因了！在这过程中，我们没有严格按照故事的重要程度来实施开发，一开始我们确定的sprint目标是完成增删改查刷以及应用等功能，而在上个礼拜我却跑去实现组件包自动部署和按实例鉴权，而且这两个还是在开发过程中临时增加的两个task，重要程度比较低。这严重违背了scrum的原则，忽视了故事重要程度的重要性。
SM：对，我也做了些其它的活。为什么这中间没有注意到这一点呢？
ME：是啊！在每日站立会议上，我们都会汇报下昨天的进展，以及今天要做的工作。当时我应该有说要完成组件包自动部署和按实例鉴权功能的。
SM：是啊！当时我应该就不允许你这么干的！在sprint计划会议上我们确定了目标，结果实施过程中却花了不少时间做了低优先级的事情，结果导致现在无法完成既定目标，需要将部分功能遗留到下个sprint中实现。
      看到没，story重要程度是多么重要啊。虽然在sprint计划中确定好了sprint backlog中各个story的重要程度，且一开始明确了按照story重要程度先做哪个，再做哪个，可是在白板上各个story卡片上以及backlog中的story条目上都没有将这个重要程度明确标识出来，这样就无法在开发过程中给我们起到一个警示作用，我想这是导致我们会偏离重点的一个主要原因。
      按照《硝烟中Scrum和XP》中的做法，白板上的story卡片是按照story的重要程度由上往下（最高处的story最重要，最低处的story优先级最低）排列的，这样子一下子就能看出团队是否没有按照主线在开展工作。
      象上面的燃尽图（见附件），一眼就可以看出团队没有目前正在做一个优先级最低的一个story，而其它比它更重要的story一点也没有开展起来，这时scrum master就应该制止了。
我们的story好象是有按照重要程度来排story，但我们脑子里好象没有这种意识，所以卡片的先后顺序并没有给我们起到任何作用，失策！
      顺便提一下，story的重要程度是sprint计划会议之前由product owner（PO）指定的，然后在sprint计划会议中根据团队成员的生产率估算结果适当调整后确定下来的，但story重要程度的调整只能由PO来实施，其它人都不可以越俎代庖。

      在CMM中，项目周期都较长，中间你即使弹性地、穿插地完成一些需要一两天的小任务，一般不会对整个项目的交付有太大的影响，但在scrum中却大大不同，由于每个sprint都有既定的承诺、输出与交付，且每个sprint的周期都很短，象我们才三个礼拜，所以要求每个人都必须在正确的时间做正确的事，且专注高效，否则象为我们那样搞两天突发性的小任务，将可能大大的影响sprint的完成。正因如此，scrum master在sprint是个很重要的角色，他负责为团队成员培训敏捷知识、获取资源、指导团队成员的日常活动，假如在开发过程中团队成员出现任何问题，他都应该予以协调解决，出现任何错误（就象在我们的例子中）他应该立即制止、纠正。
      每日的站立会议，是用来汇报昨日工作进展、今日工作计划、遇到的困难的。从我们这个例子中可以看出，其实这个过程很重要，不能流于形式。在这个过程中，scrum master以及团队成员应该是可以从每个团队成员的汇报内容中发现他是不是在做正确的事的，如果不是应该及时提出来，以免他越走越偏，导致影响sprint的交付。