磕磕绊绊的Scrum之行(十三)第一次β版本发布的最后一英里

明天就是给内部用户部署演示B、C模块的日子。

预计12.22开始的B、C模块功能测试推迟到至今,昨天临近下班时发现还有很多缺陷。我们采用Impediment来记录正式发布之前的问题,截止到现在,一共45个,剩下最后一个未关闭项。今天让测试人员加入了验证工作。这次出现如此之多问题的原因是:

  1. 界面缺乏严格的检查标准。这个工作可以由项目经理做,也可以由测试人员来做,但关键是标准的定义不严格,开发人员功能测试通过即认为工作已完成。——这个需要多检查,也需要慢慢来磨合,提高开发人员在功能测试的要求。
  2. 功能集成太迟。虽然进行了代码的持续集成,但迟迟没有部署开发环境,每位开发人员只是本地测试。许多基础性的功能如身份验证、成员数据初始化,只采用了一些临时性的编码方案,在本周补了很多工作。
  3. 每个功能在流程上缺乏内部验收环节。这也是本次给我的一个教训了,怎样算做一个完整的功能项,backlog没有写得很细,也没有花时间去做这个工作,这导致第一次测试版本发布出来,包含很多的dead links.——连同上一项,解决措施都是尽可能早地做功能集成,加入内部验收环节。
  4. Bug.这是每个项目都避免不了的。这次很多Bug的出现还是因为技术不熟练,没有业务性的Bug.技术成熟度,只有慢慢弥补。

在接下来的工作中,我们会安排测试人员尽可能早地参与到持续集成中来,每天选择一个单元测试通过的版本进行发布、验证,我将它称之为“功能持续集成”:

#持续集成# 最近忙于一个叫“功能集成”的人肉工作,今天是最后一天。想通过这次,提炼一份《软件功能集成检查表》,并且在未来会引入功能上的持续集成,而非只是代码和单元测试。

这个角色由测试工程师担任,频率为每周,记录每次版本功能持续集成的不通过项。在TFS 2010 Scrum 1.0上,我们使用impediment来标记它,下个版本如通过,就将状态设置为close.

在项目进行的过程中,我最大的感悟就是:敏捷实在是最适合软件开发的模式,只是具体怎么做,需要团队领导具备敏锐的觉察力和应变能力。

© 2018 Silent River All Rights Reserved. 本站访客数人次 本站总访问量
Theme by hiero