BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

潘正磊谈Visual Studio开发过程中的敏捷实践
录制于:

| 受访者 潘正磊 关注 0 他的粉丝 作者 霍泰稳 关注 1 他的粉丝 发布于 2009年12月31日 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。
40:39

个人简介 潘正磊女士是位于美国雷德蒙市的Visual Studio Business Applications团队的总经理。这个团队通过提供多种工具,使全球开发人员能便捷地在微软平台上搭建商业应用程序。她同时领导开发工具部门的中国研发团队,进行Visual Studio、Visual Studio Team System等产品和技术的全球研发工作。92年,她以软件开发员的身份加盟微软,参与Access、Visual InterDev等产品的开发。1998年至2006年间,她先后担任Visual Basic.NET开发经理、Visual Studio产品线开发总监、Visual Studio Team Architect产品总经理和Visual Basic产品总经理,为专业开发人员提供在.NET平台上最高效的开发工具,使数百万Visual Basic 6.0用户迁移到.NET平台。

   

1. 我了解到,Visual Studio整个研发过程中是非常好地实施了敏捷,取得了不错的效果。能不能请你介绍一下,在你们从传统的研发过程过渡到敏捷过程中,有没有经历什么一些比较好的故事?

我们实际上做敏捷转型也是因为之前有一些不太好的经历。微软在做Visual Studio 2005的时候,实际上可能延误了将近一年,而且因为各种质量问题,做完之后我们还要打一些补丁。所以作为一个开发人员来说,我认为Visual Studio 2005是一款初期做得比较失败的产品,虽然我们之后通过SP(Service Pack,补丁包)来完善它。这个产品做完之后,我们开了几次高层会议(讨论)我们怎么能够让我们下一个产品提高质量、准时发布。

当时,Visual Studio 2005的开发团队已经大约两千多人,让两千多人做同一款产品,并让这么多功能质量达标,相对来说是一个比较难的管理问题。我觉得Visual Studio 2008相对来说就,做得是非常成功的。从第一版Beta(公开测试版)开始,我们的用户反馈就非常好,他们觉得我们Beta 1的产品质量基本上可以达到我们之前的RTM(Release to Manufacturing,发布给生产厂商)的质量。

我们开发Visual Studio 2008的时候,就是我们整个大部门转型,采用敏捷开发的过程。那我来介绍一下当时我们是怎么做的。

第一,我们发现,如果从CLR(Common Language Runtime,公共运行时)、到Framework、到上面的Visual Studio这三层,同时有大改动的时候,这个是最难的。如果说CLR是我们的地基,Framework是我们的钢筋水泥,那Visual Studio就是我们上面盖的这个楼,三个东西一起改的时候,同时要建这个房子就比较困难。我们就采取了Framework有改动,但是它的基本(core)是不能改动的。如果你对我们.NET Framework比较熟悉,就知道2.0版本是最小的,然后3.0是加在它的上面延伸出来的,3.5又延伸。但它的核心的东西并没有太大的改动,我们就采用这么一个模式:我们给用户足够多的新功能和新功效。这样就保证Visual Studio建于它的基础之上,能够有非常稳定的地基。

在Visual Studio 2008中,实质上我们做了很多的工作。最大的功能就是LINQ (Language Integrated Query)功能,对编译器来说是一个非常、非常大的改动。对我们整个编译器结构的要求,和新加的功能,是很有挑战性的。当时最大的编译器当然是Visual Basic跟C#这两个编译器。我们先花了很多时间做了一个非常强大的prototype,并很早就把prototype给我们用户来反馈,帮助我们设计语言的性能,当时VB和C#都有这么一个prototype,而且我们很早让MVP使用。但是这个prototype最后有多少真正做到产品里面?非常少,不到10%。这就是我们从敏捷开发里面(借鉴的):先要以最快的方法明确用户的需求,一开始我们先是做了这个工作。从做prototype过程之中,我们还学到了什么是容易的,什么是难的。因为很多软件产品,可能一开始用来演示的80%的产品是非常快就可以做好的,但是接下来这20%的难点,可能需要你花80%的时间去做。

   

2. 最后一公里比较困难?

最后的一公里是非常困难的,尤其是在你的产品会被几百万人使用的时候,会有很多不同的场景,你在开始做演示的时候都不需要考虑到,但你最后把它做成一个产品的时候,是一定要把它做好的,否则你就需要打很多补丁。

我们在做prototype的过程中,第一,我们明确了用户的定义;第二,我们也对架构上面哪些地方是比较难的,那些地方需要花很多时间去思考才能把它做好,有一个非常深的理解。第三个好处就是,我们发现VB跟C#,虽然是由两个完全不同的code base组成的,但是在做LINQ的功能,有一些东西是可以分享的,所以从资源组合上面,我们在做完prototype之后,发现有一部分东西是两个小组可以做成一个模型。

   

3. 可以共享的。

虽然语言的表达方式完全不一样,它下面有一部分生成的东西是一样的,这样两个小组可以共享。在没有做prototype之前,我们这种设计是不可能实现的,做了prototype之后不管是用户定义、架构、分享,都有了更明确的思路。有了这个思路之后,我们再来做这个项目的规划就会比较清晰。比如,第一个里程碑我们需要做出来一个什么东西,而且我们考虑是两方面的:第一方面,是从用户的体验上面来说,哪一些语言的东西可以放进去了;另一方面,是从架构上来说,哪些最最基本的架构工作可以做好了,做完这个架构工作。在第二个里程碑,我们可以实现更多的用户体验;那另一方面,可能再去开展另外一些的架构工作,所以是这么一层一层做下来的。

   

4. 通过不同的迭代逐渐就完善这个产品?

所以Visual Studio 2008这产品我们做得非常成功,我们大概本来说是九月份要发行,基本上是十月份发行。对一个几千人的大团队,能够做这么大一个LINQ功能,而且我们跟其他的部门,像SQL Server有很多的合作关系,能够把这些都管理好,把产品做成,最后准时发布,这也是我们用了敏捷之后,一个比较大的成功案例。

另外一个比较成功的敏捷开发经验就是,我们试用了我们自己的产品。

微软内部有一个优良(传统),我们自己叫“Dog Food”,就是“吃狗粮”(指自己试用自己开发的软件)。我们在做2008的时候,就Dog Food了Team Foundation Server这个产品,每一个团队把他想做的东西,把用户的场景都放在这个大的服务器里面。作为微软的高层,在任何时候都可以把这些信息汇总,虽然不可能知道每一个项目做到多少,但可以从大面上知道哪些用户体验已经实现了,哪些用户体验还在做,从宏观上面,可以比较快(了解)。如果这个团队看上去这部分可能做得还差得比较远,那这个版本的这个功能我们就不做了,这种决策层上面的问题就比较容易解决。从一个50人的开发团队来说,你可以说有一些用户场景,这个版本是支持的,另一些用户场景,可能这个版本来不及做了,放到下一个版本去做,在这种决策的时候,你可以非常清晰地看到本来计划是什么,已经做到什么,而且场景我们都是要求有一个优先顺序的,按最重要的先做,不重要的相对晚做。

   

5. 这有包含一些敏捷的思想在里面吗?

对,这实际上都是包含敏捷的思想。因为敏捷里面最重要的一个思想就是backlog(代开发事项),你的产品都有一个backlog,有哪些东西要做的,然后有一个优先级,全部都要按优先级排序,哪一个是最重要的,哪一个是第二个,哪个是第三。

排完序之后,每个团队根据自己现有资源划一条线,觉得哪些场景是应该可以做好的,哪些场景是不能做的。划这条线之后,作为一个决策层,你同意不同意团队的观点?很多时候,我跟我团队交流,他给我一二三四五划了这些场景,我说不对,你划到线下面的这个,比方第十五个实际上是非常重要的,它应该放到第三个。我们这样改动后再看一遍,我现在同意你这个排序了。但是你这条线划得我可能不同意,因为你可能划到第十个,那我觉得说接下来的十一到十五也是非常重要的,如果这个版本没有这些功能在里面,我认为这个版本是卖不出去的。作为管理层我有这个决策权,这时团队可能跑回来跟你说,可是我只有这么多的人,资源不够,怎么办?这个时候两个非常重要的方法,第一个最简单的是加资源;第二是加时间,这也是一种资源;第三个比较难点,你要团队回去,把他每一个做的用户场景,更仔细地分析一下,每个用户场景后面都应该有一个cost information,这个场景做出来需要多少的资源。有的时候看到他这个用户场景(会发现),为什么这个用户场景需要这么多的资源,跟你想象中的是否有出入,作为一名懂技术的管理者应该有个差不多的概念。为什么这项资源花这么多,这是对还是不对,这个时候你要做一个深入分析,阐述这个场景里面具体要做一些什么东西,有些什么考虑,认为比较难的东西是什么,这样才能说明你为什么花了这么多时间和资源。

在讨论的过程中,很多时候你就会发现,他也许设计的场景太复杂了。我给你举个例子,我们做很多界面上东西,像“drag and drop”,我看到有一个用户场景,用户可以用undo、redo、cut、copy、paste,这个需要花这么多时间吗?后来发现他们设计的是一套非常完善的方案,第一,undo和redo可以是多层的;第二,两个界面之间切换之后还是可以实现的。比方用一个车,场景是我给你一辆自行车就可以了,他可能给我的是一辆非常非常优秀的奔驰,实际上是用不着的,这个资源实际上是比较浪费的,没必要做那么好,因为用户他不认为这个需要做这么好。这时候你要跟你的团队交流,我们不用做一辆奔驰轿车在这里,可能做一个最基本的就够了。反过来说他这场景是不能没有的,一定要有,但是足够好就可以了,那这个足够好的定义就需要管理层跟团队去反复研讨。我们常常说这是一个hard cut,这个东西我也觉得很好,但是从资源上面来说不够了,我们还是放到下一个版本,我把它砍掉之后,我知道我肯定会听到用户反馈的,但是从这个总体的宏观的管理角度来说,我是一定要做这个决策的。

   

6. 这都很好的融入了敏捷的思想在里面。

这里面都很好地融入了敏捷的思想,因为:第一,我们做完决策之后,就是像我刚才说的我们这个十到十五(条要做的),重新放在优先级列表里面。做完这一套东西之后,尤其是做Visual Studio,我们把很多想做的东西,做成一个可点击的PPT,像产品演示一样。实际上我们花的精力相对来说是比较少的,因为我们并没有真正去设计它下面怎么架构,它真正的用户界面是什么。但是它给了用户一个非常直观的可视性,这个产品大致可以这么操作。我们做出这么一套图形之后,把这套图形给我们的用户演示,包括我们MVP等等。给他们演示之后,他们说这方面很好,这个地方不好,我们就可以马上改进,不会花费很多资源,但是它把你的想法变成一个可视化的东西,否则你跟用户交流也是非常困难的。

   

7. 你已经形象地告诉他我要做这么一个东西。

对,所以在做这个产品之前,我们先把它变成一套可以看得见的东西。那用户就可以说,我喜欢这个,我不喜欢那个。这是非常容易做到的,而且是非常行之有效的方法。这里面要多次和用户反馈,我们一开始的优先级,最优先要做什么… … 用户反馈之后,我们拿它来作为我们的执行计划,把它分成一个一个里程碑.每个里程碑做完之后,我们再拿已经做好的东西跟用户去进行交流: 产品做到这个地方,你觉得还有什么地方(需要改进)。用户看到一个真正的产品时候,还会有很多想法,比如这个场景能不能实现?我可能说这个场景我现在没有时间做。他会说,你可不可以在这边加一个接口,你要加一个接口的话,那我就可以把我的东西嵌入在里面。这个相对来说可能是比较容易做到,而且又对这个产品的拓展性有好处,那么用户在我给他做成的基础上面能够加入他自己的东西,这些东西很多时候是跟我们的用户交流之后改进的。

   

8. 但是Visual Studio他的技术团队在自己实施敏捷的时候有没有遇到一些挑战?从传统的开发模型过渡到一个全新的开发模型,有没有遇到什么问题?

对于Visual Studio开发来说最常见的问题,可能与我们中国的客户并不完全一样,因为我们碰到的问题是跟我们团队人数有关系。中国的开发团队规模可能大多是50、100,200差不多就是上限了。我们的Visual Studio开发团队大约两三千人,就像军队管理一样,你管理50个人、100个人、500个人、1,000个人、2,000个人,协调的难度会非常不同。如何在2,000多人的团队,同时每一个小的团队差不多是50到100人,实行敏捷开发?在这个过程中,怎么样能够把所有的数据汇总起来?作为管理层,你可以很清晰地知道你这个团队到底做到什么程度了,什么地方是做得不错的,你可以放心的;什么地方是遇到了很大的困难,这个团队可能是一个非常重要的团队。比方说,如果是CLR 团队碰到了问题,那它的影响面是非常大的,因为我们所有的东西都构建在它之上。你怎么知道哪一个团队做到了什么程度,所碰到的困难是什么,采用些什么方法来补救,这些都是我们做得比较多的地方。从一个小的团队来说,也会碰到这种问题,但只是规模和扩展没有这么难就是了。

还有作为管理者,比方说一个50到100人的团队,你下面可能有7个、10个不同的功能组,在做不同的东西,你怎么知道每一个功能组实施到什么地方了,他做得好不好?功能组一般来说互相之间是关联的,有很多时候你去找一个功能组,也许他说我正在等前面那个人做完,我才能实施下面一步,那你对这种关联的理解是不是很清晰?这些是最常见的问题,实际上是Dependency Management(依赖关系管理)。我跟你解释一下,因为我们组太大了,很多东西需要CLR 团队先做,做完之后,要交给C# Compiler团队,再做下面一个功能,C# Compiler团队做完之后呢,我才能把它接过来,再做我下面的东西,这是非常常见的一个开发场景。这时候我们在做一开始prototype的时候,先需要定义几个大的里程碑,而且每个大的里程碑在你结束的时候,都要说清楚,哪一组跟哪一个组有哪一些可交付的,要做到这个里程碑里面的。在里程碑结束的时候,你可以非常快地一目了然,是不是每一个deliverable都已经做到了?如果有哪个deliverable没有做到的话,你可以很快的知道他下面的影响是什么。因为有时一个部分没完成,下面可能有一串的东西都没有办法做。我们很多这种数据的汇总都是在我们自己Team Foundation Server里面做的,我们用Team Foundation Server 的Reporting Feature把我们一开始把数据都放进去。这样的话就很明显可以看出来,虽然团队可能把这个deliverable做到了,但也许质量有问题,你怎么知道他这个东西的质量是不是合格?

   

9. 还是影响其他的?

对,有的时候他说“我做完了”,但是我根本就不能用,每跑一步都是有很多臭虫(bug)蹦出来,这也是很常见的问题。所以我们设计了一套比较严格的Quality Gates,你自己功能组做完之后,要通过所有测试程序,你才能把功能放到我们总的数据库里面。这套东西包括localization(本地化),因为我们的产品都有很多种语言版本,你localization有没有做过、测试过?像德文的字符串会非常的长,可能英文本来这么长的一句,变成德文就会长一倍,这时在你屏幕上显示,会不会有什么东西给砍掉,这种测试有没有做过?我们还有做代码覆盖率,你的代码覆盖率跟单元测试有没有写完,你的单元测试有没有写到50%、60%代码覆盖率,没有达到这个程度,我们是不允许你check-in(签入)的。另外你有没有测过新功能对原来的性能有没有任何影响,原来的性能,比方说应该是0.5秒就跑完的,你加了新功能之后,是否现在变成要0.7秒或者1秒才跑完?另外,你有没有做集成的测试,这些东西都是我们Quality Gates一部分。所以你做一个东西要把这些东西全部都满足了,才能让你允许你到软件包里面去。这样每进来一个东西,都是相对来说比较高质量的东西,这也是我们在Visual Studio 2005版本里学到的一个比较惨痛的教训,因为在做Visual Studio 2005的时候,我们并没有采用这种方法,所以很多程序做到一半,差不多可以演示了,我们就让它Check-in了。因此之后,我们花了很长很长时间使每一个功能真正达到高质量,但是这个性能已经放在产品里面去了,又很难把它再给拿出来,所以当时产品延期(的原因)跟这个有非常大的关系。我们现在改变做法,每一个功能组做的每一个功能,都要达到高性能,你才能把它集成进去,这样你等于是每一步每一步都是稳扎稳打。从一个产品的质量来说,基本上是我每一个产品放进去之后,如果不做其他的产品,再花几个月让它整个集成稳定一下,就应该可以把它发布的,到这样的程度才让你集成。这从敏捷开发来说,你可以很快地体现这个价值,这也是一个敏捷里面非常重要原则之一。

   

10. 也有人说在Visual Studio这个产品中去集成敏捷开发项目,完全是微软的一个应景之作。因为敏捷现在很热,在这个产品里面去集成敏捷可能更加好卖,因为微软可能没有完全理解敏捷的精髓,它里面有个原则:个体和交互胜过过程和工具。你对这个看法有没有什么自己的解释?

我给你讲个故事。我在微软Visual Studio做过一个职位──开发总监,开发总监这个职位实际上非常有趣的。怎么样让类似Visual Studio有几千人的开发团队能够互相协调、共同前进,是一个很关键的事情,因为你面对的对象是几千位工程师。比如,我们自己会推动很多不同的流程,你跟他们说,一个工程师没有遵循一个什么流程,把我们每天的Build给破坏了。今天你提出要遵守这个流程,过两天你说你要遵守那个流程,或者这边再加一步,在那边再加一步,在这个时候你会发现你可以给他们很多流程上面的规矩,你要做一二三四五,但是他们是记不住的,他们在做的同时他们有很多考虑。

   

11. 不是流程化的东西?

不是流程化的东西。我后来就发现,如果没有一个工具去帮助实现这些规矩的确话,你要靠每一个工程师都记住这些规矩,那是非常非常难的,基本上是不可能的。所以,我们就做了另外一套东西。在工程师把代码check-in之前,我们要求他做可能有六、七步不同的东西。而且我们常常又发现一个比较常见的问题,再加一个步骤,这个时候如果有上千,就算有几十个工程师,保证每一个人都记得有这么一回事情并做到,实际上是很难的事情,这是人员管理上面的一个难题,因为工程师有很多要考虑的东西。你要是真觉得什么规则是非常重要的话,就把它做到工具中,所以每个开发工程师,在check-in之前,要做code review,要跟对应的测试工程师做buddy test(伙伴测试),看看有没有问题,之后还要做unit test (单元测试), 跑一堆测试工程师的测试,把这些事情都做完,才能够check-in。我把这套东西全部变成了一套工具,然后就变得非常简单。比方说,谁帮你做code review了,你把那个人的名字放进去,测试工程师帮你做buddy test是谁,把他名字放进去,你的unit test,跟你下面的测试,以及后面的集成测试,我们用工具帮你跑了,跑完以后确实没有问题,就帮你自动check-in。全部做成工具化后,这套流程对工程师来说是非常简单的,如果单元测试要加新程序进去,我就把它做在工具里面,工程师也不用记,工具跑下来没有问题就可以帮工程师check-in,如果不行就打回来。所以,工具是起到一个辅助的作用,工具不能保证你什么样是最有效的,这需要团队的管理者跟团队一起去决定。工具不能帮你决定现在去北京还是去上海,还是去三亚,这个问题要团队自己解决。但是工具帮你最快实现目标。

因此我们自己运用了很多Agile方面的东西,试用我们自己开发的Team Foundation Server,所以我觉得我们对敏捷的理解是基于我们工具实施上的,并不是我们的应景之作,应该是用我们的教训,把它变成了一个工具,我们自己在用,也希望我们用户也能够使用。

   

12. 我也知道在Visual Studio新版2010里面,MSF 5.0,比从前有了很大的改进,能不能给我们简单的介绍一下,它主要的改进是在什么地方,特别在敏捷开发方面?

我们Visual Studio Team Foundation Server在2010版本里确实有非常大的改进。从最简单的来说,我们2005和08的Team Foundation Server,从一开始的Setup,把它这个安装起来,就是一个相对来说比较困难的事情。我们在这上面其实做了很多的投资,(把它变成)非常简单,就是下一步、下一步,帮你全部设置了。

从敏捷开发来说,我们很多的团队,尤其50、100人、200人的团队,他们下面肯定有些有关联的分支,我们在Team Foundation Server分支的管理上面,在2010也有非常大的提高。举个我们Visual Studio的例子,Visual Basic Compiler是一个分支,C# Compiler是一个分支,C++ Compiler又是一个分支,我团队在做的SharePoint Tools又是一个分支,Office Tools是另一个分支,这些都是不同的分支。这之间有很多关联,在Team Foundation Server 2010里面我们有一套可视化的东西,你可以知道每个分支是从哪一个分支上面延伸下来的,就像树一样。很多时候,你会知道哪一个check-in的东西可能会需要搬到另外一个分支上,可以让你非常简单易行地管理它。而且从敏捷开发上面来说,这里面有些非常重要的项目管理,包括burn-down chart,集成以前资源,资源里还有多少工作需要进行,我们在Excel上全部帮你实现了,帮你管理这些报表。同时,因为SQL Server是Team Foundation Server的数据库,你可以很容易用SQL Server的报表功能来生成你领导所需要的报表。

很多时候团队需要共享资源,在微软每天早上一个开发工程师进办公室后需要知道前一天晚上的build出来没有,在什么地方,有没有什么问题。你昨天晚上睡觉的时候,也许中国的测试团队,给你找到了很多的臭虫,又发现了什么问题。晚上集成build后,我们会运行一整套测试,测试里面又出现了什么问题,今天还有哪些本来要做的backlog任务、工程要做,这些东西你现在作为一个工程师,可能要去各个地方通过不同的工具来把它找到。在Visual Studio的Team Foundation Server里面,我们给你做了等于是一个门户,每一个工程师一上班,对所要的东西都一目了然,这是在我们SharePoint Server的基础上面做的。

我以前在做开发经理的时候,盯得最紧的,第一是还有哪些开发任务没有做,另一方面就是每天产生的臭虫。每一个人产生的臭虫,我都非常快地看一遍,这对开发管理人员来说非常重要,不是说我真的想知道这个臭虫应该怎么解决,我会很宏观地看一下,有个大致印象,这个产品里面哪个部分臭虫特别多,然后可能过了一星期发现,为什么我这一部分一个臭虫都没有看见,这可能是因为开发人员特别厉害,也有可能是这个测试人员特别差,或者协调中间忘了,测试人员根本就不知道有这么一个场景。作为管理者,你要有这种宏观概念,而且可以很快地生成一些报表,知道这个到底有没有问题。

如果你的开发团队比较大,几十人开发团队,一个开发人员比较好,做得又快又好,另一个开发人员可能改这个臭虫改得很快,但下个星期他改的臭虫里又生成很多臭虫,这是很常见的问题。虽然他臭虫改得很快,他生成速度也非常快,说明他改的过程中没有考虑周到,那你怎么能够知道这些开发人员到底在做多少事情。在敏捷开发里,你还要知道同样一个任务,给这个人和那个人,两者可能需要的时间是不一样的。怎样定义分配多少时间、监督每个人是否按时完成,你给他规定的时间是否准确。因为你第一个里程碑的时候可能定义不准确,也许这个任务对第一个人来说太简单了,你给他三天,他两天就做完了,那么下一次,有类似的任务,你给他两天就够了。对另外一个工程师,也许他觉得这个任务比较有挑战性,要花的时间相对比较长。这些数据你都要汇总之后,你才能做你下一个里程碑的规划。如果你不去考虑这些问题,你下一个规划做出来一定有很多的错误。敏捷开发另一个很重要的基本原则,你每做一个规划,每做一个迭代,都是一个学习的过程,你什么地方做的对,什么地方做的不对,你把这些经验再放到下一个迭代的规划里面去,这样你每一个里程碑都比上一个做得更好,更贴近你想做的,跟你实际做到的越来越吻合,这才是敏捷开发的精髓之一。这是一个逐步完善的过程,如果没有敏捷开发这个精髓,我跑上来,就把我下面五个里程碑全部给换了,中间要再调整其实是非常困难的。

   

13. 最后一个问题,对于那些想基于Visual Studio去实施敏捷的团队,比如50到100人的团队,能不能给出三到五条建议来?

第一,希望大家赶紧开始使用我们的Team Foundation Server,因为Team Foundation Server在2010版本中另一个很大的改进,就是对“跨平台”的支持。以前大家都认为它只适合用.NET或者C++的项目,我们在Team Foundation Server2010版本中大大提高了对“跨平台”的支持。Team Foundation Server实际上是开发了一个平台了,上面有很多Web Services,和API,有一个Teamprise公司就是用这些API另外做了一套客户端,可以在Mac上面跑,也可以在Linux、Unix上面跑,也可以集成在Eclipse里面。我们刚刚收购了Teamprise,(通过)这个公司,我们会进一步支持这种跨平台的模式。这样很多项目,用户常常会用Java做服务器端,用.NET做客户端。这时,如果你把两个项目分开管理,实际上不是一个最好的方式,现在我们给你Team Foundation Server,你可以在同一个服务器上把整个项目,不管你是用什么平台来做,都可以把它整合在这个服务器上。而且它和我们的Microsoft Project,也有非常好的集成,那就给管理者很大的便利。真正的大的50、100人团队到底在做什么,有哪些问题,哪些东西是你需要去关心解决的;哪个团队做得好,对项目最后的影响是什么;哪些用户的场景已经做出来了,现在开始跟用户的交流了,这些问题就会变得非常的一目了然,这是第一方面。

第二个方面,刚才说的工具,是给管理者提供的。但有了这个工具,并不等于取代了管理者的重要性,管理者还是主导的。你要建立一个高效的团队,团队成员之间,互相要有一种非常合作的(精神),要有同样的目标,大家都知道在做什么,工具只能帮助你进行这种交流,但是管理者的工作程度和难度并没有完全减轻。因为你每设计一个目标,需要团队的认可,让他们能够全心全意地、目标一致地前进,这种精神、这种力量,不是说哪个工具可以帮你做到的,还需要管理者实现这些事情。

最后,我们在用Team Foundation Server进行敏捷开发的时候,要时时刻刻记住敏捷最重要的精髓,不要让过程化的东西来妨碍我们的思维,不要把自己放在一个条条框框里面,敏捷一定要一二三四五。敏捷最最重要的是,根据不同的用户场景、需求,可以很灵活地调整实施方案。这个项目上用法成功了,并不等于说这套方法在另外一个项目上完全可以照搬的。你还要分开来考虑不同的因素,可能客户需求不一样,下面工程师的质量、长处各方面会不一样,因而实施方案会有不同。记住敏捷就是用最好的方法帮你来实现你的项目,它最主要的是跟用户有非常多的交流,帮助你的团队能够团结一致地、很快地朝一个非常明确的目标行进,这些才是敏捷的精髓。

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT