过程改进日记之学习Scrum2010-10-11：不好的实践-来自测试工程师

测试工程师不好的实践好多，围绕在质量、协调方面，给出了很多他觉得不好的地方，除了一些和集体反思一致的，比如UI更新、项目目标，其它方面主要是递交管理和缺陷管理。

表面上的原因，是我们放弃了原来非常严谨的递交系统和缺陷管理工具，转而使用了禅道来管理缺陷，递交和缺陷管理要求降低，导致质量下降。

按照DPM的说法：“系统自动编译，完了自动把安装包路径发给测试，然后工程师就觉得没事了，这个系统太爽了……，尤其是对于没有经历过完整的递交环节的新员工来说，完全不关心点击Autobuild按钮之后还有什么事情了”（点击 看大图）

下午，就这些问题讨论。

讨论一、关于开发频繁递交以及缺陷管理的问题

DPM重新讲解了Autobuild的逻辑、我们设计三种Build方式，分别是
1、基于工程师开发分支的每日定时构建（全自动）、
2、基于工程师开发分支的个人构建（开发工程师驱动，用于自测，也可以选择抄送测试验证）
3、基于递交分支的Team递交构建（DPM驱动，经过工程师自测通过后的代码从开发分支合并到递交分支上，构建后正式送测

因为很多工程师是新人，自测方面能力不够，因此，经常Build完成后选择抄送给测试验证，时间长了，导致大家习以为常地把本应自测的开发包递交给测试，导致测试任务太重，而真正的递交测试反而很少。

重新澄清后，DPM表示自己在代码检查、合并方面之前投入太少，后面应该增加这方面工作的计划性，另外，也请所有工程师，自测是项基本能力， 另外，鉴于每天工程师都会做个人构建，日构建在开发分支上价值不高，在递交分支上同样如此，因此，暂停一段时间，后面有需要再随时开启。

明确约定几条：
1.    为避免QA频繁测试工程包的问题，强调正式递交流程；
a)    在开发进行过程中，DPM根据开发进度确定正式版本递交计划，并在禅道的项目-Build上登记创建；
b)    开发人员确认自己的代码稳定、没有问题后，通知DPM；
c)    DPM进行code review，并将工程师提交的代码合并到递交分支；
d)    DPM基于递交分支进行build，版本提交测试；
e)    测试人员只接受正式递交版本进行测试，其他的非正式工程版本的测试不作为正式任务，测试人员根据任务松紧程度有选择的帮助确认；
f)    以上所有build、代码合并、递交等工作先由DPM仅仅是暂时负责，Team的开发工程师之后安排轮流负责，以便更快掌握递交流程，同时促进工程师更关注递交质量
2.    所有Bug需要在正式递交包中关闭，不能在工程包中关闭；
3.    工程包的测试需写明测试范围（功能、fixed bug）；
4.    Bug都通过禅道进行查看、管理，重要Bug可通过邮件进行重点提醒，并抄送PM，普通问题不要再通过邮件确认。

讨论二、关于项目目标和关键活动

这是二次讨论了，无疑，大家对这个都很深刻，讨论了些时间，大家觉得解决方案其实就在眼前－－看板，以前任务小的话就不写入看板了，或者对一些任务不重视，也不会分解出来。以后要识别一些规模较小，但比较重要的任务，通过看板加强管理。
明确约定几条：
1.    开发过程中涉及的非计划重要事项，一定要写到任务条中，贴到任务板上；
2.    DPM、QPM组织进行一次快速Test case（新员工学习写的）的review（应该不是今天就是明天了）

讨论三、关于协调
主要几个问题，一是开发测试沟通，二是设备不够多，大家都要用，所以经常听到的问题就是：“XXX设备在不在你这边”、“谁拿了YY设备”，“我用20分钟就够了”之类的问题，另外工程师座位隔了些距离，尤其是新员工，人越来越多，新员工的座位都是在事业部的各个部落中腾出来的。的确有些不便。

讨论了一会儿没啥主意，PM：“那就这样吧，最好的办法当然是换位置，不过这个没啥好讨论的。”

我突然发现，Scrum以来，我们开会讨论问题的效率貌似高了很多。经常说完了就闪，这个习惯真的很不错。