原文：http://www.cnblogs.com/me-sa/archive/2008/01/14/1037910.html
无章法，繁重，敏捷
多数的软件开发都是一个混乱无序的活动，常常就简单的划分成“CODE&FIX”两个阶段，这就是它的特点。软件的编写没有一个指导性的计划，系统的设计是由一系列短期的决定构成的。当系统规模小的时候这个方法还真的表现不错，但是随着系统规模变大新功能的开发日益艰难。雪上加霜的是这时BUG也无处不在而且难以修改；这种系统的典型特征就是在 做到"feature complete" 之后将有一个漫长的测试阶段，这个阶段将把时间计划完全打乱，因为测试和调试的时间难以预计；
解决上述问题，这就是引入软件过程方法论的初衷。方法论将一些严格的过程应用到软件开发活动，目的就是提高软件开发的可预见性和效率；他们是怎么做的呢？他们把其他工程学的原理引入进来强调计划的重要性，通过一个详细的计划来解决问题。因此这时的方法又称计划驱动的方法。
工程方法学存在了很长时间，但是并没有取得显著的成功。它们甚至没有流传开，最为人诟病的是它太官僚主义了。采用该方法要照顾太多的琐碎的事情，这让整个开发节奏慢了下来。
背负着力挽狂澜的期望，“敏捷方法”应时而生。对于大多数人来讲，敏捷方法最大的吸引力就是它能解决工程方法论的官僚主义问题。 这个方法论试图给出一个介于“无过程”和“过度过程”之间的折衷方案，使用一个适中的过程来获得合理的收益（成本和收益的一个平衡）。
之所以能做到这一点，是因为敏捷方法与之前工程方法论强调的那些观点有着显著的不同。最直接的不同点就是 它不是文档驱动的，通常对于给定的任务只需要较少的文档就可以了。它倒是有点像是代码驱动的，遵循着一个规则就是把源代码作为文档的一部分。但我不认为这是敏捷开发的关键，文档的精简只是一个表象，背后有两个深层次的原因：
可预见性VS适应性 - 泾渭分明的设计与实施
软件过程通常引入的方法论原则是源于土木工程学或者机械工程学。而这些原则强调建造之前的计划。工程师会提供一系列的图纸精确的描述要建造什么已经怎么把建造的东西进行组合。许多设计上的决定，比如桥梁负载，在设计图纸的时候就已经确定了。之后图纸移交给另外一个小组甚至是另外一个公司来施工。整个的实施工程是严格按照图纸进行的。实施过程中会遇到一些问题，但多数是无关痛痒的小问题。
由于图纸已经明确说明了各个小块的内容以及怎么组合，它们的功能就像是一个细化的实施方案，它指出要做完成什么任务，以及这些任务之间的依赖关系。这就可以进行进度预计和工程预算。图纸甚至包括人们具体怎么实施工程，这样实施工程的一方不需要太智能，尽管他们往往技术高超。
所以我们这里看到的是两个截然不同的活动。设计很难做出预计，需要大量的有创造性的人参与，而实施是很容易预计的。一旦完成了设计就可以制定实施计划，有了计划我们就可以对实施过程进行预计和控制。在土木工程中，实施比设计和计划的成本消耗时间消耗都要大。
脱胎于上述理论的软件工程学方法论也就变成了这样：我们需要一个可预见的计划，用技能比较低的人就可以完成它。要做到这一点我们就必须把设计和实施分离开，因此一个出现了：我们必须知道怎样做软件设计才能让实施工作在设计之后一马平川的进行下去。
这个计划是什么样的呢？很多时候它的角色就是UML中的设计符号。如果我们可以使用UML来做所有的重要的决定，我们就可以构建出来一个实施计划并把这个计划移交给开发组进行编码。但这个有一个关键问题，你能用设计把编码变成一个可预见的实施活动么？如果可以的话，消耗的成本是在一个可接受的范围内么？
这些引出来一些新问题，首先怎样把UML式的设计转化到程序员可以接受的状态。 UML式的设计有一个特点就是纸上看起来很不错，但是到编码实践的时候严重的错误就会凸显出来。
土木工程学的模型都是基于多年工程的实践总结，佐之以强制执行，加之精确的数学分析。而UML式的设计只能依赖同事评审，这样就造成一些错误只有在编码和测试阶段才浮出水面。甚至对于一些高水平的设计人员也会认为把设计变成软件是一件很神奇的事情。
另外一个问题就是平衡支出，建一座桥的设计费用大约是总支出的10%，剩下的实施费用。在软件开发中编码占用的时间远远小于这个比例； McConnell 指出对于一个大型的项目只有15%的时间来做编码和单元测试，这几乎和建桥的比例完全相反的。即使你把测试也作为实施的一部分设计依然保持50%的比例。这就点出了软件开发中的设计与它在其它工程学分支中的角色迥异不同！
这些问题让 Jack Reeves甚至得出这样的结论： 事实上源代码就是设计文档而实施阶段就是使用编译器和连接器。当然这时所有的实施阶段就可以完全可以也应该自动化完成。这种看法可以得出下面的结论：
每一个我参加的项目我都会听到这样的小插曲，开发人员告诉我“项目最大的问题就是需求总是变化”，让我感到惊异的是任何人对此都表示不适应； 在开发商业软件的过程中，变更是正常的，问题是我们如何面对它。
一种方式是把需求变更的原因归结为糟糕的需求分析。这种观点的隐含意思是需求分析要在编码开始之前对需求有一个全面的理解，然后用户签字，签字之后启动开发过程并尽量不做变更。这里有一个问题那就是充分理解需求是很难的一件事情，而无法对需求的成本进行评估是这件事情更加难上加难。比如你要给你的车添加一个遮阳篷，而销售人员无法告诉你要添加10美元还是100美元。不知道花多少钱你怎么判断是不是要买？
众多因素导致估计很难做到， 因素之一是软件开发是一个设计活动难以计划和估计；因素之二：基本资源一直变化难以估计；因素之三：估计取决于过程中的人，人是很难进行预计和量化分析的。
软件是没有物质实体的，在它没有做出来之前你很难看到它的位置。直到你用的时候你才知道那些功能点是有价值的哪些是没有价值的。这就要求人们应该认为软件需求是可以变化的，软件就是应该是“软”的。需求不仅仅是可变，而且是应该变；花费大量精力来跟客户确定需求，特别是客户也曾经涉足软件开发那就更糟了，因为他们知道软件变一下很容易；
即使能得到一个精确的稳定的需求，你依然难逃厄运。今天的经济形势就决定了软件的内容快速变化。今天的好需求，六个月之后就可能一文不值；即使需求不断的改进也是跟不上经济发展的步伐；经济是无法预言的，否定这个观点的人要么是撒谎要么是有足够的实力可以左右市场； 软件开发中的其他事情都取决于需求，你得不到一个稳定的需求，你也得不到一个可预见的计划。
可预见性不可能做到吗?
总体上讲，不是的；有些软件开发是可以做到可预见的。像NASA太空穿梭机软件开发就是软件可预见性的样板。这个需要大量环节，大量时间，一个大型的团队，一个稳定的需求。但是我不认为多数的商业软件和太空穿梭机软件属于统一范畴。所以需要有一个不同的开发过程。
存在一个危险就是做不到可预言的时候“做可预言状”；研究方法论的人不善于识别边界条件：在那个点上方法从合适变成不合适；绝大多数的方法论者都希望自己的理论放之四海皆准，所以他们也不愿意公开这个边界。这就导致了方法论误用的事情，比如把可预见的方法用在了不可预见的环境中。
那样做是很有诱惑性的； 可预见性是令人向往的，当你明明知其不可为而为之的时候，这就会导致人们早早的做了计划，之后局面慢慢失控；你发现计划与现实相去甚远，你可以在一个较长的时间内依然装作计划是有效的；但有时候两者过于不符，就不能视而不见了，失败总是痛苦的。
所以如果你在一个不可预见的环境中就不要使用可预见的方法论。那需要多个项目控制模型，多个客户关系模型，这最终还解决不了问题，真的很残酷。 可预见性很美好，但是太难实践了。就像大多数问题一样，最重要的是意识到问题的存在！
不依赖可预见性并不是说你要应付一堆不可控的、混乱的事情。相反你需要一个过程可以应对不可预见性。这就是适应性所关心的。
控制不可预见的过程
无章法，繁重，敏捷
多数的软件开发都是一个混乱无序的活动，常常就简单的划分成“CODE&FIX”两个阶段，这就是它的特点。软件的编写没有一个指导性的计划，系统的设计是由一系列短期的决定构成的。当系统规模小的时候这个方法还真的表现不错，但是随着系统规模变大新功能的开发日益艰难。雪上加霜的是这时BUG也无处不在而且难以修改；这种系统的典型特征就是在 做到"feature complete" 之后将有一个漫长的测试阶段，这个阶段将把时间计划完全打乱，因为测试和调试的时间难以预计；
解决上述问题，这就是引入软件过程方法论的初衷。方法论将一些严格的过程应用到软件开发活动，目的就是提高软件开发的可预见性和效率；他们是怎么做的呢？他们把其他工程学的原理引入进来强调计划的重要性，通过一个详细的计划来解决问题。因此这时的方法又称计划驱动的方法。
工程方法学存在了很长时间，但是并没有取得显著的成功。它们甚至没有流传开，最为人诟病的是它太官僚主义了。采用该方法要照顾太多的琐碎的事情，这让整个开发节奏慢了下来。
背负着力挽狂澜的期望，“敏捷方法”应时而生。对于大多数人来讲，敏捷方法最大的吸引力就是它能解决工程方法论的官僚主义问题。 这个方法论试图给出一个介于“无过程”和“过度过程”之间的折衷方案，使用一个适中的过程来获得合理的收益（成本和收益的一个平衡）。
之所以能做到这一点，是因为敏捷方法与之前工程方法论强调的那些观点有着显著的不同。最直接的不同点就是 它不是文档驱动的，通常对于给定的任务只需要较少的文档就可以了。它倒是有点像是代码驱动的，遵循着一个规则就是把源代码作为文档的一部分。但我不认为这是敏捷开发的关键，文档的精简只是一个表象，背后有两个深层次的原因：
- 敏捷方法是适应性的，而不是可预见性的；工程方法论尝试用较长的时间把软件开发的绝大部分做到计划里面，在事情没有变化的时候这个方法表现不错。所以本质上它是拒绝变化的，而敏捷方法恰恰是欢迎变化的，它强调在变化中适应和成长.
- 敏捷方法是以人为本的而不强调过程的重要性。工程学方法论是想定义一个放之四海皆准的过程，无论谁用都可以。敏捷方法断言没有什么过程会提高开发团队的技能，过程的角色就是在开发团队的工作中提供支持。
可预见性VS适应性 - 泾渭分明的设计与实施
软件过程通常引入的方法论原则是源于土木工程学或者机械工程学。而这些原则强调建造之前的计划。工程师会提供一系列的图纸精确的描述要建造什么已经怎么把建造的东西进行组合。许多设计上的决定，比如桥梁负载，在设计图纸的时候就已经确定了。之后图纸移交给另外一个小组甚至是另外一个公司来施工。整个的实施工程是严格按照图纸进行的。实施过程中会遇到一些问题，但多数是无关痛痒的小问题。
由于图纸已经明确说明了各个小块的内容以及怎么组合，它们的功能就像是一个细化的实施方案，它指出要做完成什么任务，以及这些任务之间的依赖关系。这就可以进行进度预计和工程预算。图纸甚至包括人们具体怎么实施工程，这样实施工程的一方不需要太智能，尽管他们往往技术高超。
所以我们这里看到的是两个截然不同的活动。设计很难做出预计，需要大量的有创造性的人参与，而实施是很容易预计的。一旦完成了设计就可以制定实施计划，有了计划我们就可以对实施过程进行预计和控制。在土木工程中，实施比设计和计划的成本消耗时间消耗都要大。
脱胎于上述理论的软件工程学方法论也就变成了这样：我们需要一个可预见的计划，用技能比较低的人就可以完成它。要做到这一点我们就必须把设计和实施分离开，因此一个出现了：我们必须知道怎样做软件设计才能让实施工作在设计之后一马平川的进行下去。
这个计划是什么样的呢？很多时候它的角色就是UML中的设计符号。如果我们可以使用UML来做所有的重要的决定，我们就可以构建出来一个实施计划并把这个计划移交给开发组进行编码。但这个有一个关键问题，你能用设计把编码变成一个可预见的实施活动么？如果可以的话，消耗的成本是在一个可接受的范围内么？
这些引出来一些新问题，首先怎样把UML式的设计转化到程序员可以接受的状态。 UML式的设计有一个特点就是纸上看起来很不错，但是到编码实践的时候严重的错误就会凸显出来。
土木工程学的模型都是基于多年工程的实践总结，佐之以强制执行，加之精确的数学分析。而UML式的设计只能依赖同事评审，这样就造成一些错误只有在编码和测试阶段才浮出水面。甚至对于一些高水平的设计人员也会认为把设计变成软件是一件很神奇的事情。
另外一个问题就是平衡支出，建一座桥的设计费用大约是总支出的10%，剩下的实施费用。在软件开发中编码占用的时间远远小于这个比例； McConnell 指出对于一个大型的项目只有15%的时间来做编码和单元测试，这几乎和建桥的比例完全相反的。即使你把测试也作为实施的一部分设计依然保持50%的比例。这就点出了软件开发中的设计与它在其它工程学分支中的角色迥异不同！
这些问题让 Jack Reeves甚至得出这样的结论： 事实上源代码就是设计文档而实施阶段就是使用编译器和连接器。当然这时所有的实施阶段就可以完全可以也应该自动化完成。这种看法可以得出下面的结论：
- 软件开发中: 实施是很便宜的甚至是免费的
- 在软件开发中所有的努力都在设计上，因而需要有创造性和才华的人
- 创造性的过程很难计划，所以可预计性几乎是一个不可能完成的任务
- 我们要意识到软件工程学与传统工程学的区别，这是一个完全不同的活动，需要一不同的过程。
每一个我参加的项目我都会听到这样的小插曲，开发人员告诉我“项目最大的问题就是需求总是变化”，让我感到惊异的是任何人对此都表示不适应； 在开发商业软件的过程中，变更是正常的，问题是我们如何面对它。
一种方式是把需求变更的原因归结为糟糕的需求分析。这种观点的隐含意思是需求分析要在编码开始之前对需求有一个全面的理解，然后用户签字，签字之后启动开发过程并尽量不做变更。这里有一个问题那就是充分理解需求是很难的一件事情，而无法对需求的成本进行评估是这件事情更加难上加难。比如你要给你的车添加一个遮阳篷，而销售人员无法告诉你要添加10美元还是100美元。不知道花多少钱你怎么判断是不是要买？
众多因素导致估计很难做到， 因素之一是软件开发是一个设计活动难以计划和估计；因素之二：基本资源一直变化难以估计；因素之三：估计取决于过程中的人，人是很难进行预计和量化分析的。
软件是没有物质实体的，在它没有做出来之前你很难看到它的位置。直到你用的时候你才知道那些功能点是有价值的哪些是没有价值的。这就要求人们应该认为软件需求是可以变化的，软件就是应该是“软”的。需求不仅仅是可变，而且是应该变；花费大量精力来跟客户确定需求，特别是客户也曾经涉足软件开发那就更糟了，因为他们知道软件变一下很容易；
即使能得到一个精确的稳定的需求，你依然难逃厄运。今天的经济形势就决定了软件的内容快速变化。今天的好需求，六个月之后就可能一文不值；即使需求不断的改进也是跟不上经济发展的步伐；经济是无法预言的，否定这个观点的人要么是撒谎要么是有足够的实力可以左右市场； 软件开发中的其他事情都取决于需求，你得不到一个稳定的需求，你也得不到一个可预见的计划。
可预见性不可能做到吗?
总体上讲，不是的；有些软件开发是可以做到可预见的。像NASA太空穿梭机软件开发就是软件可预见性的样板。这个需要大量环节，大量时间，一个大型的团队，一个稳定的需求。但是我不认为多数的商业软件和太空穿梭机软件属于统一范畴。所以需要有一个不同的开发过程。
存在一个危险就是做不到可预言的时候“做可预言状”；研究方法论的人不善于识别边界条件：在那个点上方法从合适变成不合适；绝大多数的方法论者都希望自己的理论放之四海皆准，所以他们也不愿意公开这个边界。这就导致了方法论误用的事情，比如把可预见的方法用在了不可预见的环境中。
那样做是很有诱惑性的； 可预见性是令人向往的，当你明明知其不可为而为之的时候，这就会导致人们早早的做了计划，之后局面慢慢失控；你发现计划与现实相去甚远，你可以在一个较长的时间内依然装作计划是有效的；但有时候两者过于不符，就不能视而不见了，失败总是痛苦的。
所以如果你在一个不可预见的环境中就不要使用可预见的方法论。那需要多个项目控制模型，多个客户关系模型，这最终还解决不了问题，真的很残酷。 可预见性很美好，但是太难实践了。就像大多数问题一样，最重要的是意识到问题的存在！
不依赖可预见性并不是说你要应付一堆不可控的、混乱的事情。相反你需要一个过程可以应对不可预见性。这就是适应性所关心的。
控制不可预见的过程
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15027599/viewspace-557389/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/15027599/viewspace-557389/
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
