探秘软件开发的另一极（1）

　　有人形象地将“瀑布式”开发与“敏捷开发”描述成为软件开发的两极。瀑布式开发从开发伊始就定义出软件架构，然后进行模块开发与组装。敏捷开发则根据细化的需求直接开发软件，并利用迭代方式逐渐组建出大的软件系统。

　　对于瀑布式开发，人们耳熟能详。但是对于敏捷开发这一极，可能所知甚少。日前，ThoughtWorks首席科学家Martin Fowler、ThoughtWorks中国公司总经理Sidney G.Pinney与中国计算机报高级副总编郭旭的一番对话将帮助你了解敏捷开发的奇妙世界。

　　敏捷开发与人

　　面对软件成败的关键因素是什么这一问题，在软件架构、开发方法与人三个因素中，Martin Fowler毫不犹豫地选择了人。那么敏捷开发与人是一个什么样的相互依存关系呢？

　　郭旭：您曾提到软件开发过程中人最重要。那么，相对于传统的开发方法而言，敏捷开发对于开发团队的人员有些什么特殊的要求？

　　Martin Fowler：目前为止，我们还没有相关验证表明什么样的人能在敏捷方法里面表现得更好。但是有一点值得注意，不管采用什么样的方法，人的素质与水平都会对项目造成至关重要的影响。

　　郭旭：传统的软件开发方法是将架构设计与程序开发分开的。架构设计往往需要具有较高造诣的架构师来实现，需要他对软件的整体结构非常熟悉，而程序开发可能只需要开发人员掌握编程语言就可以了，那么敏捷开发对开发人员的要求是怎样的呢？

　　Martin Fowler：首先软件的设计和编程这两件事情本来就是非常接近，很难区分开来。传统软件开发方法中一定要在这两者之间划分一条线，说这部分是设计，那部分是编程，造成的结果往往不是特别好，常常导致一些脱离实际的设计和脱离设计构想的编程实现，我们在很多项目中亲眼目睹了这些方面的实例。当一个架构师脱离编程实践很长时间之后，他做出来的架构设计往往变得不切实际，让程序员很难实现。

　　郭旭：对于一个企业的软件项目，其业务人员参与与否将决定着敏捷开发的成功与否吗？

　　Sidney G.Pinney：如果说业务部门能够参与到开发过程中与开发团队一起工作的话，敏捷方法将给予他们最大的参与机会。他们将能够在最短的时间内看到一个软件是如何由脑子里的想法变成草图，再变成程序，最后变成一个可以用的软件，看到整个系统如何由一小块一小块的功能组合起来变成一个大的应用程序，并享受这样一个乐趣，亲眼看到自己在业务上的需求如何变成一个实实在在的软件。

　　相反，如果业务人员不愿意参与到软件的开发过程中，那么敏捷开发是很难将一些好的开发方法贯彻进开发过程中的。我个人认为，如果业务人员对软件不感兴趣，不想跟开发人员沟通，不管通过什么样的软件开发方法都不可能得到很好的软件。

　　郭旭：在采用敏捷方法实施系统开发时，是否要求开发团队所有人在个人素质、编程能力上都有较高的水准？如果他们的水平高低不同是否会影响系统开发的效果？

　　Sidney G.Pinney：如果团队的成员都在一个水平上，并且是高水平上，当然是有它的好处。但是对于一个团队来讲，更多的情况是，团队中有一些人是比较资深的、高水平的，另外一些人则是水平较低、缺乏经验的。当这样两组人结合成一个团队进行项目开发时，首先应当是新手向高水平成员学习，这是毫无疑问的。但是，某种程度上高水平成员也需要向新手学习，因为新手的思想还处在一个新鲜的状态，脑子里不存在一些思维定式。他虽然可能不知道应该做哪些事情，但是可能会有非常新鲜的想法。人是开发过程中最重要的因素，在整个团队进行协作开发时，应当尽量让每个成员发挥出最大的能量。

　　谁更适合敏捷方法

　　作者：李琨

　　随着敏捷开发渐成气候，许多人提出了这样的疑问：敏捷开发是否适合自己的研发团队，适合自己的企业？

　　郭旭：事实上，目前使用敏捷开发的人依然是少数。既然是一个很好的方法，为什么没有被开发人员广泛采用呢？企业用户为何也甚少使用它？

　　Martin Fowler：敏捷开发仍然是一种比较新的方法。对于企业客户而言，要采用这种方法实施软件开发，就需要从事业务的人与实施开发的技术人员更加紧密地结合在一起工作，这将需要企业员工付出很大工作量，这种工作方式被接受也需要一个过程。所以即便有越来越多的人对敏捷开发很感兴趣，但是到目前为止也只是少数人在采用它。

　　郭旭：具体到应用，您觉得什么样的企业、什么样团队、什么样的项目更适合使用敏捷开发这种方法呢？

　　Sidney G.Pinney：实施敏捷开发会给企业带来很多影响与变化。一个好的企业应该是乐于接受变化的企业，愿意通过不断地改进软件来促进企业变化，并且能够从这种变化中感受到一种兴奋、快乐。也就是说，敏捷开发要求一个企业拥有适应变化的能力，它给企业带来的是拥抱变化的能力。因此，适合使用敏捷开发的企业，一定是一个愿意接受变化的企业。如果说企业更愿意看到自己的业务一万年不变，那么给它一个像敏捷开发这样灵活的方法没有意义。

　　郭旭：刚才说到在敏捷开发过程中人是最重要的因素，与传统的软件开发方法相比，知识库更多地是积累在开发人员的脑海中，而不是一堆需求分析、概要设计、详细设计、测试报告等文档。但是当一个项目结束以后，项目出现问题，或者需要重新进行软件变更与维护时，发觉对该项目有深刻了解的开发人员已经不能回来继续提供服务时，该怎么办？

　　Sidney G.Pinney：确实，在使用敏捷方法开发软件时，产生的文档非常少是毫无疑问的。因为我们用技术的手段把更多的知识固化在这个项目中。后来者可以通过阅读代码或者是察看项目本身了解到项目的很多知识。而对于那些不能在代码中体现出来的知识，我们会采用交流方式记录这些知识。在ThoughtWorks的标准工作方法中，有一个专门业务流程用来记录相应文档，帮助客户保留关键文档。而这些文档也往往是客户真正需要的。

　　为什么说这些文档是客户真正需要的呢？因为这些都是开发团队在实施开发过程遇到的真正难题，由于当时不明白，才记录下来。团队已经掌握的知识只须固化在项目内就可以，而不明白的部分可能是接下来接手项目的人同样不明白的地方。在传统的软件开发过程中留下来的例如详细设计等文档，从知识上来讲，对于许多人来讲往往是多余的。与此相对，敏捷方法留下的文档几乎是没冗余的。

　　敏捷开发如何前进

　　至今，仍然只有少部分人在使用敏捷开发。敏捷开发应当如何发展并寻找到自己的商业价值呢？

　　郭旭：敏捷开发方法解决了软件的适应性问题，但是我们知道软件工程里软件的可复用性也是很关键的。请问Martin Fowler先生，软件的适应性和软件的可复用性哪个更重要呢？

　　Martin Fowler：应当说软件的可复用必须建立在软件是可用的基础上，软件首先要解决可用性问题，可复用性对软件本身提出了更高的要求，更多的软件是不具备可复用能力的。

　　郭旭：软件的可复用性与适用性解决的是否是不同领域的问题？

　　Martin Fowler:这两者相对独立，并具备太多的可比性。敏捷方法不但能解决软件的适应性，同样也能实现软件的可复用性。

　　现在有很多人也用敏捷的方法开发可复用的软件，比如一些Java框架也是采用敏捷方法开发的，具有很强的可复用性，而且很多开源软件也采用了大量的敏捷实践，虽然他们并没有明确提出采用哪种方法，但是其开发特征具有敏捷的特征。

　　郭旭:如果在项目开发过程中，ThoughtWorks帮助客户学会敏捷开发的方法，客户将不再需要ThoughtWorks，似乎ThoughtWorks的商业价值也就此中止。相反如果不教会客户，将导致这样一种情况的出现，客户只要有一点业务变化或需求，就需要不断地寻求ThoughtWorks的帮助，让ThoughtWorks将该客户绑定，持久实现商业价值。在实际项目运作中，ThoughtWorks是如何实现自身商业价值的？

　　Sidney G.Pinney：我们最希望的工作方式是进入这个项目和客户团队一起工作，开发出客户需要的头一两个版本，与此同时提高客户团队的开发能力，让他们能够有能力把后续的开发继续进行下去，然后我们将离开并寻找下一个项目。因为对于ThoughtWorks人来讲，更喜欢去接受新的业务、新的技术、新的挑战。

　　因此，我们不太喜欢在一个项目上停留非常长的时间，这会让我们感觉有些缺乏挑战。所以我们更愿意这样做，就是与客户团队共同工作一段时间，教会客户团队敏捷开发方法，以后选择离开这个项目。ThoughtWorks的商业价值不是在于给客户做持续不断的系统维护，而是在于教会越来越多的人如何去采用敏捷开发，带给他们敏捷开发的价值。(n101)

　　作者：李琨