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结束时，代码会从主分支发布到产品库，也会每个季度更新一次分支。这些分支会继承上面提到的每日构建的版本号。

你可以在九频道 观看完整视频讲解。

查看英文原文： How TFS Embraced 3-Week Release Cycles

相关厂商内容

《JavaScript语言精粹》作者Douglas Crockford确认参会

GitHub研发团队成员Corey Donoho QCon分享Github架构设计与团队合作

Google商用Apps创始人Derek Parham确认参加QCon北京2013

相关赞助商

您可能也会喜欢