【IT168 分析评论】

    以下是我给公司管理层的一封邮件，起因是前期产品由于没有质量控制造成严重的Data Quality问题，公司要求PM/SM找到解决方案。以前产品遗留的历史质量问题（我接手的是已经进行了4个月的项目），目前需要立即解决。同时公司还要求严格的审批流程以控制产品的提交，如何和Scrum结合？邮件内容如下：

    1．造成Data Quality的原因是：

    a) 开发人员对业务了解不准确，按照自己的想法进行开发

    b) 没有coding quality的保证，即没有人审核coding的质量

    c) 不全面的Feature review保证，即feature级别的testing

    2．目前的应急做法

    a) 进行黑盒测试，由开发部和产品部分别完成（开发系统，测试系统），以发现更多的问题，快速进行解决

    b) 研发部和产品部就Data的需求进行一次完全确认，由研发部进行白盒测试，即按照确认后的Data需求进行产生报表/统计的数据链是否有设计、实现的问题

    3．如何Manage Quality Assurance

    a) 保证需求准确传递到开发人员

    i.目前公司的开发节奏很快，需求会根据业务需要不断变化，建议每一个新的需求，由产品部出需求初稿，开发人员、Product Owner，PM、QA在一起讨论、明确，这样保证需求、测试用例、设计是一致的

    ii.由Product Owner更新需求，保证需求是最新的。目前产品部和研发部之间是通过Scrumworks来管理需求和优先级。

    b) 保证设计、开发的质量

    i.设计由负责完成的programmer完成，由项目组进行讨论、评审。参加人员至少包括设计提出者，DBA、QA、PM。

    ii.Coding quality 审核：方式可以包括Unit Testing（Junit），coding review（人工）和Bug finding（开源工具）

    c) 进行完整Feature级别的测试和完善的代码版本控制

    i.评审每一次提交版本中需求的测试用例

    ii.每日16:00开发人员提交可执行代码至CVS，由专人部署在本地的测试服务器，由QA进行功能测试。

    iii.每日上午，将前一天完成的功能通知产品部，进行Feature review，将“代码与需求不符”的风险控制在24小时之内。

    iv.每周三及周五，进行系统测试

    v.周五12:00，开发人员提交本周实现的功能代码，并在CVS上建立Branch，进行版本控制，周五下午任何的修改在此Branch上进行。撰写release notes，并将更新文件放在指定目录下。

    vi.周一上午，根据QA的测试报告和研发部主管的审批意见提交Branch上的版本。

    这样的做法和经典的Scrum做法有一些出入，但Scrum首先是建立在信任的基础上，目前项目组需要先完成高质量的项目提交，才能和公司管理层建立信任关系。公司希望通过更多的评审来控制质量，实施Scrum需要有tradeoff。同时没有用到连续集成服务，自动化测试等做法，在以后再加上吧。