scrum 实施前的探雷工作

        新的一年开始了，我们的项目还没有完成，虽然在 trac 上只剩下一些低优先级的 bug ，
但显然新功能的加入只是迟早的事。领导决定让我们团队作为 scrum 的先锋体验者，如果
成功再全面推广，这对我是个振奋人心的消息。
        在开始介绍 scrum 之前，我先收集了大家对过去一年的工作小结，特别是对项目流程和
团队管理有什么不满或者建议，发信给我后做了归类汇总。然后通知项目组全职成员开会，
其他项目涉及成员作为旁听，时间允许就来参加。
        令我没想到的是我通知的项目涉及成员竟然都来了，看来他们不是憋了话要说，就是觉
得开会比工作有趣。会议开始先把大家的小结结果宣读了一番，挑起讨论。讨论刚开始时没
人发言，后来突破口出现在测试人员，他们对现在较无规律、无计划的发布测试版本很是不满
而且因为没有开发人员的讲解分析，他们每次几乎都要作系统测试，工作量很大。
         我把小结时提出的问题和讨论时提出的问题记录下来，然后开始 scrum 介绍，首先是传统
瀑布的特征和缺点，然后是 scrum 的理念、流程，期间还介绍了　TDD 和　Peer Programing
最后以买土豆的故事结尾，告诉大家 scrum是以团队为单位，团队里没有层级关系，不能消极
的等领导一步步指示也不能不做反馈的替领导作决定。
        在介绍　scrum 时并没有对之前那些问题作专门讲解，但当　scrum 流程介绍完毕大家
都表示如果按照这套流程走那些问题就可用避免了，我想这大概就是敏捷的魅力吧。
　    下午上班，准备了一下 Product backlog，人员到齐后就开始了 sprint 计划会议，因为是
试行，还没有请老板过来一起，暂时由软件部经理代替　Product Owner 的角色，由他设定需求
的优先级，确认 Product backlog。列举完需求、设定优先级后就有了第一个 Product backlog。
       下来是 Product Owner 提出 sprint 的时间线，并以此挑选出　sprint backlog　并设定优
先级，达成一致后再下来的讨论 Product Owner 可以不参加了。开发团队和测试人员一起对每个
 sprint backlog 写 user story，算是替用户分解需求，测试人员的目光集中在 user story 上就
够了，这也是测试的验收标准。
        再下来开发人员把 user story 分解成 task，分解依据是能为每个 task　估算出完成时间
并且完成时间不超过 16 小时，否则就有考虑是不是这个task 划分的不够细致还要再分解。在
划分 task 时要把实施前的准备工作，完成后的单元测试用时也考虑进去。在计划 sprint schedule
时不是简单的 task 加法，要根据每个人的能力、休假情况做预估。
        大概因为第一次要求估算 task 时间，有很多 task 大家都不敢开口，后来做了扑克牌游戏才定
下来，但有的还是不能保证完成。看来这个　sprint 计划会议开的有点急，应该先让大家认领 task，
之后留一点调研时间，然后再估算执行时间。这样虽然会让 sprint 启动稍有推迟，但得到的估算
时间更为准确，能尽早的调整 task。
        会后到下班的一段时间就留给大家作调研了，明天再统一时间，正式启动 sprint。


说今天的工作是在探雷，就是要收集大家的不满，以此作为评估 scrum 的参考点，如果 scrum
能帮团队排除这些雷，它得到大家认同的机率就大大提高。