YY项目SCRUM试行过程观察

一、2011年2月12日决定开始在新的合同型项目中试行敏捷scrum。

二、团队情况：

产品线副经理（分管技术）：H

需求：Y、F

项目经理：C

开发人员：B、Y1、W、L、T、D

测试人员：X、W

美工：Xmm

SQA/SCM：S

三、项目情况：

系统集成方面由F负责

软件部分由H负责

前期完成了需求调研工作，H、T参与调研

四、scrum实施过程

1、2011年2月12日决定开始在软件开发阶段试行敏捷scrum；

2、前期只有H对敏捷和scrum有一些了解，X对敏捷测试和探索式测试进行了学习；

3、2月12日-18日对敏捷和敏捷测试进行了一些简单的培训，并确定从2月21日开始正式开始scrum：

角色分工：PO/SM—H，其他成员为scrum团队成员（Xmm在2月24日加入）

4、2月21日H提供了product backlog：从技术协议中提取用户需求。在提供product backlog过程中，其他成员未参加；

2月21日对product backlog进行了说明，并确定了整个scrum分为4个sprint，每个sprint周期为2周，第一个sprint时间为2011.2.21-2011.3.4；

5、 2月22日团队对第一个sprint启动了计划会议，在计划会议中团队成员从product backlog中一起讨论出了第一个sprint的backlog，并估计了每个任务的工作量（在工作量估计的过程中，如果出现工作量有异议的情况，团队讨论，并举手进行表决）。

6、 backlog任务未分优先级

7、 在估计工作量时，大家将测试的工作量也直接估计在任务中了，例如A任务估计工作量为8h，其中实际开发的工作量为6h，测试的工作量为2h（但在实际过程中却存在另一个问题，见下方）

8、 在第一个sprint中，除了项目本身的任务，还包含了一些学习的任务（因为项目团队的成员对敏捷，对XP，对TDD等都不熟悉，所以团队在试行SCRUM的同时也在各自学习相关的知识和技术）。在sprint看板中，最下一行为非项目的一些学习任务

9、 在列sprint backlog时，未记录哪个任务具体由谁认领

10、在sprint进行过程中，任务不是每个团队成员自己认领，而是由PO进行分配，根据他自己的判断，将该任务分配给相应的人员。如出现该成员已经完成一项任务时，PO会说“你可以做这个”，然后直接分配另外一项任务给该成员

11、每日立会的时间，一般为半个小时（每天在会议开始的时候轮流由一名成员讲3条新闻）

A、昨天我做了哪些工作？

B、今天我将做哪些工作？

C、在工作中遇到了哪些问题？

12、在每日立会中成员表示该任务“已经完成“，但是该任务并未进行测试验证

13、3月3日团队决定新增12个小时作为测试，直接在某张任务纸条中增加了12个小时（由于之前的任务条中没有单独描述测试的任务条，而且工作量也是包含在任务中的，在进入测试阶段时，直接在某张任务条中增加了12个小时作为测试用例编写和测试的时间，这样导致测试的工作量重复进行统计）

14、在拟定任务时，未考虑版本发布前打包和调试时间（每日构建目前还未实现），但是在后期软件提交测试时发现，在打包和调试上也花费了0.5人天的时间

15、在sprint执行过程中，随意增加新的任务，例如原型开发，之前由团队内成员进行，由于页面效果不理想，后考虑增加美工

16、项目外临时增加的任务/杂活，也直接粘贴到了“已完成”中，而未贴在“unplan”中，直接记录到了工作量中

17、Sprint后期时早期计划的大量的学习任务并未完成的情况下，直接将这些任务移到“已完成”中，并直接记为“已完成工作量“，这就导致在燃尽图中剩余工作量骤降

18、记录了sprint1计划时，估计的工作量总数，但是未记录在sprint过程中增加的工作量的情况，在sprint进行过程中，可能会出现“新增”的工作量被已完成的工作量相抵消，导致只显示剩余工作量在减少，而未体现出工作量的增加情况

19、在任务完成后期，如果出现工作量估计不足时，未单独标识需要增加的工作量（例如，A任务计划8h完成，在进行了6h剩余2h时，开发人员发现，还需要5h才能完成，任务纸条显示的是8-5，而实际该任务增加的3h其实并未能够体现出来）

20、团队中原有的专职测试人员只有2名，在sprint启动时计划团队所有人员都进行测试工作，但是实际上只有2名测试人员对即将交付的软件进行测试

21、测试之前，负责测试的成员开始编写测试用例，到发布时，真正意义上的测试时间只有2个小时（在开发过程中，测试并不了解具体的开发功能，无法编写测试用例，开发和测试脱节）