所在位置:UML新闻 - 内容 论坛精华    
Robert C. Martin谈论.NET开发者如何敏捷
Kathleen Richards

[2006/8/15]

大公司对敏捷的接受现在是一个上升的势头。Robert C. Martin和他的儿子Micah Martin合写了一本新书,介绍敏捷实践在.Net环境中的应用,高级编辑Kathleen Richards和Robert C. Martin就新书Agile Principles, Patterns and Practices in C# 进行了谈话。Robert C. Martin是敏捷宣言的17位发起人之一,另外还撰写或参与撰写了以下图书:
*Agile Software Development: Principles, Patterns
*Practices; UML for Java Programmers;
*Designing Object-Oriented C++ Applications Using the Booch Method.

ADT: 很多人对敏捷软件开发的定义都不是很严格,你的定义是什么呢?

Martin: 敏捷的定义在宣言里面提到了啊,这么说的:
*人和交互重于过程和工具。
*可以工作的软件重于求全责备的文档。
*客户合作重于合同谈判。
*随时应对变化重于循规蹈矩。
我加一条,敏捷开发就是指在很短的时间周期内开发,有时候在一个月之内,可能超过一周的时间内,根据大量的反馈不断改进。至少每周左右时间内都会从软件使用者以及自动化测试返回这些反馈。

ADT: 你的书关注的是C#和.NET开发,那么其中所说的是只对Microsoft Visual C#有用呢,还是可以用于各种情况?

Martin: 书只是用C#来作示例语言而已,它对各种情况都是有用的,讨论的是通用的软件开发。

ADT: 敏捷方法学将怎样改变一个编程团队及其成员的日常工作?

Martin: 采用敏捷开发,一个.NET编程团队将会关注于很短期限内的可交付的目标,一到两周之后就可以运转的工作产品。他们会关注于代码覆盖率很高(大概会占80%到90%多)的测试编写,他们会致力于创造商业价值(business value)。 他们会希望定期地向他们的业务涉众做demo,他们会乐于接受变化。

ADT: 你的合作作者Micah Martin在介绍中提到,敏捷的.NET开发者过去几乎没听说过,你是否同意这个说法?为啥会出现这种情况呢?

Martin: 我觉得这是一两年前的情况了。现在有很多公司同时在使用.NET和敏捷方法,部分也得益于微软对敏捷方法的兴趣日增,部分我觉得是因为这种行业走向敏捷的总体趋势,不管你用什么平台。
微软雇了一些敏捷专家,甚至包括了敏捷开发之父(敏捷开发有一堆父亲:D)中的一个:Ward Cunningham。Visual Studio也开始支持一些重构和测试的功能。

ADT: 尽管大部分的敏捷讨论的是关于协作和对变化的响应,是否有些元素还是非常重要,需要预先设计的呢?

Martin: 对很小的团队而言,很少有东西是需要预先确定下来的,团队在开发过程中会知道他们当时的决策。对一个长得多的项目而言,有些很基础的架构决策需要预先确定下来,就是一些非常基本的架构设计,例如“我们要用什么数据库?”

ADT: 极限编程和Scrum是最常见的敏捷过程,后者是不是更易于入手一些?

Martin: 很多人确实是先Scrum,后极限编程的。后者是对敏捷方法的最好定义,其中包含了最多的规范(discipline),涵盖了从业务到团队到技术的各种实践,而Scrum这种方法主要关注在管理实践上,对技术和团队的实践关注较少。如果你从Scrum开始的话,可以比较容易地转到敏捷编程上,采用一些更技术的实践。
但谈论这些现在意义并不大,通常而言一个敏捷团队具有敏捷编程的一些特性,一些Scurm的特性,而且几乎没有哪个团队是同时包含这两种过程的所有实践的。因此我不会说这是一个选择哪一个的问题,只是稍微偏向哪个一些。

ADT: 这些敏捷方法—重构、结对编程、测试驱动开发(TDD)— 如何最好地应用在.NET 环境中?

Martin: 这和.NET环境实在没有什么特别的,做TDD的工具并不是固定哪一个,现在.NET框架中也有支持TDD的工具。在.NET环境中结对编程也不是什么问题。重构的工具支持现在没有Java的那些好,但也相当不错拉。另外还有一些第三方的重构工具,Visual Studio在这方面也在改进。

ADT: 为什么.NET 社区对敏捷开发过程的接受要慢一些呢?

Martin: 微软的使用者社区是有一些岛国意识的。具体说吧,如果你是一个微软技术开发者,你可能并不了解微软技术之外的技术发展情况,而非微软的技术使用者可能会了解不少微软技术的走向。因此我们发现微软技术社区在一些新的方法上和整个行业相比是有一些滞后的,现在微软在扮演一个追赶者的角色。

ADT: 当计划、需求和编写文档不再是过程中的一大块,很多人会很紧张的,如何安抚他们的这种恐慌啊?

Martin: 关于这些项目中不写文档的说法是荒诞的。文档和计划当然要做,不过他们不再是过程的一部分,而是过程中的一个任务。在敏捷项目中,会有很多任务,有些任务会包含文档化、项目计划等这些管理团队需要做的规范操作。但它们不再是过程的一部分,这句话的意思是说,它们的秩序不是固定的,我们不是一定要先写文档,也不是一定最后写文档,我们在写文档这个工作变得重要的时候来做它,它会和其它任务一样在日程中进行安排。

ADT: 敏捷方法在大公司中的应用如何?小公司使用敏捷方法的较多,但大公司好像还很少啊。

Martin: 越来越多的大公司也在走向敏捷,有一些已经明确地要采纳敏捷方法了。我们发现最好的方法就是自下而上,开发团队自己以团队(而不是角色)为单位进行训练和指导,管理层为此提供支持。大概3到5个月的时间,团队就可以转到敏捷开发上来,具体时间要看组织的规模了。

ADT: 什么情况下敏捷不是一个好的办法?

Martin: 在项目不应该敏捷的时候,确实有一些公司的文化是和敏捷相背的。非常重型的命令控制型的文化,可能对敏捷开发的回应不会太好。

ADT: 你认为,.NET开发者要考虑敏捷开发,什么是最重要的?

Martin: 对.NET开发者而言,在学习敏捷开发的过程中最大的挑战就是测试驱动开发。敏捷开发对单元测试和自动化接受测试的要求很高。TDD现在已经被全行业所接受了,就算你是微软,也是一样的。

(自adtmag,袁峰 摘译,不得转载用于商业用途)