TFS团队的敏捷转变:向三周一个Sprint进军

标签: tfs 团队 周一 | 发表时间:2012-12-11 00:07 | 作者:
出处:http://pipes.yahoo.com/pipes/pipe.info?_id=10560380f804c7341f042a2b8a03e117

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

译者 金毅 金毅,从事离岸开发中心筹建和管理工作。坚信以人为本,力争做一名实干家。关注敏捷实施和项目管理的实践。

您可能也会喜欢

相关 [tfs 团队 周一] 推荐:

TFS团队的敏捷转变:向三周一个Sprint进军

- - InfoQ cn
Buck Hodges认为,过长的发布周期导致TFS(Team Foundation Server)团队养成了不良的开发习惯,然而光靠生搬硬套sprint来缩短发布周期是不够的,还需要配合其他一些软件计划和软件开发方面的改进. 起初,TFS要好几年才发布一次. 微软的Buck Hodges说,这曾让TFS的开发人员养成了不良的习惯.

云存储在C2C网站的实际应用—详解TFS

- Caleb - 云存储技术博客:光头老蒋(云存储技术,虚拟化,IP存储, 数据库容灾等)
分布式文件系统在电子交易网站中会有广泛的用途,例如淘宝网,现在的交易额已经超过了600亿/每天,这是一个什么概念,香港一天的消费品市场也就600亿,也就是说一个淘宝已经超过香港了,而要达到这么大的交易量,交易的商业是上百亿件的,这样对商品图片的访问量就会很大. 日常照片分享往往集中在几个有限的亲朋好友之间,访问量不会特别高,而淘宝网商铺中的商品照片,尤其是热门商品,图片的访问流量其实是非常大的.

团队

- Lorna - 坏脾气的小肥
我最近心情起落比较大,如果把时间线再拉长一点,则是去年多自负,今年多自责. 冷静下来的时候也会想,我能不能做得更好. 每一个团队都有它的长处,有它的短处,对于团队的缺陷首先要问自己几个问题:. 1、有没有激励大家全心全意地认同和投入这个项目. 2、有没有分工合理,使每个人认同和投入自己的任务. 3、他的缺陷是否可以通过工作指导、严格督促,在半年或一年时间里自我完善.

团队管理101招

- 狂之想 - C++博客-牵着老婆满街逛
转载自:http://www.iteer.net/modules/doc/article.php?storyid=1402. 无论你是新手还是资深管理人,对你而言,管理好团队都是重要且具激励性的挑战. 切记:每位成员都能为团队作出一些贡献. 谨慎地设定团队目标,且认真严肃地对待它们. 尽早决定何种形态的团队适合你的目标.

DBA团队的使命

- 2sin18 - Alibaba DBA Team
DBA团队的使命:提供高可用、高性能、可扩展的数据存储服务. 高可用:可用性是运维的根本,我们不管做什么事情,都要把可用性放在第一位. 高性能:对性能的关注是我们一直坚持、做的最好的一面,仍需要继续做到极致. 可扩展:也就是最适合的,易部署,可线形透明伸缩. 数据存储:不只是关注某个数据库本身,是基于对各种最先进的数据存储技术的精深理解,提供最专业的服务.

谈团队知识管理

- - 人月神话的BLOG
如果要谈学习型团队,那么团队知识管理就相当重要,团队知识管理介于企业知识管理和个人知识管理之间,核心是知识能够成为整个团队的资产,并为团队创造价值. 今年在团队知识管理上,重点就是按照cmmi的一些思路,形成指导书,规范流程,工具模板,培训教材,检查单的完整知识库积累. 明确各个岗位职责和分工边界,能够按着规范流程做事情,大量前期积累的知识库又能够帮助团队成员快速的学习和解决问题.

谈技术团队目标

- - Tim[后端技术]
技术主管新年想得最多的一件事必定是如何比上一年做得更好. 宏大的目标设定每个团队都会做,谈几个不引人注意的小问题. 见过一些技术团队将计划定义为“按时完成需求”,需求驱动并没有什么不对,但是研发工作仅考虑被动需求的话是很难做好. 之前完成的许多需求有什么共性. 经常出问题/bug/故障的项目/功能/模块是哪些.

团队沟通杂感

- - 人月神话的BLOG
随时随地的短时间的,快速迭代的培训和教练作用远远大于正规的系统培训. 系统性培训一个是针对性往往弱,另外一个就是对团队成员有较高的要求,即自我强烈的系统性学习欲望. 走动时管理目的是及时的发现各种问题和团队技能之欠缺点,有针对性的进行沟通和经验传递,这需要团队管理者有敏锐的洞察力,不能脱离到团队工作事务之外.

某种理想的团队

- - 博客园_知识库
  (这篇文字灵感缘起于昨天发的一条半开玩笑半自嘲的 微博,由于设置了IFTTT被同步到我的 Twitter上,又被欢乐地转发了很多,估计是触发了某种有趣的共鸣). 现在我招聘已经被逼成这样了:先发自己和团队成员的简历给候选人,看你有没有兴趣跟一群这样水准的人一起做事,然后我争取到“面试你的机会”.

敏捷团队工作流

- - IT瘾-dev
站会中的内容是每天工作的开始,也是对昨天工作的回顾. 一般会由团队的某位成员主持,这位主持人有责任让电子系统上的story卡片和看板上的保持一致. 站会上,大家依看板从右至左依次更新自己负责story的状态,如果遇到阻碍,应该在站会上及时提出,团队之中的成员如果能提供帮助,应该在站会之后,组织解决方案的讨论.