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 结束时，代码会从主分支发布到产品库，也会每个季度更新一次分支。这些分支会继承上面提到的每日构建的版本号。
你可以在九频道观看完整视频讲解。
评论