TFS团队的敏捷转变:向三周一个Sprint进军
Buck Hodges认为,过长的发布周期导致TFS(Team Foundation Server)团队养成了不良的开发习惯,然而光靠生搬硬套sprint来缩短发布周期是不够的,还需要配合其他一些软件计划和软件开发方面的改进。
起初,TFS要好几年才发布一次。微软的Buck Hodges说,这曾让TFS的开发人员养成了不良的习惯。当交付日期来临,开发人员则往往将没有完成的功能赶鸭子上架。开发人员认为,与其让某个功能等两三年再上线,不如在漫长的维护阶段再去修复遗留的缺陷。于是,TFS带着两千多个缺陷上线就成了司空见惯的事了。
另一个问题是因特网的时效性。享受在线服务的用户往往想要获得及时有效的更新,一旦硬是让他们等着打补丁,他们很容易感到失望。所以在计划TFS网络版时,如果告诉客户要等几年才能有个更新版本出来,那绝对是痴人说梦。(注:网络版刚刚通过了beta测试,现在名为 Team Foundation Service。)
计划
发布周期短并不意味着缺乏方向。TFS研发工程师会从一块标有未来18个月他们大致要完成的工作的故事板开始入手,随后分解出六个月的主干计划,并将集中开发此计划中的某个选定的应用程序模块。
TFS团队由130名成员。他们被分成多个功能组,各组负责各大领域,如版本控制、工作项跟踪、自动化构建等。每组由12名成员组成(6名研发工程师,5名测试工程师以及1到2名项目经理),各自为政,管理自己的功能待办事项列表。
为了确保市场需求和工程研发不冲突,很多功能可能已经发布到了TFS但并未被启用。这有利于进一步测试,也能把功能积攒起来,发布一个大版本。
Scrum
从TFS 2012开始,团队就开始使用Scrum。他们的Scrum采用三周为一个Sprint。他们觉得短一点的周期相对更有利于全局掌控,而较长的周期很难让团队及时修正错误,从而导致相似问题重复发生。
选择Scrum的另一个原因是可以通过真实的使用场景来测试软件。微软认为Scrum在他们客户中最流行。
Sprint开始和结束时,团队都会发送邮件公告天下,再三强调跨团队的沟通。Sprint开始时的电子邮件概括了每个团队将要完成的故事,而完工邮件则包含了已完成功能的演示。
发布节奏
尽管TFS采用三周为周期的Sprint,发布可能仍旧保持四个月一次。这意味着每个发布都会非常庞大而且充满隐患。为了缩减每个发布的规模,他们曾尝试月度发布,但这又和Sprint的周期太接近了,最终他们决定合二为一,都是三周为一周期。
要这样做,就得防止等到维护期再去修复缺陷的思想死灰复燃。每三周Sprint之后,都会有一周的核实确认。它不是为了缺陷修复,而是为了确保任何无法运行的功能都必须被禁用或拿掉。核实确认的那一周通常和下一个Sprint的第一周并行进行。
测试
如果某个功能开发需要整整三周,也就是整个Sprint的时间,那么它同样会在Sprint发布时被禁用。在下一个Sprint中,测试人员将验证它,一旦完全通过则在部署时解禁。而那些只需要一两周就能实现的小功能则可以在单个Sprint中完成测试和发布。
所有测试都是自动的,并且滚动触发。现在跑完所有测试需要2到3个小时。由于测试周期比较长,所以签入的代码并不强制要求通过所有测试。取而代之的是,他们将TFS设置为只要求签入的代码可以顺利地被构建即可。下面是开发人员签入代码后收到的邮件的例子:
分支
TFS的网络版(the Service)和客户安装版(the Box)使用的是相同的基础代码。此外,大多数功能都是在主分支上进行开发的。只有区别显著的功能才会在另外的分支上开发。并且只有当这个功能完成后,在下一个Sprint开始的时候才会把分支合并回主干上。
Sprint结束时,代码会从主分支发布到产品库,也会每个季度更新一次分支。这些分支会继承上面提到的每日构建的版本号。
你可以在九频道 观看完整视频讲解。
译者 金毅 金毅,从事离岸开发中心筹建和管理工作。坚信以人为本,力争做一名实干家。关注敏捷实施和项目管理的实践。
相关厂商内容
《JavaScript语言精粹》作者Douglas Crockford确认参会
GitHub研发团队成员Corey Donoho QCon分享Github架构设计与团队合作
Google商用Apps创始人Derek Parham确认参加QCon北京2013
相关赞助商
QCon北京2013,Node专场:NodeJS如何在大企业应用落地发挥成效, 详情请点击!