日志
过程改进日记之学习Scrum2010-9-21：调整看板，准备Sprint区间计划
热度 3 ||
每个Sprint都要寻找改进的尝试，Team每一个成员都能够感受到快速的变化，在和PM的沟通中，她对于新员工的成长的反馈是“有别于以往的经验，新员工的速度成长让人惊讶，尤其是最新的新员工，他们使用我们UI殷勤的能力居然要超过几个月前到来的次新员工。这的确是Scrum的成效，这种方式大大缩短了问题的周期。
马上Sprint3快要结束了，虽然Sprint反思会要过N天才需要执行，不过我们这边早些总结过程方面的得失，并给出一些改进方案有助于提高效率。（我姑且这么说吧，其实是否真的这样我不也不确定）
这次Sprint3，任务明确程度比Sprint2要好很多，但仍然会有个别任务拖延，一方面，这是工程师自身的工作习惯，而另一方面，也是验证机制没有被明确下来。
虽然目前要求每个任务需要明确如何验证，但在每日立会中，一方面是觉得在立会上不能展开大规模讨论，另一方面基于自治考虑，我们也不会给工程师太大压力。
这样，面对某些不确定的任务，我们还是比较容易妥协的，即由负责改任务的工程师自己来确定。
基于以上考虑。学习了网络上一些经验，我觉得可以尝试在”Checked Out”和“Done”之间增加“Verified”，这样帮助Team强化验证概念。
把我的想法说给SQA MM听，她马上接受了。“行啊，不过我们得考虑下各种Task的玩法。”
嗯，这个有道理。
- 编码任务完成后，从Checked Out移到Tobe Verified，表示编码完成，需要DEMO，或者需要测试；
- 技术研究方面，提供Testbed后，表示研究完成，可以移到Tobe Verfied，测试验证通过后，移到Done；
- UI设计也没有问题，完成设计后移动Tobe Verfied，PM确认完成、或review后移到Done；
- 测试执行活动有点问题，Checked out后，等待最终完成后移到Done，不经过Tobe Verfied状态；
- 其它文档输出类任务最简单，把文档review作为验证方法，通过后转到Done。
我们大致评估了下，觉得没有问题，虽然测试任务有点特例，不过影响并不大。
征求PM意见，和PM解释了一阵子后，PM确认：“如果你们在这个Sprint提出来这样的想法，我是不会同意的，因为我觉得我们还没有能力来分解任务，就更谈不上验证任务了，但经过Sprint3，我觉得我们有能力较好的分解任务了，所以可以考虑增加Verified的环节了”
征求PM意见，和PM解释了一阵子后，PM确认：“如果你们在这个Sprint提出来这样的想法，我是不会同意的，因为我觉得我们还没有能力来分解任务，就更谈不上验证任务了，但经过Sprint3，我觉得我们有能力较好的分解任务了，所以可以考虑增加Verified的环节了”
那就没有问题了。
然后我们针对将来Sprint4的一些其它改进做了些讨论，看来还是有很多事情的，
1、需求的头脑风暴，激发工程师对需求的理解，确保工程师知道需求的来龙去脉，在此基础上完成Sprint4目标
2、Sprint4的任务分解，工程师要有足够的资讯帮助他们自主分解任务
3、Codereview需要有一个游戏规则，这样不至于在忙的时候忘了
2、Sprint4的任务分解，工程师要有足够的资讯帮助他们自主分解任务
3、Codereview需要有一个游戏规则，这样不至于在忙的时候忘了
PM说：“看来我们需要有一个Sprint之间的工作安排表了。”
我说：“这个可以有，有一份《Scrum-Checklists-Chinese》文档，Sprint所有的活动要点都有了”
SQA MM：“我针对我们的问题整理一份Sprint3－Sprint4之间的活动列表吧。
我说：“这个可以有，有一份《Scrum-Checklists-Chinese》文档，Sprint所有的活动要点都有了”
SQA MM：“我针对我们的问题整理一份Sprint3－Sprint4之间的活动列表吧。
我们欣欣然，好同学，果然够勤快～～
PS1：增加Verified，不仅仅是看板，同时还有禅道系统需要支持，修改PHP文件，修改数据库，今天把这个搞定了，先在我测试库上看几天再说。（2010-9-25）
PS2：《Scrum-Checklists-Chinese》，我上传到论坛了，有兴趣者请下载附件http://www.step365.com/thread-2519-1-1.html
