scrum之旅(1)--- introduction & planning meeting

项目背景：把公司现有产品的某些功能做成SDK提供服务，本项目大概持续5个月左右。

因为整个team初次采用敏捷方式进行团队管理和开发流程控制，摸着石头过河，难免遇到各种问题，打算记录这个过程中的点点滴滴，希望能和有兴趣的朋友共同探讨学习。

 

Planning Meeting For Sprint 1

上周2开了一个长达2.5h的 planning meeting ,在开会之前一周已经通过 brainstorm 搞定了 back log 和 user story , 故这个会主要任务就是提取出 sprint 1 要实现的 user story， 并把这些 user story 分解成 task。

会议刚开始我们设定了 user story 的优先级，其实也就是根据现有产品的 workflow 把 utility 的部分设定为最高优先级，因为以后所有的 component 都要基于 utility 实现，所以这些部分要先做掉吧 ，可是根据 scrum 的精神每个 sprint 都要出来一个可以工作的产品，而我们只实现最高优先级的部分是无法做到能把功能跑出来的，可是加入哪怕一个 component ，我们的时间都不够用, 开始大家打算把 utility 部分进行拆分，再分出优先级，可是拆分后发现要做的还是很多，没有时间去做一个 component 出来，最后大家决定 sprint 1就不做出来能 run 的东西了，等到 sprint review 的时候，看 log 和代码调用的结果，哈哈，汗一个。对了，说一下我们设定每个 sprint 时间长度为 3 weeks 。

划分 task 。这是个很难把握的工作，因为大家都没经验，只能参照功能的逻辑性和大家估摸着的工作量来进行划分。scrum master 说我们每个task 的工作时长不能超过 2 MD，后来划分的task 都是 12h , 因为我们规定 1 MD = 6 hour ，最后大家都笑了，每个 task 都给了能给的最多的时间，可见第一次大家都很保守啊。更令人郁闷的是，每个 task 对应的 unit test task 竟然按 1:1 的时间分配，因为每个 task 不能超过 2 MD啊，大家都知道这对于 UT 来说肯定是不够的，可是，没辙，目测每个晚上都要加班。

顺便说说 unit test 吧，这是 dev 的活，可是以前不到QA 报bug ，应该没人会去管代码质量，以前的代码质量拿出去都不会让人联想到是世界500强的公司产品的代码。scrum master 说这次一定要做好 UT，只把项目做好没什么好庆祝的，同时把UT做好才是意义重大。我们选定了 google test 和 google mock 做为 tools，还有个生成覆盖率的工具，我们的覆盖率标准是 90% ！反正这次前期对UT做了不少的准备，可惜 sprint 1给 UT task 的时间明显是不够的，而且以前大家都没搞过TDD，不可能写的代码很容易做UT，如何写好UT代码质量是个问题，而且让我一个实习生带两个老员工作负责 UT ，感觉怪怪的。

今天就写到这吧，明天周一，开工喽~