新方法学

发表于:2008-09-23来源:作者:点击数: 标签:
关键字:可预测型 适应型 适应型客户 迭代开发 开放源码 方法 在过去几年中, 敏捷 方法(agile methodologies)(也被称为轻量级方法,lightweight methodology)正在迅速升温。它能够有效的解决软件开发中的官僚作风,让大家的注意力重新集中在软件的秀丽
关键字:可预测型 适应型 适应型客户 迭代开发 开放源码 方法

      在过去几年中,敏捷方法(agile methodologies)(也被称为轻量级方法,lightweight methodology)正在迅速升温。它能够有效的解决软件开发中的官僚作风,让大家的注意力重新集中在软件的秀丽风景中。这篇文章展示了轻型方法产生的原因,当然不是讨论它们的重量,而是他们那符合自然规律和以人为先的特性。同时文章还给出了学习过程中的一些参考意见和一些影响你在轻型方法这条康庄大道上继续前进的因素。

      (译者注:agile methodology,agile在字典中的原意为敏捷的, 轻快的, 灵活的。但是我始终没有找到有比较权威的翻译,原先我打算根据它的另一个称谓;轻量级方法,将它翻译成轻型方法,但是在查资料中发现了管理学中也存在这个词同类词:Agile Manufacturing,翻译为敏捷制造,所以我也把这个词同样翻译成敏捷方法。如果读者觉得有更好的翻译,请mail给我。axing@linuxaid.com.cn)

      从无, 到纪念碑的, 到敏捷的
      可预测型 VS 适应型的
      设计和建构的分离
      需求的不可预测性
      可预测是无法做到的吗?
      控制一个不可预测的过程
      适应型客户
      人是第一位的
      同一的编程机器
      程序员--有责任感的专业人员
      面向过程的人员管理
      业务领导者的角色
      自适应型过程
      方法
      XP
      Cockburn的Crystal Family
      开放源码
      Highsmith的适应型软件开发
      SCRUM
      DSDM
      敏捷软件开发的宣言
      RUP是一个敏捷方法吗?
      其他资源
      你应该使用敏捷方法吗?

      从无, 到纪念碑的, 到敏捷的

      大多数的软件开发都是一个混乱、无序的过程, 人们将之戏称为“code and fix”。软件的开发毫无计划性可言,系统设计就是把许多短期决定揉在一起。这在小的系统中可以胜任,可随着系统的增长,往系统中加入新的功能就变成一件极端困难的事情。此外,bug越来越普遍,修正也越来越困难。 这样系统的一个典型现象是在系统完成之后会经历一个相当长的测试时期。测试和除错完全不可预见,如此之长的测试期严重破坏了开发进度。

      我们的这种开发软件的风格存在了很长的一段时间,但是我们也花了很长的时间来研究替代方案: 方法学。 方法学把严格规范的过程用于软件开发,使软件开发更具可预见性、更有效率。他们遵循规则,制定计划,细分过程来保证软件开发。

      这种方法学也经历了很长的发展时间。它们并不十分成功,也不致力于大众化。这些方法学的最时常发生的批评是官僚。为了遵循方法学的准则做的大量的无用功使得开发的步调缓慢。因此他们时常被称为重方法学(heavy methodologies), 或使用Jim Highsmith的话:丰碑般的方法学。 (译者注:段落小标题的丰碑由此而来)

      在这些方法学的带动下,近几年出现了一群新的方法学。在一段时间内,它们被称为轻量级方法(lightweight methodologies),但是现在普遍称之为敏捷方法。人们希望敏捷方法能够有效解决丰碑式方法的官僚问题。这些新的方法尝试着在毫无过程和太多过程之间找到一个有效的平衡点,只提供必要的过程以得到一个合理的结果。

      这样的结果是敏捷方法在某些方面和重量级方法有显著的不同。 最大的不同是敏捷方法不是文档驱动的, 通常一件给定的工作只需要很少的文档。在很多方面,它倒是以代码驱动的: 规则,最重要的文档是源代码。

      不过我不认为这是敏捷方法的重点所在。较少的文档只是两种方法之间更深层次的不同点的一个症状:

      1、敏捷方法是适应型的,而并非可预测型的。重方法倾向于为软件开发制定一个包容了大量细节、时间跨度极长的庞大计划,如果万事都不变,这个计划将会执行得非常好。所以它们必然要尽力阻止变化得发生。敏捷方法则不同,它拥抱变化。他们总是去适应变化,利用变化来发展,甚至改变自己。

      2、敏捷方法是以人为本而不是以过程为本的。他们建立起一种观念:工作应该能够发挥人的特性,而不是去限制它,强调软件开发过程应该是一个有趣的过程。

      在下列各段中,我将更详细地研究这些不同之处, 你能了解到一个发挥合适的、以人为本的方法是什么样的,它的优缺点。不论你是软件的开发者还是使用者,你都应该使用这种方法。

       可预测型 VS 适应型的

      设计和建构的分离

      方法学的灵感来自语工程学的工程规范,诸如土木工程和机械工程。这种规范强调在实际建造之间做充分的计划。这样工程师将会用一系列的图纸来精确描述该建造些什么,以及如何组织它们。同时,根据图纸作出许多设计决定,比如该如何处理一座桥的负荷。 设计好的图纸随即被移交到另一个团队,通常是一家不同的公司,让他们来负责构建。一般要假定构建程序要严格的遵循图纸。在实际中负责构建的人会遇到一些问题,但通常都是些小问题。

      因为图纸规定了各个模块是何如组装在一起的,这些模块在具体构建计划中扮演了一个基础的角色。这样的一个计划能够计算出需要哪些工作,各项工作之间的关系如何。这就需要考虑可预测的进度表和建造预算。同时图纸也详细地说明了哪些构建者应嘎如何完成他们的工作。这样,构建工作就不太需要那些智力型的工作者,只需要那些劳作型的工作者。

原文转自:http://www.ltesting.net