第13部分(第1/4 页)

第9章　没有规矩，不成方圆（3）

阿捷点了点头，“是啊！这是我们实施Scrum以来出现的一个新问题，以前有大块的时间用于Coding，所以Review也不会像现在这么急，所以需要大家发表一下意见，看看我们有没有什么好的办法。”

“在做Sprint计划的时候，针对每个需要Review的文档或者代码，给需要Review的每个人都预留出来一定的Review时间，这样大家应该就不会紧张了。”小宝说道。

“让别人Review的时候，应该给出最晚回复时间，要不然别人也不知道紧迫性。”

“被邀请Review的人，如果不能及时Review，应该提前告诉对方。”

“最好是做一个邮件模板，把需要Review的内容，如文档或者代码的存储位置、修改原因、最迟答复时间等，都放在里面，这样信息集中。”

大家七嘴八舌地提着建议，看来这个问题还是比较容易解决的。

“好，那我们就按照上面大家提的意见试验一段时间。”阿捷总结道。

“还有一个非常关键的问题，就是关于Burndown　Chart的。大家都知道，想让这个Burndown　Chart反映出我们项目的真实状况的话，那我们每天对每个任务剩余工作量的估计，就应该准确及时。可我发现，有时候我们中总有人忘记更新，譬如在　Daily　Standup　Meeting上说某个任务已经完成了，但看Sprint　Backlog，该任务的状态还是In　Progress，还有一定的剩余时间。”

“呵呵，这好办，忘记更新的接着罚款。”阿紫这个CFO时时不忘增加收入的机会。

“有时候也不是故意不更新的，一忙就忘记了。”小宝好像不更新的次数最多，赶紧出来解释。

“要不这么着吧，我们就留三次免罚机会吧。”阿捷建议。

“每个人三次？总共才三个礼拜的Sprint，这样下来还是不能反映实际状况。”大民立刻表示反对。

“就是就是！”阿朱也表示赞同大民的意见，“要不然，咱们就给整个Team留三次免罚机会，如何？”

“这个方法可以，跟100米赛跑的规则差不多，虽然不太公平，但可行。”大民表示赞同，小宝、阿紫等人也都没有异议。

“好！这个问题也有解决方案了，看看大家，谁还有啥建议？或者还有哪里需要改进？”

大家一片沉默，看来都没有什么话题了。

“好！我们今天的成果还是挺丰富的，我下去整理一下，把我们今天讨论的这些东西跟以前的总结到一起，形成咱们自己的Scrum　Rule！那今天就到这！”

大家边走边聊，陆陆续续走出“桃花岛”。

阿紫说：“大家觉得我们下次Team　Building去哪里玩比较好？”

“我提议去打真人CS，非周末的时候，平均每人100多些。”阿捷这个CS迷，本性不改。

“我觉得去爬爬香山也不错，好久没去了！”阿朱提议。

“去后海吧！先划船，然后泡吧、杀人！”大民这个*分子，每次的提议都很奢侈。

小宝插了一句：“去打Golf吧，我都建议了好几次了！”

“好啊！好啊……你请客我们就去！”阿紫开始起哄。

大家吵吵呼呼地回到格子间，引来其他Team的一阵侧目。阿捷这个团队的传统一直就是这样，人不多，但每次开会都能听到他们的笑声。

回来的路上，阿捷顺路到产品经理李沙那里，讨论了一下关于Product　Backlog条目更改的问题。让阿捷没有想到的是，李沙认为这个问题根本不是问题，只要大家添加新条目的时候，利用ScrumWorks工具软件里面的主题功能，对每个新条目施加一个“Not　Reviewed”的主题即可，这样李沙就知道这些新条目了。但是，李沙还是重复强调，对于其他已经存在的Backlog条目，一定不能修改，特别是先后顺序。

阿捷回来重新整理了一下Scrum　Rule；　然后分发给大家。

1．每日站立例会迟到，罚款￥5。

2．对于未及时更新任务状态和剩余工作量的，整个Team留三次免罚机会，以后再有人违反，则罚款￥5。

3．对于